LANDP Version 6.0 Installation and Customization Manual

LANDP(R) Family
Installation and Customization

Version 6.0

Document Number GC34-6044-00

CT0ZLIE

Note

Before using this information and the product it supports, be sure to read the general information under Appendix H, Notices.

First Edition (February 2002)

This book is based on the previous edition, LANDP Family Installation and Customization Version 5.0, GC34-5530-00, which remains applicable and current for users of LANDP(R) Version 5.0.

This edition applies to LANDP Family Version 6 (Program number 5724-B16) and to all subsequent releases and modifications, until otherwise indicated in new editions. Make sure you are using the correct edition for the level of product.

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

At the back of this publication is a page titled "Sending your comments to IBM". If you want to make comments, but the methods described are not available to you, please address them to:


IBM United Kingdom Laboratories, User Technologies,
Mail Point 095, Hursley Park, Winchester, Hampshire, England, SO21 2JN.

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.

(C) Copyright International Business Machines Corporation 1992, 2002. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


Contents

  • Figures

  • Tables

  • About this book
  • Who should read this book
  • What you need to know
  • Conventions used in this book
  • DB2 Universal Database(R)
  • Windows
  • Linux
  • Related Information
  • Web site
  • Summary of Changes

  • Introduction

  • Introduction

  • Installation

  • Installing the LANDP family
  • Planning for installation
  • Location of the customization workstation
  • Software requirements for the customization workstation
  • Software migration and installation of other products with LANDP
  • System requirements
  • Operating system requirements
  • Other software requirements
  • Customization editor requirements
  • Storage requirements
  • Installing LANDP onto the customization workstation
  • Completing the LANDP for OS/2 installation
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Financial printer server
  • 4748 printer server
  • 4733 teller assist unit
  • Completing the LANDP for Windows installation
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Financial printer server
  • 4748 printer server
  • Completing the LANDP for Linux installation
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Financial printer server
  • Completing the LANDP for DOS installation
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Financial printer server
  • 4748 printer server
  • 4733 teller assist unit
  • NetBIOS support
  • X.25 Data Link control
  • User servers
  • Installing FBSI family and 47xx banking products
  • Online books

  • Customization

  • The customization process
  • LANDP customization - things you need to know
  • Customization data structure
  • Common data--COMMON.SPC
  • Workgroup configuration data--LANCONF.SPC
  • Model configuration data--MODELS.SPC
  • Customization directory structure
  • Techniques and considerations
  • Remote customization
  • Embedded specification files
  • Partial specification files
  • The customization steps
  • Creating common data default definitions--CREATE
  • Converting common data to editable .SPC files--GENSPEC
  • Validating customization data--VALSPEC
  • Editing customization vectors--EDITSPC
  • Migrating customization data from FBSS
  • The CREATE utility program
  • Starting the CREATE procedure
  • The GENSPEC utility program
  • Starting the generation procedure
  • Data in vector format
  • Preparation of customization data
  • Using a text editor
  • Using the EDITSPC utility
  • Using the graphical customization editor
  • Rules for specifying vectors
  • Vectors - a quick reference
  • Server requirements
  • Server information
  • The VALSPEC utility program
  • Selecting workgroup configurations
  • Examples
  • Return codes
  • Starting the validation procedure

  • Distribution

  • The GENRUN and GETGLOB utility programs
  • Selecting workgroup configurations
  • Examples
  • Return codes
  • Starting the run-time generation procedure--GENRUN
  • Starting the procedure for getting customization data--GETGLOB
  • Distributing software
  • Return codes
  • Starting the getting procedure--GETTING
  • Using the shared DOS directory server for distribution
  • Creating diskettes for the workstations--EHCDISTR
  • Distributing software to the workstations--GETDATA
  • Modifying file contents
  • Distributing software using a distribution server
  • Selecting workgroup configuration
  • Examples
  • Copying files onto the shared disk--EHCIMAGE
  • Copying the workstation files from the shared disk--EHCCINST
  • EHCCINST response files
  • Using response files to update CONFIG.SYS
  • Sample NetView DM change file profile

  • Preparing LANDP platforms

  • Preparing OS/2 workstations
  • Installing and configuring IBM OS/2 workstations
  • Installation requirements for NetBIOS transport protocol
  • Installation requirements for TCP/IP transport protocol
  • Using TCP/IP X.25 support
  • Installation requirements for mixed transport protocols
  • Installation requirements for workstations with SNA servers
  • Installation requirements to use the DC and QC functions
  • Installation requirements for cryptography management
  • Installation requirements for workstations with native X.25 servers
  • Installation requirements for workstations with PPC servers
  • Installation requirements for TCP/IP wide area communications server
  • Installation requirements for workstations with LANDP link servers
  • Installation requirements for workstations with MQSeries Link servers
  • Installation requirements for workstations with query servers
  • Installation requirements for workstations with Windows 3.1 support
  • Installation requirements for Java support
  • Modifying run-time files
  • CONFIG.SYS contents
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Virtual DOS machine relay (VDM)
  • Financial printer server
  • 4770 printer server
  • 4772 or 9068-S01 printer
  • 4748 printer server
  • 4733 teller assist unit
  • AUTOFBSS.CMD contents
  • Loading statements for LANDP for OS/2 servers
  • Banking printer program (BPP)
  • Batch machine loader server
  • Batch machine operator
  • CICS interface server
  • DDE access server
  • Electronic journal server
  • Forwarding server
  • LAN server
  • LANDP Internet Protocol
  • LANDP link server
  • Magnetic stripe reader/encoder server
  • MQSeries Link server
  • Native X.25 server
  • Object post box server
  • PIN pad server
  • Program-to-program communication server
  • Query server
  • Remote change management services
  • Searcher
  • Service Availability Manager
  • Shared-file distributor
  • Shared-file replicator
  • Shared-file server
  • SNA server
  • Store-for-forwarding server
  • Supervisor
  • System manager server
  • System manager operator
  • TCP/IP wide area communications server
  • Trace tools
  • Virtual DOS machine relay
  • Financial printer server
  • 4748 and 9068-D01 printer server
  • 4770 printer server
  • Loading statements for emulators in an OS/2 VDM
  • Banking interactive workstation program
  • 3270 emulator
  • 3287 printer emulator
  • Loading servers inline
  • Unloading LANDP for OS/2
  • Unloading LANDP for OS/2 servers
  • Installing run-time files
  • Preparing Windows workstations
  • Installing and configuring Windows workstations
  • Installation requirements for NetBIOS transport protocol
  • Installation requirements for TCP/IP transport protocol
  • Installation requirements for mixed transport protocols
  • Installation requirements for workstations with SNA servers
  • Installation requirements for TCP/IP wide area communications server
  • Installation requirements for workstations with LANDP link servers
  • Installation requirements for workstations with PPC servers
  • Installation requirements for workstations with MQSeries Link servers
  • Installation requirements for workstations with shared-file servers
  • Installation requirements for workstations with ODBC query servers
  • Installation requirements for Microsoft Visual Basic
  • Installation requirements for Java support
  • Running LANDP DOS applications on Windows
  • EHCVDSPV optional parameters
  • Loading EHCWINNT.DLL in LANDP for Windows
  • 16-bit Windows LANDP applications
  • Running LANDP for Windows servers as Windows Services
  • Modifying run-time files
  • Registry contents
  • AUTOFBSS.BAT contents
  • Automated unattended startup of LANDP
  • Loading statements for LANDP for Windows servers
  • Electronic journal server
  • Forwarding server
  • LAN server
  • LANDP Internet Protocol
  • LANDP link server
  • Magnetic stripe reader/encoder server
  • MQSeries Link server
  • PIN pad server
  • ODBC Query Server
  • Program-to-program communication server
  • Remote change management services
  • Searcher
  • Service Availability Manager
  • Shared-file server
  • SNA server
  • Store-for-forwarding server
  • Supervisor
  • System manager server
  • TCP/IP wide area communications server
  • Trace tools
  • Virtual DOS machine relay
  • Financial printer server
  • 4748 printer server
  • Loading statements for emulators in a Windows VDM
  • Banking interactive workstation program
  • Banking printer program
  • 3270 emulator
  • 3287 printer emulator
  • Unloading LANDP for Windows
  • Unloading LANDP for Windows servers
  • Installing run-time files
  • Preparing Linux workstations
  • Installing and configuring Linux workstations
  • Installation requirements for TCP/IP transport protocol
  • Installation requirements for TCP/IP wide area communications server
  • Installation requirements for workstations with LANDP link servers
  • Installation requirements for workstations with shared-file servers
  • Installation requirements for Java support
  • Linux workstation setup
  • LANDP User Accounts, Groups and Passwords
  • Installation Log and Error Logging
  • LANDP Environment Variables
  • Running the Setup Process
  • Ehcsetup command line options
  • Resolving Parameter Values
  • Removing LANDP Components
  • Running LANDP DOS applications on Linux
  • EHCVDSPV optional parameters
  • Loading libehclnx.so in LANDP for Linux
  • Restarting LANDP
  • Modifying run-time files
  • Contents of autofbss
  • Loading statements for LANDP for Linux servers
  • Electronic journal server
  • Forwarding server
  • LANDP Internet Protocol
  • LANDP link server
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • Service Availability Manager
  • Shared-file server
  • Store-for-forwarding server
  • Supervisor
  • System manager server
  • TCP/IP wide area communications server
  • Trace tools
  • Virtual DOS machine relay
  • Financial printer server
  • Unloading LANDP for Linux
  • Unloading LANDP for Linux servers
  • Installing run-time files
  • Preparing DOS workstations
  • Installing and configuring IBM DOS workstations
  • Installation requirements for NetBIOS transport protocol
  • NetBIOS resources
  • IBM LAN Support program
  • IBM LAN Client
  • Installation requirements for TCP/IP transport protocol
  • PC/TCP
  • IBM TCP/IP
  • Installation requirements for TCP/IP wide area communications server
  • SNA over TCP/IP dependent LUs
  • Installation requirements for TRDLC server
  • IBM LAN Support program
  • IBM LAN Client
  • TCP/IP and TRDLC
  • Modifying run-time files
  • Emulator considerations
  • Microsoft Windows 3.1 or 3.11 considerations
  • CONFIG.SYS contents
  • Magnetic stripe reader/encoder server
  • PIN pad server
  • TRDLC server
  • X.25 DLC server for IBM PC X.25 communications adapter
  • Financial printer server
  • 4748 printer server
  • 4733 teller assist unit
  • PROTOCOL.INI contents
  • AUTOFBSS.BAT and AUTOUSER.BAT contents
  • Printer manager server
  • Loading statements for LANDP for DOS servers
  • ASCII-EBCDIC translation server
  • Compression server
  • Electronic journal server
  • Forwarding server
  • LAN server
  • LANDP Internet Protocol
  • Local resource manager server
  • Magnetic stripe reader/encoder server
  • Native X.25 server
  • Operator interface
  • PIN pad server
  • Printer manager server
  • Remote change management services
  • Searcher
  • Shared DOS directory server
  • Shared-file server
  • SNA server
  • Store-for-forwarding server
  • Supervisor
  • Synchronous data link control server
  • System manager server
  • System manager operator
  • TCP/IP wide area communications server
  • Token-ring data link control server
  • Trace tools
  • X.25 DLC server for IBM PC X.25 communications adapter
  • X.25 DLC server for IBM X.25 interface co-processor/2 adapter
  • 3270 emulator
  • 3287 printer emulator
  • Financial printer server
  • 4748 printer server
  • Unloading LANDP for DOS
  • Unloading LANDP for DOS in Microsoft Windows 3.1 or 3.11
  • Using expanded memory
  • Software requirements
  • Rules for user servers in expanded memory
  • Using high memory
  • Installing run-time files

  • Utilities and Performance Tuning

  • Run-time utility programs
  • Communication variable data
  • Variable data record format
  • Updating communication configuration records
  • Workgroup variable parameters
  • Verification programs
  • Installing updated configuration files
  • Installing and validating system files
  • Migrating and generating customization data
  • Selecting workgroup configurations
  • Return codes
  • Migrating
  • Source data for migration
  • Starting the migration procedure--MIGRATE
  • Generating data
  • Starting the generation procedure--GENSPEC
  • Data in vector format
  • Listing customization data
  • Listing internal repository--LISTRTOC
  • Listing workgroup configurations--EHCLIST
  • Performance tuning
  • Tuning the shared-file server
  • Tuning the LANDP for OS/2 query server
  • Tuning the LANDP for Windows ODBC query server for DB2
  • Tuning the shared DOS directory services
  • Tuning Windows 3.1 under LANDP for DOS
  • System maintenance--VERSION
  • Using the VERSION utility program
  • Starting the VERSION utility program
  • Reading the output
  • Version Utility on Linux
  • Starting version on a LANDP for Linux workstation
  • Applying program fixes--APPLYFIX
  • About program fix files
  • Using the APPLYFIX utility program
  • Starting the process
  • Examples
  • Installing program fixes
  • Backing up and retrieving program files
  • Example LANDP Version 6 backup file names
  • Graphical Customization Editor
  • Tutorial Part 1: Editing workgroup parameters
  • Getting started
  • The main editor window
  • Adding a new workgroup
  • The button bar
  • Adding a new workstation
  • Adding a New Server
  • Adding and Editing Clients
  • Saving and Opening
  • Tutorial Part 2: Editing common parameters
  • Adding a new vector
  • Saving and Opening
  • Tutorial Part 3: Validating and distributing
  • Validation
  • Distribution
  • What to do next
  • The menus
  • Limitations
  • Help
  • Common problems
  • Reference
  • Clients
  • Common Vectors
  • Distribution
  • Files
  • Searching
  • Servers
  • Validation
  • Workgroups
  • Workgroup lists
  • Workstations
  • Some terms used in this chapter

  • Appendixes

  • Part 7. Appendixes, Glossary, and Bibliography

  • Appendix A. An example
  • Background
  • Step 1. Installing
  • Step 2. Creating common vectors
  • Step 3. Editing common vectors
  • Step 4. Validating common vectors
  • Step 5. Editing workgroup vectors
  • Workgroup configuration
  • Workstation configurations
  • Step 6. Validating workgroup vectors
  • Step 7. Obtaining software for distribution
  • Step 8. Distributing the software
  • Appendix B. User servers
  • User server vectors - descriptions
  • DEFSERV vector
  • A quick reference
  • DEVICE vector
  • A quick reference
  • DISTRIB vector
  • A quick reference
  • PARPORT vector
  • A quick reference
  • POSTLOAD vector
  • A quick reference
  • PREVLOAD vector
  • A quick reference
  • SVRREQS vector
  • A quick reference
  • User server examples
  • Appendix C. Editing common data
  • Creating and editing common vectors
  • Common vectors - an overview
  • Common vectors - descriptions
  • BPPPARM vector
  • A quick reference
  • BPPPARM vector example
  • COLSQTBL vector
  • A quick reference
  • COLSQTBL vector example
  • DEFAULTS vector
  • A quick reference
  • DEFAULTS vector example
  • DISPLATT vector
  • A quick reference
  • DISPLATT vector example
  • EJOUPRF vector
  • A quick reference
  • EJOUPRF vector example
  • EJOUREC vector
  • A quick reference
  • EJOUREC vector example
  • FORM4710 vector
  • A quick reference
  • FORM4710 vector example
  • FORM4720 vector
  • A quick reference
  • FORM4720 vector example
  • FORM47X2 vector
  • A quick reference
  • FORM47X2 vector example
  • FORM4748 vector
  • A quick reference
  • FORM4748 vector example
  • FORM4770 vector
  • A quick reference
  • FORM4770 vector example
  • FORWDS vector
  • A quick reference
  • FORWDS vector example
  • FORWPRF vector
  • A quick reference
  • FORWPRF vector example
  • KBD3270 vector
  • A quick reference
  • KBD3270 vector example
  • KBD3270X vector
  • A quick reference
  • KBD3270X vector example
  • KBDBIWP vector
  • A quick reference
  • KBDBIWP vector example
  • KSCCBIWP vector
  • A quick reference
  • KSCCBIWP vector example
  • KSTRBIWP vector
  • A quick reference
  • KSTRBIWP vector example
  • LUPOOL vector
  • A quick reference
  • LUPOOL vector example
  • MSRINTBL vector
  • A quick reference
  • MSRINTBL vector example
  • MSROUTBL vector
  • A quick reference
  • MSROUTBL vector example
  • P3287ATT vector
  • A quick reference
  • P3287ATT vector example
  • PINPTBL vector
  • A quick reference
  • PINPTBL vector example
  • RCMSLNF vector
  • A quick reference
  • RCMSLNF vector example
  • RECDEF vector
  • A quick reference
  • RECDEF vector example
  • RECFIELD vector
  • A quick reference
  • RECFIELD vector example
  • SFORWPRF vector
  • A quick reference
  • SFORWPRF vector example
  • SFORWREC vector
  • A quick reference
  • SFORWREC vector example
  • SHFLDBD vector
  • A quick reference
  • SHFLDBD vector examples
  • SHFLPCB vector
  • A quick reference
  • SHFLPCB vector examples
  • SHFLSGM vector
  • A quick reference
  • SHFLSGM vector examples
  • SMGRPRF vector
  • A quick reference
  • SMGRPRF vector example
  • SMGRUSER vector
  • A quick reference
  • SMGRUSER vector example
  • SOFTPACK vector
  • A quick reference
  • SOFTPACK vector example
  • XLATETBL vector
  • A quick reference
  • XLATETBL vector example
  • XLAT2TBL vector
  • A quick reference
  • XLAT2TBL vector example
  • X25DIR vector
  • A quick reference
  • X25DIR vector example
  • Appendix D. Editing configuration data
  • Creating and editing configuration vectors
  • Editing workgroup configuration data
  • Workgroup configuration vectors - descriptions
  • LANCONF vector
  • A quick reference
  • LANCONF vector examples
  • LWSCONF vector
  • A quick reference
  • LWSCONF vector examples
  • BIWP definitions
  • BIWP example
  • Banking printer program definitions
  • Banking printer program example
  • Batch machine loader server definitions
  • Batch machine loader server example
  • Device cluster attachment DLC definitions
  • Device cluster attachment DLC example
  • Electronic journal server definitions
  • Electronic journal server example
  • Forwarding server definitions
  • Forwarding server example
  • Java file distribution definitions
  • Java distribution example
  • LANDP link server definitions
  • LANDP link server example
  • Logical device address 7 program definitions
  • Logical device address 7 program example
  • MQSeries Link server definitions.
  • MQ server example
  • MSR/E server definitions
  • MSR/E server example
  • Native X.25 server definitions
  • Native X.25 server example
  • Object post box server definitions
  • Object post box server example
  • ODBC Query server definitions
  • ODBC query server example
  • PIN pad server definitions
  • PIN pad server example
  • Query server definitions
  • Query server example
  • RCMS definitions
  • RCMS example
  • Shared DOS directory services definitions
  • Shared DOS directory services example
  • Shared-file distributor definitions
  • Shared-file distributor example
  • Shared-file replicator definitions
  • Shared-file replicator example
  • Shared-file server definitions
  • Shared-file server example
  • Shared-file server example with XLR
  • SNA server definitions
  • SNA server examples
  • Store-for-forwarding server definitions
  • Store-for-forwarding server example
  • Synchronous data link control definitions
  • Synchronous data link control example
  • System manager operator definitions
  • System manager operator example
  • System manager server definitions
  • System manager server example
  • TCP/IP wide area communications server definitions
  • Example TCP/IP wide area communications server definitions
  • Example: EMU3270 server sessions to Telnet protocol
  • Example: PPC server session to MPTN (AnyNet) protocol
  • Example: SNA server session to MPTN (AnyNet) protocol
  • Example: Connection of incoming TCP/IP sessions
  • Example: PPC server to TCP/IP sockets
  • Example:PPC server over TCP/IP (MPTN)
  • Example: Emulator sessions to SNA over TCP/IP (TELNET)
  • Example: SNA server over TCP/IP (MPTN)
  • Token-ring data link control definitions
  • Token-ring data link control example
  • Virtual file support definitions
  • Virtual file support example
  • Virtual volume support definitions
  • Virtual volume support example
  • X.25 data link control definitions
  • X.25 data link control examples
  • 3270 emulator definitions
  • 3270 emulator example
  • 3287 printer emulator definitions
  • 3287 printer emulator example
  • Financial printer server definitions
  • Financial printer server example
  • IBM 4721 self-service document printer
  • IBM 4721 printer example
  • IBM 4731, 4738, 4739 personal banking machines
  • IBM 4731, 4738, 4739 PBM example
  • IBM 4733 teller assist unit
  • IBM 4733 teller assist unit example
  • IBM 4737 self-service transaction station
  • IBM 4737 station example
  • IBM 4748 printer server definitions
  • 4748 printer server example
  • IBM 4770 printer server definitions
  • 4770 printer server example
  • Editing model configuration data
  • Model configuration vectors - one by one
  • LANMODEL vector
  • A quick reference
  • LANMODEL vector example
  • WSMODEL vector
  • A quick reference
  • WSMODEL vector example
  • SVRMODEL vector
  • A quick reference
  • SVRMODEL vector example
  • Appendix E. Using TCP/IP for internal communication
  • LANDP Internet Protocol (LIP)
  • LIP workstation ID definition
  • TCP/IP verification
  • Unresolved workstation IDs
  • DHCP (Dynamic Host Configuration Protocol)
  • Port number
  • Workstation identification
  • Data interchange
  • Message segmentation
  • Session partner availability
  • Communication errors
  • Appendix F. Host communication definitions
  • ACF/NCP (Read by VTAM)
  • SNA/SDLC
  • SNA/X.25
  • SNA/TRDLC
  • SNA over TCP/IP dependent LUs
  • VTAM MODETAB
  • MODEENT for LU type 0
  • MODEENT for LU type 1 (IBM LANDP 3287 printer emulator)
  • MODEENT for LU type 2 (DBCS)
  • MODEENT for LU type 2 (IBM LANDP 3270 emulator)
  • MODEENT for RCMS
  • MODEENT for LU type 6.2
  • CICS definition examples
  • Definition for LU_0
  • Definition for LU_1
  • Definition for forwarding
  • Definition for LU_2
  • IMS/VS terminal statement examples
  • Definition for LU_0
  • Definition for LU_1
  • Definition for LU_2
  • IBM AS/400 connectivity using SNA LU_2 protocol
  • IBM AS/400 connectivity using SNA LU_0 protocol
  • Appendix G. LANDP using Server Based Computing
  • WorkSpace On-Demand
  • Distributing files
  • CONFIG.SYS updates
  • File index table (FIT) updates
  • Multiple workgroup support
  • LANDP customization considerations
  • Run Time
  • References
  • Windows Terminal Server
  • Distributing files
  • LANDP customization considerations
  • Client-attached devices
  • Run time
  • An example
  • Appendix H. Notices
  • Trademarks and service marks
  • Appendix I. Glossary

  • Appendix J. Bibliography
  • IBM LANDP Family
  • IBM Financial Branch System Services Licensed Programs
  • IBM Financial Branch System Integrator Licensed Programs
  • IBM Transaction Security System
  • Banking Self-Service
  • IBM workstations
  • IBM Local Area Network
  • IBM 3270
  • Wide Area Communications
  • IBM NetView
  • IBM Financial I/O Devices
  • Encryption and Decryption
  • IBM VisualAge C++
  • IBM VisualAge Generator
  • IBM VisualAge Smalltalk
  • Java
  • IBM Personal Communications
  • IBM Communications Server
  • WorkSpace On-Demand
  • MQSeries
  • Appendix . Index

  • Appendix K. Sending your comments to IBM


  • Figures

    1. LANDP Installation, Customization, and Distribution Process
    2. IBM LANDP desktop folder on Windows
    3. Customization Directory Structure
    4. The Customization Steps
    5. Migrating customization data from FBSS
    6. LANDP Distribution Process
    7. Example of SNA LUA profile names in a workgroup (OS/2)
    8. Example of SNA LUA profile names in a workgroup (Windows)
    9. EHCWINNT loading problem and solution
    10. libehclnx.so loading problem and solution
    11. Main Editor Window
    12. Add Workgroup
    13. Button bar
    14. New Workstation
    15. New Server
    16. The file menu
    17. Add Common Vector
    18. Document dimensions for IBM 4710 printer customization
    19. Passbook Dimensions for IBM 4720 Printer Customization
    20. Passbook Dimensions for IBM 4772 and 9068 Printer Customization
    21. Document Dimensions for IBM 4009, 4712, 4722, 4772, 9068 and 9069 Printer Customization
    22. Document Dimensions for IBM 4748 Printer Customization
    23. Passbook Dimensions for IBM 4748 Printer Customization
    24. Document Dimensions for IBM 4770 Printer Customization
    25. Integrating LANDP into WorkSpace On-Demand directory structure
    26. A Simple LANDP Workgroup
    27. A Simple LANDP Workgroup in a WTS Environment

    Tables

    1. 4748 Printer Server Device Driver Files under OS/2
    2. 4712 and 4722 Printer Device Driver Customization
    3. 4748 Printer Server Device Driver Files under DOS
    4. 4748 Printer Device Driver Customization
    5. Maximum Requirements for LANDP for OS/2 Workstations in a LANDP Workgroup
    6. Variable data record formats for VARDAT utility
    7. Chained Emulators: Example 1
    8. Chained Emulators: Example 2
    9. Display Colors
    10. Keyboard Key Codes
    11. Emulated Keyboard Key Codes
    12. Keyboard Key Defaults
    13. Present-keystroke defaults
    14. Trademarks and service marks

    About this book

    This book provides information about the following IBM(R) LAN Distributed Platform (LANDP(R)) Family products:

    Note:
    This book no longer provides information about IBM LANDP for AIX(R). Refer to the previous edition of this book, LANDP Family Installation and Customization Version 5.0, GC34-5530-00, for information about this product.

    The information provided in this book is intended to help you install the LANDP family, customize it to your own requirements, and make it operational. The book also contains information about how to customize PC/Integrator and PC/Integrator/2.


    Who should read this book

    This book is written for system analysts, system programmers, and application programmers. The book, LANDP Introduction and Planning, GC34-6043, is a prerequisite.

    Individuals responsible for host computer systems and host computer applications can find useful information on how to include LANDP workstations in wide area networks.


    What you need to know

    You should be familiar with the operating systems that support your LANDP environment and the programming language you are using.

    If you are involved in wide area communications, you should be familiar with Transmission Control Protocol/Internet Protocol (TCP/IP), System Network Architecture (SNA) protocols and Synchronous Data Link Control (SDLC), X.25 1 Data Link Control, or Token-Ring Data Link Control.

    If you are involved in LANDP internal communications, you should be familiar with NetBIOS, or with the TCP/IP implementations of the systems where you are going to use the LANDP family.


    Conventions used in this book

    A graphic, like the one shown here, appears in the margin at the beginning of each major section.
    ehc_xx00

    This graphic shows the component or components of the LANDP family to which the section relates. This example shows that the paragraph relates to LANDP for DOS and LANDP for OS/2 only. This does not necessarily imply that the item being described runs on each platform shown, but it does indicate that it affects LANDP on each platform.

    Icons such as the following might appear in individual paragaphs of the book: EHCMDOS

    This example shows that the paragraph relates to LANDP for DOS only.

    DB2 Universal Database(R)

    In this book, all references to DB2(R) or DB2/2 apply to IBM DB2 for OS/2 and to IBM DB2 Universal Database(R).

    Windows

    In this book, all references to Windows apply to Microsoft Windows NT, Microsoft Windows 2000, and Microsoft Windows XP Professional, unless indicated otherwise.

    Linux

    In this book, all references to Linux apply to RedHat, Caldera, SuSE and TurboLinux distributions of Linux, unless indicated otherwise.

    File names in Linux will usually be lower-case versions of those shown in this book. In addition, for executable Linux files (for example, the LANDP servers), there are no filename extensions. For example, the LANDP for Windows TCP/IP wide area communication server is EHCTCP.EXE and the LANDP for Linux TCP/IP wide area communication server is ehctcp.


    Related Information

    The LANDP family is supported by the following books. In this book, references to other LANDP books use the shortened titles shown here. For the full titles, order numbers of these publications, and a comprehensive list of LANDP-related literature, refer to Appendix J, Bibliography.

    LANDP Introduction and Planning
    This book provides a brief description of the components and features of the LANDP family, and gives information about planning a LANDP system.

    LANDP Installation and Customization
    This book provides information about installing, customizing, and distributing the LANDP family.

    LANDP Programming Reference
    This book describes the application programming interfaces that are used to develop user servers and client applications.

    LANDP Programming Guide
    This book gives guidance on writing application programs to use the interfaces described in the LANDP Programming Reference.

    LANDP Problem Determination
    This book describes how to use trace tools, diagnostic programs, alerts, and return codes to debug code while developing LANDP applications and user servers, or resolve problems while using LANDP family components.

    LANDP Servers and System Management
    This book provides detailed information on the LANDP servers, and describes how to manage and administer a LANDP system.

    Web site

    For more information about LANDP, please visit our web site at:
    http://www.ibm.com/software/landp/


    Summary of Changes

    This manual has been updated to reflect enhancements made to LANDP in Version 6. The major changes in this version are:


    Introduction

    This part introduces the installation and customization process.

    It contains the following chapter:

    Introduction "Introduction"

    Introduction




    ehcodwl

    This book contains information enabling you to install the IBM LANDP(R) licensed programs family in your organization, to customize your LANDP workgroup so that it meets your specific needs, and to produce and distribute the workgroup information.

    Planning your configurations and their hardware and software requirements must be done before you start the installation and customization process. This is covered in the LANDP Introduction and Planning book.

    The complete installation and customization cycle includes the following steps:

    1. Installing the LANDP family

      The first step is to install the LANDP family on the workstations that will be used for customization purposes. These workstations are called customization workstations. Refer to Installation for further information.

    2. Customizing the LANDP family

      Customization is done by editing customization vectors. Vectors can be created from scratch (as described in Customization), or by migrating from FBSS (the predecessor product to LANDP) or an earlier release of LANDP (as described in Migrating and generating customization data).

      When all the vectors are defined according to your configuration plans, they contain all the operational and configurational characteristics for the workstations in the workgroup.

      If you want to add your own user servers, refer to Appendix B, User servers.

    3. Making the LANDP family operational

      After installing and customizing, the run-time files for all workstations are ready to be distributed.

      These files are located in the specified paths of the workstations that will be used to distribute the files to the individual workstations. These workstations are called distribution workstations.

      Refer to Distribution for further information.

    Figure 1 summarizes the installation, customization, and distribution process and shows where to find more information.

    The remainder of the book shows how to prepare the various LANDP platforms for LANDP, utilities you can use as part of the installation and customization process, hints on performance tuning, and appendixes providing detailed customization information.

    Figure 1. LANDP Installation, Customization, and Distribution Process


    ehcgr084


    Installation

    This part describes how to install LANDP on your customization workstation.

    It contains the following chapter:

    Installing the LANDP family "Installing the LANDP family"

    Installing the LANDP family




    ehcow

    The environment of your workgroup needs to be identified so that you can create configuration files that define the characteristics of the various workstations in your production sites.

    This chapter describes how to install the LANDP family on the fixed disks of workstations that are used for this customization process.

    These workstations are called customization workstations.

    There are four stages required for installation:


    Planning for installation




    ehcow

    This section describes what you need to consider for your particular circumstances before beginning installation. It includes sections on the following:

    • Location of the customization workstation
    • Software requirements for the customization workstation
    • Operating system requirements of the network
    • The installation environment

    You should read the LANDP Introduction and Planning book for detailed information about planning considerations for your own environment.

    Note:
    You should read the README.TXT file on the LANDP product CD-ROM before starting the installation.

    Location of the customization workstation

    You should consider installing LANDP on:

    Software requirements for the customization workstation

    You can install LANDP for DOS, LANDP for OS/2, LANDP for Windows, LANDP for Linux, and the LANDP online books on the customization workstation. If your network contains DOS, OS/2, Windows, and Linux workstations, you need to install all four components in the same location on the customization machine. The order does not matter. If your network includes workstations which are running FBSS, you will need to install FBSS too.

    You can run the customization process on an OS/2 or Windows customization workstation. Your choice of customization workstation is independent of the mix of workstation types in the target workgroup.

    Software migration and installation of other products with LANDP

    You can install LANDP Version 6.0 on top of:

    You can also install:

    on top of LANDP Version 6.0.

    Notes:

    1. PC/Integrator is the abbreviation for IBM Financial Branch System Integrator, which is the licensed program needed to use FBSS (DOS) workstations or LANDP for DOS workstations in conjunction with the IBM 4700 Finance Communication System.

    2. PC Integrator/2 is the abbreviation for IBM Financial Branch System Integrator/2, which is the licensed program needed to use FBSS/2 workstations or LANDP for OS/2 workstations in conjunction with the IBM 4700 Finance Communication System.

    3. For information on both PC/Integrator and PC Integrator/2, refer to IBM Financial Branch System Integrator General Information.

    If you plan to use the following products, you need to have the corresponding installation diskettes to copy the required files to the required paths.

    For information on copying and customizing these files, refer to the manuals of the corresponding products. See Appendix J, Bibliography. See also Installing FBSI family and 47xx banking products.

    For user-written servers you need to have the server program and all the files required by the server.

    System requirements

    Operating system requirements

    The operating system in the workstation where LANDP is to be installed can be:

    Other software requirements

    The installation process uses Java. If a suitable version of Java is not available on the customization machine, a Java virtual machine is installed as part of the LANDP installation. On Windows, Java Virtual Machine (JVM) 1.3 is used; on OS/2, Java Virtual Machine 1.1.8 is used.

    The product registration invoked during the installation process, requires either Netscape 4.04 or later, or Microsoft Internet Explorer 4.0 or later.

    Customization editor requirements

    The Graphical Customization Editor that is described in Graphical Customization Editor is a Java-based program and requires a Java Virtual Machine (JVM), Version 1.3 or higher.

    If your customization workstation is running Windows, and JVM 1.3 is not already present, it is installed as part of the LANDP installation.

    If your customization workstation is running OS/2, IBM JVM 1.3 for OS/2 can be installed from the installation CD by clicking on the 'Java Installation' icon that is in the LANDP folder. To use the Graphical Customization Editor on OS/2 you must have JVM 1.3 available on your PATH.

    Storage requirements

    64MB of disk space is required for a complete installation of the LANDP family. An additional 20MB of temporary disk space is required for the installation process. The disk storage required for any other products that you need, for example those described in the previous section, must be added to the storage that is needed by LANDP.

    If you are running Windows, and JVM 1.3 is not already present on your system, an additional 23MB of disk space is required for its installation.

    If you are running OS/2, and JVM 1.1.8 is not already present on your system, an additional 10MB of disk space is required for its installation.


    Installing LANDP onto the customization workstation

    You install LANDP from the product CD.

    On Windows platforms, the installation process should start automatically when the product CD is inserted into the CD drive. If installation does not start automatically, start the installation either from the command line or by using the Run option of the Start Menu.

    To start the installation from the command line, enter:

         x:\setupW32
     
     where x: is the address of the CD drive 
    

    On OS/2, the installation process has to be started manually. Either use the drives icon to select setupos2 from the CD drive, or, from the command line, enter:

         x:\setupos2
     
     where x: is the address of the CD drive 
    

    The installation may take a few seconds to be initialized. The time depends on the specification of your customization workstation, and also on whether Java needs to be installed.

    When the Welcome Panel is displayed, you are ready to start the installation. Use the Next and Back buttons to navigate through the installation process.

    There are two setup types, Typical and Custom. If you choose Typical, all LANDP components are selected for installation. If you choose Custom, you can select only those LANDP components that you want to install.

    After accepting the license agreement, you are given the opportunity of specifying the directory where you want to install LANDP. The target directory for installation must be of the form D:\xxxxxxxx, where D: is the drive and xxxxxxxx (maximum 8 characters with no spaces) is the pathname. If the directory that you specify does not exist, it is created during the installation process.

    During installation, a log file ehcmst.log, containing status messages showing the progress of your installation, is built. It is placed in the installation directory.

    When the installation finishes, a desktop folder, called IBM LANDP is created. See Figure 2.

    Figure 2. IBM LANDP desktop folder on Windows

    ehcgr999

    This folder contains useful shortcuts for invoking LANDP programs and utilities.


    Completing the LANDP for OS/2 installation




    ehc_0x00

    After you finished installing LANDP for OS/2, you might need some of the information provided in this section if you want to use any of the following facilities:
    • Magnetic stripe reader/encoder server
    • PIN pad server
    • Financial printer server
    • 4748 printer server
    • 4733 teller assist unit

    The EHCO600 directory mentioned in this section is located in the path where LANDP is being installed.

    Note:
    Please ensure that you have the latest set of device driver diskettes, containing the .DLL files described in the rest of this section. If you have older .DLL files, the new functions might not be supported.

    To get the latest LANDP device drivers, contact your IBM representative who will send you the ones that are listed in the LANDP V6 announcement letter.

    Magnetic stripe reader/encoder server

    Copy the following files to the EHCO600 directory:

    MAGCALLS.DLL

    FIOxxx.MSG and FIOxxxH.MSG message files, renamed to FIO.MSG and FIOH.MSG files. Note that xxx stands for the language identifier.

    If the server supports a 4717 MSR/E, or is mouse attached, copy the FIOAUXDD.SYS file from the 4700 OS/2 Device Drivers diskette to the EHCO600 directory.

    If the server supports a 4777 MSR/E or a 4778 MSR, copy the FIOSERDD.SYS file to the EHCO600 directory.

    PIN pad server

    Copy the following files to the EHCO600 directory:

    PINCALLS.DLL

    FIOxxx.MSG and FIOxxxH.MSG message files, renamed to FIO.MSG and FIOH.MSG files. Note that xxx stands for the language identifier.

    If the server supports a 4718 PIN pad, and a magnetic stripe reader/encoder server will not be loaded in the workstation, copy the FIOAUXDD.SYS file from the 4700 OS/2 Device Drivers diskette to the EHCO600 directory.

    If the server supports a 4778 PIN pad:

    If the server supports a 4778 PIN pad, and a magnetic stripe reader/encoder server will be loaded in the workstation, copy the PINMSR.DLL file to the EHCO600 directory.

    Financial printer server

    If only the parallel port is used, no device driver is required.

    If serial ports are used and 4009, 4712, 4722, 4772, 9055-002, or 9068-S01 printers are supported, copy the following files from the 4700 OS/2 Device Drivers diskette to the EHCO600 directory:

    PRTCALLS.DLL
    FIOPRT.DCP
    P4712.PCH
    P4722.PCH
    4772PDD.SYS
    4772S.DCP
    P4722-3.PCH
    R4722-3.PCH
    P4722-OP.PCH
    P4722-1.PCH
    R4722-1.PCH

    You also have to copy the FIOxxx.MSG and FIOxxxH.MSG message files, renamed to FIO.MSG and FIOH.MSG files. Note that xxx stands for the language identifier; select the files according to the language of your choice.

    4748 printer server

    Copy the COM.SYS file to the EHCO600 directory. The COM.SYS file is provided with OS/2. For IBM PS/55 Models 5560 and 5580, copy the COMDMA.SYS file.

    The 4748 Printer Server also provides support for the 9055-001 printer, which supersedes the 4748 printer and can be set to emulate the 4748. (The 9055-002 printer is supported by the 47X2 server.) The 9055 Printer provides more function, such as Reader/Encoder Magnetic Stripe (REMS) support, but needs its own device driver if the extra function is to be used under OS/2.

    Whichever printer you are using, you should copy its dynamic link library files from the diskette supplied with it to the EHCO600 directory as shown below.

    Table 1. 4748 Printer Server Device Driver Files under OS/2

    Printer 4748 emulation mode? (No REMS) DLL
    4748 Not relevant PBPCALLS.DLL
    9055 Model 1 Yes SCPCALLS.DLL or PBPCALLS.DLL
    9055 Model 1 No SCPCALLS.DLL
    9068-D01 Yes SCPCALLS.DLL or PBPCALLS.DLL
    9068-D01 No SCPCALLS.DLL

    4733 teller assist unit

    If you are using a 4733 teller assist unit, you must copy the TCD3862.SYS device driver to the EHCO600 directory.

    You have now finished the installation process for LANDP for OS/2.


    Completing the LANDP for Windows installation




    ehcw

    After you finish installing LANDP for Windows, you might need some of the information provided in this section if you want to use any of the following facilities:
    • Magnetic stripe reader/encoder server
    • PIN pad server
    • Financial printer server

    The EHCN600 directory mentioned in this section is located in the path where LANDP is being installed.

    Note:
    Ensure that you have the latest set of device driver diskettes, containing the .DLL files and other files described in the rest of this section. If you have older .DLL files, the new functions might not be supported.

    To get the latest LANDP device drivers, contact your IBM representative who will send you the ones that are listed in the LANDP V6 announcement letter.

    Magnetic stripe reader/encoder server

    Copy the following files to the EHCN600 directory:

    PIN pad server

    Copy the following files to the EHCN600 directory:

    Financial printer server

    If only the parallel port is used, no device driver is required.

    If serial ports are used and 4712, 4722, 4772, 9055-002, 9069, 9068-A01, 9068-A03, or 9068-S01 printers are supported, copy the following files from the Device Drivers diskette to the EHCN600 directory:

    4748 printer server

    Copy the file WNTDFPRT.DLL to the EHCN600 directory.

    Under Windows, the 4748 printer server does not support the 4748 printer itself, but supports a 9055-001 or 9068-D01 printer when its ID byte is set to 1E(hexadecimal).

    You have now finished the installation process for LANDP for Windows.

    Note:
    If you have a problem when loading the required dynamic library EHCWINNT.DLL, refer to LANDP Problem Determination.

    Completing the LANDP for Linux installation




    ehcl

    After you finish installing LANDP for Linux, you might need some of the information provided in this section if you want to use any of the following facilities:
    • Magnetic stripe reader/encoder server
    • PIN pad server
    • Financial printer server

    The EHCL600 directory mentioned in this section is located in the path where LANDP is being installed.

    Note:
    Ensure that you have the latest set of device driver diskettes, containing the files described in the rest of this section. If you have older files, the new functions might not be supported.

    To get the latest LANDP device drivers, contact your IBM representative who will send you the ones that are listed in the LANDP V6 announcement letter.

    Magnetic stripe reader/encoder server

    Copy the following files to the EHCL600 directory:

    PIN pad server

    Copy the following files to the EHCL600 directory:

    Financial printer server

    If only the parallel port is used, no device driver is required.

    If serial ports are used and 4712, 4722, 4772, 9055-002, 9069, 9068-A01, 9068-A03, or 9068-S01 printers are supported, copy the following files from the Device Drivers diskette to the EHCL600 directory:

    You have now finished the installation process for LANDP for Linux.

    Note:
    If you have a problem when loading the required shared object file, libehclnx.so, refer to LANDP Problem Determination.

    Completing the LANDP for DOS installation




    ehc_x000

    After you have finished installing LANDP for DOS, you might need some of the information provided in this section if you want to use any of the following facilities:

     

    • Magnetic stripe reader/encoder server
    • PIN pad server
    • Financial printer server
    • 4748 printer server
    • 4733 teller assist unit
    • NetBIOS support
    • X.25 Data Link control

    The EHCD600 directory mentioned in this section is located in the path where LANDP is being installed.

    Note:
    Ensure that you have the latest set of device driver diskettes, containing the files described in the rest of this section. Otherwise, the new functions might not be supported.

    To get the latest LANDP device drivers, please contact your IBM representative who will send you the ones that are listed in the LANDP V6 announcement letter.

    Magnetic stripe reader/encoder server

    If the server supports a 4717 MSR/E, copy the MSRE2DD.SYS device driver from the 4700 Device Drivers diskette to the EHCD600 directory.

    If the server supports a 4777 MSR/E or a 4778 MSR:

    PIN pad server

    If the server supports a 4718 PIN pad, copy the PIN2DD.SYS device driver from the 4700 Device Drivers diskette to the EHCD600 directory.

    If the server supports a 4778 PIN pad:

    If 4778 MSR capabilities are used, copy the IBM4777.SYS device driver to the EHCD600 directory.

    Financial printer server

    If only the parallel port is used, no device driver is required.

    If serial ports are used, and either 4712 printers or 4722 printers are supported, you must customize the printer device drivers by using the device driver customization program supplied with the 4700 Device Drivers diskette.

    Version 3.0 (or later) of the device drivers is required to support the 4722 model 3 printer with the Read and Encode Magnetic Stripe (REMS) facility.

    The same device drivers as those for the 4722 printer are used to support the 9055 model 2 and 9068-S01 printers.

    The device driver customization program prompts you to enter a driver file name and a driver device name. Refer to Table 2 and assign driver file names depending on the port number and model number, as well as on whether the REMS facility is present. Driver device names depend only on the port number to which the printer will be connected.

    Table 2. 4712 and 4722 Printer Device Driver Customization

    Model Port Driver File Name Driver Device Name
    4712 1 FPRT121.SYS FPRTDD1
    4722 1 FPRT221.SYS FPRTDD1
    4722 REMS 1 FPRT221R.SYS FPRTDD1
    4712 2 FPRT122.SYS FPRTDD2
    4722 2 FPRT222.SYS FPRTDD2
    4722 REMS 2 FPRT222R.SYS FPRTDD2
    4712 3 FPRT123.SYS FPRTDD3
    4722 3 FPRT223.SYS FPRTDD3
    4722 REMS 3 FPRT223R.SYS FPRTDD3
    4712 4 FPRT124.SYS FPRTDD4
    4722 4 FPRT224.SYS FPRTDD4
    4722 REMS 4 FPRT224R.SYS FPRTDD4

    If 4772 printers are supported, the required device driver is 4772SS.SYS.

    The customized device drivers must be copied to the EHCD600 directory.

    4748 printer server

    You must customize the 4748 printer device drivers by using the device driver customization program supplied with the 4748 printer device drivers diskette.

    The 4748 Printer Server also provides support for the 9055 Model 1 printer, which supersedes the 4748 printer and can be set to emulate the 4748. (The 9055 Model 2 printer is supported by the 47X2 server.) The 9055 Printer provides more function, such as Reader/Encoder Magnetic Stripe (REMS) support, but needs its own device driver if the extra function is to be used under DOS.

    Whichever printer you are using, you should copy its device driver files from the diskette supplied with it to the EHCD600 directory as shown below.

    Table 3. 4748 Printer Server Device Driver Files under DOS

    Printer 4748 emulation mode? (No REMS) Driver File Name
    4748 Not relevant FPRT48x.SYS
    9055 Model 1 Yes FPRTSCPx.SYS or FPRT48x.SYS
    9055 Model 1 No FPRTSCPx.SYS
    9068-S01 No FPRTSCPx.SYS
    Note:
    x is the port (1 or 2) to which the printer is attached.

    The device driver customization program prompts you to enter a driver file name and a driver device name. Refer to Table 4 and assign driver file names depending on the port number. Driver device names depend only on the port number to which the printer will be connected.

    Table 4. 4748 Printer Device Driver Customization

    Model Port Driver File Name Driver Device Name
    4748 1 FPRT481.SYS FPRTDD1
    4748 2 FPRT482.SYS FPRTDD2
    9055 Model 1 1 FPRTSCP1.SYS FPRTDD1
    9055 Model 1 2 FPRTSCP2.SYS FPRTDD2
    9068-D01 1 FPRTSCP1.SYS FPRTDD1
    9068-D01 2 FPRTSCP2.SYS FPRTDD2

    4733 teller assist unit

    If you are using a 4733 teller assist unit, you need to copy the TCD386D.SYS device driver to the EHCD600 directory.

    NetBIOS support

    If you select NetBIOS as the transport protocol, LANDP customization assumes that you are using the IBM LAN Support Program for a non-Network Driver Interface Specifications (NDIS) device driver.

    Copy the following device drivers from the LAN Support Program installation diskette to the EHCD600 directory:

    DXMA0MOD.SYS
    DXMC0MOD.SYS
    DXMT0MOD.SYS
    DXMG0MOD.SYS

    If the LAN Support Program version that you are using provides the message files DXMMSG.xxx, copy also the appropriate file as DXM.MSG.

    If you are using IBM LAN Client, or if there are programs other than the LANDP NetBIOS transport using NetBIOS, you must install and configure the NetBIOS directly (see Installation requirements for NetBIOS transport protocol).

    X.25 Data Link control

    If you are using IBM PC X.25 Communications Adapter, copy the following files from the installation diskette of IBM PC X.25 Communication Support Version 1.11 to the EHCD600 directory:

    X251.SYS
    X25MENA.TXT
    X25MENB.TXT
    X25MENC.TXT
    XL.EXE
    CX1.LDA
    CX2.LDA
    CX3.LDA
    CX4.LDA
    CX5.LDA
    CX6.LDA
    CX7.LDA
    CX8.LDA

    If you are using IBM X.25 Co-Processor/2, create the FBSSC2X directory in the installation path.

    Copy the following file from the IBM X.25 Co-Processor/2 option diskette to the FBSSC2X directory:

    ICAAIM.COM

    Copy the following files from the installation diskette of IBM X.25 Co-Processor/2 Support Program to the FBSSC2X directory:

    GQKENGLI.TXT
    GQKPTCOL.DEF
    GQKCONF.EXE
    GQKINIT.EXE
    GQKLOAD.EXE
    GQKSL1.EXE
    GQKPTCOL.EXE
    X25.EXE

    Copy the following files from the installation diskette of IBM Realtime Interface Co-Processor DOS Support to the FBSSC2X directory:

    ICAINTH.COM
    ICAINTH.MSG
    ICAINTH.SYS
    ICALOAD.COM
    ICALOAD.MSG

    Finally, you must customize the IBM X.25 Co-Processor/2 in order to create the profiles to be used. For information about this process, refer to the corresponding manuals.

    You have now finished the installation process for LANDP for DOS.


    User servers

    If you have developed a server, the server program, the device driver it might require, and other needed files, should all be copied to the directory specified in the SUBDIR keyword of the DEFSERV vector and, if it applies, of the DISTRIB vector. See Appendix B, User servers.

    If you have developed a server that runs under LANDP for DOS, LANDP for OS/2, LANDP for Windows, or LANDP for Linux, you must copy the files to the directories specified for each of these LANDP components. Note that LANDP for DOS, LANDP for OS/2, LANDP for Windows, or LANDP for Linux, must already be installed.


    Installing FBSI family and 47xx banking products

    After installing LANDP, you can install the following products using the procedures provided for each of them.

    If you installed LANDP to remote fixed disks, run the procedures making sure that you use the same drive and path as for LANDP installation.

    PC/Integrator and PC Integrator/2

    When LANDP has been installed:

    1. Insert the first PC/Integrator or PC Integrator/2 diskette (labeled Diskette 1) into the diskette drive.
    2. From the EHCCUS directory, created by the installation program, enter:
        INSTFBSI
      
      Note:
      The INSTFBSI procedure can be run only in a DOS environment.

    Complete the installation process using the PC/Integrator or PC Integrator/2 manuals. See Appendix J, Bibliography.

    To use BIWP or LDA7 in an OS/2 VDM, copy the BIWP.EXE file distributed with PC/Integrator to the EHCO600 directory, and rename it VBIWP.EXE.

    Similarly, to use BIWP or LDA7 in a Windows VDM, copy BIWP.EXE into the EHCN600 directory, and rename it VBIWP.EXE.

    To use BPP in a Windows VDM, copy the BPP.EXE file distributed with PC/Integrator into the EHCN600 directory, and rename it VBPP.EXE

    47XX Banking Products

    To install the software required for:

    refer to the corresponding manuals. See Appendix J, Bibliography.

    To start the customization process for the banking machines software, from the EHCCUS directory enter:

      FBSSBDV
    
    Note:
    The FBSSBDV procedure can be run only in a DOS environment.

    Complete the customization process by following the information in the Personal Banking Machines manuals.


    Online books

    The LANDP V6 books are on the product CD-ROM as PDF files, for viewing and printing under Adobe Acrobat. A PDF file that contains a Master Index to the LANDP V6 books is also on the product CD-ROM.

    The Adobe Acrobat Reader is available on Windows, DOS, OS/2, and Linux.

    Get a free copy of the Adobe Acrobat Reader for your platform from the Internet by following the instructions given on Adobe's home page:

      http://www.adobe.com
    

    Put the online book files on a shared drive, or distribute them to the machine of each user who will need them. Don't forget to tell your users that the online books are available for them to use.

    Indexing is available, but to use indexing, you need to register the index with the Adobe Acrobat Reader.


    Customization

    This part describes how to customize your LANDP installation to satisfy the requirements of your organization.

    It contains the following chapters:

    The customization process "The customization process"
    The CREATE utility program "The CREATE utility program"
    The GENSPEC utility program "The GENSPEC utility program"
    Preparation of customization data "Preparation of customization data"
    The VALSPEC utility program "The VALSPEC utility program"

    The customization process




    ehcodwl

    After you have installed LANDP for DOS, LANDP for OS/2, LANDP for Windows, or LANDP for Linux, you design a data processing network to meet your organization's requirements. This is called customizing.

    LANDP customization files are automatically installed when you install LANDP for DOS, LANDP for OS/2, LANDP for Windows, or LANDP for Linux.

    The complete customization process involves the following steps:

    1. Identifying the requirements for your environment. This is part of the planning process, and is described in LANDP Introduction and Planning.
    2. Running the customization utility programs to define the characteristics of the workstations in your production sites. These programs are covered in more detail in The customization steps.
    3. Using the customization utility to create the diskettes for each workstation (obtaining software for distribution). This is described in The GENRUN and GETGLOB utility programs.

    If you have customization data that has been generated earlier by the FBSS customization program, you can use the migration utility. This utility migrates all the previously defined data to your LANDP workgroup, and adds the information to the internal repository. This process is described in Migrating customization data from FBSS and in Migrating and generating customization data.

    You can see and perform the customization steps by following the examples described in Appendix A, An example. These examples are also provided on the product CD-ROM and might be useful if you want to get a hands-on feeling for the customization procedures.

    A graphical Customization Editor is provided to help you prepare the data to customize your system and run the related utilities. Graphical Customization Editor provides a tuturial that describes how to use the graphical editor.

    Notes:

    1. LANDP users can customize in any of the following ways:
    2. When running LANDP customisation and related utilities on Windows, your customisation workstation must have an A: diskette drive, otherwise unavoidable system delays might occur. It is not necessary to have a diskette inserted. This warning applies particularly to laptop computers, which might be shipped without an A: drive.
    3. Customization on DOS or Linux is not supported.

    LANDP customization - things you need to know

    Before starting the customization process, it is necessary to understand some fundamental concepts involved in the process.

    Customization data structure

    The customization data is specified in vector format. A vector is a set of statements defining configuration items. You define a series of vectors that are stored in files. These files are processed to generate an internal repository for retrieval purposes.

    You define and process the customization data in different vector groups. Each vector group is included in a separate LANDP specification (SPC) file:

    COMMON.SPC
    Common data vectors
    LANCONF.SPC
    Workgroup configuration data vectors
    MODELS.SPC
    Model configuration data vectors

    Common data--COMMON.SPC

    Common data vectors are common for all or for several workstations or workgroups. These include defaults, tables, record definitions, and profiles.

    The vectors that contain common data must be grouped in the COMMON.SPC file located in the EHCCUS directory, created by the installation program.

    Workgroup configuration data--LANCONF.SPC

    Workgroup configuration data vectors are specific for each workgroup.

    The vectors that contain workgroup configuration data must be grouped in a LANCONF.SPC file located in a directory created for the workgroup. For more information, refer to Customization directory structure.

    Model configuration data--MODELS.SPC

    The objective of modeling is to avoid specifying customization data more than once, when defining similar workgroup configurations.

    A model configuration is a pattern designed only for reference purposes. Once you have defined a model configuration, you can use that model in a workgroup configuration by just referencing its name.

    Models can be defined on three levels:

    Workgroup level
    A workgroup model configuration serves as a pattern for a workgroup configuration. You can make modifications to the same model in each workgroup configuration that refers to it.

    Thus you specify the more general information only once in the model, and make workgroup specific changes only in the respective workgroup configuration definitions.

    Workstation level
    A workstation model configuration serves as a pattern for a workstation configuration. It can be referenced from either a workgroup model or a workgroup configuration, and contains information that is similar in many workstations in any workgroup.

    Specific changes to a workstation model are made on the workgroup level where this model is referenced.

    Server level
    A server model configuration serves as a pattern for workstations which use similar server configurations. It can be referenced from either a workstation model or a workstation configuration.

    Another useful way of using models is nesting models.

    Within a workgroup model configuration, you can refer to a workstation model when specifying the configurations of similar workstations in the workgroup. You can also reference a server model.

    On workstation level, you can refer to a particular server model, either from a workstation configuration, or from a workstation model.

    The vectors that contain model configuration data must be grouped in the MODELS.SPC file in the EHCCUS directory that was created by the installation program.

    Customization directory structure

    To locate LANDP information, the installation program creates a set of directories.

    To locate customization information, you have to create some directories at workgroup level. The customization directory structure must be located in the first level subdirectory you define during installation.

    The base directory for customization must be of the form D:\xxxxxxxx, where D: is the drive, and xxxxxxxx (maximum 8 characters with no spaces) is the path name.

    The following figure shows the customization directory structure. The .SPC files are also included.

    Figure 3. Customization Directory Structure

    ehcgr044

    The COMMON.SPC and MODELS.SPC files must be located in the EHCCUS directory created by the installation program.

    To locate the LANCONF.SPC files, containing workgroup configuration data, create a directory for each file.

    These directories can be located in either the EHCCUS directory or any directory you create at the same level as the EHCCUS directory. You can also create a directory for each group of workgroup configurations to be defined.

    If you use the EDITSPC procedure provided by the customization program to edit .SPC files, you do not need to create those directories. The procedure creates them for you.

    Techniques and considerations

    Here are some more points you will need to know before you start to customize LANDP.

    Remote customization

    Remote customization, the process of customizing from a machine other than a designated customization workstation (for example, a LAN server), is supported. However, customization from two remote workstations at the same time is not allowed. If you try to customize, and customization is already taking place, an error message is displayed on the screen.

    Notes:

    1. You cannot run the customization program under OS/2 while FBSS/2 or LANDP for OS/2 are running in the same workstation.

    2. The migration procedure in an OS/2 customization workstation will always run in a VDM, because it can only be run in DOS.

    Embedded specification files

    The objective of embedding files is to avoid working with large .SPC files.

    Instead of storing all the common or model configuration data in the COMMON.SPC or MODELS.SPC file, some data can be stored in separate files. Later, these files can be embedded in the COMMON.SPC file or in the MODELS.SPC file, using INCLUDE statements.

    The format of the INCLUDE statements is:

      INCLUDE=D:\xxxxxxxx\yyyyyyyy\nnnnnnnn.eee
    

    where

    D:\xxxxxxxx\yyyyyyyy
    is the path where the file is located.
    nnnnnnnn
    is the filename.
    eee
    is the extension of the separate file.

    The number of directory levels is limited only by the operating system.

    The INCLUDE keyword must start in the first position. No blanks are allowed between the INCLUDE keyword, the = sign, and the full file path.

    When you retrieve customization data from the internal repository, only a single COMMON.SPC file and a single MODELS.SPC file are created, regardless of whether you embedded files to define the customization data.

    Partial specification files

    The objective of creating partial .SPC files is to avoid processing the whole COMMON.SPC or MODELS.SPC files to update the internal repository.

    When processing a COMMON.SPC file or MODELS.SPC file, the common data or model configuration data in the internal repository is not deleted. The result is that some of the data remains as it is, some of the data changes according to the data in the .SPC file, and some of the data is added to the repository.

    This feature enables you to use either a new profile (common data) without processing the whole COMMON.SPC file, or a new model of workstation (model configuration data) without processing the whole MODELS.SPC file.


    The customization steps

    Figure 4 shows an overview of the customization steps.

    Figure 4. The Customization Steps

    ehcgr082

    The boxes in Figure 4 represent the procedures you will be running during customization. Depending on your work environment, you will have to run all or just some of them.

    The following sections describe, briefly, the start state for each procedure, the task being performed, and where to find more information.

    The graphical customization editor can be used to complete all the steps shown, either as an alternative to, or in conjunction with, the utilities described in this chapter. The graphical customization editor can be used to load, edit, and save the customization files, and to run the validation and distribution processes. See Graphical Customization Editor for more information.

    Creating common data default definitions--CREATE

    Start state
    The LANDP installation is complete.

    Task
    To create common data default definitions, which are stored in the internal LANDP repository. If a COMMON.SPC file already exists, the CREATE procedure works like the VALSPEC procedure.

    For more information
    See The CREATE utility program.

    Converting common data to editable .SPC files--GENSPEC

    Start state
    There are two possible start states for running the GENSPEC procedure:

    Task
    To convert the common, workgroup, and model data located in the internal repository to editable .SPC files.

    For more information
    See The GENSPEC utility program.

    Validating customization data--VALSPEC

    Start state
    The editable .SPC files have been created using either the GENSPEC or the EDITSPC procedure.

    Task
    To validate the information created in the COMMON.SPC, LANCONF.SPC, and, if specified, MODELS.SPC files.

    For more information
    See The VALSPEC utility program.

    Editing customization vectors--EDITSPC

    Start state
    There are two possible start states for running the EDITSPC procedure:

    Task
    To edit the customization vectors within the .SPC files.

    For more information
    See Preparation of customization data.

    Note:
    You can edit the .SPC files using any text editor. Using EDITSPC has the advantage of providing a standard template for the vectors, and easy access to VALSPEC and the help files.

    Migrating customization data from FBSS

    You can migrate customization data from an earlier version of FBSS to LANDP. Figure 5 shows how the MIGRATE procedure fits into the customization process.

    Figure 5. Migrating customization data from FBSS

    ehcgr083

    Following the MIGRATE procedure, the customization process follows the same steps as for a new LANDP workgroup.

    For more information see Migrating.


    The CREATE utility program




    ehcodwl

    The CREATE utility program is used to generate common data default definitions, held as vectors in the COMMON.SPC file.

    Whether you need to specify common vectors depends on the servers in your workgroup. For a reference list of which vectors you have to specify at the common level, see Vectors - a quick reference. If you do not need to specify common vectors, you can omit the CREATE step.

    The CREATE utility runs only in OS/2 or Windows, but the common data definitions can apply to all platforms.

    Note:
    The graphical customization editor can also be used to perform the CREATE function. See Graphical Customization Editor for more information.

    Starting the CREATE procedure

    You can display online information about the CREATE procedure. From the EHCCUS directory, enter:

    CREATE ?
    

    To start the CREATE procedure, from the EHCCUS directory, enter:

    CREATE
    

    The common data default definitions are created in the internal repository, and are held as vectors on the COMMON.SPC file.

    Note:
    If a COMMON.SPC file already exists when you run CREATE, the program performs a validation of the existing COMMON.SPC file.

    The GENSPEC utility program




    ehcodwl

    This chapter explains how to perform the vector generation step. It shows how to start the generation procedure, and describes the data generated by the procedure.

    The generation procedure reads data in the internal repository, created either by the CREATE procedure, the migration procedure, or by the validation procedure, and generates vectors in the .SPC files.

    When LANDP is first installed, it is advisable to run CREATE followed by GENSPEC to create a COMMON.SPC file containing the source for all the default tables. This is useful if you later want to create or change items such as keyboard definitions and translation tables.

    If a .SPC file already exists with the same name and in the same path, the procedure creates a backup of the existing .SPC file, with the same file name but with extension BAK. If a .BAK file corresponding to the .SPC file already exists, the procedure erases the existing .BAK file.

    If a .SPC file is lost, you can recover it by running the generation procedure and using the current data in the internal repository.

    The GENSPEC utility runs only in OS/2 or Windows. The vectors generated can apply to all platforms.

    Note:
    The graphical customization editor can also be used to perform the GENSPEC function. See Graphical Customization Editor for more information.

    Starting the generation procedure

    You can display online information about the GENSPEC procedure. From the EHCCUS directory, enter:

      GENSPEC ?
    

    To start the generation procedure, from the EHCCUS directory, enter:

      GENSPEC [parm1] [parm2] [parm3] [parm4]
    

    where:

    parm1
    Is an optional parameter to specify the type of data to be processed. The parameter value can be:

    COMMON
    To process common data, such as defaults, records, profiles, and tables.

    LAN
    To process workgroup configuration data.

    MODELS
    To process model configuration data.

    The default is LAN.

    parm2
    Is an optional parameter to specify the workgroup configuration to be processed. It applies when you process only one workgroup configuration.

    If the parameter is used, only the workgroup configuration specified will be processed, whatever the contents of the LANLIMIT.SPC file.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    parm4
    Is an optional parameter with only one possible value: DELETE.

    If the parameter is specified, the customization data processed is automatically removed from the internal repository. Thus, after running the generation program, the data is stored only on the .SPC files.

    If the parameter is not specified, the customization data processed also remains stored in the internal repository.

    The parameters can be specified in any order. Return codes generated by the generation procedure are displayed on the screen.

    To avoid lengthy processing, it is strongly recommended that you run the validation procedure specifying first the COMMON parameter value. Then, if it applies, run the procedure specifying the MODELS parameter value. Finally, run the validation procedure again specifying the LAN parameter value.

    In addition, when processing workgroup configuration data, you can select the workgroup configurations affected by the process. See Selecting workgroup configurations.


    Data in vector format

    After generation of .SPC files, the customization data is stored in vector format in those files. The common data is stored in the COMMON.SPC file, in the EHCCUS directory.

    The workgroup configuration data is stored in the LANCONF.SPC files, in the yyyyyyyy\xxxxxxxx directories, where:

    yyyyyyyy
    Is the name of a group of workgroup configurations. The customization program default is EHCCUS.

    xxxxxxxx
    Is the name of a workgroup configuration.

    The vectors in a LANCONF.SPC file are:

    LANCONF
    LWSCONF

    The model configuration data is stored in the MODELS.SPC file, in the EHCCUS directory. The vectors in that file are:

    LANMODEL
    LWSCONF
    SVRMODEL
    WSMODEL

    Preparation of customization data




    ehcodwl

    Customization is done by editing customization vectors.

    A vector is a set of keyword/parameter statements that define configuration items. These items correspond to common, workgroup, and model data definitions, which are written on the COMMON.SPC, LANCONF.SPC, and MODELS.SPC files.

    Vectors can be created and written according to a set of rules.

    Keywords are the names or symbols that identify parameters, or ordered strings of parameters.

    There are three alternative methods for preparing customization data:

    • using a text editor
    • using the EDITSPC utility
    • using the graphical customization editor


    Using a text editor

    Customization vectors can be created or edited with any text editor which adheres to the specifications below. Most commonly used editors already comply with the following standards:

    Note:
    Your editor must not add either control or format characters to the text. Therefore, you cannot use a word processor.

    Using the EDITSPC utility

    The EDITSPC customization program provides a procedure that, if the .SPC file or the path does not exist, creates the necessary path and opens the new .SPC file for input.

    The file EDITSPC.CMD is provided in the EHCCUS directory. The EDITSPC command calls the OS/2 Enhanced Editor (EPM.EXE). If you want to use your own personal editor, you must modify the EDITSPC.CMD file accordingly.

    To have the OS/2 Enhanced Editor available, you must install that option from the OS/2 installation diskettes.

    The EDITSPC command also enables the LANDP customization editing tool and adds the LANDP choice to the action bar of the editor window. For information about that tool, select the View doc option in the pull-down that appears when you choose LANDP.

    Note:
    The EDITSPC utility runs only in OS/2, although the customized vectors can apply to all platforms. For information on how to use EDITSPC, refer to Creating and editing common vectors, Creating and editing configuration vectors, and Editing model configuration data.

    Using the graphical customization editor

    A graphical customization editor is provided to help the preparation of customization data. A tutorial that describes how to use the editor is included in Graphical Customization Editor.


    Rules for specifying vectors

    When creating or editing customization vectors in the COMMON.SPC, LANCONF.SPC, and MODELS.SPC files, you must keep to the following syntax rules:

    1. You can write vectors in upper case, lower case, or mixed case. However, the validation program is not case sensitive. For example, if you named one workstation A1 and another a1, they would be considered to be duplicates.

      This rule does not apply when text is enclosed within single quotes (').

      Note that the generating program transforms vectors into upper case if the target workstation is running DOS, OS/2 or Windows. However, if the target workstation is running Linux, the generating program transforms all file names into lower case.

    2. Any text starting with /* and ending with */ is a comment. For example:
      /* VECTOR1 defines the xx server properties */
      

      You can also use these characters to comment out vector lines.

    3. At the beginning of a line (after any number of blank lines), you must have one or more blank characters before you start with the vector name. The vector definition never starts at the first position of a line. For example:
      /* VECTOR1 defines the xx server properties */
       
            VECTOR1
      
    4. The vector must be separated from the first keyword by one or more blanks.

      The keyword is followed by an equal sign (=) and by its parameter specifications. For example:

      /* VECTOR1 defines the xx server properties */
       
            VECTOR1  KEYWORD1=PAR1
      

      You can have one or more blank separation characters before and after the equal sign.

    5. A comma (,) is used as a continuation character. When there is no comma after a parameter, the vector specification is considered to be complete and the program looks for the next vector.

      A comma followed by a blank skips the rest of the line. For example:

      /* VECTOR1 defines the xx server properties */
       
            VECTOR1  KEYWORD1=PAR1,
                     KEYWORD2=PAR2,
                     KEYWORD3=PAR3,
                     KEYWORD4=PAR4
      

      Any text that you put in the same line after a comma followed by a blank is disregarded.

    6. If a parameter contains blanks or special characters, it must be enclosed within single quotes (').

      Special characters are blanks, commas (,), single and double quotes (' and "), and parentheses (()). For example:

      /* VECTOR1 defines the xx server properties */
       
            VECTOR1  KEYWORD1=PAR1,
                     KEYWORD2=PAR2,
                     KEYWORD3=PAR3,
                     KEYWORD4=PAR4,
                     KEYWORD5='field description'
      
    7. If a keyword has multiple parameters that are enclosed between parentheses, it might be split over several lines. The parameter values are separated by commas. You can split a line only after a comma. For example:
      /* VECTOR1 defines the xx server properties */
       
            VECTOR1  KEYWORD1=PAR1,
                     KEYWORD2=PAR2,
                     KEYWORD3=PAR3,
                     KEYWORD4=PAR4,
                     KEYWORD5='field description',
                     KEYWORD6=(PAR6a,PAR6b),
                     KEYWORD7=(PAR7a,PAR7b,
                               PAR7c,PAR7d,
                               PAR7e,PAR7f)
      

      Note that no blanks are allowed within parentheses.

    8. All parameter values are positional. If you want to omit some parameter values in order to take the defaults, you must clearly point out their position by indicating all the commas. For example:
      /* VECTOR1 defines the xx server properties */
       
            VECTOR1  KEYWORD1=PAR1,
                     KEYWORD2=PAR2,
                     KEYWORD3=PAR3,
                     KEYWORD4=PAR4,
                     KEYWORD5='field description',
                     KEYWORD6=(PAR6a,PAR6b),
                     KEYWORD7=(PAR7a,PAR7b,
                               PAR7c,PAR7d,
                               PAR7e,PAR7f),
                     KEYWORD8=(PAR8a,,PAR8c,,,PAR8f)
      

      However, if the last parameter values of a keyword are defaulted, KEYWORDx=(a,b,,,), they can be omitted. The format will then be KEYWORDx=(a,b).

    9. Keywords are not positional. They can appear in any order.

    Vectors - a quick reference

    The use of vectors is generally related to specific servers and functional areas.

    The following is a list of LANDP functional areas and the vectors which have to be specified for each of them, both on common and on workgroup level. If you are using models, you must also specify the WSMODEL or the SVRMODEL vectors. They are not mentioned in the list.

    Note that, depending on your own configuration, you might have to specify other vectors as well. This list is intended to give a quick overview only. For detailed information, see Appendix C, Editing common data and Appendix D, Editing configuration data.

    Some LANDP functional areas in the list have a special mark:

    (*)
    Applies to PC/Integrator

    (**)
    Applies to both PC/Integrator and PC Integrator/2

    Functional Area On common level Go to page: On workgroup level Go to page:
    ASCII-EBCDIC translation server

    (EHCDBTR)

    XLAT2TBL "XLAT2TBL vector" LWSCONF
    DBCSXLAT
    "LWSCONF vector"
    ***
    (**) Banking Interactive Workstation Program

    (BIWP)

    DEFAULTS
    DISPLATT
    KBDBIWP
    KSCCBIWP
    KSTRBIWP
    LUPOOL
    MSRINTBL
    MSROUTBL
    PINPTBL
    XLATETBL
    "DEFAULTS vector"
    "DISPLATT vector"
    "KBDBIWP vector"
    "KSCCBIWP vector"
    "KSTRBIWP vector"
    "LUPOOL vector"
    "MSRINTBL vector"
    "MSROUTBL vector"
    "PINPTBL vector"
    "XLATETBL vector"
    LWSCONF
    SERVER
    PAR&BIWP
    "LWSCONF vector"
    ***
    ***
    Banking Printer Program

    (BPP)

    BPPPARM
    DEFAULTS
    FORM4710
    FORM4720
    LUPOOL
    XLATETBL
    "BPPPARM vector"
    "DEFAULTS vector"
    "FORM4710 vector"
    "FORM4720 vector"
    "LUPOOL vector"
    "XLATETBL vector"
    LWSCONF
    SERVER
    SES&BPP
    "LWSCONF vector"
    ***
    ***
    Batch Machine Loader Server

    (BMLS)

        LWSCONF
    SERVER
    PAR&BMLS
    "LWSCONF vector"
    ***
    ***
    Batch Machine Operator

    (BMOP)

        LWSCONF
    SERVER
    "LWSCONF vector"

    ***

    CICS interface server

    (EHCTRAN)

        LWSCONF
    SERVER

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***

    "LWSCONF vector"

    ***
    Compression Server

    (EHCCOMP)

        LWSCONF
    SERVER

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***

    "LWSCONF vector"

    ***
    DDE Access Server

    (EHCLAD)

        LWSCONF
    SERVER

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***

    "LWSCONF vector"

    ***
    (*) Device Cluster Attachment DLC

    (DCADLC)



    LWSCONF
    SERVER
    PAR&DCA
    "LWSCONF vector"
    ***
    ***
    Electronic journal server

    (ELECJO##)

    EJOUPRF
    EJOUREC
    RECDEF
    RECFIELD
    "EJOUPRF vector"
    "EJOUREC vector"
    "RECDEF vector"
    "RECFIELD vector"
    LWSCONF
    SERVER
    PAR&EJOU

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Financial printer server

    (PR47X2##)

    FORM47X2 "FORM47X2 vector" LWSCONF
    SERVER
    PAR&47X2

    LWSCONF

    CLIENT
    SES&47X2
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***
    Forwarding server

    (FORWARD)

    FORWPRF
    FORWDS
    LUPOOL
    XLATETBL
    "FORWPRF vector"
    "FORWDS vector"
    "LUPOOL vector"
    "XLATETBL vector"
    LWSCONF
    SERVER
    PAR&FORW
    SES&FORW
    "LWSCONF vector"
    ***
    ***
    ***
    IBM 4731, 8, 9 Personal Banking Machine

    (SS#####)



    LWSCONF
    SERVER
    PAR&4731

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    IBM 4733 Teller Assist Unit

    (DTAU4733)



    LWSCONF
    SERVER
    PAR&4733

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    IBM 4737 Self-Service Transaction Station

    (SS######)



    LWSCONF
    SERVER
    PAR&4737
    PAR&PBMS

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***
    ***

    "LWSCONF vector"

    ***
    Java file distribution

    (JAVA)



    LWSCONF
    SERVER
    PAR&JAVA
    "LWSCONF vector"
    ***
    ***
    LANDP Link server

    (EHCLINK)



    LWSCONF
    SERVER
    PAR&LINK
    SES&LINK
    "LWSCONF vector"
    ***
    ***
    ***
    Local resource manager server

    (EHCLRMGR)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    (**) Logical device address (LDA) 7 program

    (LDA7)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&LDA7
    "LWSCONF vector"
    ***
    ***
    Magnetic stripe reader/encoder server

    (MSRE47##)



    LWSCONF
    SERVER
    PAR&MSRE

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    MQSeries Link server

    (EHCMQ##)



    LWSCONF
    SERVER
    PAR&MQ

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Multiple Virtual DOS Machine Relay

    (EHCVDMGR)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    Native X.25

    (X25NAT##)



    LWSCONF
    SERVER
    PAR&XNAT

    LWSCONF

    CLIENT
    SES&NSVC
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***
    Object Post Box Server

    (OPBS)



    LWSCONF
    SERVER
    PAR&OPBS

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ODBC Query Server

    (EHCODB##)



    LWSCONF
    SERVER
    PAR&ODB

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Operator Interface

    (OPER)



    LWSCONF
    SERVER
    "LWSCONF vector"

    ***

    PIN pad server

    (PINP47##)



    LWSCONF
    SERVER
    PAR&PINP

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Print manager server

    (PRTMGR)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    Program-to-program communication (PPC) server (LU 6.2)
    (PPC) if LANDP for OS/2 or LANDP for Windows


    LWSCONF
    SERVER

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***

    "LWSCONF vector"

    ***
    Query server

    (EHCSQL##)



    LWSCONF
    SERVER
    PAR&SQL

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Remote Change Management Services

    (RMCS)

    LUPOOL RCMSLNF XLATETBL "LUPOOL vector"
    "RCMSLNF vector"
    "XLATETBL vector"
    LWSCONF
    • SERVER
    • PAR&RCMS
    "LWSCONF vector"
    ***
    ***
    Searcher for electronic journal server and store-for-forwarding server

    (SFQUERY)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    Service Availability Manager.

    (EHCSAM)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    Shared DOS Directory

    (SHRDIR)



    LWSCONF
    SERVER
    PAR&SHDR

    LWSCONF

    CLIENT
    SES&SHDR
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***
    Shared-file distributor

    (EHCSFD##)

        LWSCONF
    SERVER
    PAR&SFD

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Shared-file replicator

    (EHCSFR##)

        LWSCONF
    SERVER
    PAR&SFR

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Shared-file server

    (SHFILE##)

    COLSQTBL
    SHFLDBD
    SHFLPCB
    RECDEF
    RECFIELD
    SHFLSGM
    "COLSQTBL vector"
    "SHFLDBD vector"
    "SHFLPCB vector"
    "RECDEF vector"
    "RECFIELD vector"
    "SHFLSGM vector"
    LWSCONF
    SERVER
    PAR&SHFL

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    SNA server

    (SNA##)

    LUPOOL
    X25DIR
    "LUPOOL vector"
    "X25DIR vector"
    LWSCONF
    SERVER
    PAR&SNA

    LWSCONF

    CLIENT
    SES&SNA
    SES&SPVC
    SES&SSVC
    SBSX25
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***
    ***
    ***
    ***
    Store-for-forwarding server

    (SFORFORW)

    SFORWPRF
    SFORWREC
    RECDEF
    RECFIELD
    "SFORWPRF vector"
    "SFORWREC vector"
    "RECDEF vector"
    "RECFIELD vector"
    LWSCONF
    SERVER
    PAR&SFOR

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    Synchronous data link control server

    (SDLC)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&SDLC
    "LWSCONF vector"
    ***
    ***
    System manager

    (SMGR)

    SMGRPRF
    SMGRUSER
    RECDEF
    RECFIELD
    "SMGRPRF vector"
    "SMGRUSER vector"
    "RECDEF vector"
    "RECFIELD vector"
    LWSCONF
    SERVER
    PAR&SMGR

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    System manager operator

    (SMOP)



    LWSCONF
    SERVER
    PAR&SMOP
    "LWSCONF vector"
    ***
    ***
    Distribution

    (SOFTPACK)

    SOFTPACK "SOFTPACK vector" LWSCONF
    SOFTPACK
    "LWSCONF vector"
    ***
    TCP/IP wide area communication server

    (EHCTCP)



    LWSCONF
    SERVER
    PAR&TCP
    SES&TCP
    LWSCONF

    CLIENT

    "LWSCONF vector"
    ***
    ***
    ***
    "LWSCONF vector"

    ***

    Token-ring data link control server

    (TRDLC)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&TKR
    "LWSCONF vector"
    ***
    ***
    Trace tools

    For LANDP for DOS (DDT)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    Trace tools

    For LANDP for OS/2 and LANDP for Windows(EHCTRACW)



    LWSCONF
    SERVER
    "LWSCONF vector"
    ***
    X.25 data link control server

    For IBM X.25 Co-Processor Adapters (X25DLC)



    LWSCONF
    SERVER
    PAR&X25D
    "LWSCONF vector"
    ***
    ***
    X.25 data link control server

    For IBM X.25 Interface Co-Processor/2 (X25DLC2)



    LWSCONF
    SERVER
    PAR&X252
    "LWSCONF vector"
    ***
    ***
    3270 Emulator

    (EMU3270)

    DEFAULTS
    DISPLATT
    KBD3270
    LUPOOL
    XLATETBL
    "DEFAULTS vector"
    "DISPLATT vector"
    "KBD3270 vector"
    "LUPOOL vector"
    "XLATETBL vector"
    LWSCONF
    SERVER
    PAR&3270
    SES&3270
    "LWSCONF vector"
    ***
    ***
    ***
    3287 Printer emulator

    (EMU3287)

    DEFAULTS
    LUPOOL
    P3287ATT
    XLATETBL
    "DEFAULTS vector"
    "LUPOOL vector"
    "P3287ATT vector"
    "XLATETBL vector"
    LWSCONF
    SERVER
    PAR&3287
    SES&3287
    "LWSCONF vector"
    ***
    ***
    ***
    (*) 4700 Virtual file support

    (VFILE)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&VFIL
    "LWSCONF vector"
    ***
    ***
    (*) 4700 Virtual volume support

    (RDVVOLS)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&VVOL
    "LWSCONF vector"
    ***
    ***
    4721 Printer integrator

    (PT4721)

    LUPOOL "LUPOOL vector" LWSCONF
    SERVER
    PAR&PT21

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    4721 Self service printer server

    (SP4721##)



    LWSCONF
    SERVER
    PAR&SP21

    LWSCONF

    CLIENT
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    4748 printer server

    (PR4748##)

    FORM4748 "FORM4748 vector" LWSCONF
    SERVER
    PAR&4748

    LWSCONF

    CLIENT
    SES&4748
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***
    4770 printer server

    (PR4770##)

    FORM4770 "FORM4770 vector" LWSCONF
    SERVER
    PAR&4770

    LWSCONF

    CLIENT
    SES&4770
    "LWSCONF vector"
    ***
    ***

    "LWSCONF vector"

    ***
    ***

    Server requirements

    The following defines the prerequisites for a workstation in order to load a server or a functional area.

    Server Workstation Requirements
    BIWP
    • Must be client of SNA##
    • If loaded in a VDM, the EHCVDMGR server must be in the same workstation.

    BMOP
    • Must be client of SMGR
    • Must be client of OPBS.

    BPP
    • Must be client of SNA##
    • The PR47X2## server must be in the same workstation.
    • If loaded in a VDM, the EHCVDMGR server must be in the same workstation.

    BMLS
    • Must be client of OPBS.

    EHCSFD##
    • Must be client of the SHFILE## servers, the EHCSFD## distributors, and the EHCSFR## replicators that are owned by the EHCSFD## distributor you define.
    • At least one SHFILE## server must be in the same workgroup.
    • At least one of the following conditions must be fulfilled:
      • A SHFILE## server in the workgroup is owned by the EHCSFD## distributor you define, through PAR&SHFL specifications.
      • A EHCSFD## distributor in the workgroup is owned by the EHCSFD## distributor you define, through PAR&SFD specifications.
      • A EHCSFR## replicator in the workgroup is owned by the EHCSFD## distributor you define, through PAR&SFR specifications.

    EHCSFR##
    • Must be client of the SHFILE## servers, the EHCSFD## distributors, and the EHCSFR## replicators that are owned by the EHCSFR## replicator you define.
    • At least one SHFILE## server must be in the same workgroup.
    • At least one of the following conditions must be fulfilled:
      • A SHFILE## server in the workgroup is owned by the EHCSFR## replicator you define, through PAR&SHFL specifications.
      • A EHCSFD## distributor in the workgroup is owned by the EHCSFR## replicator you define, through PAR&SFD specifications.
      • A EHCSFR## replicator in the workgroup is owned by the EHCSFR## replicator you define, through PAR&SFR specifications.

    EHCTCP
    • If being used to emulate the SNA## server, the SNA## server must be defined to run in the same workstation.
    • If being used to emulate the PPC server, the PPC server must be defined to run in the same workstation.

    ELECJO##
    • Must be client of SMGR
    • The SFQUERY server must be in the same workstation
    • The SHFILE## server must be in the same workstation.

    EMU3270
    • Must be client of SNA##
    • If loaded in a VDM, the EHCVDMGR server must be in the same workstation.
    • In DBCS mode, the EHCDBTR server must be in the same workstation.

    EMU3287
    • Must be client of SNA##
    • If loaded in a VDM, the EHCVDMGR server must be in the same workstation.
    • In DBCS mode, the EHCDBTR server must be in the same workstation.

    FORWARD
    • Must be client of SMGR
    • Must be client of SNA##
    • Must be client of SFORFORW.
    • In DBCS mode, the EHCDBTR server must be in the same workstation.

    LDA7
    • Must be client of SNA##
    • If loaded in a VDM, the EHCVDMGR server must be in the same workstation.

    OPBS
    • Must be client of SMGR
    • The SMGR profile must have, at least, one user defined
    • The SHFILE## server must be in the same workstation.

    PBMS
    • Must be client of SNA##
    • The SS###### server must be in the same workstation.

    PT4721
    • Must be client of SNA##
    • The SP4721## server must be in the same workstation.

    RCMS
    • Must be client of SNA##.
    • In DBCS mode, the EHCDBTR server must be in the same workstation.

    RDVVOLS
    • Must be client of SNA##, or
    • The DCADLC server must be in the same workstation.

    SDLC
    • The SNA## server must be in the same workstation.

    SFORFORW
    • Must be client of SMGR
    • The SFQUERY server must be in the same workstation
    • The SHFILE## server must be in the same workstation.

    SMOP
    • Must be client of SMGR.

    SNA##
    • In DOS, it must have a DLC server in the same workstation (DCADLC, SDLC, TRDLC, X25DLC, or X25DLC2).

    TRDLC
    • The SNA## server must be in the same workstation.

    VFILE
    • Must be client of SNA## in the same workstation.


    Server information

    Online help, including an example, is available for each LANDP functional area.

    You can use any text editor to call this online help. In the EHCHELP subdirectory of the EHCCUS directory, open with your editor:

      xxxxxxxx
    

    where xxxxxxxx stands for the name of the functional area.

    A list of the names follows:

    BIWP BMLS BMOP BPP
    DCADLC DTAU4733 EHCLAD EHCLINK
    EHCLRMGR EHCMQ## EHCODB## EHCSAM
    EHCSFD## EHCSFR## EHCSQL## EHCTCP
    EHCTRAN EHCVDMGR ELECJO## EMU3270
    EMU3287 FORWARD JAVA LDA7
    MSRE47## OPBS OPER PBMS
    PINP47## PPC PR47X2## PR4748##
    PR4770## PRTMGR PT4721 RCMS
    RDVVOLS SDLC SFORFORW SFQUERY
    SHFILE## SHRDIR SMGR SMOP
    SNA## SP4721## SS##### SS######
    TRDLC VFILE X25DLC X25DLC2
    X25NAT##      

    The VALSPEC utility program




    ehcodwl

    You have to run the validation procedure, VALSPEC, to validate customization data. This procedure reads customization data from the .SPC files, and checks the consistency of the data. The validation procedure generates data in the internal repository.

    Although the VALSPEC utility runs only in OS/2 or Windows, the data that is validated can apply to all platforms.

    Note:
    The graphical customization editor can also be used to perform the VALSPEC function. See Graphical Customization Editor for more information.

    Selecting workgroup configurations

    This section applies when you want to process more than one workgroup configuration at the same time.

    The LANLIMIT.SPC file is located in the EHCCUS directory. You can edit the LANLIMIT.SPC file using any text editor, and specify the workgroup configurations to be processed.

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    You cannot use both INCLUDE and OMIT statements at the same time.

    Comments must start with /* and end with */.

    The LANLIMIT.SPC file provided with the customization program has the following contents, and specifies that all the workgroup configurations will be processed.

        INCLUDE = *
    

    You can modify the LANLIMIT.SPC file to meet your requirements.

    Examples

    Example 1:

     /* LANLIMIT.SPC Example 1*/
        INCLUDE = GROUP2\*
        INCLUDE = GROUP4\CONF47
    

    Only the workgroup configurations located in the GROUP2 directory, and the workgroup configuration named CONF47 and located in the GROUP4 directory, will be processed.

    Example 2:

     /* LANLIMIT.SPC Example 2 */
        OMIT = GROUP6\*
    

    All the workgroup configurations, except for those located in the GROUP6 directory, will be processed.

    Example 3:

     /* LANLIMIT.SPC Example 3*/
        INCLUDE = GROUP8\*
        INCLUDE = \CONF13
    

    Only the workgroup configurations located in the GROUP8 directory, and the workgroup configuration named CONF13 and located in the EHCCUS directory, will be processed.


    Return codes

    The return codes generated by the validation procedure are classified into four types. The following list shows the types of return codes, starting with the least severe; an identifier for each type appears in parenthesis.

    1. Informative (I) : Some input might be missing or incorrectly specified.
    2. Attention or Warning (W) : Some secondary functions might not work correctly at the production sites.
    3. Error (E) : Some LANDP functional areas will not work correctly.
    4. Severe (S) : The execution will be ended.

    The identifier of the type of return code is displayed as the last character of the return code. For example, the following might be displayed on the screen:

    01159 I Host identification default for session not defined.
    

    This means that the validation procedure has ended with an informative return code.

    When running the validation procedure, you can specify the highest severity allowed.


    Starting the validation procedure

    You can display online information about the VALSPEC procedure.

    From the EHCCUS directory, enter:

      VALSPEC ?
    

    To start the validation procedure, from the EHCCUS directory, enter:

      VALSPEC [parm1] [parm2] [parm3]
    
    where:

    parm1
    Is an optional parameter to specify the type of data to be processed. The parameter value can be:

    COMMON
    To process common data such as defaults, records, profiles, and tables.

    LAN
    To process workgroup configuration data.

    MODELS
    To process model configuration data.

    When you specify LAN or MODELS, if there is no common data in the internal repository, COMMON is also assumed. If a COMMON.SPC file is available, this file is processed to generate common data. If a COMMON.SPC file is not available, a COMMON.SPC file, containing only the DEFAULT vector with no keyword, is generated and processed.

    parm2
    Is an optional parameter to specify the workgroup configuration to be processed. It applies when you process only one workgroup configuration.

    If the parameter is used, only the workgroup configuration specified is processed, regardless of the LANLIMIT.SPC file contents.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    The parameters can be specified in any order. The CUSPARM.LST file, which is generated in the EHCCUS subdirectory, contains the vectors and pointers to any problems that might arise.

    If you use the OS/2 Enhanced Editor with the LANDP customization editing tool, you can also start the validation procedure using that tool.

    Select the LANDP choice from the action bar in the editor window, and the Validate option in the pull-down that appears when you choose LANDP.

    For further information, select the View doc option in that pull-down.

    To avoid long processing, it is strongly recommended to run the validation procedure specifying first the COMMON parameter value. Then, if it applies, run the procedure specifying the MODELS parameter value. Finally, run the validation procedure again, specifying the LAN parameter value.

    In addition, when processing workgroup configuration data, you can select the workgroup configurations affected by the process. See Selecting workgroup configurations.

    Example

    VALSPEC LAN \Sample1
    

    This command validates the Sample1 workgroup configuration on the EHCCUS directory. Only informative return codes are allowed; higher severity return codes result in execution ending.


    Distribution

    This part describes how to distribute your LANDP configuration software to the workstations in your LANDP workgroup. It contains the following chapters:

    The GENRUN and GETGLOB utility programs "The GENRUN and GETGLOB utility programs"
    Distributing software "Distributing software"
    Distributing software using a distribution server "Distributing software using a distribution server"

    The diagram on the next page shows the stages of the distribution process.

    Figure 6. LANDP Distribution Process


    ehcgr085


    The GENRUN and GETGLOB utility programs




    ehcodwl

    The customization process creates software to be distributed to the production workstations.

    This chapter describes how to obtain that software and copy it to the distribution workstation.

    When the software is ready for distribution:

    • To distribute updates to DOS, OS/2, or Windows workstations in an existing workgroup configuration, you can use RCMS and NetView DM directly. For more information, see LANDP Servers and System Management.
    • To distribute a new workgroup configuration, refer to Distributing software.

    To obtain the software needed by the workstations:

    1. Generate run-time files.

      This step is always required, and is performed using the GENRUN procedure on the customization workstation.

      The GENRUN procedure reads data in the internal repository, created either by the migration procedure or the validation procedure, and generates run-time files. For each defined workstation, it generates a GETTING.SPC file that contains information about the software to be installed. The file is located in a directory where the directory name is the workstation ID.

      For information on how to run the procedure, refer to Starting the run-time generation procedure--GENRUN.

    2. Copy run-time files to the distribution workstation.

      This step is optional, and can be skipped if the customization workstation will be used for distribution purposes.

      If you have carried out the customization process on a unique customization workstation located in the development site, you need to copy the run-time files to the distribution workstation using the GETGLOB procedure on the customization workstation.

      The GETGLOB procedure creates, on a specified drive, an image of the customization directory structure corresponding to a specified workgroup configuration. Only one copy is made of the run-time files needed by the workgroup.

      If the distribution workstation cannot be accessed remotely, you can specify a diskette drive and create a diskette set with the customization image.

      For information on how to run the procedure, refer to Starting the procedure for getting customization data--GETGLOB.

    Although the GENRUN and GETGLOB utilities run only in OS/2 or Windows, the software generated can be distributed to all platforms.

    Note:
    The graphical customization editor can also be used to perform the GENRUN and GETGLOB functions. See Graphical Customization Editor for more information.

    Selecting workgroup configurations

    This section applies when you want to process more than one workgroup configuration at the same time.

    The LANLIMIT.SPC file is located in the EHCCUS directory. You can edit the LANLIMIT.SPC file using any text editor, and specify the workgroup configurations to be processed.

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    You cannot use both INCLUDE and OMIT statements at the same time.

    Comments must start with /* and end with */.

    The LANLIMIT.SPC file provided with the customization program has the following contents, and specifies that all the workgroup configurations will be processed:

        INCLUDE = *
    

    You can modify the LANLIMIT.SPC file to meet your requirements.

    Examples

    Example 1:

     /* LANLIMIT.SPC Example 1*/
        INCLUDE = GROUP2\*
        INCLUDE = GROUP4\CONF47
    

    Only the workgroup configurations located in the GROUP2 directory, and the workgroup configuration named CONF47 and located in the GROUP4 directory, will be processed.

    Example 2:

     /* LANLIMIT.SPC Example 2 */
        OMIT = GROUP6\*
    

    All the workgroup configurations, except for those located in the GROUP6 directory, will be processed.

    Example 3:

     /* LANLIMIT.SPC Example 3*/
        INCLUDE = GROUP8\*
        INCLUDE = \CONF13
    

    Only the workgroup configurations located in the GROUP8 directory, and the workgroup configuration named CONF13 and located in the EHCCUS directory, will be processed.


    Return codes

    The return codes generated by both the run-time generation procedure and the getting procedure are classified into four types. The following list shows the types of return codes, starting with the least severe; an identifier for each type appears in parenthesis.

    1. Informative (I) : Some input might be missing or incorrectly specified.
    2. Attention or Warning (W) : Some secondary functions might not work correctly at the production sites.
    3. Error (E) : Some LANDP functional areas will not work correctly.
    4. Severe (S) : The execution will be ended.

    The identifier of the type of return code is displayed as the last character of the return code. For example, the following is displayed on the screen:

    00011 S COMMON specifications must be processed
            before RUN TIME generation
    

    This means that the run-time generation procedure has ended with a severe return code.

    When running both the run-time generation and getting procedure, you can specify the highest severity allowed.


    Starting the run-time generation procedure--GENRUN

    You can display online information about the GENRUN procedure.

    From the EHCCUS directory, enter:

      GENRUN ?
    

    To start the run-time generation procedure, from the EHCCUS directory, enter:

      GENRUN [parm1] [parm2] [parm3]
    

    where:

    parm1
    Is an optional parameter to specify the type of data to be processed. The parameter value can be:

    COMMON
    To process common data, such as defaults, records, profiles, and tables.

    LAN
    To process workgroup configuration data.

    The default is LAN.

    When you change existing data, or add new data, to the COMMON.SPC file, you have to reprocess the workgroup configurations affected by the modifications.

    parm2
    Is an optional parameter to specify the workgroup configuration to be processed. It applies when you process only one workgroup configuration.

    If this parameter is used, only the workgroup configuration specified will be processed, no matter what the LANLIMIT.SPC file contains.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    To process data created by the validation procedure or the migration procedure, with return code 2 or 3, you have to specify parm3 with a parameter value equal to, or higher than, the return code obtained.

    To avoid lengthy processing, it is strongly recommended that you run the run-time generation procedure twice. Specify the COMMON parameter value on the first run and the LAN parameter value on the second run.

    In addition, when processing workgroup configuration data, you can select the workgroup configurations affected by the process. See Selecting workgroup configurations.

    Example

    GENRUN \Sample1
    

    This command generates the distributable workgroup configuration data files for the Sample1 workgroup on the EHCCUS directory. Only informative return codes are allowed; higher severity return codes result in execution ending.


    Starting the procedure for getting customization data--GETGLOB

    You can display online information about the GETGLOB procedure. From the EHCCUS directory, enter:

      GETGLOB ?
    

    To start the procedure for getting customization data, from the EHCCUS directory, enter:

      GETGLOB parm1 [parm2] [parm3]
    

    where:

    parm1
    Is a required parameter to specify the workgroup configuration to be processed.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm2
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    parm3
    Is an optional parameter to specify the path where the run-time files are to be copied. The parameter format is:
      path
    

    Replace path with the required path, for example D:. The default path is A:.

    The GETGLOB procedure creates on the specified drive an image of the directory structure generated during customization.

    Example

    GETGLOB \Sample1
    

    This command gets the customization data for the Sample1 workgroup configuration on the EHCCUS directory, and copies it to the A: drive. Only informative return codes are allowed; higher severity return codes result in execution ending.


    Distributing software




    ehcodwl

    After obtaining software for distribution, the run-time files are located in the distribution workstation. The distribution workstation can be the same as the customization workstation.

    From the distribution workstation, you distribute the files to the individual workstations. The software must be distributed from an OS/2 or Windows workstation, although it can be distributed to all supported platforms.

    You can accomplish this task in three ways:


    Return codes

    The return codes generated by both the run-time generation procedure and the getting procedure are classified into four types. The following list shows the types of return codes, starting with the least severe; an identifier for each type appears in parenthesis.

    1. Informative (I) : Some input might be missing or incorrectly specified.
    2. Attention or Warning (W) : Some secondary functions might not work correctly at the production sites.
    3. Error (E) : Some LANDP functional areas will not work correctly.
    4. Severe (S) : The execution will be ended.

    The identifier of the type of return code is displayed as the last character of the return code. For example, the following might be displayed on the screen:

    00042I A file is missing. Correct the error and run GETTING again.
    

    This means that the GETTING procedure has ended with an informative return code.

    When running both the run-time generation and the GETTING procedure, you can specify the highest severity allowed.


    Starting the getting procedure--GETTING

    You can display online information about the GETTING procedure. From the EHCCUS directory, enter:

      GETTING ?
    

    To start the getting procedure, from the EHCCUS directory, enter:

      GETTING parm1 [WS=parm2] [parm3] [parm4] [/W:parm5] [/S]
    

    where:

    parm1
    Is a required parameter to specify the workgroup configuration.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm2
    Is an optional parameter to specify the workstation in the workgroup configuration.

    The parameter format is:

      workstation name
    

    Replace workstation name with the name of your workstation, for example AA.

    The default is all workstations (WS=ALL).

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    Note that the only check that the GETTING program does is to ensure that all the software that is being copied to the specified path is available.

    parm4
    Is an optional parameter to specify the path where the run-time files are to be copied. The parameter format is either the drive name, for example A:, or a full path name ending with a backslash, for example B:\PLACE\. A maximum of three directory levels is allowed. The default is A:.

    If the target drive is demountable, and WS=ALL is specified (or defaulted) the copy must be targeted at the root directory, for example:

    getting \sample ws=all 1 a:\
    

    When running GETTING on Windows, the length of each directory name must be 8 characters or less.

    If, in the path you specify, a directory already exists with the workstation ID as the directory name, and the directory is not empty, the program can overwrite the contents before copying the run-time files to that directory.

    parm5
    Is an optional parameter to specify a working directory. The CUSPARM.LST file is to be generated in the EHCCUS directory that is created under the path you specify. The default is the current path.

    The parameter is required, if you run the GETTING procedure on different workstations simultaneously.

    The parameter format is:

      drive:[\directory\]
    

    Replace drive with the required drive name. Replace directory with any required directory name. Always include the final \ after the directory name.

    /S
    Is an optional parameter to specify that the files for the Server Based Computing (SBC) server for this workstation are to be distributed.
    Note:
    The /S parameter is not valid when WS=ALL is specified, either explicitly or by default.

    The /S parameter is used only for workstations that act as SBC servers. The files should be copied to the read-only directory (on the SBC server) that contains the files to be shared by the SBC clients. Refer to Appendix G, "LANDP using Server Based Computing" for more information about SBC servers.

    The GETTING program builds a GETTING.SPC file for each workstation. This file contains the names of all the files that are to be distributed to that workstation.

    The GETTING.SPC files are built for all SBC workstations, whether or not they are SBC servers or SBC clients. In addition, for an SBC server workstation, the GETTING program builds a GETWSVR.SPC file that contains the names of all the files that are to be distributed to that server workstation. It is this file that is used to determine which files are distributed to the SBC server when /S is specified.

    Example

      GETTING \Sample1 WS=AA 1 A:\
    

    This command reads the information from the GETTING.SPC files created by the GENRUN procedure in the EHCCUS directory. This information is held in the Sample1 workgroup configuration. The files for workstation AA are copied to the A: drive, home directory.

    Only information return codes are allowed. Higher severity return codes result in execution ending.


    Using the shared DOS directory server for distribution

    To distribute the files from the distribution workstation to the individual workstations in the workgroup, you can use the shared DOS directory server.

    Because this is a DOS process, all workstations involved must run DOS. This means that you must boot OS/2 and Windows workstations to DOS. The required version of the operating system is IBM DOS Version 7.1.

    The process is as follows:

    1. Create a diskette to be loaded in the distribution workstation. This workstation must be integrated in the workgroup, and will become the server workstation.
    2. Create diskettes to be loaded in the other workstations in the workgroup. These will become requester workstations.

      You must run the procedure to create diskettes (EHCDISTR) on the customization workstation. If you have installed only LANDP for OS/2 on your customization workstation, copy the LAN Support Program device drivers to the EHCCUS\EHCD600 directory before running the EHCDISTR procedure.

    3. Distribute software to the server workstation as well as to the requester workstations.

      See Distributing software to the workstations--GETDATA.

    Creating diskettes for the workstations--EHCDISTR

    If you plan to boot from the diskette, you must format the diskette with the system files included, by using the /S option on the FORMAT command. This can be done only from a DOS workstation.

    To create the diskette, from the EHCCUS directory, enter:

      EHCDISTR parm1 WS=parm2 [parm3] [parm4] [parm5] [parm6] [parm7]
    

    where:

    parm1
    Is a required parameter to specify the workgroup configuration.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm2
    Is a required parameter to specify the workstation in the workgroup that becomes the server workstation.

    The parameter format is:

      workstation name
    

    Replace workstation name with the name of your workstation, for example, AA.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    parm4
    Is an optional parameter to specify the type of diskette to be created. The parameter value can be:

    SVR
    Diskette for the distribution workstation (server)

    REQ
    Diskette for other workstataions (requester)

    The default is REQ.

    parm5
    Is an optional parameter to specify the target diskette drive. The parameter format is:
      path
    

    Replace path with the path you require. The default is A:.

    parm6
    Is a parameter to specify the shared directory to be used by the shared DOS directory server.

    The parameter applies only when you create the diskette for the distribution workstation. In this case, it is required.

    The parameter value must be the path on the distribution workstation where LANDP is installed. The parameter format is:

      /S:path
    

    Replace path with the path you require.

    parm7
    Is an optional parameter to specify a working directory. The CUSPARM.LST file is to be generated in the EHCCUS directory that is created under the path you specify.

    The parameter format is:

      /W:path
    

    Replace path with the path you require. The default is the current directory.

    Example

    EHCDISTR \Sample1 WS=AA
    

    This command creates the distribution diskettes for the Sample1 workgroup configuration. Workstation AA will become the server workstation.

    Only informative return codes are allowed; higher severity return codes result in execution ending.

    Distributing software to the workstations--GETDATA

    To distribute software to each workstation in the workgroup, insert the created diskette in the server or requester workstation and, if it applies, boot from that diskette.

    Then, on the server workstation, run the AUTOFBSS.BAT procedure.

    Finally, on the server and requester workstations, from the diskette drive, enter:

      GETDATA parm1 parm2
    

    where:

    parm1
    Is a required parameter to specify the workstation ID.

    The parameter format is:

      workstation name
    

    Replace workstation name with the name of your workstation, for example AA. It must be specified in upper case.

    parm2
    Is a required parameter to specify the path where the files will be located. The parameter format is:
      path
    

    Replace path with the path you require.

    Example

    GETDATA CC D:\LANDP
    

    This command is run on workstation CC. It gets the workstation configuration data from a distribution diskette, and places it on the LANDP directory on the D: drive. The remaining files are copied from the server.


    Modifying file contents

    To meet your own requirements, you might need to modify some files created by the customization program, or files such as CONFIG.SYS on the production workstation.

    Use the EHCADD utility program to add a new statement.

    Note:
    EHCADD is supported on OS/2 workstations only.

    The format of the command is:

      EHCADD path\nnnnnnnn.eee 'statement'
    

    where:

    path
    Is the path where the file to be modified is located.

    nnnnnnnn.eee
    Is the name of the file (filename plus extension).

    statement
    Is the statement to be added to the file.

    The statement is added at the end of the file. If the file does not exist, the utility program creates it.

    Example

    EHCADD C:\CONFIG.SYS 'REM updated'
    

    Use the EHCAPPEN utility program to append a new path to an existing statement.

    Note:
    EHCAPPEN is supported on OS/2 workstations only.

    The format of the command is:

      EHCAPPEN path\nnnnnnnn.eee 'identifier' 'entry'
    

    where:

    path
    Is the path where the file to be modified is located.

    nnnnnnnn.eee
    Is the name of the file (filename plus extension).

    identifier
    Identifies the statement that is to be modified. The parameter value can be:
    PATH
    To add the path at the end of a PATH or SET PATH statement.
    LIBPATH
    To add the path at the end of a LIBPATH statement.
    DPATH
    To add the path at the end of a DPATH statement.
    HELP
    To add the path at the end of a HELP statement.

    entry
    Is the path to be added to the statement.

    If the path specified as the entry parameter already exists in the statement, the command is ignored. If the statement specified in the identifier parameter does not exist, the utility program creates it.

    Example

    EHCAPPEN C:\CONFIG.SYS 'PATH' '.'
    

    You can create a CMD file that contains EHCADD and EHCAPPEN statements. The EHCADD and EHCAPPEN utility programs are located in the EHCO000 directory.

    To move a file from one directory to another, you can also include COPY statements, which copy files from one directory to another, and DEL statements, which delete files from a directory.

    To start the getting procedure with the BAT file or the CMD file, you must include a GETTING statement as shown in the following example:

      GETTING WS=%1 %2
      COPY %2\PGM1.EXE X:\aaa\PGM1.EXE
      DEL %2\PGM1.EXE
      EHCADD C:\CONFIG.SYS 'LASTDRIVE=G'
      EHCAPPEN C:\CONFIG.SYS 'LIBPATH' 'C:\aaa\xxx;'
    

    Distributing software using a distribution server




    ehcodwl

    You can distribute files from an OS/2 or Windows distribution workstation to DOS, OS/2, Windows, and Linux workstations using a disk that is shared between the distribution workstation and the individual workstations. Typically, the shared disk will be on a LAN drive.

    Or, you can use other shared mechanisms for distributing to DOS, OS/2, or Windows workstations. You can then use a distribution server, such as NetView DM/2, to distribute the workstation files to each workstation. This is sometimes referred to as distribution using CID.

    The task of distributing using CID is accomplished in two steps:

    1. Copy the workstation files onto the shared disk.

      This step is performed using the EHCIMAGE procedure on the distribution workstation. The distribution workstation must be running OS/2 to perform this step.

      The EHCIMAGE procedure uses the run-time files generated by GENRUN, copies all the necessary files onto the shared disk, and generates response files for each individual workstation.

      For more information on GENRUN, see Starting the run-time generation procedure--GENRUN.

    2. Copy the workstation files from the shared disk.

      This step is performed using the EHCCINST procedure and can run on DOS, OS/2, or Windows workstations.

      The EHCCINST procedure reads the response file for the workstation and copies the files for the individual workstation from the shared disk.

    Note that the above process does not support the distribution of Server Based Computing (SBC) server software.


    Selecting workgroup configuration

    This section applies when you want to process more than one workgroup configuration at the same time.

    The LANLIMIT.SPC file is located in the EHCCUS directory. You can edit the LANLIMIT.SPC file using any text editor, and specify the workgroup configurations to be processed.

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    You cannot use both INCLUDE and OMIT statements at the same time.

    Comments must start with /* and end with */.

    The LANLIMIT.SPC file provided with the customization program has the following contents, and specifies that all the workgroup configurations will be processed.

        INCLUDE = *
    

    You can modify the LANLIMIT.SPC file to meet your requirements.

    Examples

    Example 1:

     /* LANLIMIT.SPC Example 1*/
        INCLUDE = GROUP2\*
        INCLUDE = GROUP4\CONF47
    

    Only the workgroup configurations located in the GROUP2 directory, and the workgroup configuration named CONF47 and located in the GROUP4 directory, will be processed.

    Example 2:

     /* LANLIMIT.SPC Example 2 */
        OMIT = GROUP6\*
    

    All the workgroup configurations, except for those located in the GROUP6 directory, will be processed.

    Example 3:

     /* LANLIMIT.SPC Example 3*/
        INCLUDE = GROUP8\*
        INCLUDE = \CONF13
    

    Only the workgroup configurations located in the GROUP8 directory, and the workgroup configuration named CONF13 and located in the EHCCUS directory, will be processed.


    Copying files onto the shared disk--EHCIMAGE

    You can display online information about the EHCIMAGE procedure. From the EHCCUS directory enter:

      EHCIMAGE ?
    

    To start copying the run-time files onto the shared disk, from the EHCCUS directory, enter:

      EHCIMAGE [parm1parm2 parm3
    

    where:

    parm1
    Is an optional parameter to specify the workgroup to be processed. It applies when you want to copy only one workgroup to the shared disk.

    If the parameter is used, only the workgroup specified will be copied, regardless of the contents of the LANLIMIT.SPC file.

    The parameter format is:

      langroup\lanname
    

    Replace langroup with the name of the directory on which the workgroup configuration resides. If you omit langroup, EHCCUS is assumed.

    Replace lanname with the name of the workgroup configuration.

    parm2
    Is a required parameter to specify the path where the directory structure for the LANDP program files will be kept.

    parm3
    Is a required parameter to specify the path where the directory containing the response files for each workstation in the workgroups will be placed. One response file is generated for each workstation in every workgroup.

    The names of the response files created include the NetView/DM workstation name, as specified by the WSID keyword on the LWSCONF vector for the workstation. The default value for this name comprises the first six characters of the workgroup name and the two character workstation name.

    Example

    EHCIMAGE \DJV W:\DJV\IMG\EHC W:\DJV\RSP\EHC
    

    This command copies files from the LANDP installation directory to a directory tree that is similar to:

       W:\DJV\IMG\EHC                - Root directory for this CID directory tree
       W:\DJV\IMG\EHC\EHCCUS         - Customization root directory
       W:\DJV\IMG\EHC\EHCCUS\DJV     - Root directory for the DJV workgroup
       W:\DJV\IMG\EHC\EHCCUS\DJV\AA  - Information for the AA workstation
       W:\DJV\IMG\EHC\EHCCUS\DJV\BB  - Information for the BB workstation
       W:\DJV\IMG\EHC\EHCCUS\DJV\CC  - Information for the CC workstation
       W:\DJV\IMG\EHC\EHCCUS\EHCD100 - Customization files for DOS
       W:\DJV\IMG\EHC\EHCCUS\EHCO100 - Customization files for OS/2
       W:\DJV\IMG\EHC\EHCD600        - Common files for LANDP for DOS
       W:\DJV\IMG\EHC\EHCO600        - Common files for LANDP for OS/2
       W:\DJV\IMG\EHC\EHCN600        - Common files for LANDP for Windows
       W:\DJV\IMG\EHC\EHCL600        - Common files for LANDP for Linux
    

    This might create response files with the following names:

       W:\DJV\RSP\EHC\DJVAA.RSP      - Response file for workstation AA
       W:\DJV\RSP\EHC\DJVBB.RSP      - Response file for workstation BB
       W:\DJV\RSP\EHC\MYFILE.RSP     - Response file for workstation CC
                                       ('MYFILE' specified on the WSID on the
                                       LWSCONF vector for this workstation)
    

    EHCIMAGE checks that all the response files that are generated have unique names before performing the copy operation.

    Note:
    NetView DM/2 can only handle response file names of 6 characters or less. However, because the default response file created by EHCIMAGE uses the LAN name suffixed by the workstation name, the response file name can be greater than 6 characters. If it is greater than 6 characters, EHCIMAGE truncates the response file name to 6 characters, and a duplicate response might result.

    It is recommended that you use only the default response file names created by EHCIMAGE, because this reduces user error situations where the same WSID is specified by different workgroups.

    If you specify the WSID vector in a LANCONF.SPC, it overrides the default name created by EHCIMAGE only for that workstation.


    Copying the workstation files from the shared disk--EHCCINST

    You can display online information about the EHCCINST procedure. From the EHCCUS directory, enter:

      EHCCINST ?
    

    To start the EHCCINST procedure, from the distribution directory, enter:

      EHCCINST [/S:parm1] /T:parm2 /R:parm3 /L1:parm4 /L2:parm5
    

    where:

    parm1
    Is an optional parameter to specify the path where the files to be distributed are kept. The default is . (current directory), because EHCCINST is copied to the top of the distribution directory structure by EHCIMAGE.

    parm2
    Is a required parameter to specify the path where the files are to be copied.

    parm3
    Is a required parameter to specify the response file to be used for distribution to this workstation.

    parm4
    Is a required parameter to specify the location of the error log file. If you specify only a path (indicated by the use of a trailing backslash on this parameter), the error log file is placed in the directory that has a filename matching that of the response file, and an extension of L1.

    parm5
    Is a required parameter to specify the location of the history log file. If you specify only a path (indicated by use of a trailing backslash on this parameter), the error log file is placed in the directory that has a filename matching that of the response file, and an extension of L2.

    Example

    EHCCINST /S:X:\DJV\IMG\EHC /T:D:\EHC /R:X:\DJV\RSP\EHC\MYFILE.RSP
             /L1:W:\ERRS\MYFILE.ERR /L2:W:\HIST
    

    This command installs from the CID image directory X:\DJV\IMG\EHC, using the response file X:\DJV\RSP\EHC\MYFILE.RSP. The error log file is W:\ERRS\MYFILE.ERR and the history log file is W:\HIST\MYFILE.L2.

    EHCCINST does not update any system files (such as CONFIG.SYS) on the individual workstation. If such an update is required, you can update the response file for the workstation to invoke a user exit program.

    EHCCINST response files

    Although response files are generated by EHCIMAGE, you might want to perform additional tasks before or after EHCCINST transfers the LANDP files to the individual workstations. This can be done by enhancing the response file provided by EHCIMAGE.

    The response file read by EHCCINST can contain records which use the following keywords. They are processed in the order they are encountered.

    COPY
    This keyword takes two values, a source and a target. The source file is copied to the target file specification.

    INCLUDE
    This keyword takes one value, the file specification for another response file. This response is read and acted upon.

    USEREXIT
    This keyword takes one value, the file specification of a user exit to be invoked. The user exit program is passed one value, the target directory.

    LANDP.GETTING
    This keyword takes two values, the path of the directory used on the distribution machine to hold the run time files, and the file specification of the GETTING.SPC file for the individual workstation. When the LANDP.GETTING keyword is processed, the run-time files for the individual workstation are copied into the target path.

    The file specifications used by the COPY, INCLUDE, and USEREXIT keywords can start with one of the following substitution variables:

    $(Sourcedrive)
    The drive where the source files can be found.
    $(Sourcedir)
    The source directory specified on EHCCINST.
    $(Targetdrive)
    The target drive to which the files will be copied.
    $(Targetdir)
    The target directory to which the files will be copied.
    $(Responsedrive)
    The drive where the response file can be found.
    $(Responsedir)
    The directory where the response file can be found.

    Example

    USEREXIT=$(Sourcedir)\EXITS\PREPWS.CMD
    

    Using response files to update CONFIG.SYS

    Together with a user exit program, you can use user-written response files to update the CONFIG.SYS file for individual workstations. To do this, create new response files for each workstation of the form:

    USEREXIT=W:\USEREXIT\PREPWS.CMD
    INCLUDE=W:\DJV\RSP\EHC\DJVAA.RSP
    USEREXIT=W:\USEREXIT\FINISHWS.CMD
    REBOOT=YES
    

    The first user exit prepares the workstation for run-time files by ensuring that a copy of the workstation's original CONFIG.SYS has been saved.

    The include statement then includes the response file created by EHCIMAGE. This allows EHCIMAGE to be rerun at a later date without losing the new responses that specify the user exits.

    The final user exit then appends the CONFIG.ADD file created for the workstation to the original CONFIG.SYS and saves that as the workstation's new CONFIG.SYS.

    An example of the first user exit program, PREPWS.CMD, is:

    @MKDIR C:\ORIGINAL
    @IF NOT EXIST C:\ORIGINAL\CONFIG.SYS COPY C:\CONFIG.SYS C:\ORIGINAL
    

    An example of the second user exit program, FINISHWS.CMD, is:

    /* In REXX, since we need to be able to give a return code */
     
    /* Create the CONFIG.SYS from the original file and */
    /* the additions from LANDP                         */
    "@COPY C:\ORIGINAL\CONFIG.SYS+%1\CONFIG.ADD C:\CONFIG.SYS"
     
    /* Return to EHCCINST indicating that a reboot is required. */
    exit x2d("FE 00")
    

    Sample NetView DM change file profile

    A sample change file profile for NetView DM Change Distribution Manager (CDM) is shown below:

      TargetDir = D:\EHC
     
     Section Catalog
     Begin
        GlobalName  = LANDP2.DISTRIBUTION.REF.5.0
        ObjectType  = SOFTWARE
        Description = 'LANDP Version 5.0 Distribution files'
     End
     
     Section Install
     Begin
        Program             = $(SourceDir)\EHCCINST.EXE
        Parms               = /S:$(SourceDir) /T:$(TargetDir)
                              /R:$(ResponseFile) /L1:$(LogFile1)
                              /L2:$(LogFile2)
        SourceDir           = SA:\IMG\EHC
        WorkingDir          = $(TargetDir)
        ResponseFile        = SA:\RSP\EHC\$(WorkStatName).RSP
        GeneralResponsePath = SA:\RSP\EHC\$(WorkStatName).RSP
        Logfile1            = SB:\ERRS\$(WorkStatName).ERR
        Logfile2            = SB:\HIST\
     End
    

    It is best to use variables as much as possible, as this allows you to have just one change profile for all workstations in your workgroup. The $(WorkStatName) is the NetView DM workstation name, and might not be the same as your LANDP workstation name.

    It is helpful to create your NetView DM workstations with the same name as your LANDP workstation names, remembering to prefix the name with the workgroup name.


    Preparing LANDP platforms

    LANDP can run on the following platforms:

    This part describes how to prepare these platforms for the installation of LANDP. It contains the following chapters:

    Preparing OS/2 workstations "Preparing OS/2 workstations"
    Preparing Windows workstations "Preparing Windows workstations"
    Preparing Linux workstations "Preparing Linux workstations"
    Preparing DOS workstations "Preparing DOS workstations"

    Preparing OS/2 workstations




    ehc_0x00

    The first part of the chapter, Installing and configuring IBM OS/2 workstations, describes the requirements for installing the LANDP for OS/2 run-time files onto the OS/2 workstations. Some requirements relate to a specific server.

    The second part of the chapter, Modifying run-time files, describes the process of modifying the run-time files created by the customization program, according to your needs.

    The third part of the chapter, Installing run-time files, describes how to check for a correct installation of the run-time files.

    Appendix G, LANDP using Server Based Computing gives additional information about implementing LANDP for OS/2 on Workspace on Demand.


    Installing and configuring IBM OS/2 workstations

    The workstation files, which might typically be kept on diskettes, created for the OS/2 workstations do not contain any OS/2 system files. Therefore, before installing the LANDP for OS/2 operational files onto your OS/2 workstation, make sure that OS/2 is installed according to the existing recommendations.

    The LAN adapter and protocol support (LAPS) can be provided by one of the following products, or later versions:

    When working in DBCS mode, the operating system can be one of the following, or later versions, depending on your national language:

    Language Operating system Supported codepage
    Traditional Chinese IBM OS/2 T4.0 938, 950 (no defaults)
    Korean IBM OS/2 H4.0 949
    Simplified Chinese IBM OS/2 P4.0 1381, 1386 (no defaults)

    Installation requirements for NetBIOS transport protocol

    This section applies to LANDP for OS/2 workstations integrated in a LANDP workgroup that uses NetBIOS as the transport protocol.

    Table 5. Maximum Requirements for LANDP for OS/2 Workstations in a LANDP Workgroup

    Sessions nn
    Commands MIN(nn+2, 70)
    Names 1

    Where nn is the number of workstations in the LANDP workgroup minus 1. This value corresponds to the case when every workstation in the workgroup needs a NetBIOS session to all the workstations in the LANDP workgroup.

    To optimize the resources, for each workstation you can specify a lower value, which depends on the workstation requirements. This value refers to the number of workstations the workstation is related to - those to which it provides services, or from which it receives services.

    The resources have to be specified in the current PROTOCOL.INI file that is used by LAPS. You should take into consideration the requirements of other programs installed in the same workstation. If OS/2 LAN Server or LAN Requester is installed, take into account the resources assigned through the IBMLAN.INI file.

    Check the following statements in the PROTOCOL.INI file:

    [NETBEUI]
            .
            .
            .
          SESSIONS = nn      + (number of sessions used by other NetBIOS programs)
     
          NCBS = nn+2   + (number of commands used by other NetBIOS programs)
     
          NAMES = 1          + (number of names used by other NetBIOS programs)
             .
             .
             .
    

    In addition, check for the DEVICE statements that correspond to the following LAPS modules in the CONFIG.SYS file:

    Finally, add the DEVICE statement corresponding to the adapter used in the workstation, and any other DEVICE statement to meet your own requirements.

    For information on those statements, refer to the manuals of the corresponding products. See Appendix J, Bibliography.

    Installation requirements for TCP/IP transport protocol

    This section applies to LANDP for OS/2 workstations integrated in a LANDP workgroup that uses TCP/IP as the transport protocol.

    To use TCP/IP as an internal communications protocol for a LANDP workgroup, OS/2 TCP/IP must be installed and configured in those workstations defined to use this transport protocol.

    For detailed information, refer to the TCP/IP manuals. See Appendix J, Bibliography.

    For more information about the TCP/IP transport protocol, see Appendix E, Using TCP/IP for internal communication.

    Using TCP/IP X.25 support

    If you plan to use TCP/IP X.25 support for LANDP workstations internal communications, consider the limit of X.25 switched circuits supported by OS/2 TCP/IP, and the characteristics of this support.

    It is recommended that for each workstation-to-workstation session a circuit is always available when there is data exchange. Otherwise, the response time and session lost conditions might increase dramatically.

    Installation requirements for mixed transport protocols

    It is possible to use both the NetBIOS and the TCP/IP transports within the same workgroup. Workstations can be configured to use either NetBIOS, or TCP/IP, or both. However, each workstation must use the same protocols as the other workstations that they need to communicate with (related workstations).

    For example, if a workgroup has a SNA gateway with some clients configured to use the TCP/IP transport and some other clients configured to use the NetBIOS transport, the SNA gateway workstation must be configured to use both NetBIOS and TCP/IP transports.

    When a workstation is configured to use both transport protocols the required NetBIOS resources can be reduced to be sufficient for only the number of related workstations using the NetBIOS protocol.

    Installation requirements for workstations with SNA servers

    The LANDP for OS/2 SNA server uses the LUA interface that is provided by one of the following SNA communications providers:

    The workstation containing the SNA server must be defined in the appropriate SNA communications provider as the workstation connected to the host. All logical units types 0, 1, and 2 receiving services from the LANDP SNA server must be defined in the appropriate SNA communications provider of the workstation in which the SNA server is loaded; that is, the workstation that is connected to the host computer.

    In the configuration files of the appropriate SNA communications provider, you define the workstation profile and the SNA profiles. Within the SNA profiles you update the following sections:

    1. DLC profiles
    2. SNA local node characteristics
    3. SNA connections
    4. SNA LUA APIs

    If you do not use LU pooling support, you have to define as many LUA profiles as SNA sessions.

    If you plan to use LU pooling support, you have to group LUA profiles in LU pools. In this case, the number of LUA profiles depends on your configuration requirements.

    The profile name is a string of eight characters, which must comply with the following conventions:

           EHCxxnn 
    

    where:

    xx
    Has two different meanings:

    nn
    Is the SNA session identifier.

     
    Is one character you leave blank.

    The variable nn takes the following values.

    For the 3270 emulator:

    You can have five sessions running simultaneously in each workstation, with the identifiers numbered from 51 (for the first session) through 55 (for the fifth session). That is, the value for nn for the 3270 emulator ranges from 51 to 55.

    For the 3287 printer emulator:

    You can have five sessions running simultaneously in each workstation, with the identifiers numbered from 76 (for the first session) through 80 (for the fifth session). That is, the value for nn for the 3287 printer emulator ranges from 76 to 80.

    For RCMS:

    The value for the variable nn for RCMS is 33.

    For Forwarding:

    You can have three sessions running simultaneously, with the identifiers numbered from 37 (for the first session) through 39 (for the third session).

    For applications:

    For DOS applications, the variable nn can take the values of 1 through 15. For DOS user servers, it can take the values of 16 through 30.

    For OS/2 or Windows applications or user servers, the variable nn can take the values of 1 through 30. However, a modified SNA interface that allows for more than 30 user sessions per workstation is available when the SNA services are provided from an OS/2 or Windows workstation. When using this interface, the session identifier can be any two ASCII characters. The SNA session identifier part of the LUA profile name (defined under the appropriate SNA communications provider) can now be any two ASCII characters instead of just two decimal digits.

    For 4731 and 4737:

    The variable nn can take the values 34 and 35 for the 4731 Personal Banking Machine (PBM), and the value 34 only for the 4737 PBM.

    For the BIWP emulator:

    When the PC/Integrator version is running in an OS/2 VDM, the variable nn takes the value 63. For the PC Integrator/2 version running in OS/2 native, the variable nn takes the value 61.

    For the LDA 7 Program:

    When the PC/Integrator version is running in an OS/2 VDM, the variable nn takes the value 64. For the PC Integrator/2 version running in OS/2 native, the variable nn takes the value 62.

    Following is an example of communications provider definition of the SNA LUA profile names for a given workgroup, for which LU pooling is not used:

    Figure 7. Example of SNA LUA profile names in a workgroup (OS/2)

    ehcgr051

    These are the expected profile names in the communications provider for workstation XX (gateway):

    EHCAA01
    For the client workstation AA
    EHCBB01
    For the client workstation BB
    EHCCC51
    For the first emulator session in workstation CC
    EHCCC52
    For the second emulator session in workstation CC
    EHCDD33
    For the RCMS client workstation DD
    EHCEE33
    For the RCMS client workstation EE

    Then you specify the following profile parameters:

    Comment
    This entry is optional

    Local NAU address
    The address of the valid host connections

    DLC Type
    The DLC profile customized earlier for the gateway

    Note:
    If you use correlation tables, ensure that the Communications Server LUA level supports the corresponding definitions.

    Installation requirements to use the DC and QC functions

    The LANDP for OS/2 SNA server provides the define connection (DC) and query connection (QC) functions.

    These functions require that the communications provider is installed in the workstation where the SNA server is loaded.

    To use the DC and QC functions, the communications provider requires further configuration:

    1. Define as many X.25 directory entries as X.25 destinations you are to use.

      The following sample shows the most relevant fields in a X.25 directory entry definition:

      Directory Entry Name    ENTRY01
                              Directory Entry        Remote
                              Directory Type         SNA
                              Virtual Circuit Type   SVC
                              Link Name              PHYSLINK
                              Link Station Role      Secondary
                              Remote DTE Address     111111111
      
    2. Define a SNA connection for one of the X.25 directory entries you have defined. The X.25 directory entry you choose becomes the default for all the LUs over that SNA connection.

      The following sample shows the most relevant fields in a SNA connection definition:

      Link Name    LINK0002
                   X25 Directory Entry    ENTRY04
                   Node ID                05D 80002
      
    3. Define all dependent LUs (LUA and 3270 emulations). All the LUs in the same PU must be associated to the same SNA connection.

      The following sample shows the most relevant fields in a LU (LUA) definition:

      LU Name   EHCAA01
                Host Link Name   LINK0002 (to X25 SNA Connection)
                NAU Address      001
      

    All the subscriber numbers that become parameter values for the DC function must be defined as X.25 directory entries. These X.25 directory entries must not be referenced by any other SNA connection.

    Installation requirements for cryptography management

    The LANDP for OS/2 SNA server can manage cryptography.

    If cryptography is managed by the SNA server, copy the following files to the D:\CMLIB\DLL path, where D is the drive where the communications provider is installed.

    ACSRENCR.DLL
    ACSRDECR.DLL

    Installation requirements for workstations with native X.25 servers

    To run the native X.25 server, you have to provide some definitions for the communications provider configuration.

    You should provide the following definitions. The given values are mandatory.

    For the X.25 feature profiles:

    To ensure that all the communications provider files needed for X.25 management are located in the \CMLIB directory, reinstall the communications provider using a correctly defined configuration file.

    Installation requirements for workstations with PPC servers

    To run the PPC server, you have to provide some definitions for the communications provider configuration.

    The definitions that can be involved are shown in this section. However, you do not need to specify all the definitions in all the cases, due to the communications provider dynamic configuration.

    Most definitions and the resulting configuration should be regarded as a pattern to define your own configuration.

    For the workstation profile and automatic start options:

    Translation table
    The translation table specified in the workstation information option can be ACSGTAB.DAT.

    Local node characteristics

    Additional SNA features

    Connections, to peer node

    Installation requirements for TCP/IP wide area communications server

    LANDP for OS/2 workstations configured to use the TCP/IP wide area communications server must have OS/2 TCP/IP installed and configured.

    There must also be an EHCTCP.INI file to provide the information required to map LANDP sessions with SNA and PPC servers to TCP/IP protocols, ports and internet addresses. The file can be created with any text editor, but it is best practice to use the file as generated by LANDP customization. See SES&TCP on page *** for a description of the file contents.

    Installation requirements for workstations with LANDP link servers

    Workstations that are configured to use the LANDP link server must have TCP/IP installed and configured.

    Installation requirements for workstations with MQSeries Link servers

    A significant amount of planning and configuration is required for each MQSeries Queue Manager. For more details on MQSeries administration please refer to the MQSeries documentation. For book numbers and titles, refer to Appendix J, Bibliography.

    You can use the CRTMQM utility to define queue managers for use with the MQSeries Link server. When defining the queue manager, you should ensure that the queue manager has the same name as specified for the MQSeries Link server during customization.

    In addition to MQSeries naming requirements, the MQSeries Link server can only accept MQSeries names that comply with the following.

    The LANDP customizing process also imposes some restrictions on the naming of the MQSeries queue manager. For details, see the MQM_name parameter of the LOADER EHCMQ## statement in MQSeries Link server.

    A default queue manager can be defined on the MQSeries server when CRTMQM is run, by using the -q flag.

    It is suggested that the MQSeries Queue Manager is defined to have a maximum message length similar to the LANDP MQ Server. This can be achieved by use of the MQSeries attribute MaxMessageLength.

    The MQSeries Link server must be installed on an MQSeries Server so that the MQSeries Queue Manager is on the same workstation as the MQSeries Link server.

    For security control the MQSeries Link server relies on the services of the Object Authority Manager (OAM). If access to MQSeries entities is to be controlled, the access policies for the OAM have to be defined. This should be planned as part of the configuration of the MQSeries Queue Manager.

    Data conversion of messages has been enabled in the LANDP API with the GQ option EHCGQ_CONVERT. When requested, conversion is attempted by the MQSeries Queue Manager.

    Queues used by the MQSeries Link server should be predefined. Some sample queue definition files have been provided to aid application development. They can be found in \EHC\EHCO600\SAMPLES.

    Installation requirements for workstations with query servers

    You can use the IBM DB2 Universal Database Control Center to create and customize a database for the LANDP for OS/2 query server. The control center is part of the IBM DB2 Universal Database program suite. For information on creating and customizing a new database, refer to the IBM DB2 Universal Database User's Guide.

    When defining the parameters for the new database, consider the following:

    For enhanced performance and performance tuning information, see Tuning the LANDP for OS/2 query server.

    If you are migrating data definitions or Shared File data from a LANDP for DOS SHFILE## environment, refer to LANDP Programming Reference.

    Installation requirements for workstations with Windows 3.1 support

    If Microsoft Windows 3.1 support was specified at customization time, the EHCWIN.DLL file is distributed to the workstation.

    In addition, the multiple virtual DOS machine relay (EHCVDMGR) is required in the workstation.

    Installation requirements for Java support

    The LANDP Java support on OS/2 can be found in the following files located in the EHCO600 directory:

    LDPJAVA.JAR
    Java Archive File containing the LANDP Java classes

    LDPJMAN.EXE
    LANDP Java Manager

    LDPJDISP.EXE
    LANDP Java Dispatcher

    LDPJAVA.DLL
    DLL that implements the native methods of the LANDP Java classes

    LDPMSRE.JAR
    LANDP J/XFS device support for magnetic stripe readers

    LDPPINP.JAR
    LANDP J/XFS device support for PIN pads

    LDP47X2.JAR
    LANDP J/XFS device support for the 4722 financial printer

    To support the running of Java user servers, applications, applets or servlets on a LANDP workstation, these files should be copied to the directory on the workstation containing the LANDP files. For more details, refer to LANDP Programming Guide.

    These files can be distributed automatically with the LANDP files by specifying SERVER=JAVA in the LWSCONF definition for this workstation. However, note that this method of distribution does not distribute the documentation file ldpjdocs.zip, which is located in the EHCO600 directory.

    Once copied, edit CONFIG.SYS and make the following changes:


    Modifying run-time files

    The main areas of modification are:

    For a utility program to modify files, see Modifying file contents.

    Depending on which applications and servers you have developed, and which devices you have installed, you might need to copy additional files.

    When the shared-file server starts up, it creates the necessary shared-file directories if they do not already exist. This removes the need (which existed in some earlier LANDP releases) to call CREADB.CMD to create these directories.

    CONFIG.SYS contents

    The customization program creates a CONFIG.ADD file for each workstation that requires it. You should compare the CONFIG.ADD file with the CONFIG.SYS file in your workstation, and make the necessary modifications to merge them into one.

    You should specify the paths for the new device drivers and other files needed.

    You should take into account that the default LIBPATH statement created during OS/2 installation is:

      SET LIBPATH=.;C:\OS2\DLL
    

    and DLLs in the current directory can be accessed.

    Magnetic stripe reader/encoder server

    If you plan to load this server, the following statements are typical of those required in the CONFIG.SYS file. Full details of the statements can be found in the LANDP/DOS and LANDP/2 Support for Financial Magnetic stripe Readers/Encoders, SG24-4530.

    If the server supports a 4717 MSR/E:

      DEVICE=FIOAUXDD.SYS /M /P
    

    where /P should be specified only if a PIN pad server will also be loaded in the workstation.

    If the server supports a 4777 MSR/E:

      DEVICE=FIOSERDD.SYS /Cp /M /P
    

    where /P should be specified only if a PIN pad server will also be loaded in the workstation. The p parameter value corresponds to the COM port where the 4777 MSR/E will be attached.

    If the server supports a 4778 MSR:

      DEVICE=FIOSERDD.SYS /Cp /P /S
    

    where /P should be specified only if a PIN pad server will also be loaded in the workstation. The p parameter value corresponds to the COM port where the 4778 PIN pad MSR will be attached.

    If a 4777 or 4778 device is mouse attached:

      DEVICE=FIOAUXDD.SYS /M
    

    PIN pad server

    If you plan to load this server, the following statements are required in the CONFIG.SYS file.

    If the server supports a 4718 PIN pad, and a magnetic stripe reader/encoder server will not be loaded in the workstation:

      DEVICE=FIOAUXDD.SYS /P
    

    If the server supports a 4778 PIN pad, and a magnetic stripe reader/encoder server will not be loaded in the workstation:

      DEVICE=FIOSERDD.SYS /Cp /P
    

    The p parameter value corresponds to the COM port where the 4778 PIN pad MSR will be attached.

    If a 4778 device is mouse attached:

      DEVICE=FIOAUXDD.SYS /P
    

    Virtual DOS machine relay (VDM)

    If you plan to load this server, the following statement is required in the CONFIG.SYS file:

      DEVICE=<drive> <path> EHCVDMVD.SYS
    

    where:

    drive
    Is the drive on which the device is located.

    path
    Is the directory on which the device is located.

    Financial printer server

    If you plan to load this server, the following statement is required in the CONFIG.SYS file:

      DEVICE=<drive> <path> OS2PRT.SYS /Dd /Bnm /Cnp
    

    where:

    drive
    Is the optional disk or diskette drive.

    path
    Is the directory-search sequence to locate the OS2PRT.SYS file.

    d
    Is the number of physical devices that are attached to the workstation.

    The parameter value ranges from 1 to 8. The default is 1.

    np
    Associates the logical device driver n. with the physical COM port p.

    Valid values for both n and p range from 1 to 8, with a default of 1.

    nm
    Associates the logical device driver n with the communication speed setting for its physical device m.

    The parameter value for n ranges from 1 to 8, with a default of 1.

    The parameter value for m is the baud rate of the device, in bits per second. Its value can be 9600, 4800, 2400, 1200, 600, 300, and 150. The default is 9600.

    IBM 4712 and 4722 printers use the 4772PDD.SYS device driver (for more information see 4772 or 9068-S01 printer).

    Note:
    4772 printer drivers supersede OS2PRT.SYS files. The information in the section above is retained for compatibility with older printers.

    4770 printer server

    If you plan to load this server, the following statement is required in the CONFIG.SYS file.

      DEVICE=<drive> <path> COS2PRT.SYS /D:d /B:nm
    

    where:

    drive
    Is the optional disk or diskette drive.

    path
    Is the directory-search sequence to locate the COS2PRT.SYS file.

    d
    Is the number of physical devices that are attached to the workstation.

    The parameter value ranges from 1 to 8. The default is 1.

    np
    Associates the logical device driver n with the physical COM port p.

    Valid values for both n and p range from 1 to 8, with a default of 1.

    nm
    Associates the logical device driver n with the communication speed setting for its physical device m.

    The parameter value for n ranges from 1 to 8, with a default of 1.

    The parameter value for m is the baud rate of the device, in bits per second. Its value can be 9600, 4800, 2400, 1200, 600, 300, and 150. The default is 9600.

    4772 or 9068-S01 printer

    The 4772PDD.SYS driver must be loaded if you plan to use a 4772, 9068-S01, 9068-A01, or 9068-A03 printer. The 4772PDD.SYS driver can also be loaded for 4712 and 4722 printers.

    The following statement is required in the CONFIG.SYS file:

      DEVICE=<drive> <path> 4772PDD.SYS [/Dd] [/Bnm] [/Cnp]
    

    where:

    drive
    Is the optional disk or diskette drive.

    path
    Is the directory-search sequence to locate the 4772PDD.SYS file.

    d
    Is the number of 4772 printers attached.

    The parameter value ranges from 1 to 3. The default is 1.

    nm
    Associates the logical device driver with the communication speed setting for its physical device:

    n
    Is the logical device driver. The parameter value ranges from 1 to 3.

    m
    Is the baud rate of the device, in bits per second.

    The parameter value can be 9600, 4800, 2400, 1200, or 600. The default is 9600.

    np
    Associates the logical device driver n with the physical COM port p.

    The driver has to be customized if a 4770 device, and a 47X2 or a 9068-S01 printer, is to be included. The customization program 4772OCUS.EXE is on the 4772 device driver diskette, along with a detailed description in its READ.ME file, describing how and why the customization is done.

    4748 printer server

    The following statement is required in the CONFIG.SYS file if you plan to load this server for each 4748, 9055-001, or 9068-D01 printer connected to an RS-232 port:

      DEVICE=<drive> <path>COM.SYS
    

    where:

    d:
    Is the drive on which the device is located.

    path
    Is the directory path of the asynchronous device driver
    Note:
    COM.SYS is provided in OS/2 Warp Version 4 onwards as a standard device driver. (It is provided as COMDMA.SYS for PS/55, 5560, 5580, and PS/2 models 57, 90, and 95 workstations.)

    If you plan to use the 9055-001 or 9068-D01 printer, you can use the same device driver as for the 4748 printer (but it provides support only for 4748 emulation mode).

    If the extra features of these printers are to be used (for example, REMS), change the device driver name in your CONFIG.SYS file to:

      DEVICE=<drive> <path>FPRTSCPx.SYS [/B:bbbb] [/X]
    

    4733 teller assist unit

    If you plan to use a 4733 teller assist unit, you must specify the following statement in your CONFIG.SYS file:

      DEVICE=TCD3862.SYS
    

    AUTOFBSS.CMD contents

    The AUTOFBSS.CMD file contains the loading statements of the supervisor and the servers that are to reside on the workstation. The first program loaded is the supervisor.

    Ensure that any modification of this file does not cause a server to be loaded before the supervisor. Application loading statements should be placed at the end of the server loading statements.

    Note:
    To get trace and log information about the loading process, you have to load the LANDP trace tool (EHCTRACW) immediately after the supervisor.

    The following is an example of a AUTOFBSS.CMD file for a workstation that contains the SNA server. The name of the workstation is AB.

        LOADER SPV.EXE /AB
        IF ERRORLEVEL 1  GOTO END
        LOADER LAN.EXE
        IF ERRORLEVEL 1  GOTO END
        LOADER SNA##.EXE
        IF ERRORLEVEL 1  GOTO END
        GOTO OK
        :END
        EHCFREE SPV /F
        EXIT
        :OK
    

    If the workstation is in a LANDP workgroup that uses TCP/IP as transport protocol, specify EHCLIP.EXE instead of LAN.EXE.

    If the LANDP workgroup uses mixed transport protocols, and the workstation needs to use both transport protocols, include LOADER statements for both LAN.EXE (for NetBIOS) and EHCLIP.EXE (for TCP/IP).

    You can specify the EXIT command to close the OS/2 session, and leave LANDP for OS/2 running in the background. After the :OK label, you can specify an OS/2 command to invoke a LANDP for OS/2 application.

    In order to get an information window about LANDP for OS/2 status, and a LANDP for OS/2 icon, you should invoke the EHCINFO utility program. EHCINFO is a LANDP utility program; it is described in LANDP Servers and System Management. Alternatively, a command line version, EHCCINFO, is available.

    Loading statements for LANDP for OS/2 servers

    Most loading statements explained in this section are automatically created by the customization program, using the parameters you provided. The following commands appear in the AUTOFBSS.CMD provided by customization. Manual modifications can be done if need be. The LOADER command is used to run the servers and the supervisor, in the background. You can use any OS/2 command (such as DETACH or START) to run these programs since they are regular OS/2 programs. Note that using the LOADER command displays the return codes corresponding to the initialization process.

    The LOADER program provides the optional parameter T to specify the timeout for a specific server load:

      LOADER [/T:xxxxservername serverparms
    

    The timeout value xxxx can be up to four characters long. The minimum is 1, the maximum 3600 seconds. If a timeout is not specified, the default used when loading the server is 30 seconds.

    If the initialization works without errors, the server performs initialization, then goes into a wait state until it receives a request from an application. If an initialization error occurs, it is logged in the error log file. This file is named EHCLOGxx.DAT, where xx stands for the workstation ID.

    To check the type of errors, use IF ERRORLEVEL statements. If a LANDP error occurs, the corresponding return code is provided. If an OS/2 error occurs, the value 1 is provided.

    For return codes during loading, refer to LANDP Problem Determination.

    The following commands are used when you load the LANDP for OS/2 functional areas.

    Banking printer program (BPP)

    The banking printer program (BPP), part of the IBM Financial Branch System Integrator/2 program, provides financial printer support that enables IBM 4700 application programs to use IBM 4712 and IBM 4722 printers (or IBM 9068 and 9069 printers in 4722 or 4712 emulator mode respectively) that are attached to the workstation.

    The loading statements for BPP are described in IBM Financial Branch System Integrator/2 Programmer's Reference. LANDP for OS/2 provides an extra parameter for BPP that allows printer sharing between the 4700 and local applications, as described below.

    [/Y:nnn]
    

    where:

    nnn
    Is the interval, in seconds, for which BPP holds the printer after a write from the 4700 application has completed. The printer is then released for use by local applications. When the next 4700 request is received either to write to or set the parameters for the printer, the printer is reacquired. If the printer is in local mode and a write request is received, the previous set of device parameters is restored first.

    nnn must be in the range 001 to 255. All three digits must be specified. A value of 000 means that BPP holds the device indefinitely (as is the case without this new parameter). BPP reacquires the device automatically when a print request is received from the 4700 application.

    The PRTMON.EXE utility must be installed to enable OS/2 printing to a serial-attached printer. This utility is shipped with the IBM printer drivers.

    Batch machine loader server

    LOADER BMLS.EXE /N:bmlname /P:progname [/D:workdir] [/T:yyy]
    

    where:

    bmlname
    Is the public user ID used by the object post box server.

    progname
    Is the name of the program called by the batch machine loader server when a message is pending in the message queue.

    workdir
    Is the working directory for the program. The default is the current directory.

    yyy
    Is the priority for batch machine loader server processor. The parameter value can be:
    1
    Idle
    2
    Normal
    3
    High
    4
    Very high

    The default is 3.

    Batch machine operator

    START BMOP [/U:userid] [/P:password] [/J:jobname]
    

    where:

    userid
    Is the user ID used to logon to the system manager. It can be a maximum of eight characters.

    password
    Is the password used to logon to the system manager. It can be a maximum of eight characters.

    jobname
    Requests loading of the job definition stored in the file jobname. The name and path can be a maximum of 80 characters.

    CICS interface server

    LOADER EHCTRAN.EXE
    

    DDE access server

    START EHCLAD.EXE
    

    Electronic journal server

    LOADER ELECJO##.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the electronic journal records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Forwarding server

    LOADER FORWARD.EXE /O:vvvvvvvv.vvv [/T:wwww] [/S:xxxxxxxx.xxx] [/K:y] [/H:z]
                           [/Z:nnnn]
    

    where:

    vvvvvvvv.vvv
    Is the name of the file corresponding to the ASCII-to-EBCDIC translation table. It must follow the operating system rules.

    wwww
    Is the number of time ticks after which the supervisor dispatches the forwarding function. One time tick is roughly 0.05 seconds.

    It can range from 1 to 6000. The default is 20 (about 1 second).

    xxxxxxxx.xxx
    Is the name of the file corresponding to the sign-on feature. It must follow the operating system rules.

    y
    Is the size, in KBs, of the buffer used to read the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the value assigned in the loading statement of the store-for-forwarding server.

    z
    Specifies whether headers are included when sending host computer messages. The parameter value can be Y, to include headers, or N, not to include headers. The default is Y.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China
     
    (the default value is 935)
    937
    Taiwan

    LAN server

    LOADER LAN.EXE [/N:n[,n,...]] [/I:x] [/S:y] [/U:s[,s,...]]
    

    where:

    n[,n,...]
    Represents the logical adapter numbers used by the LAN.EXE program. These must match the values defined for the NetBIOS protocol driver during NetBIOS configuration.

    The parameter value can range from 0 to 3. The default is 0.

    You can specify a series of up to four adapter numbers. This enables you to configure a server which provides services to workstations on two or more otherwise unconnected LANs. For example, /N:0,1,2,3, tells LAN.EXE to use all four adapters.

    x
    Is the time interval, in seconds, between attempts to establish the required NetBIOS sessions.

    The parameter value can be 0 or in the range 5 through 3000. The default is 20 seconds. If a value of 0 is specified, only one attempt is made to establish each session, at startup, or after a session has been lost.

    y
    Is the NetBIOS send timeout, in seconds.

    The parameter value can be 0 or in the range 10 through 127. The default is 10 seconds. A value of 0 implies no timeout.

    s[,s,...]
    Represents the number of NetBIOS sessions to be made via each adapter. The s values correspond to the adapters specified on the /N parameter. For example, the first s value after /U corresponds to the first n value after /N, and so on.

    The parameter values can range from 0 to 254, provided sufficient sessions have been defined during NetBIOS configuration. If the parameter is omitted, or specified as 0, then enough sessions for all the related workstations are used. The total number of sessions specified must be not less than the number of related workstations.

    The LAN server is needed only when more than one workstation is present in a LAN. It is included during the process of creating diskettes for distribution.

    LANDP Internet Protocol

    LOADER EHCLIP.EXE [/N:n] [/Y] [/T] [/C[:ws-id]] [/O:o[filename]] [/J]
    

    where:

    n
    Specifies the TCP/IP port number used by LANDP Internet Protocol.

    The parameter value ranges from 1024 to 65535. The default is 52699.

    Y
    Specifies that no availability probe datagram is sent when a session has no normal traffic.

    T
    Requests LANDP Internet Protocol internal routines trace.

    C
    Requests LANDP Internet Protocol communications trace. All sessions are traced, except when the ws-id parameter is specified. In this case, only the session with the workstation specified in that parameter is traced.

    o
    Specifies the destination of trace data. The parameter value can be:

    1
    Standard output.

    Note that the screen is the usual output, and requires that LANDP Internet Protocol is loaded in the foreground, with the DETACH or START command.

    2
    ASCII file. If you do not specify a name of file, the trace data is stored in the LIPTRACE.TRC file. The target file is initialized each time. Thus, if an existing file is used, the file contents get lost.

    3
    EHCTRACW (the default).

    J
    Specifies that no checking for related workstations with undefined LANDP Internet Protocol addresses is carried out.

    LANDP link server

    LOADER EHCLINK.EXE [/T] [/E:eeeeeeee[,eeeeeeee...]]  [/I:iiiiiiii[,iiiiiiii...]
                       /L:llllllll [/A:aaaaaaaa [,aaaaaaaa...]] [/R:rrrr]] [/P:ppppp]
    

    where:

    T
    Turns on component internal tracing.

    eeeeeeee
    Are the names of up to 10 services to be exported. Only these local workgroup services are made available to remote workgroups. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    iiiiiiii
    Are the names of up to 10 services to be imported. Only these remote workgroup services are made available in the local workgroup. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    llllllll
    Is the TCP/IP network name, or the IP address of the workstation running the LANDP link server that is exporting services. Network names must be resolvable to IP addresses by the domain name server or the local HOSTS file.This parameter must be present when, and only when, the imports parameter is also specified.

    aaaaaaaa
    Are alias names of services to be imported. The names in the alias parameter correspond one-to-one with the names in the imports parameter. If an alias is specified, an imported service will be made available with the corresponding alias name. If the alias parameter is absent, or if the corresponding alias name is null, the imported service will be made available without the name being changed. Names must not appear more than once in this parameter. If an import name has trailing '#' characters, the corresponding alias name must have the same '#' characters. This is an optional parameter that is allowed only if the imports parameter is also specified.

    rrrr
    Is the connection retry interval in seconds. It is in the range 0 through 3276. A value of 0 means no retry. The default retry interval is 30 seconds. This is an optional parameter that is only allowed when the imports parameter is also specified.

    ppppp
    Is the TCP/IP port number. It is in the range 1024 through 65535. The default value is 52699. To make a connection the exporting LANDP link server and the importing LANDP link server must use the same TCP/IP port. This is an optional parameter.

    The LANDP link server can act as both an exporter and an importer of services. It can do both at the same time, if required.

    There can be any number of exporters and importers in a workgroup and in a workstation, but only one exporter on each workstation can use each TCP/IP port number.

    Magnetic stripe reader/encoder server

    LOADER MSRE47##.EXE
    

    MQSeries Link server

    
    
    LOADER EHCMQ## [/Q:MQM_name] [/L:lllll] [/M:m] [/P:[d:[path]]] [/T:tt] [/S:ss]
    

    where:

    MQM_name
    Is the MQSeries Queue Manager Name.

    This parameter specifies the name of the queue manager to which the server is to connect. The parameter can be a string that conforms to the rules defined for MQSeries object naming.

    Alternatively, the parameter can define an environment variable, for example, '%MQMNAME%', which is resolved when the AUTOFBSS file is processed. The special characters '%' and '/' should not be used in the queue manager name.

    If this parameter is omitted or entered as spaces, EHCMQ## connects to the default MQSeries queue manager.

    lllll
    Specifies the maximum message length permitted by the MQSeries Link server. This is used to restrict the maximum message length to something less than the default of 57,000 bytes. The variable lllll can take a value between 1000 and 57,000.

    m
    Specifies the message detail level to be written to the log file. The variable m can have the values E|W|I where E=errors, W=warnings and I=info. I includes levels W and E, W includes level E. If m is omitted, logging is switched off, which is the default.

    d
    Is the drive where the log files are created. If this parameter is omitted, the drive defaults to the drive of the current working directory for the EHCMQ## process.

    path
    Is the path where the log files are created, which defaults to 'EHCMQLOG'. If a path is specified, a drive should also be defined. If both drive and path are omitted, 'EHCMQLOG' is created as a sub- directory of the current working directory for the EHCMQ## process.

    A log file is created for each workstation that initiates a session. The log file is named as XXhhmmss.ddd, where

    The maximum length of the combined /P arguments, d and path, must not exceed 128 bytes

    tt
    Is the total number of permitted sessions.

    This parameter specifies the maximum number of different sessions that the server can process at the same time. The parameter is optional, and can be in the range 1 to 64. The default is 32.

    ss
    Is the number of MQ connections that should be made at startup. Every session requires a MQ connection, which can be made at startup or as session requests are received. The parameter is optional, the variable ss can be in the range 0 to tt. The default value is 0. When this option is non-zero, the LOADER server's timeout probably needs to be increased. Refer to Loading statements for LANDP for OS/2 servers.

    Native X.25 server

    LOADER X25NAT##.EXE
    

    Object post box server

    LOADER OPBS.EXE
    

    PIN pad server

    LOADER PINP47##.EXE /M
    

    where /M indicates that 4778 magnetic stripe reader capabilities are to be used.

    Program-to-program communication server

    LOADER PPC.EXE [/FA] [/FS] [/D:nn]
    

    where:

    FA
    Specifies MC_FLUSH after ALLOCATE, as a result of an Open Services (OP) function.

    FS
    Specifies MC_FLUSH after a Send Data (SD) function.

    When the application sends data to the partner application program, the data is stored in buffers that are automatically flushed, and is immediately sent to the partner application. Note that this option might affect the workstations and the network performance.

    nn
    Is the buffer pool that the PPC server initializes to send data to or receive data from the communications provider The default is 16.

    Query server

    LOADER EHCSQL##.EXE [/C:s] [/P:y] [/S:z] [/T:x] [/F] [/W:q] [/EL]
    

    where:

    s
    Is the Database Manager database name the server works with.

    y
    Is the number of processes. This is the maximum number of simultaneous processes that the server can support at a given moment. It must be big enough to satisfy the application requirements. The default value is 4.

    z
    Is the number of sessions. This is the maximum number of working sessions that a workstation is allowed to open by issuing the open session function (OS). The default value is 10. This includes the current number of different applications connected to the server at a given time (one session per application).

    x
    Is the number of threads. This is the maximum number of requests that can be processed simultaneously. The default value is 5.

    x should be slightly larger than y The defaults of 5 and 4 are suitable in most installations. If you are using Distributed Database Connection Services/2(R) (DDCS/2) to communicate with a remote DB2(R) database (for example, DB2 on a mainframe), it is advisable to increase the /T and /P parameters. Suggested values are 8 and 7.

    /F
    Stands for fast cursor operation. If you do not include this parameter, the index search is forced by the server when issuing functions and working in shared file mode. This switch can be added if you want improved throughput without an index search in some cases.

    q
    Specifies (in seconds) the timeout value to wait for an SQL response. The default value is 15. If a request is not satisfied within the specified time, the sentence is interrupted, and an error code appears:
    RL
    Resources locked (shared file mode)
    TE
    Timeout error (query mode)

    If you use Query Server in Shared File mode, set the /W parameter high enough for a call to complete before it is timed out. When increasing this parameter, keep it less than the LAN timeout value. If the LAN times out first, the result of the query call is lost.

    /EL
    Stands for logging enabled. If you do not include this parameter, the server does not enable logging.

    At load time it is not necessary to have Database Management Services started, but if the selected database is protected with a logon password, a logon procedure must have been run previously. This can be done interactively by accessing User Profile Management, or by using the LOGON command. For example:

    LOGON USERID /P=PASSWORD.
    

    An attempt to load this server before you have logged on, will not be successful, and you will get a return code of RC=152.

    For information on enhanced performance and performance tuning, see Tuning the LANDP for OS/2 query server.

    Remote change management services

    LOADER RCMS.EXE /I:xxx /O:yyy [/T:ttt] [/L:n] [/P:q] [/C:x] [/R:r]  [/Z:nnnn]
    

    where:

    xxx
    Is the file extension of the EBCDIC-to-ASCII translation table (EARCMS.xxx). In DBCS mode the parameter does not apply.

    yyy
    Is the file extension of the ASCII-to-EBCDIC translation table (AERCMS.yyy). In DBCS mode the parameter does not apply.

    ttt
    Is the number of timer ticks after which RCMS receives control. One timer tick is roughly 0.05 seconds. The default is 10. The value must be a decimal number in the range 1 to 999, For example:
    /T:1, /T:2,  or  /T:55
    

    n
    Specifies the number of lines in the EHCRCMS.LOG file. The parameter value can range from 100 to 10000. The default is 1000.

    Attention: If an EHCRCMS.LOG file with n1 lines exists already, and you choose a value for the L parameter that is different from n1, your old file is destroyed and a new one is created. If you want to keep the old file, rename it or copy it to somewhere else before running the LOADER program.

    q
    Specifies the translation mode. The parameter applies only to DBCS mode. The parameter value can be:

    S
    Standard ASCII-EBCDIC and EBCDIC-ASCII translation

    P
    ASCII-EBCDIC translation with ASCII SI/SO characters changed to EBCDIC SI/SO characters, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to ASCII SI/SO characters

    B
    Standard ASCII-EBCDIC translation, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to blanks.

    x
    Specifies the reception mode for CLISTs. The parameter value can be:
    B
    The CLIST is received as a binary file.
    E
    The CLIST is received as an EBCDIC file.

    The default is E.

    r
    Is the interval, in minutes, before retrying a connect to SNA and communications provider after a communications problem. The value must be an integer in the range 0 (which is taken to mean 30 seconds) and 1440 (24 hours). The default value is 0.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    Searcher

    LOADER SFQUERY.EXE [/K:y]
    

    where y is the size, in KBs, of the buffer used to read the electronic journal and store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the highest of the values assigned in the loading statements of the electronic journal and store-for-forwarding servers.

    This loading statement does not correspond to a separate functional area. The SFQUERY.EXE program is required by the electronic journal and the store-for-forwarding servers.

    Service Availability Manager

    This loading statement does not correspond to a separate functional area. The EHCSAM.EXE program is required by shared-file servers when using the XLR (external logging replicator) facility. For details, see LANDP Servers and System Management.

    LOADER EHCSAM.EXE
    

    Shared-file distributor

    LOADER EHCSFD##.EXE [/T:nnn] [/E]
    

    where:

    nnn
    Specifies the number of threads to attend and process requests in parallel.

    The parameter is optional. The parameter value can range from 1 to 252. The default is 2.

    /E
    Is an optional parameter to create a file for the statistics gathered during the session.

    Shared-file replicator

    LOADER EHCSFR##.EXE /C:confname [/T:nnn] [/E]
    

    where:

    confname
    Specifies the name of the PCB profile to be used. The parameter is required.

    nnn
    Specifies the number of threads to attend and process requests in parallel.

    The parameter is optional. The parameter value ranges from 1 to 252. The default is 2.

    /E
    Is an optional parameter to create a file for the statistics gathered during the session.

    Shared-file server

    (Note In this statement, the last parameter uses the letter O, not the digit 0.)

    LOADER SHFILE##.EXE [/C:confname] [/B:nnn] [/E] [/R] [/S:xxx] [/D] [/L:y] [/F:zz]
    [/X:ss] [/A:ttt] [/O]
    

    where:

    confname
    Specifies the name of the profile that defines the shared file. If you omit this parameter, the server uses the name CONFIGUR.

    nnn
    Specifies the number of additional 1 KB index buffers to be allocated; that is, buffers over 15. More index buffers increase system throughput, but also reduce the amount of free storage available for the server workstation. A rule of thumb is that the number of buffers should be 10 per workstation using the shared file server simultaneously. A practical limit is approximately 100, depending on available storage size. The maximum value is 968.

    Another factor that must be considered is that the more buffers you have, the greater is the probability of losing index file data when the shared file server is abnormally ended. Thus, if many index buffers are allocated, and the server workstation is switched off with a transaction still in process, or if no RF function has been called, an automatic index rebuild is issued the next time the server is loaded.

    /E
    Is an optional parameter to create a file for the statistics gathered during the session.

    /R
    Is an optional parameter to rebuild FREECHAIN. Use this parameter after receiving a X'A7' loading error.

    xxx
    Specifies the total number of additional sessions in the whole workgroup that the server can manage. The maximum is 243.

    This number plus the number of workstations that receive services must not be higher than 243.

    /D
    Is an optional parameter to use the OS/2 default collated table. If not specified, the collated keys as defined by the configuration are used.

    y
    Specifies the log management type. The parameter value can be:
    0
    Dynamic and static log with a unique log file
    1
    Dynamic log with a unique log file
    2
    Dynamic and static log with two log files
    3
    Dynamic log with two log files

    The default is 0.

    zz
    Is the number of files open at a time.

    The parameter value can range from 10 to 245.

    ss
    Is the suffix assigned to the shared-file server. During shared-file data replication, the external logging replicator (XLR) uses this suffix to match associated active and backup servers. For example, for SHFILE01/BKFILE01, /X:01 would be specified.

    ttt
    Is used during shared-file data replication by the external logging replicator (XLR). It is the time delay in seconds before an automatic takeover by the backup is attempted when the active terminates. A value of zero means that no automatic takeover is attempted. This parameter is valid only for XLR servers.

    Range: 0-999

    /O
    Overrides normal XLR initialization if only one EHCSAM server is available. This parameter has no default. Use it when only one EHCSAM server is available and then only when you are certain that up-to-date databases are available to that server. Do not use this parameter until you have read the following section. (Note This parameter uses the letter O, not the digit 0.)

    Use of /O parameter

    During XLR server initialization, LANDP:

    If a majority vote of at least two SAMs cannot be achieved, LANDP issues the following messages, where xlr can be SH or BK.

    EHC0587: Waiting for XLR state confirmation (Last XLR state on WS N1:
    xlrFILE01).
    EHC0588: Start other XLR WS, or use /O parameter on SHFILE## to override.
    

    If one of the XLR workstations is permanently unavailable and no other SAM is active, the server cannot complete initialization. If you are sure that the state given in the first message is correct, and that the issuing server has up-to-date copies of the databases, you can force confirmation by restarting SHFILE## with the /O parameter. Do not use this parameter in any other circumstances.

    Consider the following scenario:

         Workstation X1                     Workstation N1
     
         Start as Active                    Start as Backup
         Process transactions               Track transactions
         Machine failure                    Take over as new Active
         Repair.....                        Process transactions
         .....machine                       Normal shutdown
         Start as  ???
    

    In the last step, it is not safe for the XLR server on X1 to initialize. With /O specified, X1 would erroneously assume that it is still the active and use out-of-date data. The only thing to do is to get workstation N1 running as soon as possible. Meanwhile:

    X1 waits until workstation N1 starts.
    N1 initializes as the active, and X1 as the backup.
    X1 catches up on the transactions that took place during its outage.
    When catchup is complete, X1 is in a state to take over should N1 fail.

    In the above scenario, you must wait until workstation N1 is initialized. The following is a scenario in which it is safe to use the /O parameter:

         Workstation X1             Workstation N1
     
         Start as Active            Start as Backup
         Process transactions       Track transactions
         Machine failure            Take over as new Active
         Repair.....                Process transactions
               .....                Normal shutdown
               .....                Start as Active with /O parameter
    

    In this case, N1 has up-to-date databases and can safely be started as the active, so the use of the /O parameter is valid. When X1 or another XLR server again becomes available, it automatically becomes the backup, bringing its log and databases up-to-date by communication with N1.

    Note:
    After messages EHC0597 and EHC0588 are issued and before user intervention with the /O parameter, another SAM might start up. If this causes a majority vote, the chosen active XLR server continues initialization.

    SNA server

    LOADER SNA##.EXE [/S:nnn] [/W:x] [/C:kkkkkkk] [/R:r]
    

    where:

    nnn
    Is the number of entries, divided by 50 (nnn * 50 = number of entries), in the communications provider LUA correlation table.

    The parameter is optional. The parameter value ranges from 1 to 255. The default is 1.

    x
    Specifies whether the wrap option for the communications provider correlation table is used.

    The parameter is optional. The parameter value can be:

    Y
    To set the wrap option.

    N
    Not to set the wrap option.

    The default is N.

    kkkkkkk
    Is the master key to be used, provided cryptography is managed by the SNA server. The default is TMKssww, where ss stands for the session ID and ww stands for the workstation ID.

    To have cryptography managed by the SNA server, and use the default master key, specify /C.

    Omit the parameter if you do not wish to have cryptography managed by the SNA server.

    r
    Is the number of retries if a Connect to communications provider for a session returns the LINK_NOT_STARTED_RETRY message.

    The value must be an integer in the range 0 (do not retry) to 8. It is advisable to specify a low value, for example 1; if the connection does not succeed after one retry, there is likely to be a problem in the communications network which needs to be resolved before the connection can succeed.

    Store-for-forwarding server

    LOADER SFORFORW.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Supervisor

    LOADER SPV.EXE /pc-id [/CL:n] [/PRIOR:pp]
    

    where:

    pc-id
    Is the identifier of the workstation that was assigned during customization. The parameter value is a string of up to 2 alphanumeric characters, and is case sensitive.

    n
    Must be a value greater than or equal to 0, and less than or equal to 4. A value equal to 3 is not recommended. The default is 4.

    This parameter is optional. It enables you to change the priority class of the SPV.EXE and all the LANDP servers. The value n has the same meaning and rules as the OS/2 system function DosSetPrty for the field Priority Class.

    pp
    Must be a value greater than or equal to -31, and less than or equal to 31. The default is 15.

    This parameter is optional. It enables you to change the priority level of the SPV.EXE and all the LANDP servers. The value pp has the same meaning and rules as the OS/2 system function DosSetPrty for the field Priority Delta.

    System manager server

    LOADER SMGR.EXE /D:x /O:yyyyyyyy  [/Z:nnnn]
    

    where:

    x
    Is the drive where the FBSS#GDT backup is located. If the parameter is omitted, the backup is not performed.

    yyyyyyyy
    Is the NetView operator ID. The default is OPER1.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    System manager operator

    START SMOP.EXE
    

    TCP/IP wide area communications server

    LOADER EHCTCP.EXE [/M:aaaaaaaa[,aaaaaaaa]] [/T]
    

    Where:

    aaaaaaaa
    Is the name of a LANDP communications server to be emulated. This can be SNA## to emulate the SNA server, PPC to emulate the PPC server, or both.

    /T
    Is an optional parameter to turn on internal tracing for problem determination.

    Trace tools

    LOADER EHCTRACW [/R:rrrr][/B:bbb][/T:xxx][/MT:mmm][/ML:mmm][/LT:lll][/LL:lll]
    [/PT:[d:][path]filename][/PL:[d:][path]filename]
    

    where:

    rrrr
    Is the record length in shared memory.

    The variable rrrr can take values between 64 and 1024 + 64. The default is 394.

    bbb
    Is the maximum number of records in shared memory.

    The variable bbb can take values greater than 1. The minimum is 2, and the default is 162.

    Note that the maximum number of bbb is calculated using the formula:

    [(64 ×( 1024 - 64)) ÷ (record length rrrr)]

    xxx
    Is the trace option. There are three options for /T (trace facility):
    NO
    No trace is provided.
    MEMORY
    Trace records provided in memory only.
    FILE
    Trace records stored in both memory and in the file specified by the /PT parameter.

    The default is MEMORY. This parameter does not affect the log file, because a log error file is always provided by the server.

    mmm
    Is the maximum number of records for Trace file (/MT) and Log file (/ML). The variable mmm can take values between 1 and 50000. If there is not enough space available, an error is returned. The default value is 512.

    You must erase the existing Trace or Log files when you are creating new ones, otherwise the new parameters do not take effect.

    Note that you must specify /T:FILE in the loading statement when you create a new Trace file.

    lll
    Is the maximum record length for Trace file (/LT) and Log file (/LL). The variable lll must be less than or equal to rrrr. The minimum value is 128.

    The default for Trace is 394. The default for Log is 150.

    d
    Is the drive where the Trace file and the Log file are created.

    path
    Is the path where the Trace file (/PT) and the Log file (/PL) are be created. The path must be less than 128 bytes.

    filename
    Is the name of the Trace file (/PT) and the Log file (/PL). The default name is EHCTRCxx.DAT for Trace, and EHCLOGxx.DAT for Log. In both cases, xx is the workstation identifier.

    If EHCTRACW is loaded while the supervisor is still in the loading process, the workstation ID value xx in the filenames EHCTRCxx and EHCLOGxx are sometimes given the value [!!]. This might happen if you load with the DETACH or START command. To avoid this, you can either use the LOADER command, or rename the xx value for the files afterwards.

    Virtual DOS machine relay

    LOADER EHCVDMGR.EXE [path\name]
    

    where:

    path
    Is the directory where the configuration file created for the VDM relay is located.

    name
    Is the name of the configuration file.

    The configuration file is optional. The default is EHCBOXS.CFG, if it exists.

    Financial printer server

    LOADER PR47X2##.EXE [/K:n]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    4748 and 9068-D01 printer server

    LOADER PR4748##.EXE [/K:n]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    To change the baud rate of the device, you can issue a MODE OS/2 command before loading the server. Specify 9600, 4800, 2400, 1200, 600, 300, or 150. The default is 1200 bits per second.

    4770 printer server

    LOADER PR4770##.EXE [/K:n]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    Loading statements for emulators in an OS/2 VDM

    If you select VDM relay during customization, and define the emulators to be loaded in an OS/2 VDM, the customization program creates an AUTOFBSS.BAT file with the emulator loading statements. The LSI command is used to run the emulators in the OS/2 VDM.

    When you install more than one emulator, they must be run in separate OS/2 VDMs. A separate AUTOFBSS.BAT file is required for each VDM, containing the loading statements for the emulators that run in that particular VDM. To create those files, copy only the required loading statements.

    FBSS (DOS) and LANDP for DOS clients (not servers) can also be run in an OS/2 VDM.

    Banking interactive workstation program

    LSI VBIWP.EXE /C:atr /K:kbd /D:dis /T:at1 /P:pin /M:msi /N:mso /I:n /F:nnn
     
    

    where:

    atr
    Is the name of the selected display color attributes table.

    kbd
    Is the name of the selected keyboard ASCII-to-EBCDIC translation table.

    dis
    Is the name of the selected display EBCDIC-to-ASCII translation table.

    at1
    Is the model and attribute definitions.

    pin
    Is the name of the selected PIN pad input table.

    msi
    Is the name of the selected MSR/E input table.

    mso
    Is the name of the selected MSR/E output table.

    n
    Is the emulator identification number.

    nnn
    Applies only to BIWP running in a DOS VDM under OS/2, and enables MSR/E and PINPad sharing between the 4700 and local applications. The BIWP window has the focus while it is active and loses the focus when inactive.

    nnn is the interval, in seconds, for which BIWP holds the device after its window has lost the focus. The value specified must be in the range 001 to 255. All 3 digits must be specified. A value of 000 means that BIWP holds the device indefinitely (as is the case without this parameter). BIWP reacquires the device automatically when it regains the focus.

    A user server, WINFOCUS.EXE, must be installed under OS/2. The server is shipped with LANDP for OS/2 but the following steps are necessary to install it:

    1. Add the following line to LANCONF.SPC
      SERVER=WINFOCUS,
      
    2. Define as a user server in COMMON.SPC. For example:
      DEFSERV NAME=WINFOCUS,
              TYPE=OS/2,
              SCOPE=BOTH,
              DESCRIPTION='Check Window Focus',
              OBJECT=WINFOCUS.EXE,
              SUBDIR=EHCO000,
              LOADER=LOADER,
              PRIORITY=3,
              LANUNIQ=N,
              ALLCLI=N
      
    3. Load the user server with LOADER.EXE

    The version of the BIWP server must be 10026 or later.

    Note:
    The VBIWP.EXE program running in an OS/2 VDM includes support for LDA7 block transfer sessions.

    3270 emulator

    LSI EMU3270.EXE /C:atr /K:kbd /D:dis /I:n  [/H:hh] [/W:www] [/B:y] [/S:xxxxxxxx]
     [/Z:nnnn] [/P:a] [/L:l] [/T:tt]
     
    

    where:

    atr
    Is the name of the selected display color attributes table.

    kbd
    Is the name of the selected keyboard ASCII-to-EBCDIC translation table.

    dis
    Is the name of the selected display EBCDIC-to-ASCII translation table.

    n
    Is the emulator identification number.

    hh
    Specifies the alternate screen height (number of rows) of the 3270 display to be emulated. (The height specified should not include the operator information area line at the bottom of the emulator screen.) nn must be in the range 24 through 49. For 132-column screens, the maximum height might be limited by the capabilities of the PC video display adapter installed in your system.

    Use this parameter, in conjunction with /W, to make the emulated alternate screen look like one of the following 3270 models:

                       Alternate             Alternate
    3270 model         screen height         screen width
        2                   24                    80
        3                   32                    80
        4                   43                    80
        5                   27                   132
    

    If this parameter is omitted, the default is 24.

    www
    Specifies the alternate screen width (number of columns) of the 3270 display to be emulated. www must be either 80 or 132. Some PC video display adapters do not support 132-column mode.

    If this parameter is omitted, the default is 80.

    y
    Indicates whether blinking is supported. Specify Y for yes or N for no.

    If this parameter is omitted, the default is N.

    xxxxxxxx
    Specifies the long name of the 3270 emulator session (sometimes known as the "host session ID"), which is displayed in the operator information area on the screen. You can specify up to eight characters (with no imbedded blanks).

    If this parameter is omitted, the default is a name of eight blanks.

    nnnn
    Specifies the size (in bytes) of the buffer used to communicate with the host. nnnn can be any value in the range 2048 through 4096. Specifying a small buffer size minimizes memory requirements; using a large buffer can reduce the number of transmissions needed to send or receive a large data stream. The parameter value specified must match the RU size detailed in the bind session.

    If this parameter is omitted, the default is 2048.

    a
    Indicates whether the 3270 emulator should handle the Print Screen key. Specify N for no or Y for yes.

    If this parameter is omitted, the default is Y.

    l
    Indicates whether the SNA session is connected at emulator load time rather than at 'hot key' time. Specify N for NO or Y for YES. The default is N.

    tt
    Specifies the minimum time in seconds between checks on 'print screen' key presses. The default is 3.
    Note:
    When working with LANDP for OS/2 workstations, the 3270 emulator can be used only in an OS/2 VDM. When working in DBCS mode, the 3270 emulator cannot be used in an OS/2 VDM, and therefore it cannot run on a LANDP for OS/2 workstation.

    3287 printer emulator

    LSI EMU3287.EXE /x /E:prt [/T:nn] [/P:HP] [/N:n]
    

    where:

    x
    Can be S or M. Select S for single and M for multiple LU_1 support.
    Note:
    This parameter and its values are no longer supported, though they are accepted for compatibility purposes with earlier versions of LANDP. If specified, they are ignored.

    prt
    Is the name of the selected EBCDIC-to-ASCII translation table.

    nn
    Is the frequency of polling.

    The parameter value ranges from 1 to 60. The default is 15.

    /P:HP
    Indicates that the 3287 printer emulator uses either an IBM 4019 Printer, an IBM 4029 Printer, or an IBM 4039 Printer for output. The default is to use an IBM 4201 Proprinter(R) or equivalent device.

    /N:n
    Specifies the range of logical printer numbers that can be used. The parameter value can be in the range 1 through 3. Specify:

    If the parameter is not specified, the emulator uses the number of parallel printer ports physically installed on the workstation.

    Note:
    When working with LANDP for OS/2 workstations, the 3287 printer emulator can be used only in an OS/2 VDM. When working in DBCS mode, the 3287 printer emulator cannot be used in an OS/2 VDM, and therefore it cannot run on a LANDP for OS/2 workstation.

    Loading servers inline

    LANDP for OS/2 provides a utility program to load the LANDP emulators supported by the multiple virtual DOS machine relay and the EXFS user server support (for the LANDP 3287 printer emulator) in virtual DOS machines of OS/2.

    The load servers inline (LSI) utility program can also load the FBSI banking interactive workstation program (BIWP), if the FBSI is installed. The LSI program is called as follows:

    LSI [/K:m] [/X] [/N:n] [/P:zzservername serverparms
    

    where:

    m
    Is the entry hot key for the display emulators. If you are loading the 3270 emulator or the BIWP and you do not specify this parameter, the customized value is used.

    X
    Prevents intercepting hardware interrupts. Use this parameter only if you have coexistence problems in some environments.

    n
    Is the alias server name.

    zz
    Is the PCID for requests passed by LSI. The default is ' '.

    servername
    Is the name of the emulator or user server to be loaded.

    serverparms
    Are the parameters available for the emulator to be loaded; they depend on the emulator. For information on the LANDP emulator parameters that can be included in the loading statement, see earlier parts of this chapter.

    Use the following command to unload LSI and the emulators from memory:

    LSI /U
    

    See the LANDP Programming Reference book for more information about the EXFS user-written server support for 3287 printer emulation.

    Unloading LANDP for OS/2

    The EHCFREE.EXE utility is provided to unload LANDP for OS/2. You can also unload LANDP for OS/2 by issuing a supervisor function call from an application program. For more information on supervisor function calls, see LANDP Programming Reference.

    The LANDP for OS/2 utility, EHCFREE.EXE, is called as follows:

    d:\path\EHCFREE SPV [/p]
    

    where:

    d:
    Is the drive where the utility is located.

    path
    Is the path where the utility is located.

    p
    Is an optional parameter that can take the following values:

    The EHCFREE.EXE program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.

    Unloading LANDP for OS/2 servers

    The EHCFREE.EXE utility program is used to dynamically unload a LANDP for OS/2 server at LANDP run time. The command must be entered in the workstation where the specific LANDP for OS/2 server to be unloaded is located.

    Note that the EHCFREE.EXE program can also be used to unload the entire LANDP for OS/2 program.

    The EHCFREE.EXE program is called as follows:

    d:\path\EHCFREE servername [/p]
    

    where:

    d:
    Is the drive where the utility is located.

    path
    Is the path where the utility is located.

    servername
    Is the name of the server to be unloaded, entered in either upper or lower case. Note that if you specify SPV, the entire LANDP for OS/2 is unloaded.

    p
    Is an optional parameter, which can take the following values.

    The EHCFREE.EXE program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.


    Installing run-time files

    The LANDP family provides a utility program to check the path where the run-time files are located. See Installing and validating system files for more information about this program.

    For other utility programs also provided to be used at run-time, refer to Run-time utility programs.

    The customization program creates the EHC.MSG message file, which follows the OS/2 rules. The file is provided only for the workstations with:

    The EHC.MSG file must be located in the current path, or in a path specified using a DPATH statement in the CONFIG.SYS file. Note that, for device drivers, the current path is the root directory.


    Preparing Windows workstations




    ehcw

    The first part of the chapter, Installing and configuring Windows workstations, describes the requirements to install the LANDP for Windows run-time files on the Windows workstations. Some requirements are related to a specific server.

    The second part of the chapter, Modifying run-time files, describes the process of modifying the run-time files created by the customization program, according to your needs.

    The third part of the chapter, Loading statements for LANDP for Windows servers, describes how to check that the files have been correctly installed.


    Installing and configuring Windows workstations

    The workstation files, which might typically be kept on diskettes, created for the Windows workstations do not contain any Windows system files. Therefore, before installing the LANDP for Windows operational files into your Windows workstation, make sure that Windows is installed according to the existing recommendations.

    The TCP/IP support that LANDP for Windows requires is provided as part of Microsoft Windows NT Version 4.0, Windows 2000, or Windows XP Professional.

    The NetBIOS support that LANDP for Windows requires is provided as part of Microsoft Windows NT Version 4.0 or Windows 2000.

    The SNA support that LANDP for Windows may require is provided as part of one of the following products:

    When working in DBCS mode, the operating system can be one of the following depending on your national language:

    Language Operating system Supported codepage
    Traditional Chinese Microsoft Windows NT V4 (Traditional Chinese) 950 (no defaults)
    Simplified Chinese Microsoft Windows NT V4 (Simplified Chinese) 1386 (no defaults)
    Note:
    Windows (Korean) is not supported by LANDP for Windows.

    Installation requirements for NetBIOS transport protocol

    This section applies to LANDP for Windows workstations integrated in a LANDP workgroup that uses NetBIOS as the transport protocol.

    Important

    The NetBIOS interface might not be available on some versions of Windows. Check your operating system documentation to confirm whether or not it is available.

    The NetBIOS interface must be installed and it is recommended that you configure it so that Lana (LAN adapter) Number 0 is assigned to the Network route starting with Nbf-> because LANDP uses adapter number 0 by default. The NetBIOS interface can be configured by selecting the appropriate items within the Network function of the Windows Control Panel.

    Alternatively, you can choose to use the ADAPTNUM keyword in LANCONF.SPC (see LWSCONF vector) or the /N parameter on loading LAN.EXE (see LAN server) to specify the Lana (LAN adapter) Number of the route starting with Nbf->.

    LAN adapter numbers for Windows 2000

    A change to the Windows 2000 GUI has resulted in the logical adapter numbers used by the LAN.EXE program no longer being displayed to the administrator. This might cause LANDP configuration problems, because you cannot tell what the Logical Adapter Number parameter on the LOADER statement for LAN.EXE should be.

    Microsoft have provided a Windows 2000 utility LANACFG.EXE that enumerates the Logical Adapter Numbers as in Windows NT.

    If you have difficulty connecting LANDP using NetBIOS, get a copy of the LANACFG.EXE utility from the Microsoft web site.

    In a workgroup with OS/2 or DOS machines as well as Windows machines, you should change the default NETBIOS timing parameters, which are different to those provided by IBM's NetBios support. The T1, T2 and TI values should be the same on all machines. On Windows machines, these values are in the registry under the following subkey:

      HKEY_LOCAL_MACHINE\SYSTEM\Services\NBF\Parameters
    

    Installation requirements for TCP/IP transport protocol

    This section applies to LANDP for Windows workstations integrated in a LANDP workgroup that uses TCP/IP as a transport protocol.

    TCP/IP must be configured in those workstations defined to use this transport protocol, so that you can use TCP/IP as an internal communications protocol for a LANDP workgroup.

    For detailed information, refer to the TCP/IP information in the Microsoft Windows online documentation.

    For more information about the TCP/IP transport protocol, see Appendix E, Using TCP/IP for internal communication.

    Installation requirements for mixed transport protocols

    It is possible to use both the NetBIOS and the TCP/IP transports within the same workgroup. Workstations can be configured to use either NetBIOS, or TCP/IP, or both. However, each workstation must use the same protocols as the other workstations that they need to communicate with (related workstations).

    For example, if a workgroup has a SNA gateway with some clients configured to use the TCP/IP transport and some other clients configured to use the NetBIOS transport, the SNA gateway workstation must be configured to use both NetBIOS and TCP/IP transports.

    When a workstation is configured to use both transport protocols the required NetBIOS resources can be reduced to be sufficient for only the number of related workstations using the NetBIOS protocol.

    Installation requirements for workstations with SNA servers

    The LANDP for Windows SNA server uses the LUA interface that is provided by one of the following products:

    The workstation configured to run the SNA server must be the one that is connected to the host computer. All logical units types 0, 1, and 2 receiving services from the LANDP SNA server must be defined in the SNA provider of the workstation that is connected to the host computer.

    You define the workstation profile and the SNA profiles in the configuration files of the SNA provider, as follows:

    If you do not use LU pooling support, you have to define as many LUA profiles as SNA sessions.

    If you plan to use LU pooling support, you have to group LUA profiles in LU pools. In this case, the number of LUA profiles depends on your configuration requirements.

    The profile name is a string of eight characters, which must comply with the following conventions:

           EHCxxnnb
    

    where:

    xx
    Has two different meanings:

    nn
    Is the SNA session identifier.

     
    Is one character you leave blank.

    The variable nn takes the following values.

    For the 3270 emulator:

    You can have five sessions running simultaneously in each workstation, with the identifiers numbered from 51 (for the first session) through 55 (for the fifth session). That is, the value for nn for the 3270 emulator ranges from 51 to 55.

    For the 3287 printer emulator:

    You can have five sessions running simultaneously in each workstation, with the identifiers numbered from 76 (for the first session) through 80 (for the fifth session). That is, the value for nn for the 3287 printer emulator ranges from 76 to 80.

    For RCMS:

    The value for the variable nn for RCMS is 33.

    For Forwarding:

    You can have three sessions running simultaneously, with the identifiers numbered from 37 (for the first session) through 39 (for the third session).

    For applications:

    For DOS applications, the variable nn can take the values of 1 through 15. For DOS user servers, it can take the values of 16 through 30.

    For OS/2 or Windows applications or user servers, it can take the values 1 through 30. However, a modified SNA interface that allows for more than 30 user sessions per workstation is available when the SNA services are provided from an OS/2 or Windows workstation. When using this interface, the session identifier may be any two ASCII characters. The SNA session identifier part of the LUA profile name (LU0 through LU3) (defined under the appropriate SNA communications provider) may now be any two ASCII characters instead of just two decimal digits.

    For 4731 and 4737:

    The variable nn can take the values 34 and 35 for the 4731 Personal Banking Machine (PBM), and the value 34 only for the 4737 PBM.

    For the BIWP emulator:

    When the PC/Integrator version is running in a Windows VDM, the variable nn takes the value 61 or 63.

    For the LDA 7 Program:

    When the PC/Integrator version is running in a Windows VDM, the variable nn takes the value 62 or 64.

    For the BPP emulator:

    When the PC/Integrator version is running in a Windows VDM, the variable nn takes the value 71 or 72.

    Following is an example definition of the SNA LUA profile names for a given workgroup, for which LU pooling is not used:

    Figure 8. Example of SNA LUA profile names in a workgroup (Windows)

    ehcgr086

    These are the expected profile names in the SNA provider for workstation XX (gateway):

    EHCAA01
    For the client workstation AA
    EHCBB01
    For the client workstation BB
    EHCCC51
    For the first emulator session in workstation CC
    EHCCC52
    For the second emulator session in workstation CC
    EHCDD33
    For the RCMS client workstation DD
    EHCEE33
    For the RCMS client workstation EE

    You then specify the following profile parameters:

    Note:
    If you use correlation tables, ensure that the SNA provider's LUA level supports the corresponding definitions.

    Installation requirements for TCP/IP wide area communications server

    LANDP for Windows workstations, configured to use the TCP/IP wide area communications server, must have Windows TCP/IP installed and configured.

    There must also be an EHCTCP.INI file to provide the information required to map LANDP sessions with SNA and PPC servers to TCP/IP protocols, ports and internet addresses. The file can be created with any text editor, but it is best practice to use the file as generated by LANDP customization. See SES&TCP on page *** for a description of the file contents.

    Installation requirements for workstations with LANDP link servers

    Workstations that are configured to use the LANDP link server, must have TCP/IP installed and configured.

    Installation requirements for workstations with PPC servers

    To run the PPC server, one of the following products must be installed, configured and running:

    The following information must be configured:

    Refer to the documentation for your communications provider for more details, and for information about how to configure transaction programs to be started automatically.

    Installation requirements for workstations with MQSeries Link servers

    A significant amount of planning and configuration is required for each MQSeries Queue Manager. For more details on MQSeries administration please refer to the MQSeries documentation. Book numbers and titles can be found in Appendix J, Bibliography.

    You can use the CRTMQM utility to define queue managers for use with the MQSeries Link server. When defining the queue manager, you should ensure that the queue manager has the same name as specified for the MQSeries Link server during customization.

    A default queue manager can be defined on the MQSeries server when CRTMQM is run, by using the -q flag.

    It is suggested that the MQSeries Queue Manager is defined to have a maximum message length similar to the LANDP MQ Server. This can be achieved by use of the MQSeries attribute MaxMessageLength.

    The MQSeries Link server must be installed on an MQSeries Server so that the MQSeries Queue Manager is on the same workstation as the MQSeries Link server.

    In addition to MQSeries naming requirements, the MQSeries Link server can only accept MQSeries names that comply with the following.

    For security control the MQSeries Link server relies on the services of the Object Authority Manager (OAM). If access to MQSeries entities is to be controlled, the access policies for the OAM have to be defined. This should be planned as part of the configuration of the MQSeries Queue Manager.

    Data conversion of messages has been enabled in the LANDP API with the GQ option EHCGQ_CONVERT. When requested conversion will be attempted by the MQSeries Queue Manager.

    Queues used by the MQSeries Link server should be predefined. Some sample queue definition files have been provided to aid application development. These files can be found in \EHC\EHCN600\SAMPLE.

    Installation requirements for workstations with shared-file servers

    If you are migrating data definitions or Shared File data from a LANDP for DOS SHFILE## environment, refer to LANDP Programming Reference.

    Installation requirements for workstations with ODBC query servers

    The workstation must have the Windows ODBC Driver Manager and an ODBC Device Driver installed. The ODBC Device Driver must:

    For instructions on installing the ODBC Driver Manager, refer to the Microsoft Windows documentation. For instructions on installing the ODBC Device Driver, refer to the vendor's instructions.

    Installation requirements for Microsoft Visual Basic

    On a machine that needs to use Microsoft Visual Basic, take the following steps to install the OCX.

    1. Copy the landp.OCX file from the EHCN600 directory to the \system32 directory, which should be under the Windows install directory, conventionally c:\winnt\system32 on Windows NT and Windows 2000, or c:\windows\system32 on Windows XP.
      Note:
      The EHCN600 directory is on the customization machine and the target is probably a different machine. Use a diskette or the LAN to transfer the file. It would be helpful to copy the LANDP.HLP file.
    2. Run the registration program regsvr32 from the system32 directory with the parameter Landp.OCX. For example:
      c:\winnt\system32\regsvr32 Landp.OCX (on Windows NT or Windows 2000)
      or
      c:\windows\system32\regsvr32 Landp.OCX (on Windows XP)
      

      Alternatively you can run regsvr32 from anywhere as long as you specify the fully qualified path name of where you placed the OCX. For example:

      x:\regsvr32 c:\directory1\directory2\Landp.OCX
      
    3. You should get a pop up window saying the registration succeeded.

      An error code of 7e usually indicates that the OCX cannot be found. Check that the path name been specified fully and correctly, and that the OCX is in the current directory.

    4. Run Visual Basic. You should see the Landp.OCX referred to in the Custom Controls panel under the Tools directory.
    5. Check the box next to the LANDP custom control statement and an icon should appear in the Controls toolbar.
    6. Select the icon and place the control onto the form.

    Installation requirements for Java support

    The LANDP Java support on Windows can be found in the following files located in the EHCN600 directory:

    LDPJAVA.JAR
    Java Archive File containing the LANDP Java classes

    LDPJMAN.EXE
    LANDP Java Manager

    LDPJDISP.EXE
    LANDP Java Dispatcher

    LDPJAVA.DLL
    DLL that implements the native methods of the LANDP Java classes

    LDPMSRE.JAR
    LANDP J/XFS device support for magnetic stripe readers

    LDPPINP.JAR
    LANDP J/XFS device support for PIN pads

    LDP47X2.JAR
    LANDP J/XFS device support for the 4722 financial printer

    To support the running of Java user servers, applications, applets or servlets on a LANDP workstation these files should be copied to the directory on the workstation containing the LANDP files. For more details, refer to LANDP Programming Guide.

    These files can be distributed automatically with the LANDP files by specifying SERVER=JAVA in the LWSCONF definition for this workstation. However, note that this method of distribution does not distribute the documentation file ldpjdocs.zip, which is located in the EHCN600 directory.

    Once copied, two system environment variables need to be updated. This can be done from the Control Panel System icon.

    Running LANDP DOS applications on Windows

    The VDM Relay DOS stub (EHCVDSPV.COM) must be loaded in any VDM that will run LANDP/DOS applications. This can be achieved in a number of ways, some of which are covered here. The most appropriate way depends on the way the workstation is used and the applications that will be used.

    Firstly, an understanding of the Windows MS-DOS command window is required.

    When an MS-DOS window is first opened, it runs the CMD.EXE command interpreter. This allows the invocation of Windows programs, OS/2 16 bit programs and DOS programs. When a DOS program is detected, a new process is created and COMMAND.COM is used to start the program. Before running the DOS program, CONFIG.NT and AUTOEXEC.NT from the SYSTEM32 subdirectory of the Windows directory (usually WINNT) are processed. When the DOS program ends, CMD.EXE regains control. Subsequent programs run under either CMD or COMMAND, depending on their type.

    CONFIG.NT and AUTOEXEC.NT are the default files used for MS-DOS windows and WOW (Win16 On Win32) applications. However, different files may be specified using a PIF (Program Information File). Refer to Windows documentation for details.

    Note:
    For naming PIF startup files, Windows NT uses a different convention from Windows 2000 and Windows XP. Under Windows NT, the convention is AUTOEXEC.nnn and CONFIG.nnn where nnn is chosen by the user. Under Windows 2000 or Windows XP, the convention is nnnnnnnn.NT where nnnnnnnn is chosen by the user.

    This ability to have different start-up files can be used in a number of ways to implement a VDM relay.

    If the workstation will only be used for specific LANDP for DOS applications, it may be appropriate to invoke EHCVDSPV in-line with the application using a batch file as in the following example:

         STARTAPP.BAT
     
              LOADHIGH EHCVDSPV.COM
              LANDPAPP
              EXIT
     
    

    In this case the VDM DOS stub is loaded into high memory and LANDP for DOS is started. The window is closed on termination of the application. No changes to CONFIG.NT or AUTOEXEC.NT are required.

    If 16-bit Windows applications are to be run and/or all MS-DOS prompts have the capability to run LANDP for DOS applications, the following should be added to AUTOEXEC.NT:

             D:
            CD \LANDPV6
            EHCVDSPV
    

    (Assumes the LANDP runtime is in D:\LANDPV6)

    In some circumstances it may be necessary to create a PIF for LANDP for DOS command prompts because of disruptions to the EHCVDSPV TSR caused by non-DOS programs. In the following example the PIF file for a shortcut to COMMAND.COM called "LANDPDOS" is modified to use CONFIG.LDP and AUTOEXEC.LDP. These files are copies of CONFIG.NT and AUTOEXEC.NT respectively, with the following additions:

            Appended to CONFIG.LDP
     
               DOSONLY
     
            Appended to AUTOEXEC.LDP
     
               D:
               CD \LANDPV5
               EHCVDSPV
    

    Note that only DOS programs will be able to run in this window.

    EHCVDSPV optional parameters

     

    /Q
    Quiet mode; no copyright messages issued.

    /I
    Initialize immediately. Requires that LANDP for Windows has been started already. By default, initialization is delayed until the first LANDP API call.

    /U
    Unload a previously installed copy of EHCVDSPV if safe to do so.

    Loadhigh can be used to load EHCVDSPV. Refer to the Windows help for details.


    Loading EHCWINNT.DLL in LANDP for Windows

    EHCWINNT.DLL is the dynamic link library that contains the LANDP interface routines RMTREQ, GETRPLY, SRVINIT, GETREQ, RMTRPLY, and RMTAREQ.

    EHCWINNT.DLL is loaded in the supervisor and in every other LANDP process. LANDP for Windows expects EHCWINNT.DLL to be mapped to the same virtual address in every process that uses it. If the supervisor attempts to load EHCWINNT.DLL at an address that another process has already used, the load fails. To prevent this problem arising:

    1. Use the following registry entry, where value is the virtual address at which EHCWINNT.DLL is to be loaded:
      HKEY_LOCAL_MACHINE\SOFTWARE\IBM\LANDP\4.0 value= SharedMemAddress (DWORD)
      
    2. Ensure that the supervisor is always started first.

    Figure 9 illustrates the problem and the solution.

    Figure 9. EHCWINNT loading problem and solution

    Possible situation without
    HKEY_LOCAL_MACHINE\SOFTWARE\IBM\LANDP\4.0 registry entry.
    EHCWINNT.DLL loaded at different virtual addresses in the supervisor
    and application. This causes a failure.


    EHCGR922

    Situation with HKEY_LOCAL_MACHINE\SOFTWARE\IBM\LANDP\4.0
    registry entry. EHCWINNT.DLL always loaded at same virtual
    address in the supervisor and all applications, provided supervisor is started
    first.


    EHCGR923


    16-bit Windows LANDP applications

    16-bit Windows LANDP applications developed for Windows 3.x may be run on Windows NT, Windows 2000, or Windows XP Professional.

    AUTOEXEC.NT must be modified as in the previous section and EHCWIN.DLL must be present in the LANDP runtime directory.

    Only one LANDP/DOS application can be run in any one WOW (Win16 on Win32) VDM. However, multiple applications can be run, if they are run in a separate VDM (See Windows documentation).

    SVPCPRBW may be used to verify correct installation of Win16 support.


    Running LANDP for Windows servers as Windows Services

    Under Windows, programs are normally run by, and associated with, one or more users. If the user logs off, the program is terminated. As this is not desirable in some environments, there is a facility to run programs as services. By default, LANDP Servers run as services. This imposes some restrictions:


    Modifying run-time files

    The main areas of modification are:

    Depending on the applications and servers you have developed, and the devices you have installed, additional files might need to be copied.

    When the shared-file server starts up, it creates the necessary shared-file directories if they do not already exist. This removes the need (which existed in earlier LANDP releases) to call CREADB.BAT to create these directories.

    Registry contents

    LANDP for Windows adds entries to the Windows registry so that LANDP servers can be run as Windows services. See also Loading statements for LANDP for Windows servers.

    AUTOFBSS.BAT contents

    The AUTOFBSS.BAT file contains the loading statements of the supervisor and the servers that are to reside on the workstation. The first program loaded is the supervisor.

    Ensure that any modification of this file does not cause a server to be loaded before the supervisor. Application loading statements should be placed at the end of the server loading statements.

    Note:
    To get trace and log information about the loading process, you have to load the trace tool immediately after the supervisor.

    The following is an example of an AUTOFBSS.BAT file for a workstation that contains the SNA server. The name of the workstation is AB.

        LOADER %1 SPV.EXE /AB
        IF ERRORLEVEL 1  GOTO END
        LOADER %1 LAN.EXE
        IF ERRORLEVEL 1  GOTO END
        LOADER %1 SNA##.EXE
        IF ERRORLEVEL 1  GOTO END
        GOTO OK
        :END
        EHCFREE SPV /F
        EXIT
        :OK
    

    AUTOFBSS.BAT can be invoked with one positional parameter that will be passed to the loader. Any valid loader parameters can be used. For example:

         AUTOFBSS /R:
    

    This will remove all servers referenced in AUTOFBSS.BAT from the registry. See page *** for a description of LOADER parameters.

    EHCLIP.EXE should be specified instead of LAN.EXE if the workstation is integrated in a LANDP workgroup that uses TCP/IP as a transport protocol.

    If the LANDP workgroup uses mixed transport protocols, and the workstation needs to use both transport protocols, include LOADER statements for both LAN.EXE (NetBIOS) and EHCLIP.EXE (TCP/IP).

    You can specify the EXIT command to close the Windows session, and leave LANDP for Windows running in background. After the :OK label, you can specify a Windows command to invoke a LANDP for Windows application.

    You should invoke the EHCINFO utility program to get an information window about LANDP for Windows status. EHCINFO is a LANDP utility program; it is described in LANDP Servers and System Management.

    Automated unattended startup of LANDP

    Under normal circumstances, AUTOFBSS.BAT can only be invoked by a logged on user with the necessary authority. As this may not be convenient in some environments, EHCAUTO.EXE is provided to automate LANDP startup when Windows is booted.

    To automate the LANDP startup, after the LANDP installation has been verified, issue EHCAUTO from the command prompt in the LANDP runtime directory. You must have administrator authority. This registers EHCAUTO as a Windows service that will be started automatically at Windows startup. Subsequent reboots of Windows will now run EHCAUTO. In turn, EHCAUTO will invoke AUTOFBSS.BAT. Note that only servers which can run as services are supported and any other programs run from AUTOFBSS must not attempt to interact with the user. By default, EHCAUTO runs under the Local System Account (LSA) and inherits the LSA access authority (refer to Windows documentation).

    Syntax:

              EHCAUTO [/D:|/R:|/S:]
    

    Parameters of EHCAUTO are:

    /D:
    Displays the status of the EHCAUTO service.

    /R:
    Displays automated startup. Administrator authority is required.

    /S:
    Stops the EHCAUTO service if it is running.

    If no parameters are given, automated startup is enabled. Administrator authority is required.

    Loading statements for LANDP for Windows servers

    Most loading statements explained in this section are automatically created by the customization program, using the parameters you provided. The following commands appear in the AUTOFBSS.BAT file provided by customization. Manual modifications can be done if need be. The LOADER command is used to run the servers and the supervisor.

    You can use any Windows command, such as the START command, to run these programs because they are regular Windows programs. Note that using the LOADER command displays the return codes corresponding to the initialization process.

    The following syntax is used when servers are to be started as Windows services:

      LOADER [/P:] [/T:nnnserver_name[.exe] [server_options]
    

    The first time LOADER is run for any given server, the server will be registered as a Windows service. This registration can be done only by users with Administrators authority. When the service has been registered, any user can start the service (see the /P: parameter, below).

    Note:
    You cannot run multiple instances of a server with the same name if the server is running as a Windows service.

    The LOADER options are:

    /P:
    Protected mode. Only users with Administrator or Power User authority can start or stop this server. This option must be specified when the service is first registered for protected mode to be enforced.

    nnnn
    Server initialization timeout (in seconds). The range is 1 to 3600; the default is 30.

    The following form of the LOADER statement can be used to manage LANDP servers that are run as services:

      LOADER {/D:|/R:|/S:} server_name[.exe]
    

    The LOADER options are:

    /D:
    Displays the state of the service. All users can use this option.

    /R:
    Removes the service from the Windows registry. The server will be registered again the next time it is started as a service. Only users with Administrator authority can use this option.

    /S:
    Stops the service. This option should only be used if EHCFREE fails to stop the server. All users can use this option if the service was first registered without the /P: option. Otherwise, users must have Administrator or Power User authority.

    A %1 parameter is generated within the LOADER statements in AUTOFBSS.BAT during customization. This is to facilitate the addition of a common option to each LOADER request. For example, a /D: loader request would display the status of all LANDP servers contained within AUTOFBSS.BAT, by entering the command:

    AUTOFBSS /D:
    

    When servers are to be run as normal applications, the format is:

      LOADER [/T:nnn] /N: server[.exe] serverparms
    

    The LOADER options are:

    /N:
    Normal mode (that is, not as a Windows service).

    nnnn
    Server initialization timeout (in seconds). The range is 1 to 3600; the default is 30.

    Note:
    Servers stop if a user logs off.

    See Unloading LANDP for Windows servers for details of how to stop LANDP for Windows servers.

    If the initialization works without errors, the server performs initialization, then goes into a wait state until it receives a request from an application. If an initialization error occurs, it is logged in the error log file.

    Use IF ERRORLEVEL statements to check the type of errors. If a LANDP error occurs, the corresponding return code is provided.

    For return codes during loading, refer to LANDP Problem Determination.

    Errors detected by LOADER are logged to the Application section of the Windows event log. System and Security Event Log messages can also be generated by system functions invoked by LOADER. Server initialization messages may also be logged in EHCLOGxx.DAT.

    The following commands are used when you load the LANDP for Windows functional areas.

    Electronic journal server

    LOADER ELECJO##.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the electronic journal records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Forwarding server

    LOADER FORWARD.EXE /O:vvvvvvvv.vvv [/T:wwww] [/S:xxxxxxxx.xxx] [/K:y] [/H:z] [/Z:nnnn]
    

    where:

    vvvvvvvv.vvv
    Is the name of the file corresponding to the ASCII-to-EBCDIC translation table. It must follow the operating system rules.

    wwww
    Is the number of time ticks after which the supervisor will dispatch the forwarding function. One time tick is roughly 0.05 seconds.

    It can range from 1 to 6000. The default is 20 (about 1 second).

    xxxxxxxx.xxx
    Is the name of the file corresponding to the sign-on feature. It must follow the operating system rules.

    y
    Is the size, in KBs, of the buffer used to read the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the value assigned in the loading statement of the store-for-forwarding server.

    z
    Specifies whether headers are included when sending host computer messages. The parameter value can be Y, to include headers, or N, not to include headers. The default is Y.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    LAN server

    LOADER LAN.EXE [/N:n[,n,...]] [/I:x] [/S:y] [/U:s[,s,...]]
    

    where:

    n[,n,...]
    Represents the logical adapter numbers used by the LAN.EXE program. These must match the values defined for the NetBIOS protocol driver during NetBIOS configuration. See Installation requirements for NetBIOS transport protocol.

    The parameter value can range from 0 to 255. The default is 0.

    You can specify a series of up to four adapter numbers. This enables you to configure a server which provides services to workstations on two or more otherwise unconnected LANs. For example:

    /N:0,1,2,3
    

    tells LAN.EXE to use all four adapters.

    x
    Is the time period, in seconds, between attempts to establish the required NetBIOS sessions.

    The parameter value can be 0 or in the range 5 through 3000. The default is 20 seconds. If a value of 0 is specified, only one attempt is made to establish each session, at startup, or after a session has been lost.

    y
    Is the NetBIOS send timeout, in seconds. NetBIOS send, LAN server

    The parameter value can be 0 or in the range 10 through 127. The default is 10 seconds. A value of 0 implies no timeout.

    s[,s,...]
    Represents the number of NetBIOS sessions to be made via each adapter. The s values correspond to the adapters specified on the /N parameter. For example, the first s value after /U corresponds to the first n value after /N, and so on.

    The parameter values can range from 0 to 254, provided sufficient sessions have been defined during NetBIOS configuration. If the parameter is omitted, or specified as 0, then enough sessions for all the related workstations are used. The total number of sessions specified must be not less than the number of related workstations.

    The LAN server is needed only when more than one workstation is present in a LAN. It is included during the process of creating diskettes for distribution.

    LANDP Internet Protocol

    LOADER EHCLIP.EXE [/N:n] [/Y] [/T] [/C[:ws-id]] [/O:o[filename]] [/J]
    

    where:

    n
    Specifies the TCP/IP port number used by LANDP Internet Protocol.

    The parameter value ranges from 1024 to 65535. The default is 52699.

    Y
    Specifies that no availability probe datagram will be sent, when a session has no normal traffic.

    T
    Requests LANDP Internet Protocol internal routines trace.

    C
    Requests LANDP Internet Protocol communications trace. All sessions are traced, except when the ws-id parameter is specified. In this case, only the session with the workstation specified in that parameter is traced.

    o
    Specifies the destination of trace data. The parameter value can be:

    1
    Standard output. Note that the screen is the usual output, and requires LANDP Internet Protocol be loaded in foreground, with the START command.

    2
    ASCII file. If you do not specify a name of file, the trace data is stored in the LIPTRACE.TRC file. The target file is initialized each time. Thus, if an existing file is used, the file contents get lost.

    3
    EHCTRACW (the default).

    J
    Specifies that no checking for related workstations with undefined LANDP Internet Protocol addresses will be carried out.

    LANDP link server

    LOADER EHCLINK.EXE [/T] [/E:eeeeeeee[,eeeeeeee...]] [/I:iiiiiiii[,iiiiiiii...]
                       /L:llllllll [/A:aaaaaaaa[,aaaaaaaa...]] [/R:rrrr]] [/P:ppppp]
    

    where:

    T
    Turns on component internal tracing.

    eeeeeeee
    Are the names of up to 10 services to be exported. Only these local workgroup services are made available to remote workgroups. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    iiiiiiii
    Are the names of up to 10 services to be imported. Only these remote workgroup services are made available in the local workgroup. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    llllllll
    Is the TCP/IP network name, or the IP address of the workstation running the LANDP link server that is exporting services. Network names must be resolvable to IP addresses by the domain name server or the local HOSTS file.This parameter must be present when, and only when, the imports parameter is also specified.

    aaaaaaaa
    Are alias names of services to be imported. The names in the alias parameter correspond one-to-one with the names in the imports parameter. If an alias is specified, an imported service will be made available with the corresponding alias name. If the alias parameter is absent, or if the corresponding alias name is null, the imported service will be made available without the name being changed. Names must not appear more than once in this parameter. If an import name has trailing '#' characters, the corresponding alias name must have the same '#' characters. This is an optional parameter that is allowed only if the imports parameter is also specified.

    rrrr
    Is the connection retry interval in seconds. It is in the range 0 through 3276. A value of 0 means no retry. The default retry interval is 30 seconds. This is an optional parameter that is only allowed when the imports parameter is also specified.

    ppppp
    Is the TCP/IP port number. It is in the range 1024 through 65535. The default value is 52699. To make a connection the exporting LANDP link server and the importing LANDP link server must use the same TCP/IP port. This is an optional parameter.

    The LANDP link server can act as both an exporter and an importer of services. It can do both at the same time, if required.

    There can be any number of exporters and importers in a workgroup and in a workstation, but only one exporter on each workstation can use each TCP/IP port number.

    Magnetic stripe reader/encoder server

    LOADER MSRE47##.EXE [/C:x] [/D:n] [/O:e]
    

    where:

    x
    Identifies the Windows communications port to which the MSRE device is attached.

    The parameter is optional. The value can be specified in the range 1 through 8. The default is 1.

    n
    Identifies whether a 4777 MSRE device may be combined with a 4778 on the same workstation.

    The parameter is optional; if used, the value specified must be 1.

    e
    Enables some 4777 device requests to be redirected to a 4778.

    The parameter is optional. The value specified can be 0 or 1. The default value 0 disables redirected device requests. The value 1 enables the requests.

    MQSeries Link server

    LOADER EHCMQ## [/Q:MQM_name][/L::lllll] [/M:m] [/P:[d:[path]]] [/T:tt] [/S:ss]
    

    where:

    MQM_name
    is the MQSeries Queue Manager Name.

    This parameter specifies the name of the queue manager to which the server is to connect. The parameter can be a string that conforms to the rules defined for MQSeries object naming.

    Alternatively, the parameter can define an environment variable, for example, '%MQMNAME%', which is resolved when the AUTOFBSS file is processed. The special characters '%' and '/' should not be used in the queue manager name.

    If this parameter is omitted or entered as spaces, EHCMQ## connects to the default MQSeries queue manager.

    lllll
    Specifies the maximum message length permitted by the MQSeries Link server. This is used to restrict the maximum message length to something less than the default of 57,000 bytes. The variable lllll can take a value between 1000 and 57,000.

    m
    Specifies the message detail level to be written to the log file. The variable m can have the values E|W|I where E=errors, W=warnings and I=info. I includes levels W and E, W includes level E. If m is omitted, logging is switched off, which is the default.

    d
    Is the drive where the log files are created. If this parameter is omitted, the drive defaults to the drive of the current working directory for the EHCMQ## process.

    path
    Is the path where the log files are created, which defaults to 'EHCMQLOG'. If a path is specified, a drive should also be defined. If both drive and path are omitted, 'EHCMQLOG' is created as a sub- directory of the current working directory for the EHCMQ## process.

    A log file is created for each workstation that initiates a session. The log file is named as XXhhmmss.ddd, where

    The maximum length of the combined /P arguments, d and path, must not exceed 128 bytes .

    tt
    Is the total number of permitted sessions.

    This parameter specifies the maximum number of different sessions that the server can process at the same time. The parameter is optional and can be in the range from 1 to 64. The default is 32.

    ss
    Is the number of MQ connections that should be made at startup. Every session requires a MQ connection, which can be made at startup or as session requests are received. The parameter is optional. The variable ss can be in the range 0 to tt. The default value is 0. When this option is non-zero, the LOADER server's timeout probably needs to be increased. Refer to Loading statements for LANDP for Windows servers.

    PIN pad server

    LOADER PINP47##.EXE [/M] [/C:x]
    

    where:

    /M
    Indicates that 4778 magnetic stripe reader capabilities are to be used.

    The parameter is optional.

    x
    Identifies the Windows communications port to which the PIN pad device is attached.

    The parameter is optional. The value that can be specified is in the range 1 to 8. The default is 1.

    ODBC Query Server

    LOADER EHCODB##.EXE [/C:datasource] [/T:tt] [/MT:mm] [/S:ss] [/W:zz] [/EL] [/A]
    

    where:

    datasource
    Specifies the name of the ODBC data source that is to be connected. The default is the ODBC data source "CONFIGUR".

    tt
    Specifies the number of worker threads to create at start up. Each thread allows simultaneous processing of requests, the more threads the greater the throughput. However, the more threads the higher the overhead on system resources. The default is 5. The maximum permitted value is the lowest of 128 and the value of mm.

    mm
    Specifies the maximum number of worker threads that EHCODB## can start. This value should be set to enable the ODBC Query Server to increase throughput without using too much system resource. The default is 128. This value must be greater than or equal to tt.

    ss
    Specifies the maximum number of sessions a single workstation can handle. The default is 10. This value must be in the range 1 to 64.

    zz
    Specifies the timeout length in seconds for a database request. The default is 15. This value must be in the range 10 to 100000.

    /EL
    Specifies that the ODBC Query Server should be enabled to write information messages to the Windows event log.

    /A
    Specifies that EHCODB## server is aliased to the EHCSQL## server. The EHCODB## server receives requests directed to the EHCSQL## server, as well as direct requests to the EHCODB## server. This is used to aid migration of existing EHCSQL## (query server) applications to EHCODB## (ODBC query server).

    Program-to-program communication server

    LOADER PPC.EXE [/FA] [/FS] [/D:nn]
    

    where:

    FA
    Specifies MC_FLUSH after ALLOCATE, as a result of an Open Services (OP) function.

    FS
    Specifies MC_FLUSH after a Send Data (SD) function.

    When the application sends data to the partner application program, the data is stored in buffers that are automatically flushed, and is immediately sent to the partner application. Note that this option may affect the workstations and the network performance.

    nn
    Is the buffer pool that the PPC server initializes to send data to or receive data from the communications provider The default is 16.

    Remote change management services

    LOADER RCMS.EXE /I:xxx /O:yyy [/T:ttt] [/L:n] [/P:q] [/C:x] [/R:r] [/Z:nnnn]
    

    where:

    xxx
    Is the file extension of the EBCDIC-to-ASCII translation table (EARCMS.xxx). In DBCS mode the parameter does not apply.

    yyy
    Is the file extension of the ASCII-to-EBCDIC translation table (AERCMS.yyy). In DBCS mode the parameter does not apply.

    ttt
    Is the number of timer ticks after which RCMS receives control. One timer tick is roughly 0.05 seconds. The default is 10. The value must be a decimal number in the range 1 to 999, For example:
    /T:1, /T:2,  or  /T:55
    

    n
    Specifies the number of lines in the EHCRCMS.LOG file. The parameter value can range from 100 to 10000. The default is 1000.

    Attention: If an EHCRCMS.LOG file with n1 lines exists already, and you choose a value for the L parameter that is different from n1, your old file will be destroyed and a new one created. If you want to keep the old file, rename it or copy it to somewhere else before running the LOADER program.

    q
    Specifies the translation mode. The parameter applies only to DBCS mode. The parameter value can be:

    S
    Standard ASCII-EBCDIC and EBCDIC-ASCII translation

    P
    ASCII-EBCDIC translation with ASCII SI/SO characters changed to EBCDIC SI/SO characters, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to ASCII SI/SO characters

    B
    Standard ASCII-EBCDIC translation, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to blanks.

    x
    Specifies the reception mode for CLISTs. The parameter value can be:
    B
    The CLIST is received as a binary file.
    E
    The CLIST is received as an EBCDIC file.

    The default is E.

    r
    Is the interval, in minutes, before retrying a connect to SNA and communications provider after a communications problem. The value must be an integer in the range 0 (which is taken to mean 30 seconds) and 1440 (24 hours). The default value is 0.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    Searcher

    LOADER SFQUERY.EXE [/K:y]
    

    where y is the size, in KBs, of the buffer used to read the electronic journal and store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the highest of the values assigned in the loading statements of the electronic journal and store-for-forwarding servers.

    This loading statement does not correspond to a separate functional area. The SFQUERY.EXE program is required by the electronic journal and the store-for-forwarding servers.

    Service Availability Manager

    This loading statement does not correspond to a separate functional area. The EHCSAM.EXE program is required by shared-file servers when using the XLR (external logging replicator) facility. For details, see LANDP Servers and System Management.

    LOADER EHCSAM.EXE
    

    Shared-file server

    (Note In this statement, the last parameter uses the letter O, not the digit 0.)

    LOADER SHFILE##.EXE [/C:confname] [/B:nnn] [/E] [/R] [/S:xxx] [/L:y] [/F:zz]
    [/X:ss] [/A:ttt] /O
    

    where:

    confname
    Specifies the name of the profile that defines the shared file. If you omit this parameter, the server uses the name CONFIGUR.

    nnn
    Specifies the number of additional 1 KB index buffers to be allocated; that is, buffers over 15. More index buffers increase system throughput, but also reduce the amount of free storage available for the server workstation. A rule of thumb is that the number of buffers should be 10 per workstation using the shared file server simultaneously. A practical limit is approximately 100, depending on available storage size. The maximum value is 968.

    Another factor that must be considered is that the more buffers you have, the greater is the probability of losing index file data when the shared file server is abnormally ended. Thus, if many index buffers are allocated, and the server workstation is switched off with a transaction still in process, or if no RF function has been called, an automatic index rebuild is issued the next time the server is loaded.

    /R
    Is an optional parameter to rebuild FREECHAIN. Use it after receiving a X'A7' loading error.

    /E
    Is an optional parameter to create a file for the statistics gathered during the session.

    xxx
    Specifies the total number of additional sessions in the whole workgroup that the server can manage. The maximum is 243.

    This number plus the number of workstations that receive services must not be higher than 243.

    y
    Specifies the log management type. The parameter value can be:
    0
    Dynamic and static log with a unique log file
    1
    Dynamic log with a unique log file
    2
    Dynamic and static log with two log files
    3
    Dynamic log with two log files

    The default is 0.

    zz
    Is the number of files open at a time.

    The parameter value can range from 10 to 245.

    ss
    Is the suffix of the XLR server pair. For example, for SHFILE01/BKFILE01, /X:01 would be specified.

    ttt
    Is the time delay in seconds before an automatic takeover by the backup is attempted when the active terminates. A value of zero means that no automatic takeover is attempted. This parameter is valid only for XLR servers.

    Range: 0-999

    /O
    Overrides normal XLR initialization if only one EHCSAM server is available. This parameter has no default. Use it when only one EHCSAM server is available and then only when you are certain that up-to-date databases are available to that server. Do not use this parameter until you have read the following section. (Note: This parameter uses the letter O, not the digit 0.)

    Use of /O parameter

    During XLR server initialization, LANDP:

    If a majority vote of at least two SAMs cannot be achieved, LANDP issues the following messages, where xlr can be SH or BK.

    EHC0587: Waiting for XLR state confirmation (Last XLR state on WS N1:
    xlrFILE01).
    EHC0588: Start other XLR WS, or use /O parameter on SHFILE## to override.
    

    If one of the XLR workstations is permanently unavailable and no other SAM is active, the server cannot complete initialization. If you are sure that the state given in the first message is correct, and that the issuing server has up-to-date copies of the databases, you can force confirmation by restarting SHFILE## with the /O parameter. Do not use this parameter in any other circumstances.

    Consider the following scenario:

         Workstation X1                     Workstation N1
     
         Start as Active                    Start as Backup
         Process transactions               Track transactions
         Machine failure                    Take over as new Active
         Repair.....                        Process transactions
         .....machine                       Normal shutdown
         Start as  ???
    

    In the last step, it is not safe for the XLR server on X1 to initialize. With /O specified, X1 would erroneously assume that it is still the active and use out-of-date data. The only thing to do is to get workstation N1 running as soon as possible. Meanwhile:

    In the above scenario, you must wait until workstation N1 is initialized. The following is a scenario in which it is safe to use the /O parameter:

         Workstation X1                     Workstation N1
     
         Start as Active            Start as Backup
         Process transactions       Track transactions
         Machine failure            Take over as new Active
         Repair.....                Process transactions
               .....                Normal shutdown
               .....                Start as Active with /O parameter
    

    In this case, N1 has up-to-date databases and can safely be started as the active, so the use of the /O parameter is valid. When X1 or another EHCSAM server again becomes available, it automatically becomes the backup, bringing its log and databases up-to-date by communication with N1.

    Note:
    After messages EHC0597 and EHC0588 are issued, and before user intervention with the /O parameter, another SAM may start up. If this causes a majority vote, the chosen active XLR server continues initialization.

    SNA server

    LOADER SNA##.EXE [/R:r]
    

    where:

    r
    Is the number of retries if a Connect to an SNA provider for a session returns the LINK_NOT_STARTED_RETRY message.

    The value must be an integer in the range 0 (do not retry) to 8. It is advisable to specify a low value, for example 1; if the connection does not succeed after one retry, there is likely to be a problem in the communications network which needs to be resolved before the connection can succeed.

    Store-for-forwarding server

    LOADER SFORFORW.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Supervisor

    LOADER SPV.EXE /pc-id
    

    where:

    pc-id
    Is the identifier of the workstation that was assigned during customization. The parameter value is a string of up to 2 alphanumeric characters, and is case sensitive.

    System manager server

    LOADER SMGR.EXE /D:x /O:yyyyyyyy  [/Z:nnnn]
    

    where:

    x
    Is the drive where the FBSS#GDT backup is located. If the parameter is omitted, the backup is not performed.

    yyyyyyyy
    Is the NetView operator ID. The default is OPER1.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    TCP/IP wide area communications server

    LOADER EHCTCP.EXE [/M:aaaaaaaa[,aaaaaaaa]] [/T]
    

    Where:

    aaaaaaaa
    Is the name of a LANDP communications server to be emulated. This can be SNA## to emulate the SNA server, PPC to emulate the PPC server, or both.

    /T
    Is an optional parameter to turn on internal tracing for problem determination.

    Trace tools

    LOADER EHCTRACW  [/R:rrrr] [/B::bbb] [/T:xxx] [/MT:mmm] [/ML:mmm] [/LT:lll]
     [/LL:lll] [/PT:[d:][path]filename] [/PL:[d:][path]filename]
    

    where:

    rrrr
    Is the record length in shared memory.

    The variable rrrr can take values between 64 and 1024 + 64. The default is 394.

    bbb
    Is the maximum number of records in shared memory.

    The variable bbb can take values greater than 1. The minimum is 2, and the default is 162.

    Note that the maximum number of bbb is calculated using the formula:

    [(64 × (1024 - 64)) ÷ (record length rrrr)]

    xxx
    Is the trace option. There are three options for /T (trace facility):

    NO
    No trace is provided

    MEMORY
    Trace records in memory only

    FILE
    Trace records in memory and in the file specified by the /PT parameter.

    The default is MEMORY. This parameter does not affect the log file, because a log error file is always provided by the server.

    mmm
    Is the maximum number of records for Trace file (/MT) and Log file (/ML). The variable mmm can take values between 1 and 50000. If there is not enough space available, an error will be returned. The default in both cases is 512.

    You must erase the existing Trace or Log files when you are creating new ones, otherwise the new parameters will not take effect.

    Note that you must specify /T:FILE in the loading statement when you create a new Trace file.

    lll
    Is the maximum record length for Trace file (/LT) and Log file (/LL). The variable lll must be less than or equal to rrrr. The minimum value is 128.

    The default for Trace is 394. The default for Log is 150.

    d
    Is the drive where the Trace file and the Log file will be created.

    path
    Is the path where the Trace file (/PT) and the Log file (/PL) will be created. The path must be less than 128 bytes.

    filename
    Is the name of the Trace file (/PT) and the Log file (/PL). The default name is EHCTRCxx.DAT for Trace, and EHCLOGxx.DAT for Log. In both cases, xx is the workstation identifier.

    If EHCTRACW is loaded while the supervisor is still in the loading process, the workstation ID value xx in the filenames EHCTRCxx and EHCLOGxx will sometimes be given the value [!!]. This may happen if you load with the DETACH command. To avoid this, you can either use the LOADER command, or rename the xx value for the files afterwards.

    Virtual DOS machine relay

    LOADER EHCVDMGR.EXE [path\name]
    

    where:

    path
    Is the directory where the configuration file created for the VDM relay is located.

    name
    Is the name of the configuration file.

    The configuration file is optional. The default is EHCBOXS.CFG, if it exists.

    Financial printer server

    LOADER PR47X2##.EXE [/K:n] [/T] [/N] [/R]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    /T
    Causes the printer event log PR4742.TXT to be generated.

    The parameter is optional.

    Network attached laser printer support

    In LANDP for Windows only, the WR (Write to Printer) request allows the DEFAULT Parallel Attached printers to be accessed.

    Use two new load-time parameters:

    /N
    This tells WR to use the default printer on Windows (local or LAN-attached). Without this parameter, the printer server writes only to the local attached printer in PROPRINTER mode.

    /R
    This tells the server to leave the data as RAW data and not parse it. Any printer-control escape sequences in the datastream can pass through without being reformatted by the printer server.

    Running with /N but without /R, the server allows normal PROPRINTER escape sequences to be passed through to the printer. With /R, Postscript or PCL data streams pass through without change.

    Accessing the DEFAULT Parallel Attached printers

    While running as a service, LANDP does not have any knowledge of who is, or is not, logged on. To allow it to find a default printer, the printer server needs an identity. To do this, allow the server to log on as a particular user. Do this after the servers have been registered (that is, AUTOFBSS has run at least once).

    In control panel,

    1. Select Services
    2. Scroll to LANDP PR47X2## Server, and left double-click.
    3. Change the part of the panel that says Log on AS from system account to this account.

      Select the account name and password that the printer server is supposed to use.

    4. To make the changes take effect, stop LANDP and rerun AUTOFBSS.

    Selecting as above in the services panel enables the server to find the default printer. There is no default way to do this, even if a user is logged on. This also allows a different user to be logged on when LANDP is running in the background.

    If you unregister LANDP

    If you run AUTOFBSS /R:, you totally unregister LANDP. If you then want to access DEFAULT parallel attached printers, you must:

    1. Run AUTOFBSS to re-register PR47X2##.EXE
    2. Repeat the process described in Accessing the DEFAULT Parallel Attached printers.

    4748 printer server

    LOADER PR4748##.EXE [/K:n]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    Loading statements for emulators in a Windows VDM

    If you select VDM (virtual DOS machine) relay during customization, and define the emulators to be loaded in a Windows VDM, the customization program creates an AUTO_VDM.BAT file with the emulator loading statements. The LSI command is used to run the emulators in the Windows VDM.

    When you install more than one emulator, they can run in different Windows VDMs. A separate AUTO_VDM.BAT file is required for each VDM, containing the loading statements for the emulators that run in that particular VDM. To create those files, copy only the required loading statements.

    FBSS (DOS) and LANDP for DOS clients (not servers) can also be run in a Windows VDM. If the VDM relay is not working on your Windows system, check the following.

    If you are loading EHCVDSPV from AUTOEXEC.NT, all 16-bit Windows (WOW or Win16-on-Win32) lock EHCVDVXD.DLL, so it cannot be replaced. To overcome this either:

    Banking interactive workstation program

    LSI VBIWP.EXE /C:atr /K:kbd /D:dis /T:at1 /P:pin /M:msi /N:mso /I:n
    

    where:

    atr
    Is the name of the selected display color attributes table.

    kbd
    Is the name of the selected keyboard ASCII-to-EBCDIC translation table.

    dis
    Is the name of the selected display EBCDIC-to-ASCII translation table.

    at1
    Is the model and attribute definitions.

    pin
    Is the name of the selected PIN pad input table.

    msi
    Is the name of the selected MSR/E input table.

    mso
    Is the name of the selected MSR/E output table.

    n
    Is the emulator identification number.
    Note:
    The VBIWP.EXE program running in a Windows VDM includes support for LDA7 block transfer sessions.

    Banking printer program

    LSI VBPP.EXE /E:e2a /H:ses /L:pses /M|S /I:n
    

    where:

    e2a
    Is the name of the selected EBCDIC-to-ASCII translation table.

    ses
    Is the name of the selected printer session.

    pses
    Is the name of the printer port.

    M|S
    Is the DOS-allowed indicator; M is Yes, S is No.

    n
    Is the emulator identification number.

    3270 emulator

    LSI EMU3270.EXE /C:atr /K:kbd /D:dis /I:n [/H:hh] [/W:ww] [/B:y]
             [/S:xxxxxxxx] [/Z:nnnn] [/P:a] [/L:l] [/T:tt]
    

    where:

    atr
    Is the file extension of the selected display color attributes table.

    kbd
    Is the file extension of the selected keyboard ASCII-to-EBCDIC translation table.

    dis
    Is the file extension of the selected display EBCDIC-to-ASCII translation table.

    n
    Is the emulator identification number.

    hh
    Specifies the alternate screen height (number of rows) of the 3270 display to be emulated. (The height specified should not include the operator information area line at the bottom of the emulator screen.) nn must be in the range 24 through 49.

    Use this parameter, in conjunction with /W, to make the emulated alternate screen look like one of the following 3270 models:

                       Alternate             Alternate
    3270 model         screen height         screen width
        2                   24                    80
        3                   32                    80
        4                   43                    80
    

    If this parameter is omitted, the default is 24.

    ww
    Specifies the alternate screen width (number of columns) of the 3270 display to be emulated. ww must be 80.

    If this parameter is omitted, the default is 80.

    y
    Indicates whether blinking is supported. Specify Y for yes or N for no.

    If this parameter is omitted, the default is N.

    xxxxxxxx
    Specifies the long name of the 3270 emulator session (sometimes known as the "host session ID"), which is displayed in the operator information area on the screen. You can specify up to eight characters (with no imbedded blanks).

    If this parameter is omitted, the default is a name of eight blanks.

    nnnn
    Specifies the size (in bytes) of the buffer used to communicate with the host. nnnn can be any value in the range 2048 through 4096. Specifying a small buffer size minimizes memory requirements; using a large buffer can reduce the number of transmissions needed to send or receive a large data stream. The parameter value specified must match the RU size detailed in the bind session.

    If this parameter is omitted, the default is 2048.

    a
    Indicates whether the 3270 emulator should handle the Print Screen key. Specify N for no or Y for yes.

    If this parameter is omitted, the default is Y.

    l
    Indicates whether the SNA session is connected at emulator load time rather than at 'hot key' time. Specify N for NO or Y for YES. The default is N.

    tt
    Specifies the minimum time in seconds between checks on 'print screen' key presses. The default is 3.
    Note:
    When working with Windows workstations, the 3270 emulator can be used only in a Windows VDM. When working in DBCS mode, the 3270 emulator cannot be used in a Windows VDM, and therefore it cannot run on a LANDP for Windows workstation.

    3287 printer emulator

    LSI EMU3287.EXE /x /E:prt [/T:nn] [/P:HP] [/N:n]
    

    where:

    x
    Can be S or M. Select S for single and M for multiple LU_1 support.
    Note:
    This parameter and its values are no longer supported, though they will be accepted for compatibility purposes with earlier versions of LANDP. If specified, they will be ignored.

    prt
    Is the file extension of the selected EBCDIC-to-ASCII translation table.

    nn
    Is the frequency of polling.

    The parameter value ranges from 1 to 60. The default is 15.

    /P:HP
    Indicates that the 3287 printer emulator will use either an IBM 4019 Printer, an IBM 4029 Printer, or an IBM 4039 Printer for output. The default is to use an IBM 4201 Proprinter or equivalent device.

    /N:n
    Specifies the range of logical printer numbers that can be used. The parameter value can be in the range 1 through 3. Specify:

    If the parameter is not specified, the emulator uses the number of parallel printer ports physically installed on the workstation.

    Note:
    When working with Windows workstations, the 3287 printer emulator can be used only in a Windows VDM. When working in DBCS mode, the 3287 printer emulator cannot be used in a Windows VDM, and therefore it cannot run on a LANDP for Windows workstation.

    Unloading LANDP for Windows

    The EHCFREE.EXE utility is provided to unload LANDP for Windows. You can also unload LANDP for Windows by issuing a supervisor function call from an application program. For more information on supervisor function calls, see LANDP Programming Reference.

    The LANDP utility, EHCFREE.EXE, is called as follows:

    d:\path\EHCFREE SPV [/p]
    

    where:

    d:
    Is the drive where the utility is located.

    path
    Is the path where the utility is located.

    p
    Is an optional parameter that can take the following values:

    The EHCFREE.EXE program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.

    Unloading LANDP for Windows servers

    The EHCFREE.EXE utility program is used to dynamically unload a LANDP for Windows server at LANDP run time. The command must be entered in the workstation where the specific LANDP for Windows server to be unloaded is located.

    Note that the EHCFREE.EXE program can also be used to unload the entire LANDP for Windows program.

    The EHCFREE.EXE program is called as follows:

    d:\path\EHCFREE servername [/p]
    

    where:

    d:
    Is the drive where the utility is located.

    path
    Is the path where the utility is located.

    servername
    Is the name of the server to be unloaded, entered in upper or in lower case. Note that if you specify SPV, the entire LANDP for Windows program is unloaded.

    p
    Is an optional parameter, which can take the following values.

    The EHCFREE.EXE program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.


    Installing run-time files

    The LANDP family provides a utility program to check the path where the run-time files are located. See Installing and validating system files for more information about this program.

    For other utility programs also provided to be used at run-time, refer to Run-time utility programs.

    The LANDP customization process creates the EHCMSG.DLL file, which must be located in the current path or in a path specified using a PATH statement in the registry table.


    Preparing Linux workstations




    ehcl

    The first part of this chapter, Installing and configuring Linux workstations, describes the requirements to install the LANDP for Linux run-time files on the Linux workstations. Some requirements are related to a specific server.

    The second part of the chapter, Linux workstation setup, describes the final step of workstation distribution.

    The third part of the chapter, Modifying run-time files, describes the process of modifying the run-time files created by the customization program, according to your needs.

    The fourth part of the chapter, Loading statements for LANDP for Linux servers, describes how to check that the files have been correctly installed.


    Installing and configuring Linux workstations

    The LANDP workstation files, which might typically be kept on diskettes, created for the Linux workstations do not contain any Linux system files. Therefore, before installing the LANDP for Linux operational files into your Linux workstation, make sure that a conforming version of Linux is installed.

    The conforming versions supported by LANDP must contain the following kernel and glibc versions:

    LANDP has been verified against the conforming versions of the following distributions of Linux for Intel-based platforms (x86 32-bit architecture):

    The TCP/IP support that LANDP for Linux requires is typically provided as part of the Linux distribution that you have chosen.

    After you have distributed the files from your customization workstation to a distribution directory that is accessible to the Linux workstations, you must run the ehcsetup utility program. Refer to "Linux workstation setup" for more details.

    When working in DBCS mode, the operating system can be one of the following depending on your national language:

    Language Linux Codeset PC codepage Linux Locale
    Traditional Chinese BIG5 950 (no defaults) zn_TW.BIG5
    Simplified Chinese GBK 1386 (no defaults) zn_CN.GBK

    Notes:

    1. The Linux Codeset and Locale available depend on which distribution of Linux you are using.

    2. Korean is not supported by LANDP for Linux.

    Installation requirements for TCP/IP transport protocol

    LANDP for Linux workstations can only communicate in a LANDP workgroup by using TCP/IP as the transport protocol. TCP/IP must be configured for all the workstations that are to communicate to a Linux workstation. For detailed information, refer to the TCP/IP information in the Linux documentation. For more information about the TCP/IP transport protocol, see Appendix E, Using TCP/IP for internal communication.

    Installation requirements for TCP/IP wide area communications server

    LANDP for Linux workstations that are configured to use the TCP/IP wide area communications server, must have Linux TCP/IP installed and configured.

    There must also be an ehctcp.ini file to provide the information required to map LANDP sessions configured with SNA and PPC servers to TCP/IP protocols, ports and internet addresses. The file can be created with any text editor, but it is best practice to use the file as generated by LANDP customization. See SES&TCP on page *** for a description of the file contents.

    Installation requirements for workstations with LANDP link servers

    Workstations that are configured to use the LANDP link server, must have TCP/IP installed and configured.

    Installation requirements for workstations with shared-file servers

    If you are migrating data definitions or Shared File data from a SHFILE## environment on another LANDP environment, refer to LANDP Programming Reference.

    Installation requirements for Java support

    The LANDP Java support on Linux is provided by the following files located in the EHCL600 directory:

    ldpjava.jar
    Java Archive File containing the LANDP Java classes

    ldpjman
    LANDP Java Manager

    ldpjdisp
    LANDP Java Dispatcher

    libldpjava.so
    shared object that implements the native methods of the LANDP Java classes

    ldpmsre.jar
    LANDP J/XFS device support for magnetic stripe readers

    ldppinp.jar
    LANDP J/XFS device support for PIN pads

    ldp47x2.jar
    LANDP J/XFS device support for the 4722 financial printer

    To support the running of Java user servers, applications, applets or servlets on a LANDP workstation, copy these files to the directory on the workstation containing the LANDP files.

    There are two alternative methods of distribution of the Java files:

    Additionally, you can copy the documentation file, ldpjdocs.zip, from the EHCL600 directory located in the customization workstation.


    Linux workstation setup

    After you have distributed the files from your customization workstation to a distribution directory that is accessible to the Linux workstations, you must perform some post-customization tasks before LANDP can be run.

    These tasks include:

    The LANDP utility program ehcsetup performs these tasks.

    Another LANDP utility program, ehcremove, can be used to delete components of an existing LANDP setup.

    LANDP User Accounts, Groups and Passwords

    All LANDP directories and files belong to the same Linux group, landp, and are owned by the LANDP Manager Account, ldpmgr. If ehcsetup detects that either the landp group or the LANDP Manager Account is not present, they will be created, using either default or user-prompted values, depending on the options specified on the command line invocation of ehcsetup.

    LANDP user accounts can be created or modified using the ehcsetup utility program. If the account is a new account, the account is created, made part of the landp group, and the password for the account is stored in the LANDP password file, .landp_passwords, in the root home directory, if requested. A user home directory will be created.

    If the account name already exists, the account will simply be added to the landp group.

    The password for the account is not recorded in a readable form anywhere, except in the LANDP password file. Therefore if ehcsetup is run without --add_password, make sure that passwords are assigned to any user accounts that are created.

    Because these accounts belong to the landp group, they can access all the LANDP files and data, but with restricted capabilities (for example, user accounts might not have the authority to delete LANDP objects).

    Note:
    At this time, ehcsetup cannot generate passwords for new accounts created on distributions from SuSE or Caldera. Passwords must be assigned to these accounts by the systems administrator before the accounts can be used.

    Under normal circumstances, LANDP runs under a user account, not under the LANDP Manager Account, and definitely not under a root account. If landp is not the primary group of the user account, the command newgrp landp should be run immediately before .ehc_profile. See LANDP Environment Variables.

    Installation Log and Error Logging

    The utility program ehcsetup generates a log, .landp_log, in the administrator home directory. This log contains details of the processing that was done during the setup run. If any errors are detected during the setup, an error message is issued and the setup is terminated.

    To help diagnose the error, the log also records any system-generated error codes associated with the error. Once the problem has been corrected, the setup can be rerun. However, any processing done before the error condition might not have been undone. Therefore, the ehcsetup parameters might need to be modified, or the incomplete setup removed and a new setup performed.

    LANDP Environment Variables

    The utility program ehcsetup generates the files that contain the LANDP environment variables. The values of these variables should be created using information extracted during the setup run. They are not built as part of customization.

    All workstation-specific environment variables are generated in the file, .ehc_profile, which is stored in the workstation directory. This file should be run as part of the user environment (ideally, it should be included in the user .profile file) to correctly build the LANDP process space.

    Running the Setup Process

    Because many of the functions performed by the ehcsetup utility program require administrator privileges, ehcsetup can be run only by the root user. The utility will check that this is the case before continuing with the setup.

    All messages and prompts produced by ehcsetup are catalog-based. To have messages and prompts displayed correctly during the workstation setup process, the ehcsetup message catalog (ehcsetup.msg), the ehcsetup message processor (ehcsmesg), and the ehcsetup script message defaults (shellmsg), must be present in the current working directory.

    Ehcsetup can be run in one of three modes:

    Ehcsetup command line options

    All the ehcsetup command line options are detailed below.

    ehcsetup [--landp_release REL]               *
             [--workstation_directory WSID]      *
             [--distribution_directory DIR]      *
             [--workstation_path WDPATH]         *
             [--no_user]                         *
             [--default_manager]                 *
             [--default_group]                   *
             [--ws_dir_exist cancel|clear|replace]
             [--release_exist cancel|clear|replace]
             [--add_password]
             [--prompt full|brief|none]
             [--quiet]
             [--ignore_parameter_file]
             [--check_parameters] 
    
    ehcsetup [--prompt full|brief|none]
             [--quiet]
              --remove         
    
    ehcsetup [--prompt full|brief]
             [--add_password]
             [--quiet]
             [--check_parameters]
              --create_user       
    
    ehcsetup [--prompt full|brief]
             [--default_manager]
             [--quiet]
             [--check_parameters]
              --create_manager       
    
    ehcsetup [--prompt full|brief]
             [--default_group]
             [--quiet]
             [--check_parameters]
              --create_group  
    
    ehcsetup  --help
    

    where:

    Note:
    In the above command-line definitions, options that should be specified for non-interactive setup are marked with an asterisk ('*').

    A full functional description of each option, with an example of its use, is detailed below. The short form of the command line option is shown in brackets. Short and long forms of the commands can be mixed on the same command line.

    --landp_release REL (-rl)

    This defines the LANDP release code, related to the distribution being set up on this workstation. The parameter value REL is used as the directory name under which the LANDP components are installed.

    There is no default value for REL. The parameter value REL can be any valid Linux directory name. See also the section Resolving Parameter Values for further details of how to define the parameter value during the running of ehcsetup.

    Example: --landp_release L60

    Example: -rl L60

    --workstation_directory WSID (-wd)

    This defines the name of the LANDP workstation directory. The parameter value WSID is the directory name under which all the LANDP workstation files are stored.

    There is no default value for WSID. The parameter value WSID can be any valid Linux directory name. See also the section Resolving Parameter Values for further details of how to define the parameter value during the running of ehcsetup.

    Example: --workstation_directory AC

    Example: -wd AC

    --distribution_directory DIR (-dd)

    This is the name of the directory that currently holds all the LANDP files that are to be distributed on this workstation. These are the workstation files generated by LANDP customization, and put into the directory after the GETTING process. The directory DIR can be either local or network attached. Ehcsetup examines each file in the directory, makes a decision based on the file type about where the file should be placed, and then copies the file to the appropriate LANDP directory. Ehcsetup makes no changes to the contents of the files in the distribution directory, but some files and file types might be modified while being copied to their destination directories.

    There is no default value for DIR. The parameter value DIR can be any valid, locally-accessible Linux directory name. See also the section Resolving Parameter Values for further details of how to define the parameter value during the running of ehcsetup.

    Example: --distribution_directory /tmp/landp

    Example: -dd /tmp/landp

    --workstation_path WDPATH (-wp)

    This defines the local path to the workstation directory. The workstation path combined with the workstation directory defines the absolute location of the LANDP workstation files. If the path does not exist, ehcsetup will create it.

    There is no default value for WDPATH. The parameter value WDPATH can be any valid, locally-accessible Linux path name. See also the section Resolving Parameter Values for further details of how to define the parameter value during the running of ehcsetup.

    Example: --workstation_path /data/landp/workstations

    Example: -wp /data/landp/workstations

    --ws_dir_exist ACTION (-wx)

    This specifies the action to be taken by ehcsetup if the workstation directory, as defined by the workstation path and the workstation directory name, already exists. The default for ACTION is cancel, which specifies that ehcsetup will terminate with an error message.

    The parameter ACTION can take either of the following values:

    Example: ws_dir_exist replace

    Example: -wx replace

    --release_exist ACTION (-rx)

    This specifies the action to be taken by ehcsetup if the LANDP release directory already exists. The default for ACTION is cancel, which specifies that ehcsetup will terminate with an error message.

    The parameter ACTION can take the following values:

    Example: --release_exist clear

    Example: -rx clear

    --no_user (-nu)

    This specifies that no user accounts should be created or modified during the present ehcsetup run. By default, ehcsetup prompts for the optional modification or creation of user accounts as part of the setup processing. For further information on user accounts, see the section LANDP User Accounts, Groups and Passwords.

    Example: --no_user

    Example: -nu

    --default_manager (-dm)

    This specifies that ehcsetup should create a LANDP manager account using defaults, if it detects that a LANDP manager account is not present on the local workstation. By default, if there is no LANDP manager account, ehcsetup prompts the user for the name of the manager account. For further information on the LANDP manager account, see the section LANDP User Accounts, Groups and Passwords.

    Example: --default_manager

    Example: -dm

    --default_group (-dg)

    This specifies that ehcsetup should create the LANDP group using the next available group number, if it detects that a LANDP group has not been setup on the local workstation. By default, if there is no LANDP group, ehcsetup prompts the user to supply a group identifier number. For further information on the LANDP group, see the section LANDP User Accounts, Groups and Passwords.

    Example: --default_group

    Example: -dg

    --add_password (-ap)

    When ehcsetup creates a new user account, it also generates a user password. This parameter specifies that the new password should be appended to the LANDP account password file .landp_passwords in the home directory of the root user. Only the root user can write or read the LANDP password file.

    The LANDP password file is only a record of the passwords generated for each new user; it has no other function, security or otherwise.

    Example: --add_password

    Example: -ap

    --prompt TYPE (-pr)

    This specifies the detail level of the prompts that are displayed to the user when ehcsetup requires input. The default for TYPE is full, which specifies that any formal prompts are preceded by a detailed explanation of the prompt and the input requirements, and a list of possible replies and examples of use.

    The parameter TYPE can also take the following values:

    brief - only the prompt itself is displayed; this is an expert mode

    none - no prompts are displayed.

    If ehcsetup is unable to resolve any required parameters, it terminates with an error message. This mode is used when ehcsetup is to run unattended.

    Example: --prompt brief

    Example: -pr none

    --quiet (-qt)

    This specifies that ehcsetup should run in quiet mode. By default, ehcsetup provides the user with a scrolled commentary that lists the tasks that it performs. In quiet mode, this commentary is not displayed, although it is still generated in the LANDP log file. For further information on the LANDP log file, see the section Installation Log and Error Logging.

    Example: --quiet

    Example: -qt

    --ignore_parameter_file (-ip)

    At the completion of every successful run, ehcsetup stores in a file, .landp_parameters, the parameters that were used. This file is held in the home directory of the root user. By default, this parameter file provides parameter values to ehcsetup on subsequent runs. See the section Resolving Parameter Values for details regarding which parameters can be supplied by the parameter file, and under what circumstances the parameter file will supply these parameters to ehcsetup. This parameter specifies that the parameter file should not be used to resolve any missing values.

    Example: --ignore_parameter_file

    Example: -ip

    --check_parameters (-cp)

    When specified, this parameter causes ehcsetup to display a list of all the proposed parameter values that are to be used in the present run, including all internally resolved parameters. No processing, except parameter checking, is performed.

    Example: --check_parameters

    Example: -cp

    --create_group (-cg)

    When specified, and if the LANDP group, landp, is not present on the local workstation, ehcsetup only performs LANDP group create processing. The user is prompted to input a group number for the new LANDP. For further details about the LANDP group, see the section LANDP User Accounts, Groups and Passwords.

    Example: --create_group

    Example: -cg

    --create_user (-cu)

    When specified, ehcsetup only performs user account processing on the local workstation. The user is prompted for the names of user accounts that are to be either created or modified. The use of this parameter implies parameter --create_group. For further details about user accounts, see the section LANDP User Accounts, Groups and Passwords.

    Example: --create_user

    Example: -cu

    --create_manager (-cm)

    When specified, ehcsetup creates a LANDP manager account, if this account is not present on the local workstation. The user is prompted for the name of the account to be created. The use of this parameter implies the parameter --create_group. For further details about user accounts, see the section LANDP User Accounts, Groups and Passwords.

    Example: --create_manager

    Example: -cm

    --remove (-rm)

    When specified, ehcsetup allows the user to remove various LANDP components from the local workstation, based on the release and/or workstation id that were specified during a previous ehcsetup. Because the user will not be able to subsequently recover any components that are removed, the user is prompted to confirm each removal before ehcsetup continues. At completion, all directories based upon the chosen LANDP release and/or workstation ID will have been removed.

    Note:
    The use of the remove option might cause LANDP to be unavailable on the workstation. In this case, ehcsetup must be used to redistribute LANDP to this workstation.

    Example: --remove

    Example: -rm

    --help (-hp)

    When specified, a summary of all the command line parameters is displayed.

    Example: --help

    Example: -hp

    Resolving Parameter Values

    The parameter values for the LANDP release, workstation directory name, distribution directory and workstation path are resolved in the following order:

    1. If any parameter is defined on the command line, this value is used.
    2. If the distribution_directory is unresolved, the value is taken from the LANDP parameter file, unless --ignore_parameter_file is specified.
    3. If the distribution_directory is still unresolved, the user is prompted for input.
    4. If either the landp_release or the workstation_directory name are not resolved, the values are taken from the AUTOFBSS file in the distribution directory, if the file and directory are present.
    5. If any parameter value is still unresolved, the value is taken from the LANDP parameter file, unless --ignore_parameter_file is specified.
    6. If any parameters at this point are unresolved, the user is prompted for input.

    Using the --check_parameters on the command line provides users with feedback about which parameter values will be used on a live run. This check is particularly useful when prompting is turned off, and when there might be different parameter values specified in the LANDP parameter and AUTOFBSS files.

    Removing LANDP Components

    Running ehcremove allows the user to delete LANDP components from the local workstation. The utility ehcremove can only be run by the root user. The utility will check that this is the case before continuing with the process. The components deleted are based on the landp release and/or the workstation id as specified during a previous ehcsetup. Because the user cannot subsequently recover components deleted during ehcremove, prompting occurs at several points to confirm the deletion before continuing. At completion, all directories based upon the chosen LANDP release and/or workstation id will have been removed.

    Warning - the use of ehcremove might cause LANDP to become unavailable on the workstation. In this case, ehcsetup must be used to redistribute LANDP to this workstation.


    Running LANDP DOS applications on Linux

    DOS is supported on Linux using DOSEMU. This can be obtained from the www.dosemu.org website. You are responsible for correctly installing this, and the LANDP plug-in, on your Linux system. For more information refer to Chapter 24 of the LANDP Programming Reference.

    The DOS-box Relay DOS stub (EHCVDSPV.COM) must be loaded in a DOS-box that will run LANDP/DOS applications. This can be achieved in a number of ways, some of which are covered here. The most appropriate way depends on the way the workstation is used.

    If the workstation will only be used for specific LANDP for DOS applications, it might be appropriate to invoke EHCVDSPV in-line with the application using a batch file as in the following example:

         STARTAPP.BAT
     
              LOADHIGH EHCVDSPV.COM
              LANDPAPP
              EXIT
     
    

    In this case the DOS-box Relay DOS stub is loaded into high memory and the LANDP for DOS application is started. The window is closed on termination of the application. No changes to AUTOEXEC.BAT are required.

    If all MS-DOS prompts have the capability to run LANDP for DOS applications, the following should be added to AUTOEXEC.BAT:

             D:
            CD \LANDPV6
            EHCVDSPV
    

    This example assumes that the LANDP runtime exec is in D:\LANDPV6.

    EHCVDSPV optional parameters

     

    -Q
    Quiet mode; no copyright messages issued.

    -I
    Initialize immediately. This requires that LANDP for Linux has been started already. By default, initialization is delayed until the first LANDP API call.

    -U
    Unload a previously installed copy of EHCVDSPV if safe to do so.

    Loadhigh can be used to load EHCVDSPV. Refer to the Linux help information for details.


    Loading libehclnx.so in LANDP for Linux

    libehclnx.so is a shared object (similar to a dynamic link library) that contains the LANDP interface routines RMTREQ, GETRPLY, SRVINIT, GETREQ, RMTRPLY, and RMTAREQ.

    libehclnx.so is loaded in the supervisor and in every other LANDP process. LANDP for Linux expects libehclnx.so to be mapped to the same virtual address in every process that uses it. If the supervisor attempts to load libehclnx.so at an address that another process has already used, the load fails. To prevent this problem arising:

    1. Use the environment variable, EHC_MAP_LOC, in all shells that will run a LANDP process:
         $export EHC_MAP_LOC=value 9000000
      

      where value is the virtual address where libehclnx.so. The default virtual address is 9000000.

    2. Ensure that the supervisor is always started first.

    Figure 10 illustrates the problem and the solution.

    Figure 10. libehclnx.so loading problem and solution

    Possible situation without EHC_MAP_LOC environment variable
    defined. libehclnx.so is loaded at different virtual addresses
    in the supervisor and application. This causes a failure.


    EHCGR972

    Possible situation with EHC_MAP_LOC environment variable
    defined. libehclnx.so is always loaded at the same virtual
    address in the supervisor and all applications, provided the supervisor is
    started first.


    EHCGR973


    Restarting LANDP

    On Linux systems, signals are sent to processes to indicate that a particular event has occurred. These signals might be sent from the hardware, from other software, or from other processes. The signals are detected and handled by programs in a similar way to exceptions.

    The ability to catch and handle an exception is necessary to keep a system stable. But in Linux, not all signals can be caught. SIGKILL and SIGSTOP will end a process without performing any signal-handling. This means that some resources held by that process might not be released back to the operating system or shared libraries.

    The ehcrstml utility program is called by autofbss before the supervisor is loaded. This utility restarts the shared library libehcmap.so by removing all allocated semaphores and queues. The utility can only run if the supervisor is not loaded. Therefore, LANDP should be unloaded before running this utility.

    If a LANDP process is sent a SIGKILL or a SIGSTOP, the workstation should be unloaded and ehcrstml should be run before reloading LANDP.

    ehcrstml has no parameters.


    Modifying run-time files

    You might need to modify the contents of the autofbss file.

    Depending on the applications and servers that you have developed, and the devices that you have installed, additional files might also need to be copied.

    Contents of autofbss

    The autofbss file contains the loading statements of the supervisor and the servers that are to reside on the workstation. The first program loaded is the supervisor.

    Ensure that any modification of this file does not cause a server to be loaded before the supervisor. Application loading statements should be placed at the end of the server loading statements.

    Note:
    To get trace and log information about the loading process, you have to load the trace tool immediately after the supervisor.

    Linux provides two uncatchable signals, SIGKILL and SIGSTOP, that will force a process to end. Because system resources are not freed when you use SIGKILL or SIGSTOP to end a process, this way of ending a process is not recommended. If a LANDP process has been ended in this way, you must release its system resources using the utility ehcrstml to ensure that LANDP behaves normally.

    Note:
    The utility ehcrstml must only be used when LANDP is not running.

    The following is an example of an autofbss file for a workstation that contains the shared file server. The name of the workstation is AB.

    #!/bin/bash
    #
    # Exit routine in case of any loader error
    doexit ()
    {
      ehcfree spv
      exit 1
    }
    #
    # Echo commands to user
      set -x
    #
    # Ensure clean system before LANDP startup
      ehcrstml
      if [ $? -ne 0 ] ; then
         exit 1
      fi
      varparm
      if [ $? -ne 0 ] ; then
         doexit
      fi
    #
    # Load the LANDP supervisor
      loader spv -AB
      if [ $? -ne 0 ] ; then
         doexit
      fi
    # prodlvl=l60
    #
    # Load the TCP/IP workgroup transport protocol
      loader  ehclip
      if [ $? -ne 0 ] ; then
         doexit
      fi
      newcfg
      if [ $? -ne 0 ] ; then
         doexit
      fi
    #
    # Load the shared file server
      loader shfile## -C:SFSEDUC -B:3 -E -S:10 -L:0 -F:10
      if [ $? -ne 0 ] ; then
         doexit
      fi
    # end of file
     
    

    You should invoke the ehccinfo utility program from a command prompt to get information about LANDP for Linux status. ehccinfo is a LANDP utility program; it is described in the LANDP Servers and System Management book.

    Loading statements for LANDP for Linux servers

    Most loading statements explained in this section are automatically created by the customization program, using the parameters that you provided. The following commands appear in the autofbss file provided by customization. Manual modifications can be done if required. The loader command is used to run the servers and the supervisor, in the background.

    These are regular Linux programs that can be started from the shell prompt, either as a foreground or background task. Note that using the loader command displays the return codes corresponding to the initialization process.

    The loader program provides an optional parameter t to specify the timeout for a specific server load:

      loader [-t:xxxxservername serverparms
    

    The timeout value xxxx can be up to four characters long. The minimum timeout is 1 second and the maximum timeout is 3600 seconds. If a timeout is not specified, the default that is used when loading the server is 30 seconds.

    serverparms are qualified by a hyphen, '-', and are of the form -<param>:<value>.

    If the initialization completes without error, the server goes into a wait state until it receives a request from an application. If an error occurs during initialization, the error is logged in the Linux system log.

    To check the type of error, use if [ $? -ne 0 ] statements. If a LANDP error occurs, the corresponding error code is returned.

    Error codes returning during loading are listed in the LANDP Problem Determination book.

    The following commands are used when you load the LANDP for Linux functional areas.

    Electronic journal server

    loader elecjo## [-K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the electronic journal records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Forwarding server

    loader forward -O:vvvvvvvv.vvv [-T:wwww] [-S:xxxxxxxx.xxx] [-K:y] [-H:z] [-Z:nnnn]
    

    where:

    vvvvvvvv.vvv
    Is the name of the file corresponding to the ASCII-to-EBCDIC translation table. It must follow the operating system rules.

    wwww
    Is the number of time ticks after which the supervisor will dispatch the forwarding function. One time tick is roughly 0.05 seconds.

    It can range from 1 to 6000. The default is 20 (about 1 second).

    xxxxxxxx.xxx
    Is the name of the file corresponding to the sign-on feature. It must follow the operating system rules.

    y
    Is the size, in KBs, of the buffer used to read the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the value assigned in the loading statement of the store-for-forwarding server.

    z
    Specifies whether headers are included when sending host computer messages. The parameter value can be Y, to include headers, or N, not to include headers. The default is Y.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    LANDP Internet Protocol

    loader ehclip [-N:n] [-Y] [-T] [-C[:ws-id]] [-O:o[filename]] [-J]
    

    where:

    n
    Specifies the TCP/IP port number used by LANDP Internet Protocol.

    The parameter value ranges from 1024 to 65535. The default is 52699.

    Y
    Specifies that no availability probe datagram will be sent, when a session has no normal traffic.

    T
    Requests LANDP Internet Protocol internal routines trace.

    C
    Requests LANDP Internet Protocol communications trace. All sessions are traced, except when the ws-id parameter is specified. In this case, only the session with the workstation specified in that parameter is traced.

    o
    Specifies the destination of trace data. The parameter value can be:

    1
    Standard output. Trace data will be in '/dev/console'.

    2
    ASCII file. If you do not specify a name of file, the trace data is stored in the LIPTRACE.TRC file. The target file is initialized each time. Thus, if an existing file is used, the file contents get lost.

    3
    EHCTRACW (the default).

    J
    Specifies that no checking for related workstations with undefined LANDP Internet Protocol addresses will be carried out.

    LANDP link server

    loader ehclink [-T] [-E:eeeeeeee[,eeeeeeee...]] [-I:iiiiiiii[,iiiiiiii...]
                   -L:llllllll [-A:aaaaaaaa[,aaaaaaaa...]] [-R:rrrr]] [-P:ppppp]
    

    where:

    T
    Turns on component internal tracing.

    eeeeeeee
    Are the names of up to 10 services to be exported. Only these local workgroup services are made available to remote workgroups. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    iiiiiiii
    Are the names of up to 10 services to be imported. Only these remote workgroup services are made available in the local workgroup. Names must not appear more than once in this parameter. Either the imports parameter, or the exports parameter, or both, must be specified.

    llllllll
    Is the TCP/IP network name, or the IP address of the workstation running the LANDP link server that is exporting services. Network names must be resolvable to IP addresses by the domain name server or the local HOSTS file.This parameter must be present when, and only when, the imports parameter is also specified.

    aaaaaaaa
    Are alias names of services to be imported. The names in the alias parameter correspond one-to-one with the names in the imports parameter. If an alias is specified, an imported service will be made available with the corresponding alias name. If the alias parameter is absent, or if the corresponding alias name is null, the imported service will be made available without the name being changed. Names must not appear more than once in this parameter. If an import name has trailing '#' characters, the corresponding alias name must have the same '#' characters. This is an optional parameter that is allowed only if the imports parameter is also specified.

    rrrr
    Is the connection retry interval in seconds. It is in the range 0 through 3276. A value of 0 means no retry. The default retry interval is 30 seconds. This is an optional parameter that is only allowed when the imports parameter is also specified.

    ppppp
    Is the TCP/IP port number. It is in the range 1024 through 65535. The default value is 52699. To make a connection the exporting LANDP link server and the importing LANDP link server must use the same TCP/IP port. This is an optional parameter.

    The LANDP link server can act as both an exporter and an importer of services. It can do both at the same time, if required.

    There can be any number of exporters and importers in a workgroup and in a workstation, but only one exporter on each workstation can use each TCP/IP port number.

    Magnetic stripe reader/encoder server

    loader msre47## [-C:x] [-D:n] [-O:e]
    

    where:

    x
    Identifies the Linux communications port to which the MSRE device is attached.

    The parameter is optional. The value that can be specified is in the range 1 to 8. The default is 1.

    n
    Identifies whether a 4777 MSRE device may be combined with a 4778 on the same workstation.

    The parameter is optional; if used, the value specified must be 1.

    e
    Enables some 4777 device requests to be redirected to a 4778.

    The parameter is optional. The value specified can be 0 or 1. The value 0 (the default) disables redirected device requests. The value 1 enables the requests.

    PIN pad server

    loader pinp47## [-M] [-C:x]
    

    where:

    M
    Indicates that 4778 magnetic stripe reader capabilities are to be used.

    The parameter is optional.

    x
    Identifies the Linux communications port to which the PIN pad device is attached.

    The parameter is optional. The value that can be specified is in the range 1 to 8. The default is 1.

    Service Availability Manager

    loader ehcsam
    

    This loading statement does not correspond to a separate functional area. The ehcsam program is required by shared-file servers when using the XLR (external logging replicator) facility. For details, see LANDP Servers and System Management.

    Shared-file server

    loader shfile## [-C:confname] [-B:nnn] [-E] [-R] [-S:xxx] [-L:y] [-F:zz]
                    [-X:ss] [-A:ttt] -O 
    

    where:

    confname
    Specifies the name of the profile that defines the shared file. If you omit this parameter, the server uses the name CONFIGUR.

    nnn
    Specifies the number of additional 1 KB index buffers to be allocated; that is, buffers over 15. More index buffers increase system throughput, but also reduce the amount of free storage available for the server workstation. A rule of thumb is that the number of buffers should be 10 per workstation using the shared file server simultaneously. A practical limit is approximately 100, depending on available storage size. The maximum value is 968.

    Another factor that must be considered is that the more buffers you have, the greater is the probability of losing index file data when the shared file server is abnormally ended. Thus, if many index buffers are allocated, and the server workstation is switched off with a transaction still in process, or if no RF function has been called, an automatic index rebuild is issued the next time the server is loaded.

    -R
    Is an optional parameter to rebuild FREECHAIN. Use it after receiving a X'A7' loading error.

    -E
    Is an optional parameter to create a file for the statistics gathered during the session.

    xxx
    Specifies the total number of additional sessions in the whole workgroup that the server can manage. The maximum is 243.

    This number plus the number of workstations that receive services must not be higher than 243.

    y
    Specifies the log management type. The parameter value can be:
    0
    Dynamic and static log with a unique log file
    1
    Dynamic log with a unique log file
    2
    Dynamic and static log with two log files
    3
    Dynamic log with two log files

    The default is 0.

    zz
    Is the number of files open at a time.

    The parameter value can range from 10 to 245.

    ss
    Is the suffix of the XLR server pair. For example, for SHFILE01/BKFILE01, -X:01 would be specified.

    ttt
    Is the time delay in seconds before an automatic takeover by the backup is attempted when the active terminates. A value of zero means that no automatic takeover is attempted. This parameter is valid only for XLR servers.

    Range: 0-999

    -O
    Overrides normal XLR initialization if only one ehcsam server is available. This parameter has no default. Use it when only one ehcsam server is available and then only when you are certain that up-to-date databases are available to that server. Do not use this parameter until you have read the following section. (Note: This parameter uses the letter O, not the digit 0.)

    Use of -O parameter

    During XLR server initialization, LANDP:

    If a majority vote of at least two SAMs cannot be achieved, LANDP issues the following messages, where xlr can be SH or BK.

    EHC0587: Waiting for XLR state confirmation (Last XLR state on WS N1:
    xlrFILE01).
    EHC0588: Start other XLR WS, or use -O parameter on SHFILE## to override.
    

    If one of the XLR workstations is permanently unavailable and no other SAM is active, the server cannot complete initialization. If you are sure that the state given in the first message is correct, and that the issuing server has up-to-date copies of the databases, you can force confirmation by restarting SHFILE## with the -O parameter. Do not use this parameter in any other circumstances.

    Consider the following scenario:

         Workstation X1                     Workstation N1
     
         Start as Active                    Start as Backup
         Process transactions               Track transactions
         Machine failure                    Take over as new Active
         Repair.....                        Process transactions
         .....machine                       Normal shutdown
         Start as  ???
    

    In the last step, it is not safe for the XLR server on X1 to initialize. With -O specified, X1 would erroneously assume that it is still the active and use out-of-date data. The only thing to do is to get workstation N1 running as soon as possible. Meanwhile:

    In the above scenario, you must wait until workstation N1 is initialized. The following is a scenario in which it is safe to use the -O parameter:

         Workstation X1                     Workstation N1
     
         Start as Active            Start as Backup
         Process transactions       Track transactions
         Machine failure            Take over as new Active
         Repair.....                Process transactions
               .....                Normal shutdown
               .....                Start as Active with /O parameter
    

    In this case, N1 has up-to-date databases and can safely be started as the active, so the use of the -O parameter is valid. When X1 or another ehcsam server again becomes available, it automatically becomes the backup, bringing its log and databases up-to-date by communication with N1.

    Note:
    After messages EHC0597 and EHC0588 are issued, and before user intervention with the -O parameter, another SAM may start up. If this causes a majority vote, the chosen active XLR server continues initialization.

    Store-for-forwarding server

    loader sforforw [-K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum:

    Supervisor

    loader spv -pc-id
    

    where:

    pc-id
    Is the identifier of the workstation that was assigned during customization. The parameter value is a string of up to 2 alphanumeric characters, and is case sensitive.

    System manager server

    loader smgr -D:path -O:yyyyyyyy  [-Z:nnnn] [-r:cc]
    

    where:

    path
    Is the path where the FBSS#GDT backup is located. If the parameter is omitted, the backup is not performed. The maximum length of path is 255 characters.

    yyyyyyyy
    Is the NetView operator ID. The default is OPER1.

    nnnn
    Is the host code page identifier (DBCS countries or regions only). The permitted values are:
    933
    Korea
    935 or 1388
    People's Republic of China (the default value is 935)
    937
    Taiwan

    cc
    Is the code that is returned when the SD (Set system date and time) function is used on Linux. The SD function is not supported on Linux and, by default, X'P1' is returned; however, for migration purposes, the -r parameter allows a user specific code to be returned.

    TCP/IP wide area communications server

    loader ehctcp [-M:aaaaaaaa[,aaaaaaaa]] [-T]
    

    Where:

    aaaaaaaa
    Is the name of a LANDP communications server to be emulated. This can be SNA## to emulate the SNA server, PPC to emulate the PPC server, or both.

    -T
    Is an optional parameter to turn on internal tracing for problem determination.

    Trace tools

    loader ehctracw  [-R:rrrr] [-B::bbb] [-T:xxx] [-MT:mmm] [-ML:mmm] [-LT:lll]
     [-LL:lll] [-PT:[d:][path]filename] [-PL:[d:][path]filename]
    

    where:

    rrrr
    Is the record length in shared memory.

    The variable rrrr can take values between 64 and 1024 + 64. The default is 394.

    bbb
    Is the maximum number of records in shared memory.

    The variable bbb can take values greater than 1. The minimum is 2, and the default is 162.

    Note that the maximum number of bbb is calculated using the formula:

    [(64 × (1024 - 64)) ÷ (record length rrrr)]

    xxx
    Is the trace option. There are three options for -T (trace facility):

    NO
    No trace is provided

    MEMORY
    Trace records in memory only

    FILE
    Trace records in memory and in the file specified by the -PT parameter.

    The default is MEMORY. This parameter does not affect the log file, because a log error file is always provided by the server.

    mmm
    Is the maximum number of records for Trace file (-MT) and Log file (-ML). The variable mmm can take values between 1 and 50000. If there is not enough space available, an error will be returned. The default in both cases is 512.

    You must erase the existing Trace or Log files when you are creating new ones, otherwise the new parameters will not take effect.

    Note that you must specify -T:FILE in the loading statement when you create a new Trace file.

    lll
    Is the maximum record length for Trace file (-LT) and Log file (-LL). The variable lll must be less than or equal to rrrr. The minimum value is 128.

    The default for Trace is 394. The default for Log is 150.

    d
    Is the drive where the Trace file and the Log file will be created.

    path
    Is the path where the Trace file (-PT) and the Log file (-PL) will be created. The path must be less than 128 bytes.

    filename
    Is the name of the Trace file (-PT) and the Log file (-PL). The default name is ehctrcxx.dat for Trace, and ehclogxx.dat for Log. In both cases, xx is the workstation identifier.

    If EHCTRACW is loaded while the supervisor is still in the loading process, the workstation ID value xx in the filenames ehctrcxx and ehclogxx will sometimes be given the value [!!]. To avoid this, you can either use the loader command, or rename the xx value for the files afterwards.

    Virtual DOS machine relay

    loader ehcvdmgr [path/name]
    

    where:

    path
    Is the directory where the configuration file created for the VDM relay is located.

    name
    Is the name of the configuration file.

    The configuration file is optional. The default is ehcboxs, if it exists.

    Financial printer server

    loader pr47x2## [-K:n] [-T] [-N] [-R]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

    -T
    Causes the printer event log pr4742.txt to be generated.

    The parameter is optional.

    Unloading LANDP for Linux

    The ehcfree utility program is provided to unload LANDP for Linux. You can also unload LANDP for Linux by issuing a supervisor function call from an application program. For more information on supervisor function calls, see LANDP Programming Reference.

    The LANDP utility program, ehcfree, is called as follows:

    ehcfree spv [-p]
    

    where:

    p
    Is an optional parameter that can take the following values:

    The ehcfree program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.

    Unloading LANDP for Linux servers

    The ehcfree utility program is used to dynamically unload a LANDP for Linux server at LANDP run time. The command must be entered in the workstation where the specific LANDP for Linux server to be unloaded is located.

    Note that the ehcfree program can also be used to unload the entire LANDP for Linux program.

    The ehcfree program is called as follows:

    ehcfree servername [-p] [-q]
    

    where:

    servername
    Is the name of the server to be unloaded, entered in upper or in lower case. Note that if you specify SPV, the entire LANDP for Linux program is unloaded.

    p
    Is an optional parameter, which can take the following values.

    q
    Is an optional parameter, which indicates that the server is unloaded quietly (that is, with no output to the screen).

    The ehcfree program errors are detected by the LAN server or the supervisor. For information on the corresponding return codes, refer to the LANDP Problem Determination manual.


    Installing run-time files

    The LANDP family provides a utility program to check the path where the run-time files are located. See Installing and validating system files for more information about this program.

    For other utility programs also provided to be used at run-time, refer to Run-time utility programs.

    The LANDP customization process creates the ehc.msg file, whose location is specified by the environment variable NLSPATH. This variable is set during the workstation setup.


    Preparing DOS workstations




    ehc_x000

    The first part of the chapter, Installing and configuring IBM DOS workstations, describes the requirements to install the LANDP for DOS run-time files on the DOS workstations. Some requirements are related to a specific server.

    The second part of the chapter, Modifying run-time files, describes the process of modifying the run-time files created by the customization program, according to your needs.

    The third part of the chapter, Installing run-time files, describes how to check for the correct installation of the run-time files.


    Installing and configuring IBM DOS workstations

    If the workstation files, which might typically be held on diskettes, created for the DOS workstations do not contain the DOS system files, make sure that IBM DOS V7.1 is installed according to the existing recommendations, before installing the LANDP for DOS operational files into your DOS workstation.

    When working in DBCS mode, the operating system can be one of the following, or later versions, depending on your national language:

    Language Operating system Supported codepage
    Traditional Chinese IBM DOS T2000 938, 950
    Korean IBM DOS H2000 949
    Simplified Chinese IBM DOS P2000 1381

    Installation requirements for NetBIOS transport protocol

    This section applies to LANDP for DOS workstations integrated in a LANDP workgroup that uses NetBIOS as the transport protocol.

    To use NetBIOS as the internal communications protocol for a LANDP workgroup, a NetBIOS implementation must be installed and configured in all the workstations. This can be the IBM LAN Support Program, IBM LAN Client, or another compatible implementation.

    If you select NetBIOS as the transport protocol, LANDP customization assumes that you are using the IBM LAN Support Program for a non-Network Driver Interface Specifications (NDIS) device driver. It generates a CONFIG.SYS file containing statements to load the NetBIOS device drivers. The software distribution procedure (GETTING) copies these device drivers to the distribution media. However, if you are not using the IBM LAN Support Program for a non-NDIS device driver, or if there are programs other than the LANDP NetBIOS transport using NetBIOS, you will have to configure the NetBIOS support directly.

    NetBIOS resources

    Before configuring some NetBIOS implementations you need to know what NetBIOS resources will be required. The NetBIOS resources to note are NAMES, SESSIONS, and COMMANDS. Each program that uses NetBIOS will require a number of these. Find out the programs that use NetBIOS and the resource that they require and add these resource requirements together to find the total number of NAMES, SESSIONS, and COMMANDS required for each workstation in the workgroup.

    You should take into account:

    The LANDP NetBIOS transport
    This requires 1 NAME, n SESSIONS and n+3 COMMANDS, where n is the number of other workstations that the subject workstation is configured to communicate with. Look on the DXMT0MOD line in the generated CONFIG.SYS file and you will see S, the number of sessions, and C, the number of commands.

    Servers for NetBIOS attached devices
    If the subject workstation is to run any of DTAU4733, PT4721, SP4721##, SS#####, or SS###### servers, additional NetBIOS resources will be required. LANDP customization adds 1 SESSION and 2 COMMANDS to the values in the DXMT0MOD line in the generated CONFIG.SYS file if any of these servers are configured. However, more resources might be required if more than one of them is configured, or if more than one device is assigned. Refer to the documentation of these servers for more details.

    IBM LAN Server and other products
    Refer to the documentation of these products for more details.

    IBM LAN Support program

    When using non-NDIS adapters the statements in the generated CONFIG.SYS file are usually adequate. If n1 NAMES, n2 SESSIONS and n3 COMMANDS are required, the DXMT0MOD line should be:

      DEVICE=DXMT0MOD N=n1 ST=n2 S=n2 C=n3
    

    When using an NDIS adapter there is a choice of drivers depending upon whether the IEEE 802.2 interface is required in addition to the NetBIOS interface. The LANDP TRDLC server requires the IEEE 802.2 interface.

    DXME0MOD
    If both interfaces are required the DXME0MOD driver must be used. It is easiest to configure this by changing DXMC0MOD to DXME0MOD in the customization generated CONFIG.SYS file. In addition O=N must be specified on the DXMT0MOD line, giving the following CONFIG.SYS file lines for NetBIOS:
      DEVICE=DXMA0MOD
      DEVICE=DXME0MOD
      DEVICE=DXMT0MOD N=n1 ST=n2 S=n2 C=n3 O=N
    

    DXMJ0MOD
    If only the NetBIOS interface is required, you can use DXMJ0MOD. This replaces both the DXMC0MOD and DXMT0MOD lines in the generated CONFIG.SYS file. The lines for NetBIOS are as follows:
      DEVICE=DXMA0MOD
      DEVICE=DXMJ0MOD
    

    It has no parameters as NetBIOS resource information is contained in the PROTOCOL.INI file. For more information, see PROTOCOL.INI contents.

    For either of these device drivers LANDP customization will not generate the correct software distribution statements in the GETTING.SPC files. You can either alter these or install and configure the IBM LAN Support Program separately on each workstation.

    When using the device drivers for PC Network Adapters (DXMGnMOD) or NDIS adapters (DXME0MOD) the workspace might not be large enough if there are a large number of sessions or a large volume of data traffic. A message might be generated, the adapter might fail to open, or the workstation might simply hang at start-up. The workspace is the second positional parameter for these drivers. For example, to set it to the maximum of 64K, change the DXMG0MOD line to:

      DEVICE=DXMG0MOD ,64
    

    See the IBM LAN Support Program User's Guide for more details.

    IBM LAN Client

    LANDP customization will not generate the correct software distribution statements in the GETTING.SPC files. You can either alter these or install and configure the IBM LAN Client separately on each workstation.

    Discard the IBM LAN Support Program configuration statements in the generated CONFIG.SYS file and install IBM LAN Client in the required workstations. There is no requirement to enter NetBIOS resources.

    Installation requirements for TCP/IP transport protocol

    This section applies to LANDP for DOS workstations integrated in a LANDP workgroup that uses TCP/IP as transport protocol.

    To use TCP/IP as the internal communications protocol for a LANDP workgroup, TCP/IP must be installed and configured in all the workstations.

    LANDP operates with either IBM TCP/IP for DOS version 2.1.1.4 or with PC/TCP(R) Network Software version 5.0 from NetManage Inc.(R).

    PC/TCP

    The datagram length used by LANDP must not exceed the PC/TCP maximum segment size (MSS). The MSS values for different types of network are listed in the PC/TCP Advanced Users Guide. The datagram length used by LANDP can be set by the /D parameter of the LANDP Internet Protocol (LIP) LOADER statement described in LANDP Internet Protocol.

    When large volumes of data are being transmitted, the PC/TCP kernel might require additional packet buffers for optimal performance. See the PC/TCP Advanced Users Guide for instructions on adjusting the number of packet buffers.

    For more information about the PC/TCP transport protocol, see Appendix E, Using TCP/IP for internal communication.

    The default configuration of PC/TCP has 4 TCP connections and 2 UDP connections. This might not be sufficient when using the TCP/IP wide area communications server. The connections required are:

    udp-connections
    The LANDP Internet Protocol requires 1 UDP connection and the TCP/IP wide area communications server requires 2 UDP connections, so if both are used add:
    udp-connections=3
    

    to the [PCTCP KERNEL] section of the PCTCP.INI file.

    tcp-connections
    The TCP/IP wide area communications server requires the following numbers of TCP connections:

    Listening sessions.
    One TCP connection is required for every listening session.

    TELNET sessions.
    One TCP connection is required for every TELNET session.

    MPTN (LU6.2) sessions.
    One TCP connection is required for every LU-LU combination in session, plus one TCP connection for every session between the LUs.

    MPTN (LU0/1/2) sessions.
    Two TCP connections are required for every dependent LU server (DLUS) in use plus one TCP connection for every dependent LU session.

    To change the number of TCP connections add:

    tcp-connections=number
    

    to the [PCTCP KERNEL] section of the PCTCP.INI file.

    When the TCP/IP wide area communications server is being used for MPTN (AnyNet) sessions, it is necessary to set the TCP window size parameter of PC/TCP to a value of at least 254 bytes more than the maximum RU size sent by the primary LU. The PC/TCP documentation recommends setting this parameter to a multiple of the maximum segment size of the network interface.

    To set the TCP window size, where value is the required size, add:

    window=value
    

    to the [PCTCP KERNEL] section of the PCTCP.INI file.

    IBM TCP/IP

    To prepare TCP/IP software for coexisting with LANDP, update the IntExclude parameter in the TCPDOS.INI file, located in the ETC subdirectory in the path where TCP/IP is installed. The default specifies:

      IntExclude = 61-63, 67
    

    That means that TCP/IP will not use interrupts 61, 62, 63, and 67. Because interrupt 64 is used by LANDP, to avoid unpredictable results, specify also 64:

      IntExclude = 61-64, 67
    

    For detailed information, refer to the TCP/IP manuals. See Appendix J, Bibliography.

    For more information about the TCP/IP transport protocol, see Appendix E, Using TCP/IP for internal communication.

    Installation requirements for TCP/IP wide area communications server

    LANDP for DOS workstations configured to use the TCP/IP wide area communications server must have PC/TCP installed. For more information, refer to Installation requirements for TCP/IP transport protocol.

    There must also be an EHCTCP.INI file to provide the information required to map LANDP sessions with SNA and PPC servers to TCP/IP protocols, ports and internet addresses. This file can be created with any text editor, but it is best practice to use the file as generated by LANDP customization. See SES&TCP on page *** for a description of the file contents.

    SNA over TCP/IP dependent LUs

    When using the TCP/IP wide area communications server the dependent LU names must have a common alphanumeric prefix and a numeric suffix with a constant difference between the suffix and the LOCADDR. For example:

         IYCKT300 LU LOCADDR=2
         IYCKT301 LU LOCADDR=3
         IYCKT327 LU LOCADDR=29
         IYCKT481 LU LOCADDR=183
    

    Installation requirements for TRDLC server

    This section applies to LANDP for DOS workstations configured to use the TRDLC server for SNA communications.

    To use the TRDLC server on a workstation an IEEE 802.2 interface to the LAN adapter must be installed and configured on the workstation. This can be provided by IBM LAN Support Program, IBM LAN Client, or another compatible implementation.

    If you select NetBIOS as the transport protocol and specify the TRDLC server, LANDP customization assumes that you are using IBM LAN Support Program for a non-NDIS device driver. It generates a CONFIG.SYS file containing statements to load the IEEE 802.2 device drivers. The software distribution procedure (GETTING) copies these device drivers to the distribution media. However, if you're not using IBM LAN Support Program for a non-NDIS device driver, then you will have to configure the NetBIOS support directly.

    IBM LAN Support program

    When using non-NDIS adapters the statements in the generated CONFIG.SYS file should be correct. For example:

      DEVICE=DXMA0MOD
      DEVICE=DXMC0MOD 4000xxxxxxxx
      DEVICE=DXMT0MOD N=n1 ST=n2 S=n2 C=n3 ES=1 EST=1 DS=600
    

    where 4000xxxxxxxx is the locally administered address for the adapter and 'ES=1 EST=1 DS=600' are additional required parameters for the NetBIOS driver when using the IEEE 802.2 interface.

    When using an NDIS adapter simply change DXMC0MOD to DXME0MOD in the customization generated CONFIG.SYS file. In addition, O=N must be specified on the DXMT0MOD line, giving the following CONFIG.SYS file lines:

      DEVICE=DXMA0MOD
      DEVICE=DXME0MOD 4000xxxxxxxx
      DEVICE=DXMT0MOD N=n1 ST=n2 S=n2 C=n3 O=N ES=1 EST=1 DS=600
    

    IBM LAN Client

    Discard the IBM LAN Support Program configuration statements in the generated CONFIG.SYS file.

    During IBM LAN Client installation make sure that the IEEE 802.2 interface is configured and that the locally administered address is set to the required value.

    TCP/IP and TRDLC

    LANDP customization will not permit the configuration of the TCP/IP transport together with the TRDLC server because it is not possible to run them both through the same non-NDIS adapter with IBM LAN Support program. However, with multiple adapters or with an NDIS adapter it is possible to use them together. To get around the customization restriction, customize LANDP to use the NetBIOS transport. Substitute EHCLIP.EXE for LAN.EXE in the distributed files and in the loading statement in AUTOFBSS.BAT. To arrive at the correct adapter driver configuration see the IBM TCP/IP Version 2.1.1.4 for DOS Installation and Administration manual.


    Modifying run-time files

    The main areas of modification are:

    For a utility program to modify files, see Modifying file contents.

    Depending on the applications and servers you have developed and the devices you have installed, additional files might need to be copied.

    Emulator considerations

    There are some considerations for the CONFIG.SYS and AUTOFBSS.BAT files for the emulators.

    In accordance with the keyboard and display code page selected at emulator customization time, additions might be needed in the CONFIG.SYS and AUTOFBSS.BAT files. If these are not included, you might get unexpected results.

    Note:
    The following commands do not apply to DBCS mode.

    To CONFIG.SYS, add the following DOS commands for the 3270 emulator:

        COUNTRY=xxx,yyy,COUNTRY.SYS
        DEVICE=DISPLAY.SYS CON:=(EGA,yyy,1)
    

    To CONFIG.SYS, add the following DOS commands for the 3287 printer emulator:

        COUNTRY=xxx,yyy,COUNTRY.SYS
        DEVICE=PRINTER.SYS LPT1:=(4201,yyy,1)
    

    To AUTOFBSS.BAT, add the following DOS commands for the 3270 emulator:

        NLSFUNC
        KEYB zz,yyy,KEYBOARD.SYS
        MODE CON: CP PREP=((yyy) EGA.CPI)
        CHCP 850   or   MODE CON CP SELECT=yyy
    

    To AUTOFBSS.BAT, add the following DOS commands for the 3287 printer emulator:

        NLSFUNC
        KEYB zz,yyy,KEYBOARD.SYS
        MODE LPT1: CP PREP=((yyy) 4201.CPI)
        CHCP 850   or   MODE CON CP SELECT=yyy
    

    where:

    xxx
    Is the country code.
    yyy
    Is the code page.
    zz
    Is the keyboard code.

    For more information about these commands, refer to the DOS Reference Guide.

    Microsoft Windows 3.1 or 3.11 considerations

    If Microsoft Windows 3.1 or 3.11 support was specified at customization time, the following files will be distributed to the workstation:

    EHCPREV.BAT
    WINSTART.BAT
    EHCDOSVM.BAT
    EHCAPLVM.BAT
    SYSTEM.ADD
    EHCDOSVM.PIF

    The EHCPREV.BAT procedure should be run before starting Windows 3.1 or 3.11.

    The first statement in the file must be:

      EHCWGMDI /L:xx
    

    where xx is an optional parameter to specify the maximum storage, in KB, required by Windows parameters and user data. The parameter value ranges from 4 to 56. The default is 4.

    If the following servers were specified at customization time, the corresponding loading statements will appear after the EHCWGMDI statement:

    For information on those loading statements, refer to Loading statements for LANDP for DOS servers.

    The WINSTART.BAT file contains the following statement:

      EHCWVDMI
    

    EHCWVDMI is accessed by the Windows 3.1/3.11 applications.

    The EHCDOSVM.BAT procedure should be run under Windows 3.1/3.11 in a virtual machine.

    The EHCDOSVM.BAT file contains the loading statements of the supervisor and the servers that are to reside on the workstation, except for those whose loading statement should be placed in the EHCPREV.BAT file.

    Ensure that any modification of this file does not cause a server to be loaded after the supervisor. For information on the loading statements, refer to Loading statements for LANDP for DOS servers.

    The EHCAPLVM.BAT procedure should be run under Windows 3.1/3.11 in the virtual machine where the LANDP application will be loaded. The default contents are:

      EHCWVDMI
      AUTOUSER
    

    The SYSTEM.ADD file should be added to the SYSTEM.INI Windows 3.1/3.11 setting file. The default contents are:

        [386Enh]
        DEVICE=EHCVMSD.386
    

    The EHCDOSVM.PIF file can be edited with the Windows 3.1/3.11 PIF editor. You can modify the contents according to the settings to be assigned to the virtual machines where LANDP or LANDP applications run.

    CONFIG.SYS contents

    You should compare the CONFIG.SYS file created by the customization program with the CONFIG.SYS file in your workstation, and make the necessary modifications to merge them into one.

    You should specify the paths for the new device drivers and other needed files.

    You should also take into account the following:

    The following is an example of a CONFIG.SYS file for a workstation that contains the SNA server with X.25 data link control, the shared-file server, and a 3270 emulator. The workstation is integrated in a LANDP workgroup that uses NetBIOS as transport protocol.

        BUFFERS=20
        FILES=40
        SHELL = \COMMAND.COM /E:256 /P
        REM              The environment parameter above might
        REM              need to be increased based on other
        REM              than LANDP for DOS program requirements.
        DEVICE=DXMAOMOD.SYS
        DEVICE=DXMCOMOD.SYS
        DEVICE=DXMTOMOD.SYS  ST=26  S=26  C=30
        DEVICE=X251.SYS
    

    Magnetic stripe reader/encoder server

    If you plan to load this server, the following statements are required in the CONFIG.SYS file.

    If the server supports a 4717 MSR/E:

        DEVICE=MSRE2DD.SYS /X
    

    If the server supports a 4777 MSR/E:

        DEVICE=IBM4777.SYS /X /Cp
    

    The p parameter value corresponds to the COM port where the 4777 MSR/E will be attached.

    If the server supports a 4778 MSR:

        DEVICE=IBM4777.SYS /X /Cp /M
    

    The p parameter value corresponds to the COM port where the 4778 PIN Pad MSR will be attached.

    If a 4778 device is mouse attached:

        DEVICE=MSRE2DD.SYS /M
    

    If a 4777 device is mouse attached:

        DEVICE=MSRE2DD.SYS
    

    PIN pad server

    If you plan to load this server, the following statements are required in the CONFIG.SYS file.

    If the server supports a 4718 PIN pad:

        DEVICE=PIN2DD.SYS /X
    

    If the server supports a 4778 PIN pad:

        DEVICE=IBM4778P.SYS /X /Cp
    

    The p parameter value corresponds to the COM port where the 4778 PIN Pad MSR will be attached. The second statement should be specified only if MSR capabilities will be used.

    If a 4778 device is mouse attached:

        DEVICE=PIN2DD.SYS
    

    TRDLC server

    If you plan to load this server, refer to Installation requirements for TRDLC server.

    X.25 DLC server for IBM PC X.25 communications adapter

    If you plan to load this server, the following statement is required in the CONFIG.SYS file:

        DEVICE=<drive> <path> xxxxxx.SYS
    

    where:

    drive
    Is the drive on which the device is located.

    path
    Is the directory on which the device is located.

    xxxxxx
    Is the name of the device driver. This can be:
    X25DD2
    X.25 Communications Adapter uses interrupt level 2.
    X251
    X.25 Communications Adapter uses interrupt level 3.
    X25DD4
    X.25 Communications Adapter uses interrupt level 4.

    Financial printer server

    If you plan to load this server, the following statement is required in the CONFIG.SYS file for each printer connected to an RS-232 port :

        DEVICE=<drive> <path> FPRTxxxx.SYS [/B:bbbb][/A:a] [/R:rrr] [/X] [/M]
    

    where:

    drive
    Is the drive on which the device is located.

    path
    Is the directory on which the device is located.

    FPRTxxxx.SYS
    Is the driver file name. For a list of file names, refer to Table 2.

    bbbb
    The desired baud rate (in bits per second). Permissible values are: 9600, 4800, 2400, 1200, 0600, 0300, 0150. The default value is 9600 bps.

    a
    The logical connector address of the printer. Permissible values are:
    1 - Asynchronous connector 1
    2 - Asynchronous connector 2
    3 - Asynchronous connector 3
    4 - Asynchronous connector 4

    The default value is Asynchronous connector 1.

    rrr
    The redirection assignment for parallel connectors 1, 2, and 3. The redirection of the connectors is as follows:
    1 - Connector 1 - 100
    2 - Connector 2 - 010
    3 - Connector 3 - 001

    All combinations 000 through 111 are valid. The default value is 000.

    /X
    This option suppresses error messages to the screen.

    /M
    To be used if REMS is used.

    The same device drivers as those for the 4722 printer are used if you plan to use the 9055 Model 2 or 9068-S01 printers.

    4748 printer server

    If you plan to load this server, the following statement is required in the CONFIG.SYS file for each 4748 printer connected to an RS-232 port:

        DEVICE=<drive> <path>FPRTxxxx.SYS [/B:bbbb] [/A:a] [/X]
    

    where:

    drive
    Is the drive on which the device is located.

    path
    Is the directory on which the device is located.

    FPRTxxxx.SYS
    Is the driver file name. For a list of file names, refer to Table 4.

    bbbb
    The desired baud rate (in bits per second). Permissible values are: 9600, 4800, 2400, 1200, 0600, 0300, 0150. The default value is 9600 bps.

    a
    The logical connector address of the printer. Permissible values are:
    1 - Asynchronous connector 1
    2 - Asynchronous connector 2

    The default value is Asynchronous connector 1.

    /X
    This option suppresses error messages to the screen.

    If you plan to use the 9055 Model 1 or 9068-D01 printer, you can use the same device driver as for the 4748 printer (but it will provide support only for 4748 emulation mode). If the extra features of these printers are to be used (for example, REMS), change the device driver name in your CONFIG.SYS file to:

        DEVICE=<drive> <path>FPRTSCPx.SYS [/B:bbbb] [/X]
    

    4733 teller assist unit

    If you plan to use a 4733 teller assist unit, you must specify the following statement in your CONFIG.SYS file:

        DEVICE=TCD386D.SYS
    

    PROTOCOL.INI contents

    If your workstation is using LAN Support Program device driver DXMJ0MOD.SYS, which requires LAN Support Program Version 1.38 or later, you need to update your PROTOCOL.INI file to include details that the LANDP configuration added to the CONFIG.SYS file. These include:

    For example, LANDP customization might have generated a CONFIG.SYS file that includes the lines:

      DEVICE=DXMC0MOD.SYS
      DEVICE=DXMT0MOD.SYS O=N ST=3 S=3 C=6
    

    If, for example, you are using the IBMTOK.DOS MAC driver, PROTOCOL.INI would look something like this:

      [DXMJ0MOD_NIF]
         Driver Name=NETBEUI$
         Bindings=...
         NCBS=6
         SESSIONS=3
         DATAGRAMPACKETS=6
      
    ·
    ·
    ·
    Note:
    DATAGRAMPACKETS should be set to at least double the number of sessions. The maximum value for DATAGRAMPACKETS is 140, so if you have more than 70 sessions, the value should be set to 140.

    AUTOFBSS.BAT and AUTOUSER.BAT contents

    Note:
    This section does not apply if you use Windows 3.1 or 3.11 support. If you do use Windows 3.1 or 3.11, refer to Microsoft Windows 3.1 or 3.11 considerations.

    The AUTOFBSS.BAT file contains the loading statements of the supervisor and the servers that are to reside on the workstation. The last program loaded is the supervisor.

    Ensure that any modification of this file does not cause a server to be loaded after the supervisor. Application loading statements should not be placed in the AUTOFBSS.BAT file but in the AUTOUSER.BAT file.

    If DOSKEY is used as well as LANDP, execute DOSKEY before AUTOFBSS to ensure that the settings are saved.

    The following is an example of a AUTOFBSS.BAT file for a workstation that contains the SNA server with X.25 data link control, the shared-file server, and a 3270 emulator. The workstation is integrated in a LANDP workgroup that uses NetBIOS as transport protocol.

        NEWCFG
        IF ERRORLEVEL 1  GOTO END
        VARDAT
        IF ERRORLEVEL 1  GOTO END
        LOADER SHFILE##.EXE /C:SFILE1 /B:12 /E /S:3 /L:2 /F:50
        IF ERRORLEVEL 1  GOTO END
        LOADER SNA##.EXE
        IF ERRORLEVEL 1  GOTO END
        XL.EXE
        IF ERRORLEVEL 1  GOTO END
        LOADER X25DLC.EXE
        IF ERRORLEVEL 1  GOTO END
        LOADER EMU3270.EXE /C:ATR/K:KBD/D:DIS/I:1
        IF ERRORLEVEL 1  GOTO END
        LOADER DDT.EXE
        IF ERRORLEVEL 1  GOTO END
        LOADER LAN.EXE/AB
        IF ERRORLEVEL 1  GOTO END
        LOADER SPV.EXE/AB /K:20
        IF ERRORLEVEL 1  GOTO END
        AUTOUSER
        :END
        FREE
    

    If the workstation is integrated in a LANDP workgroup that uses TCP/IP as transport protocol, EHCLIP.EXE should be specified instead of LAN.EXE.

    In order to get an information window about LANDP for DOS status, you should invoke the EHCCINFO utility program.

    You should modify the AUTOUSER.BAT file to meet the requirements of your applications. They can be started with AUTOUSER.BAT.

    Printer manager server

    If you plan to use DOS PRINT together with this server and either the 3287 printer emulator, or the financial printer server, or your own printer server, the following statement is required in the AUTOFBSS.BAT file:

      FBSSP <path>\PRINT<parameters>
    

    where FBSSP is the loading command. You should provide the path and parameters.

    Loading statements for LANDP for DOS servers

    Most loading statements explained in this section are automatically created by the customization program, using the parameters you provided. LOADER is used by LANDP for DOS to load the functional areas into workstation memory.

    For return codes during loading, refer to LANDP Problem Determination.

    After loading LANDP, the functional areas become an extension of DOS. Control is transferred to the servers when loading is completed. Each server performs initialization, then goes into a wait state. Invocation is subsequently done by the supervisor as needed.

    Some functional areas can be loaded into expanded memory, thus not occupying space in conventional memory. The loading command then is changed to LOADERE.

    Both loading commands, LOADER and LOADERE, provide two optional parameters, w:e and &:e. These parameters can be included in the loading statements of some user servers, as follows:

      LOADER (or LOADERE) [/w:e] [servername]
    

    where servername is the name of the server being loaded.

    The w:e parameter applies to user servers that do not call DOS functions at run-time, and therefore do not need specific internal storage for that purpose.

    If the parameter is specified, the LOADER(E) program uses less memory. If specified, but the server uses DOS functions, the results are unpredictable.

      LOADER (or LOADERE)  [/&:e] [servername]
    

    where servername is the name of the server being loaded.

    The &:e parameter applies to user servers that do not process connection functions ("&&") and disconnection functions ("**") corresponding to a specific process, and therefore do not need to be involved in the general process for that purpose. Both parameters, w:e and &:e, can be included in the same loading statement.

    If the &:e parameter is specified in the loading statement of the supervisor, the applications calling the Wait for Asynchronous Events (WM) supervisor function do not receive "&&" and "**" events.

    LANDP for DOS functional areas can be loaded into high memory. Add the LOADHIGH command to the loading statement, in front of LOADER or LOADERE:

      LOADHIGH LOADER (or LOADERE) [servername]
    

    where servername is the name of the server being loaded.

    The following commands can be used when you load the LANDP for DOS functional areas.

    ASCII-EBCDIC translation server

    LOADER EHCDBTR.EXE
    

    Compression server

    LOADER EHCCOMP.EXE
    

    Electronic journal server

    LOADER ELECJO##.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the electronic journal records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum of:

    Forwarding server

    LOADER FORWARD.EXE /O:vvvvvvvv.vvv [/T:wwww] [/S:xxxxxxxx.xxx] [/K:y] [/H:z]
    

    where:

    vvvvvvvv.vvv
    Is the name of the file corresponding to the ASCII-to-EBCDIC translation table. It must follow the operating system rules.

    wwww
    Is the number of time ticks after which the supervisor will dispatch the forwarding function. One time tick is roughly 0.05 seconds.

    Values can range from 1 to 6000. The default is 20 (about 1 second).

    xxxxxxxx.xxx
    Is the name of the file corresponding to the sign-on feature. It must follow the operating system rules.

    y
    Is the size, in KBs, of the buffer used to read the store-for-forwarding records. It can range from 1 to 4. The default is 1.

    The parameter value must be the value assigned in the loading statement of the store-for-forwarding server.

    z
    Specifies whether headers are included when sending host computer messages. The parameter value can be Y, to include headers, or N, not to include headers. The default is Y.

    LAN server

    LOADER LAN.EXE /pc-id [/N:n] [/B:bb] [/I:x] [/S:y]
    

    where:

    pc-id
    Is the one (or two) character alphanumeric identification of the workstation that was assigned during customization. The pc-id must be the same as the one for the supervisor.

    n
    Is the adapter number used by the workstation.

    The parameter value can be 0 or 1. The default is 0, or the value specified at workgroup level.

    bb
    Is the number of KB that should be reserved for the internal buffer to be shared with the NetBIOS manager layer in order to receive data from remote workstations.

    The parameter value can range from 1 to 56. The default is 4, or the value specified at workgroup level.

    If an incoming message size is bigger than the buffer size, performance degrades.

    x
    Is the time interval, in seconds, between attempts to establish the required NetBIOS sessions.

    The parameter value can be 0 or in the range 5 through 3000. The default is 20 seconds. If a value of 0 is specified, only one attempt is made to establish each session, at startup, or after a session has been lost.

    y
    Is the NetBIOS send timeout, in seconds.

    The parameter value can be 0 or in the range 10 through 127. The default is 10 seconds. A value of 0 implies no timeout.

    The LAN server is needed only when more than one workstation is present in a workgroup that uses NetBIOS as transport protocol. It is included during the process of creating diskettes for distribution.

    LANDP Internet Protocol

    LOADER EHCLIP.EXE /pc-id [/N:n] [/Y] [/R:r]  [/C[:ws-id]] [/P:p] [/J] [/D:d]
    

    where:

    pc-id
    Is the workstation ID that was specified during customization. The pc-id must be the same as that for the supervisor. This parameter must always be the first one.

    n
    Specifies the TCP/IP port number used by LANDP Internet Protocol.

    The parameter value can range from 1024 to 65535. The default is 52699.

    Y
    Specifies that no availability probe datagram will be sent, when a session has no normal traffic.

    r
    Specifies the storage, in bytes, to be allocated for the retransmission table.

    This table is used by LANDP Internet Protocol to save information about datagrams sent, in case they should be retransmitted.

    The parameter value ranges from 256 to 65000. The default value is calculated using the following formula:

    910 * ((N * 40) / (N + 34))
    

    where N is the number of related workstations.

    C
    Requests LANDP Internet Protocol communications trace. All sessions are traced, except when the ws-id parameter is specified. In this case, only the session with the workstation specified in that parameter is traced.

    p
    Specifies the number of trace pages to be displayed for LANDP Internet Protocol communications trace. Each trace page you add requires 836 bytes.

    The parameter value can range from 3 to 70. The default value is 3.

    J
    Specifies that no checking for related workstations with undefined LANDP Internet Protocol addresses will be carried out.

    d
    Specifies the maximum datagram length in bytes. The parameter value can be in the range 688 through 32711. The default is 1472.

    Local resource manager server

    LOADER EHCLRMGR.EXE
    

    Magnetic stripe reader/encoder server

    LOADER MSRE47##.EXE
    

    Native X.25 server

    LOADER X25NAT##.EXE
    

    Operator interface

    LOADER OPER.EXE
    

    PIN pad server

    LOADER PINP47##.EXE /M
    

    where /M indicates that 4778 magnetic stripe reader capabilities are to be used.

    Printer manager server

    LOADER PRTMGR.EXE
    

    The loader statement for the printer manager server will be included automatically during the process of creating diskettes for distribution if the 3287 printer emulator or the financial printer server is using the parallel port.

    Remote change management services

    LOADER RCMS.EXE /I:xxx /O:yyy [/T:ttt] [/A:mmm] [/L:n] [/P:q] [/C:x] [/R:r]
    

    where:

    xxx
    Is the file extension of the EBCDIC-to-ASCII translation table (EARCMS.xxx). In DBCS mode the parameter does not apply.

    yyy
    Is the file extension of the ASCII-to-EBCDIC translation table (AERCMS.yyy). In DBCS mode the parameter does not apply.

    ttt
    Is the number of timer ticks after which RCMS receives control. One timer tick is roughly 0.05 seconds. The default is 10. The value must be a decimal number in the range 1 to 999. For example, /T:1, /T:12, or /T:255.

    mmm
    Is the amount of memory reserved for COMMAND.COM (in KB). You can enter values in the range 48 to 256. If you do not enter a value for mmm, 47.5 KB is reserved. The default amount of memory reserved for COMMAND.COM is not sufficient for some versions of DOS. For example, PC-DOS 7.1 requires 53 KB.

    n
    Specifies the number of lines in the EHCRCMS.LOG file. The parameter value ranges from 100 to 10000. The default is 1000.

    Attention: If an EHCRCMS.LOG file with n1 lines exists already, and you choose a value for the L parameter that is different from n1, your old file will be destroyed and a new one created. If you want to keep the old file, rename it or copy it to somewhere else before running the LOADER program.

    q
    Specifies the translation mode. The parameter applies only to DBCS mode. The parameter value can be:
    S
    Standard ASCII-EBCDIC and EBCDIC-ASCII translation.
    P
    ASCII-EBCDIC translation with ASCII SI/SO characters changed to EBCDIC SI/SO characters, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to ASCII SI/SO characters.
    B
    Standard ASCII-EBCDIC translation, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to blanks.

    x
    Specifies the reception mode for CLISTs. The parameter value can be:
    B
    The CLIST is received as a binary file.
    E
    The CLIST is received as an EBCDIC file.

    The default is E.

    r
    Is the interval, in minutes, before retrying a connect to SNA if there is a communications problem. The value must be an integer in the range 0 (which is taken to mean 30 seconds) and 8 (8 minutes). The default value is 0.

    Searcher

    LOADER SFQUERY.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to read the electronic journal and store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The parameter value must be the highest of the values assigned in the loading statements of the electronic journal and store-for-forwarding servers.

    This program is required by the electronic journal and the store-for-forwarding servers.

    Shared DOS directory server

    LOADER SHRDIR.EXE /E:nn
    

    where:

    nn
    Is the maximum number of entries in the profile table (SHRDIR.PRO) that describe the relationship between the short name and the directories to be shared.

    In the client workstations that have IBM DOS 7.1 or higher installed, the customization program includes the following statement in the AUTOFBSS.BAT file:

    SHRDIRDD /K:mm
    

    where:

    mm
    Is the size of the request/reply data area used by the shared DOS directory server. The parameter value can range from 1 to 56. The default is 4.

    Shared-file server

    LOADER SHFILE##.EXE [/C:confname] [/B:nnn] [/E] [/S:xxx] [/L:y] [/F:zz]
    

    where:

    confname
    Specifies the name of the shared file server profile. If you omit this parameter, the system uses the name CONFIGUR.

    nnn
    Specifies the number of additional 1 KB index buffers to be allocated; that is, buffers over 15. More index buffers increase system throughput, but also reduce the amount of free storage available for the server workstation. A rule of thumb is that the number of buffers should be 10 per workstation using the shared file server simultaneously. A practical limit is approximately 100, depending on available storage size. The maximum value is 968.

    Another factor that must be considered is that the more buffers you have, the greater is the probability of losing index data when the shared file server is abnormally ended. Thus, if many index buffers are allocated, and the server workstation is switched off with a transaction still in process, or if no RF function has been called, an automatic index rebuild is issued the next time the server is loaded.

    /E
    Is an optional parameter to create a file for the statistics gathered during the session.

    xxx
    Specifies the total number of additional sessions in the whole workgroup that the server can manage. The maximum is 245.

    This number plus the number of workstations that receive services must not be higher than 245.

    y
    Specifies the log management type. The parameter value can be:
    0
    Dynamic and static log with a unique log file
    1
    Dynamic log with a unique log file
    2
    Dynamic and static log with two log files
    3
    Dynamic log with two log files

    The default is 0.

    zz
    Is the number of files open at a time.

    The parameter value can be in the range 10 to 245.

    Note:
    The shared-file server for DOS does not load if the log file has ever been used (on OS/2 or Windows) by the shared file server running in external log replicator (XLR) mode. To overcome this problem, issue the GENLOG command. (For further information see LANDP Servers and System Management.)

    SNA server

    LOADER SNA##.EXE /P:nn
    

    where:

    nn
    Is the number of trace pages to be displayed for the SNA server.

    The parameter value can range from 3 to 70. The default is 3.

    Store-for-forwarding server

    LOADER SFORFORW.EXE [/K:y]
    

    where:

    y
    Is the size, in KBs, of the buffer used to insert the store-for-forwarding records. It ranges from 1 to 4. The default is 1.

    The size of the buffer must be large enough to hold the maximum of:

    Supervisor

    LOADER SPV.EXE /pc-id [/S] [/D:yy] [/L:zz] /K:mmm
    

    where:

    pc-id
    Is the one (or two) character alphanumeric identification of the workstation that was assigned during customization. This parameter is required.

    yy
    Is the percentage of dispatching cycles where control is maintained by the application and pending LANDP tasks are not processed. That is, yy% of dispatching cycles come back to the application immediately, and (100-yy)% of the cycles perform LANDP processes before returning to the application. Therefore, yy can be any number from 0 to 99. The default is 0.

    zz
    Is the numeric value for the number of screen lines used to display the trace. Valid numbers are from 1 to 24. The default is 12.

    mmm
    Is the number of KB that should be reserved for the internal buffer pool to allocate incoming/outgoing requests from/to remote workstations, and requests from servers loaded into expanded memory to servers that are also loaded into expanded memory.

    The parameter value ranges from 7 to 512. It can be specified during customization through the POOLSIZE keyword in the LWSCONF vector.

    The default calculated by the customization program is [1.25 x N], where N is the number of workstations that receive services from the workstation you are defining, or provide services to it.

    The value is limited by the available memory. In addition, a low value might result in a poor performance. Thus, it is highly recommended to adjust this value accurately. On the panels of the trace tools you can obtain information about the percentage of buffer pool being used.

    If the size of the buffer pool is not big enough, the requester might receive status X'01004C46' (no free space in the buffer pool), X'01004C47' (no free space in the remote buffer pool), or X'01004C48' (timeout, due to the fact that a reply is not possible because no free space is available). On the Routines Trace panel of the trace tools you can see the number of times that a requester received these statuses.

    For workstations that provide or receive shared DOS directory services, the customization program recalculates the default accordingly.

    Increasing the value of mmm will resolve the error.

    If you are using the shared DOS directory, a situation might occur where there are insufficient Supervisor buffers. This might result in the following symptoms:

    If the /S parameter is omitted, the SI function returns a list of loaded processes. If the /S parameter is specified, the SI function returns loaded and configured processes.

    Synchronous data link control server

    LOADER SDLC.COM /C:x /T:nn /I:yy
    

    where:

    x
    Is a parameter used for SNA/SDLC switched communications. The parameter value can be:

    Y
    Data terminal ready (DTR) will be activated and deactivated by applications, using the Connect (CN) and Release (RL) functions of the SNA server.

    N
    DTR of the modem will be activated automatically when LANDP for DOS is ready.

    The default is N.

    nn
    Is the number of seconds of the line inactivity timer.

    The parameter value can range from 10 to 65. The default is 65.

    yy
    Is the interrupt request numbers to be used for the IBM Asynchronous/SDLC Communications Adapter.

    The parameter value can be:

    34
    Use interrupt requests 3 and 4
    54
    Use interrupt requests 5 and 4
    37
    Use interrupt requests 3 and 7
    57
    Use interrupt requests 5 and 7

    The default is 34.

    The parameter values must match the jumper settings on the adapter card.

    System manager server

    LOADER SMGR.EXE /D:x /O:yyyyyyyy
    

    where:

    x
    Is the drive where the FBSS#GDT backup is located. If the parameter is omitted, the backup is not performed.

    yyyyyyyy
    Is the NetView operator ID. The default is OPER1.

    System manager operator

    LOADER SMOP.EXE
    

    TCP/IP wide area communications server

    LOADER xxx.EXE [/S:nn] [/T]
    

    where:

    xxx
    Is either SNA## to emulate the SNA server or PPC to emulate the PPC server. EHCTCP.EXE has to be renamed to SNA##.EXE or PPC.EXE. It is not possible to emulate both SNA##.EXE and PPC.EXE on the same DOS workstation.

    nn
    Is the maximum number of TCP/IP wide area communications server sessions that can be in use at any time. The default and minimum values are 5. The maximum value is 2048, but available memory forces a lower maximum.

    /T
    Is an optional parameter to turn on internal tracing for problem determination.

    Token-ring data link control server

    LOADER TRDLC.EXE
    

    Trace tools

    LOADER DDT.EXE /I:x /R:y /P:nn
    

    where:

    x
    Is a parameter with two possible values:

    I
    Specifies that an internal function trace is included. The information refers to server-to-server requests.

    E
    Specifies that an internal function trace is excluded.

    The default is I. For application debugging purposes, choose the E parameter value.

    y
    Is a parameter with two possible values:

    I
    Remote requests trace is included. The information refers to incoming requests from remote workstations.

    E
    Remote requests trace is excluded.

    The default is I. For application debugging purposes, choose the E parameter value.

    nn
    Is the number of trace pages to be displayed for the supervisor functions. Each trace page you add requires 1216 bytes.

    The parameter value can range from 3 to 40. The default is 3.

    Note:
    If you use the LOADERE loading command, the parameter value ranges from 3 to 30.

    X.25 DLC server for IBM PC X.25 communications adapter

    LOADER X25DLC.EXE
    

    X.25 DLC server for IBM X.25 interface co-processor/2 adapter

    LOADER X25DLC2.EXE [/T]
    

    If the X25DLC2 server is used, it is renamed to X25DLC.EXE and loaded accordingly.

    If option /T is added to the loading statement, the X.25 trace will be started from the beginning.

    Note:
    The two X.25 servers (one used with the IBM PC X.25 Communications Adapter and the other used with the IBM X.25 Interface Co-Processor Adapter/2) use the same LOADER statement. However, the /T parameter is valid only for the IBM X.25 Interface Co-Processor Adapter/2.

    3270 emulator

    LOADER EMU3270.EXE /C:atr /K:kbd /D:dis /I:n [/H:hh] [/W:www] [/B:y] [/S:xxxxxxxx]
                  [/Z:nnnn] [/P:a] [/L:l] [/T:tt]
    

    where:

    atr
    Is the name of the selected display color attributes table.

    kbd
    Is the name of the selected keyboard ASCII-to-EBCDIC translation table.

    dis
    Is the name of the selected display EBCDIC-to-ASCII translation table.

    n
    Is the emulator identification number.

    hh
    Specifies the alternate screen height (number of rows) of the 3270 display to be emulated. (The height specified should not include the operator information area line at the bottom of the emulator screen.) nn must be in the range 24 through 49. For 132-column screens, the maximum height might be limited by the capabilities of the PC video display adapter installed in your system.

    Use this parameter, in conjunction with /W, to make the emulated alternate screen look like one of the following 3270 models:

                       Alternate             Alternate
    3270 model         screen height         screen width
        2                   24                    80
        3                   32                    80
        4                   43                    80
        5                   27                   132
    

    If this parameter is omitted, the default is 24.

    www
    Specifies the alternate screen width (number of columns) of the 3270 display to be emulated. nnn must be either 80 or 132. Some PC video display adapters do not support 132-column mode.

    If this parameter is omitted, the default is 80.

    y
    Indicates whether blinking is supported. Specify Y for yes or N for no.

    If this parameter is omitted, the default is N.

    xxxxxxxx
    Specifies the long name of the 3270 emulator session (sometimes known as the "host session ID"), which is displayed in the operator information area on the screen. You can specify up to eight characters (with no imbedded blanks).

    If this parameter is omitted, the default is a name of eight blanks.

    nnnn
    Specifies the size (in bytes) of the buffer used to communicate with the host. nnnn can be any value in the range 2048 through 4096. Specifying a small buffer size minimizes memory requirements; using a large buffer can reduce the number of transmissions needed to send or receive a large data stream.

    The parameter value specified must match the RU size detailed in the bind session.

    If this parameter is omitted, the default is 2048.

    a
    Indicates whether the 3270 emulator should handle the Print Screen key. Specify N for no or Y for yes.

    If this parameter is omitted, the default is Y.

    l
    Indicates whether the SNA session is connected at emulator load time rather than at 'hot key' time. Specify N for no or Y for yes. The default is N.

    tt
    Specifies the minimum time in seconds between checks on 'print screen' key presses. The default is 3.

    3287 printer emulator

    LOADER EMU3287.EXE /x /E:prt [/T:nn] /P:HP [/N:n]
    

    where:

    x
    Can be S or M. Use S for single and M for multiple LU_1 support.
    Note:
    This parameter and its values are no longer supported, though they will be accepted for compatibility purposes with earlier versions of LANDP. If specified, they will be ignored.

    prt
    Is the name of the selected EBCDIC-to-ASCII translation table.

    nn
    Is the frequency of polling.

    The parameter value ranges from 1 to 60. The default is 15.

    /P:HP
    Indicates that the 3287 printer emulator will use either an IBM 4019 Printer or an IBM 4029 Printer for output.

    /N:n

    Specifies the range of logical printer numbers that can be used. The parameter value can be in the range 1 through 3. Specify:

    If the parameter is not specified, the emulator uses the number of parallel printer ports physically installed on the workstation.

    Financial printer server

    LOADER PR47X2##.EXE [/K:n]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value can range from 1 to 4. The default is 1.

    4748 printer server

    LOADER PR4748##.EXE [/K:n] [/H] [/N] [/A:xxxx]
    

    where:

    n
    Is the maximum number of KB to be printed at a time.

    The parameter is optional. The parameter value can range from 1 to 4. The default is 1.

    /H
    Shows that ALERT support is required.

    /N
    Shows that code conversion is not required.

    xxxx
    Is the fully qualified filename of the User-Defined Character (UDC) file.

    Unloading LANDP for DOS

    The FREE.EXE utility is provided to unload LANDP for DOS. You can also unload LANDP for DOS by issuing a supervisor function call from an application program. For more information on supervisor function calls, see LANDP Programming Reference. The FREE.EXE, is called as follows:

    d:\path\FREE
    

    where:

    d:
    Is the drive where the utility is located.

    path
    Is the path where the utility is located.

    Notes:

    1. If you use the X.25 Co-processor, you must unload the support program and the interrupt handler using the X.25 Co-processor support program functions.

    2. If you use TCP/IP internal communications, you must unload LANDP for DOS before stopping TCP/IP.

    Unloading LANDP for DOS in Microsoft Windows 3.1 or 3.11

    To unload LANDP for DOS, the FREE program must be run from the application VDM after EHCWVDMI. The FREE program unloads only the LANDP modules loaded after Microsoft Windows 3.1 or 3.11.

    To unload EHCWGMDI and the servers that were loaded before Windows 3.1/3.11, you must exit Microsoft Windows and then enter:

    FREE /W:1
    

    Using expanded memory

    The maximum amount of conventional memory (640 KB) is sometimes not enough for large programs or groups of programs. Lotus Development Corporation, Intel Corporation, and Microsoft Corporation created the Lotus/Intel/Microsoft (LIM) Expanded Memory Specification to enable programs to be loaded into expanded memory.

    The LIM Expanded Memory Specification defines the software interface between the Expanded Memory Manager (EMM), a device driver that controls and manages expanded memory, and programs that use expanded memory.

    To use the LIM Expanded Memory Specification for loading servers into expanded memory, a special loader program called LOADERE is included in the LANDP for DOS distribution package.

    To load a server into expanded memory, you have to select expanded memory for the server during customization. The customization program places the correct statements in the CONFIG.SYS and AUTOFBSS.BAT files, depending on the version of DOS chosen, and the LOADERE program loads the servers into expanded memory. The LOADERE program itself is always loaded in conventional memory.

    The following LANDP for DOS functional areas can be loaded in expanded memory. The user servers that conform to the rules listed in Rules for user servers in expanded memory can also be loaded in expanded memory. Note that the corresponding definitions are provided during customization through the DEFSERV vectors.

    ASCII-EBCDIC translation server EHCDBTR.EXE
    3270 emulator EMU3270.EXE
    3287 printer emulator EMU3287.EXE
    PIN pad server PINP47##.EXE
    Electronic Journal ELECJO##.EXE
    Store-for-Forwarding SFORFORW.EXE
    Searcher SFQUERY.EXE
    Forwarding FORWARD.EXE
    MSR/E server MSRE47##.EXE
    Financial printer server PR47X2##.EXE
    4748 printer server PR4748##.EXE
    Trace DDT.EXE
    SNA server SNA##.EXE
    Shared file server SHFILE##.EXE
    X.25 Co-Processor X25DLC.EXE
    Operator interface OPER.EXE
    System manager operator SMOP.EXE
    System manager SMGR.EXE
    Local resource manager server EHCLRMGR.EXE
    Remote Change Management Services RCMS.EXE
    LANDP Internet Protocol EHCLIP.EXE

    Notes:

    1. If IBM PC 3270 Emulation LAN Management Program is installed, the system manager server cannot be loaded into expanded memory.

    2. If you are using PC code page 950 (Taiwan) or host code page 1388 (People's Republic of China), the ASCII-EBCDIC translation server (EHCDBTR.EXE) cannot be loaded into expanded memory.

    The following PC/Integrator software can also be loaded into expanded memory:

    Banking interactive workstation program BIWP.EXE
    Banking printer program BPP.EXE

    Software requirements

    Depending on the DOS version selected during customization, your CONFIG.SYS file is updated differently.

    If you select DOS, the following statements are added to your CONFIG.SYS file:

         DEVICE=HIMEM.SYS
         DEVICE=EMM386.EXE [parameters]
    

    The second statement is valid only for personal computer systems with a processor higher than 80286. If your systems have processors lower than 80386, you must change your CONFIG.SYS file and use the XMA2EMS.SYS device driver or another specific device driver related to your memory adapter.

    Note that the FRAME value must range from C000 to E000, in increments of 400h.

    For more information, refer to the DOS library.

    LOADERE checks for the largest frame that is available consisting of contiguous pages.

    Important:
    Memory problems might occur due to incorrect memory allocations. Make sure the values specified in your CONFIG.SYS file are not overlapping with addresses used by the adapters installed. You can verify or change the memory values either in the CONFIG.SYS file or in the workstation configuration diskette.

    Following is an example of a configuration for a PS/2 Model 70 (80386) with Token-Ring (16Mb (bits) per second), X.25 Co-Processor, and DOS installed. The italicized lines show a possible memory address distribution:

     Slot 1 - Token Ring Network 16/4 Adapter/A
             Primary or Alternate Adapter........[Primary  ]
             Adapter Data Rate...................[16 Mps]
        ROM Address Range...................[DE000 - DFFFF]
       RAM Size and Address Range..........[16 KB / DA000 - DDFFF]
             Interrupt Level.....................[Interrupt 2]
     
    

    Slot 2 - IBM Realtime Interface Co-Processor Multiport/2
             Physical Card number...........[Physical Card 0; 02A0H - 02A7H]
        Shared Storage Window Location
           and Size.......................[D8000 - D9FFF (8 KB Window)]
             Interrupt Level.....................[Interrupt Level]
             Port 0 Transmit Clock Source...[DCE Sourced Clocking]
             Port 0 Receive Clock Source....[DCE Sourced Remote Clocking]
             Port 1 Transmit Clock Source...[DCE Sourced Clocking]
             Port 1 Receive Clock Source....[DCE Sourced Remote Clocking]
     
    

    Possible CONFIG.SYS entries could be:

              BUFFERS=20
             FILES=40
             DOS=HIGH,UMB
             DEVICE=HIMEM.SYS
        DEVICE=EMM386.EXE RAM FRAME=C000 /X=D800-DFFF
             DEVICEHIGH=DXMAOMOD.SYS
             DEVICEHIGH=DXMCOMOD.SYS
             DEVICEHIGH=DXMTOMOD.SYS  ST=26  S=26  c=30
     
    

    Rules for user servers in expanded memory

    LIM EMS involves some restrictions related to loading servers in expanded memory. Besides, user servers to be loaded in expanded memory must conform to the following rules:

    1. LOADERE uses the largest contiguous frame found for the EMM LIM. The servers that can be loaded must fit within this frame. Depending on the fragmentation of the frames, some servers that could be loaded on some configurations of the EMM LIM will fail in loading on other configurations.
    2. The maximum contiguous frame possible is 64 KB. Any servers above that size, including any additional memory allocated at load time by using the SETBLOCK function under DOS INT 21H, are not loaded by LOADERE.
    3. If the server must expand itself (allocate more memory), it must do it at load time using the DOS Allocate Memory Block or the DOS Set Block function calls.
    4. The memory allocated through the DOS INT 21H Allocate Memory Block function is not in expanded memory. This memory is provided by DOS from its conventional memory (640 KB).
    5. LOADERE keeps track of the interrupts that the server is chaining into. To do this, servers must chain into an interrupt vector at IN time, using the DOS INT 21H SET VECTOR function. A maximum of eight interrupt vectors can be set.
    6. Servers that catch hardware interrupts, or software interrupts inside hardware interrupts, cannot be loaded with LOADERE.

    Using high memory

    To use high memory (between 640K and 1MB), Upper Memory Block (UMB) support is required. Set the CONFIG.SYS file to enable UMB support, following the standard DOS rules.

    Because IBM TCP/IP uses UMB support, it is recommended not to load LANDP for DOS functional areas into high memory in IBM TCP/IP environments.


    Installing run-time files

    When you install the run-time files on a DOS workstation, take the following into account:

    The LANDP family provides a utility program to check the path where the run-time files are located. See Installing and validating system files for more information about this program.

    For other utility programs also provided to be used at run time, refer to Run-time utility programs.


    Utilities and Performance Tuning

    This part describes some utilities that you can use when installing and customizing LANDP. It also describes how to tune some of your LANDP servers to obtain better performance.

    It contains the following chapters:

    Run-time utility programs "Run-time utility programs"
    Migrating and generating customization data "Migrating and generating customization data"
    Listing customization data "Listing customization data"
    Performance tuning "Performance tuning"
    System maintenance--VERSION "System maintenance--VERSION"
    Applying program fixes--APPLYFIX "Applying program fixes--APPLYFIX"
    Graphical Customization Editor "Graphical Customization Editor"

    Run-time utility programs




    ehcodwl

    This chapter explains some utility programs provided with LANDP to be used at run-time. Those programs help you to:

    • Update communication variable data
    • Update workgroup variable parameters
    • Verify configuration and system files

     

     


    Communication variable data




    ehc_x000

    Often organizations using the LANDP family have numerous production sites similarly equipped and configured. Because of this, there are usually several sets of almost identical customization files. The only differences are the definitions for the communication parameters that need to be unique; for example, token-ring adapter addresses, physical unit addresses for multi-dropped SDLC lines, and so on.

    To change the communication definitions, LANDP for DOS supplies a facility so that you do not have to go through the entire customization process. This facility is provided by the VARDAT.EXE program, which updates the communication configuration records using the data stored on the fixed-format VARDAT.CFG file.

    To create and distribute variable data, create the VARDAT.CFG file. You can create the file in the customization workstation or, to avoid distribution, in a workstation in a workgroup. Note that, while communication definitions are being changed, user intervention is required.

    You can also create the VARDAT.CFG file in a host computer, and implement an application to create the communication variable data for each workstation in a workgroup.

    If the VARDAT.EXE program does not find a file named VARDAT.CFG, it assumes that there is no variable data for the workgroup configuration.

    Variable data record format

    The characteristics of the file are as follows:

    The records must have the formats shown in Table Table 6. Create only the records that apply to the communication devices affected by the update. If the record contains optional fields, include only those that contain changed information.

    Table 6. Variable data record formats for VARDAT utility

    Field Description Length (Bytes) Form Type Value Note
    DCA Variable Data Record:
    Service Identification 8 C R "DCADLC "
    Number of Buffers 4 N R "nnnn" 1
    Filler 48 C R " "
    SDLC Variable Data Record:
    Service Identification 8 C R "SDLC "
    Number of Buffers 4 N O "nnnn" 1
    Physical Unit Address 2 X O "xx" 2
    Identification Number 5 X O "xxxxx" 2
    Filler 41 C R " "
    Token-Ring Variable Data Record:
    Service Identification 8 C R "TRDLC "
    Number of Buffers 4 N O "nnnn" 1
    PC Local Admin Address 8 X O "xxxxxxxx" 1,7
    Host Local Admin Address 8 X O "xxxxxxxx" 1
    Identification Number 5 X O "xxxxx" 2
    Filler 27 C R " "
    X.25 Variable Data Record: Network User Address 3
    Service Identification 8 C R "X25DLCNA"
    Number of Buffers 4 N O "nnnn" 1
    Network User Address 15 N O "n(15)" 1
    Included in Packet Call 1 N O "n" 6
    Filler 32 C R " "
    X.25 Variable Data Record: Permanent Circuits 4
    Service Identification 8 C R "X25DLCSA"
    Connection Type 1 N R "P"
    No. of The Perm Circuit 4 N R "nnnn" 1
    Filler 30 C R " "
    Identification Number 5 X R "xxxxx" 2
    Filler 12 C R " "
    X.25 Variable Data Record: Switched Circuits 5
    Service Identification 8 C R "X25DLCSA"
    Connection Type 1 N R "I","O","B"
    Filler 4 C R " "
    Old Subscriber Address 15 N* R "n"(15) 1
    New Subscriber Address 15 N* O "n"(15) 1
    Identification Number 5 X O "xxxxx" 2
    Filler 12 C R " "

    Definitions for Form column (field format):

    Definitions for Type column:

    The Value of the fields must adhere to the following rules, depending on the DLC. The field format is validated according to these rules.

    Notes:

    1. These fields are in numeric ASCII format. LANDP programs convert them to the proper internal format at loading time.

    2. These fields are the ASCII image of a hexadecimal field. LANDP programs convert all bytes from 0 to F.

    3. You can have only one network user address. This is identified by the header, X25DLCNA.

    4. You can have as many permanent circuits as necessary. These are identified by the header X25DLCSA and connection type P. The number of permanent circuits in the record must exist in the model configuration file. The only part of this record that is considered variable data is the identification number.

    5. You can have as many switched circuits as necessary. These are identified by the header X25DLCSA and connection types I (incoming), O (outgoing), or B (both ways).

      The old subscriber address in the record must exist in the model configuration file and be unique, as only one physical unit is allowed per subscriber address for incoming circuits and for outgoing circuits. After updating, all the subscriber addresses of each type must be different. The only part of this record that is considered variable data is the new subscriber address and the identification number.

    6. This field can be updated only by manually editing the VARDAT.CFG file. Valid input for the field is:
      0
      Telephone number not included in packet call
      1
      Only telephone number included in packet call
      2
      Country code, subcode, and telephone number included in packet call

    7. You must change the following statement in your CONFIG.SYS file:
             DEVICE=DXMC0MOD.SYS address
      

      where address is the PC local administration address.

    Updating communication configuration records

    The program VARDAT.EXE is copied by the customization utility program onto the operational diskettes for the gateway workstations in the branches and loaded before any server. VARDAT.EXE searches for a file called VARDAT.CFG, which is the file that contains the communication variable data. VARDAT.EXE performs the following steps:

    1. Verifies whether a VARDAT.CFG file exists in the directory. If the file does not exist, the program ends normally.
    2. Validates file and record consistency.

      If errors are found, the program generates a return code. See LANDP Problem Determination.

      If no errors are found, the program updates the communication configuration files and deletes the variable communication data file VARDAT.CFG.


    Workgroup variable parameters




    ehcodwl

    The workgroup variable run-time parameters program (VARPARM.EXE) enables you to change the following at run-time:
    • The workgroup ID used by the system manager server.

      During customization, for each workgroup you specify the workgroup name in the NAME keyword of the corresponding LANCONF vector. The workgroup name becomes the default workgroup ID.

    • The workgroup suffix used when establishing LANDP sessions.

      If you select suffix usage through the SUFFIX keyword in the LANCONF vector, the workgroup name becomes the default workgroup suffix.

    • The 4721 printer ID used in the workgroup.

      During customization, for each 4721 printer you specify the 4721 printer ID in the corresponding PAR&SP21 keyword (parameter 2) of the LWSCONF vector.

    In the run-time environment, when AUTOFBSS is running, the program VARPARM.EXE is loaded. The program searches for the VARPARM.SPC file, validates it, and changes the workgroup ID, the workgroup suffix, or the 4721 printer ID, according to the specifications in that file.

    You can create the VARPARM.SPC file using any text editor. The file has the following format:

      LANCONFG NAME = newwgid,
               SUFFIX = newsuffix,
               ID4721 = new4721id
    

    where:

    newwgid
    Is the new workgroup ID to be used by the system manager server.
    newsuffix
    Is the new workgroup suffix to be used when establishing LANDP sessions.
    new4721id
    Is the new 4721 printer ID to be used in the workgroup.
    Note:
    Position 1 must be a blank, and the statement must start in position 2 or greater.

    The VARPARM.SPC file is renamed to VARPARM.OLD at the end of the process, so that it is not processed each time you run AUTOFBSS.

    If the VARPARM.SPC file is not available, the VARPARM.EXE program ends with no error and no change is made. If errors are found in the VARPARM.SPC file, the VARPARM.EXE program generates a return code. See LANDP Problem Determination.

    On Windows, a native Windows 32-bit version, VARPARMW.EXE, provides equivalent function.

    The 16-bit version, VARPARM.EXE, can be run under DOS in a VDM.


    Verification programs




    ehcodwl

    This section describes the utility programs provided to check record formats, profiles and parameters, and installation paths.

    Installing updated configuration files

    Changes in the record definitions or in the electronic journal, store-for-forwarding, forwarding, or shared file server profiles can cause unpredictable errors at run-time. Make sure that the values specified in the new profiles are compatible with the existing shared files.

    To prevent this, the customization program creates all the configuration files related to these definitions with a file name extension that is different from the one used at run-time:

    Server profiles From Customization At Run-Time
    Shared file profile .DBN
    .PCN
    .DBD
    .PCB
    Electronic journal profile EJOU.PRN EJOU.PRO
    Store-for-forwarding profile STOR.PRN STOR.PRO
    Forwarding profile FORW.PRN FORW.PRO

    In the run-time environment, when AUTOFBSS is running, the program NEWCFG.EXE is loaded. If any of the configuration files created by a new customization are found, the program NEWCFG.EXE checks to see if the same configuration file also exists with the different run-time name.

    Installing and validating system files

    The following is a list of files that must be in the paths specified during the software building process.

    The installation and validation utility program EHCVAL.EXE checks the customized paths in the FBSSPATH.DAT file against the servers being loaded. EHCVAL validates whether the path exists, and if it does not, enables the creation of the path. The program also validates the existence of all system files needed, and copies or updates all files required by the servers to be in the path. The copied files are erased from the original directory. In the run-time environment, when AUTOFBSS is running, the program EHCVAL.EXE is loaded.

    Error messages, information messages, and prompts that require a response may be displayed. The messages are contained in the EHC.MSG file, or in the EHCMSG.DLL file for LANDP for Windows; see the LANDP Problem Determination book.


    Migrating and generating customization data

    This chapter contains instructions for:

    You can migrate customization data provided for:

    Customization data provided for PC/Integrator, and PC Integrator/2 can also be migrated.


    Selecting workgroup configurations

    This section applies when you want to process more than one workgroup configuration at the same time.

    The LANLIMIT.SPC file is located in the EHCCUS directory. You can edit the LANLIMIT.SPC file using any text editor, and specify the workgroup configurations to be processed.

    Note that if langroup is omitted, EHCCUS is assumed.

    You cannot use both INCLUDE and OMIT statements at the same time. Comments must start with /* and end with */.

    The LANLIMIT.SPC file provided with the customization program has the following contents, and specifies that all the workgroup configurations will be processed.

        INCLUDE = *
    

    You can modify the LANLIMIT.SPC file to meet your requirements. Three examples follow.

    Example 1:

    Only the workgroup configurations located in the GROUP2 directory, and the workgroup configuration named CONF47 and located in the GROUP4 directory, will be processed.

     /* LANLIMIT.SPC Example 1*/
        INCLUDE = GROUP2\*
        INCLUDE = GROUP4\CONF47
    

    Example 2:

    All the workgroup configurations, except for those located in the GROUP6 directory, will be processed.

       /* LANLIMIT.SPC Example 2 */
        OMIT = GROUP6\*
    

    Example 3:

    Only the workgroup configurations located in the GROUP8 directory, and the workgroup configuration named CONF13 and located in the EHCCUS director, will be processed.

     /* LANLIMIT.SPC Example 3*/
        INCLUDE = GROUP8\*
        INCLUDE = \CONF13
    

    Return codes

    The return codes generated by both the migration and the generation procedures are classified into four types. The following list shows the types of return codes, starting with the least severe. An identifier for each type appears in parentheses.

    1. Informative (I) return code: some input may be missing or incorrectly specified.
    2. Attention or Warning (W) return code: some secondary functions may not work properly at the production sites.
    3. Error (E) return code: some LANDP functional areas will not work properly.
    4. Severe (S) return code: the execution will be ended.

    The identifier of the type of return code is displayed as the last character of the return code. For example, the following is displayed on the screen:

    00039W   This is an attention or warning return code. It ends with a 'W'.
    

    When running the migration or the generation procedure, you can specify the highest severity allowed.


    Migrating

    This section explains how to perform the migration step. It shows the data used by the migration procedure, and how to start that procedure.

    The migration procedure reads data from the directories that contain FBSS customization data. Then, using that information, the procedure generates data in the internal repository.

    Source data for migration

    The migration procedure uses the customization information that the FBSS customization program generated in the directories in the following list. They are located either in the root directory or in a first level subdirectory. The list also shows the contents of the directories.

    Directory
    Contents
     
     
    FBSS
    FBSS programs
    FBSSCUS
    Customization results
    DIFFERENT
    Customization results.

    Note that DIFFERENT stands for the name of any directory you created during customization to locate your workgroup configurations.

    The directories containing the information for each workgroup configuration are located under the FBSSCUS and DIFFERENT directories. In turn, the directories containing information for each workstation are located under the workgroup configuration directories.

    If you used the automatic building option of the FBSS customization program, the migration procedure uses the automatic building file created during the building process.

    If some customization data cannot be obtained from existing FBSS customization data, or if the automatic building file does not exist, the migration procedure provides defaults, when possible, or generates ? symbols. When ? symbols are generated, the migration procedure ends with a non-zero return code.

    When it is displayed on the screen, you should:

    1. Generate the LANCONF.SPC files corresponding to the workgroup configuration processed by the migration procedure, using the generation procedure.
    2. Edit those files, replacing the ? symbols by the appropriate information.

    When you have finished updating the LANCONF.SPC files, run the validation procedure.

    To convert an FBSS/2 workstation configuration to a LANDP for OS/2 workstation configuration, that is to migrate to a workstation running IBM OS/2 Warp V4.0, or higher, you have to:

    1. Migrate the FBSS customization data corresponding to that FBSS/2 workstation.
    2. Generate the LANCONF.SPC file containing the migrated data.
    3. Edit that file, updating the type of the workstation to IBM OS/2 Warp V4, or higher.

    When you have finished updating the LANCONF.SPC file, run the validation procedure.

    To convert all the FBSS/2 workstation configurations to LANDP for OS/2 workstation configurations, the migration procedure provides a parameter to specify it.

    Starting the migration procedure--MIGRATE

    You can display online information about the MIGRATE procedure. From the EHCCUS directory, enter:

      MIGRATE ?
    

    To start the migration procedure, from the EHCCUS directory, enter:

      MIGRATE [parm1] [parm2] [parm3] [parm4] [parm5] [parm6]
    

    where:

    parm1
    Is an optional parameter to specify the type of data to be processed. The parameter value can be:
    COMMON
    To process common data, such as defaults, records, profiles, and tables.
    LAN
    To process workgroup configuration data.

    If you specify LAN, but there is no common data in the internal repository, COMMON is also assumed. If the parameter is omitted, and there is no common data in the internal repository, both common and workgroup data are processed.

    parm2
    Is an optional parameter to specify the workgroup configuration to be processed. It applies when you process only one workgroup configuration.

    If the parameter is used, only the workgroup configuration specified will be processed, no matter the LANLIMIT.SPC file contents.

    The parameter format is:

      lanpath\lanname
    

    If lanpath is omitted, FBSSCUS is assumed as the directory where the source workgroup configuration data is located. The migrated workgroup configuration data is located in the current path, that is, in the EHCCUS directory.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in execution ending.

    2
    To admit informative and attention return codes. Higher severity results in execution ending.

    3
    To admit informative, attention, and error return codes. Higher severity results in execution ending.

    The default is 1. For further information, refer to Return codes.

    parm4
    Is an optional parameter to specify the path of the directory where the FBSS customization data is located. The parameter format is:
      d:\dirname\
    

    where d is the drive identifier and dirname is the name of the directory. The default is the current first level subdirectory.

    parm5
    Is an optional parameter to specify that all workstations running FBSS/2 are migrated to workstations running LANDP for OS/2. If the parameter is omitted, after migration, they remain FBSS/2 workstations.

    The parameter value must be NEWOS.

    parm6
    Is an optional parameter to specify that all workstations running FBSS (DOS) are migrated to workstations running LANDP for DOS. If the parameter is omitted, after migration, they remain FBSS (DOS) workstations.

    The parameter value must be NEWDOS.

    The parameters can be specified in any order. You will get the CUSPARM.LST file in the EHCCUS subdirectory, containing pointers to any problems that arise.

    To avoid long processing, it is strongly recommended to run the migration procedure specifying first the COMMON parameter value. Then, run the procedure specifying the LAN parameter value.

    In addition, when processing workgroup configuration data, you can select the workgroup configurations affected by the process. See Selecting workgroup configurations.


    Generating data

    This section explains how to perform the generation step. It shows how to start the generation procedure, and the data generated by that procedure.

    The generation procedure reads data in the internal repository, created either by the migration procedure or by the validation procedure, and generates vectors in the .SPC files.

    If an .SPC file with the same name and in the same path already exists, the procedure creates a backup of the existing .SPC file, with the same filename and extension BAK. If a .BAK file corresponding to the .SPC file already exists, the procedure erases the existing .BAK file.

    If an .SPC file is lost, you can recover it running the generation procedure and using the current data in the internal repository.

    Starting the generation procedure--GENSPEC

    You can display online information about the GENSPEC procedure. From the EHCCUS directory, enter:

      GENSPEC ?
    

    To start the generation procedure, from the EHCCUS directory, enter:

      GENSPEC [parm1] [parm2] [parm3] [parm4]
    

    where:

    parm1
    Is an optional parameter to specify the type of data to be processed. The parameter value can be:
    COMMON
    To process common data, such as defaults, records, profiles, and tables.
    LAN
    To process workgroup configuration data.
    MODELS
    To process model configuration data.

    The default is LAN.

    parm2
    Is an optional parameter to specify the workgroup configuration to be processed. It applies when you process only one workgroup configuration.

    If the parameter is used, only the workgroup configuration specified will be processed, no matter the LANLIMIT.SPC file contents.

    The parameter format is:

      langroup\lanname
    

    If langroup is omitted, EHCCUS is assumed.

    parm3
    Is an optional parameter to specify the highest severity of return codes allowed. The parameter value can be:

    1
    To admit only informative return codes. Higher severity results in ending execution.

    2
    To admit informative and attention return codes. Higher severity results in ending execution.

    3
    To admit informative, attention, and error return codes. Higher severity results in ending execution.

    The default is 1. For further information, refer to Return codes.

    parm4
    Is an optional parameter with only one possible value: DELETE.

    If the parameter is specified, the customization data processed is automatically removed from the internal repository. Thus, after running the generation program, the data is stored only on the .SPC files.

    If the parameter is not specified, the customization data processed also remains stored in the internal repository.

    The parameters can be specified in any order. Return codes generated by the generation procedure are displayed on the screen.

    To avoid long processing, it is strongly recommended to run the validation procedure specifying first the COMMON parameter value. Then, if it applies, run the procedure specifying the MODELS parameter value. Finally, run the validation procedure again specifying the LAN parameter value.

    In addition, when processing workgroup configuration data, you can select the workgroup configurations affected by the process. See Selecting workgroup configurations.

    Note:
    The GENSPEC utility runs in OS/2 or Windows only, although the data that is being generated can apply to all platforms.

    Data in vector format

    After generation of .SPC files, the customization data is stored in vector format in those files. The common data is stored in the COMMON.SPC file, in the EHCCUS directory.

    The workgroup configuration data is stored in the LANCONF.SPC files, in the yyyyyyyy\xxxxxxxx directories, where:

    yyyyyyyy
    Is the name of a group of workgroup configurations. The customization program default is EHCCUS.

    xxxxxxxx
    Is the name of a workgroup configuration.

    The vectors in a LANCONF.SPC file are:

    LANCONF
    LWSCONF

    The model configuration data is stored in the MODELS.SPC file, in the EHCCUS directory. The vectors in that file are:

    LANMODEL
    LWSCONF
    SVRMODEL
    WSMODEL

    Because the model concept has been introduced with the LANDP customization, no data exists in the FBSS customization files to generate the model configuration vectors. These vectors are generated only if you have already created a MODELS.SPC file, and run the validation procedure specifying the MODELS parameter value.


    Listing customization data

    This chapter explains the following utility programs, which enable you to list customization data in different formats:

    Note:
    The utilities run in OS/2 and Windows only, although the data that is listed can apply to all platforms.

    Listing internal repository--LISTRTOC

    The LISTRTOC program is provided to generate the internal repository table of contents. The table of contents is generated on a file named CUSPARM.LST.

    You can display online information about the LISTRTOC procedure. From the EHCCUS directory, enter:

      LISTRTOC ?
    

    To start the procedure, from the EHCCUS directory in your customization workstation, enter:

      LISTRTOC [parm1]
    

    where:

    parm1
    Is the type of data to be processed. The parameter value can be:

    COMMON
    To process common data. The program generates a list of the common vectors.

    LAN
    To process workgroup configuration data. The program generates a list of the workgroup configuration vectors.

    MODELS
    To process model configuration data. The program generates a list of the workgroup model configuration vectors.

    The default is LAN.


    Listing workgroup configurations--EHCLIST

    The EHCLIST program is provided to list and view the structure of your workgroup configurations. You can use this program after you have defined at least one workgroup. Two types of listings can be obtained: one oriented towards servers and the other towards services.

    You can display online information about the EHCLIST procedure. From the EHCCUS directory, enter:

      EHCLIST ?
    

    To start the procedure, from the EHCCUS directory in your customization workstation, enter:

      EHCLIST parm1 parm2 parm3 parm4 parm5
    

    where:

    parm1
    Is the group of the workgroup configuration you wish to list.

    parm2
    Is the name of the workgroup configuration you wish to list.

    parm3
    Is the listing format.

    The parameter has two possible values:

    Y
    To have the listing printed continuously
    N
    For separate pages.

    parm4
    Is the output device.

    You can print the report or store it on a file. To print the report, enter the device name of the printer port to be used: LPT1, LPT2, or LPT3.

    To store the report on a file, enter the name of the file. The file will be placed under the EHCCUS subdirectory.

    parm5
    Is the listing type.

    The parameter has two possible values:

    1
    To have the listing oriented towards servers
    2
    To have the listing oriented towards services.

    The following is an example of a servers listing for a workgroup configuration that contains an OS/2 workstation with an SNA server, MQSeries Link server, and a user-defined server, and a Windows workstation with an ODBC query server, shared-file server and a 47x2 financial printer server.

    Servers Server PCs
    GW
    OS/2
    S1
    NT








    EHCMQ## *








    EHCODB01
    *







    PR47X2##
    *







    SHFILEBA
    *







    SNA## *








    USERSVR1 *








    In this listing you can see all the servers installed in the workgroup and the workstations in which they are installed.

    The services listing provides a complete picture of your workgroup configuration and the connections between the server workstations and the client workstations. For a complete listing of all the configurations, make sure you define, under communication configuration customization, all the communication parameters. If you have not defined the communication parameters, the listing will show question marks where services need to be defined.

    Following is an example of a services listing for the same workgroup configuration model as above:

    Served PCs and Services
    Server PCs

    GW
    OS/2
    S1
    NT








    S1 NT










    PR47X2PP

    *







    W1 OS/2










    USERSVR1
    *








    EHCODB01

    *







    PR47X2##

    *







    SHFILEBA

    *







    W2 DOS










    SNA










      EMU32701
    *








      EMU32702
    *








    EHCMQ01
    *








    SHFILEBA

    *







    W3 NT










    EHCMQ01
    *








    EHCMQ02
    *








    EHCODB01

    *







    PR47X202

    *







    SHFILEBA

    *







    The server workstations are shown horizontally at the top of the listing. On the left side, shown vertically, are the client workstations and the services they receive. For example:


    Performance tuning

    This chapter contains information on how to tune the performance of some LANDP components. The following list shows what these specific components are, and where to find the related information:


    Tuning the shared-file server




    ehcodwl

    The shared-file server is designed to take advantage of the system cache. Therefore, increasing the system cache will, in most cases, result in an increased server throughput.

    The ideal cache size is the one resulting from adding the data and index file sizes that the server manages. However, when memory limitations do not allow having such a large cache size, a cache size that is about 20% of the previous addition will also result in improved performance.

    You can specify the cache size in the following ways:

    • For DOS: adding a cache device driver such as IBMCACHE.SYS or SMARTDRV.SYS to your CONFIG.SYS file, with a cache size large enough for your environment.
    • For OS/2 with FAT drives: setting the parameter xx of the DISKCACHE=xx statement in your CONFIG.SYS file to a higher value.

      For OS/2 with HPFS drives: setting the parameter xx in the statement IFS=HPFS.IFS /C:xx to a higher value.

    • For Windows: the cache is controlled dynamically by Windows.
    • For Linux: the cache is controlled dynamically by Linux and its size depends upon the amount of free RAM.

    You can also tune the server loading time parameter /B:nnn (number of index buffers) in order to improve the performance, if there is enough memory available in the system. The value nnn specifies the number of additional (above 10) 1KB index buffers to be allocated. More index buffers increase system throughput, but also reduce the amount of free storage available for the server workstation. A rule of thumb is that the number of buffers should be 10 per workstation using the shared-file server simultaneously. A practical limit is approximately 100, depending on available storage size. The maximum value for nnn is 484.

    Another factor that must be considered is that the more buffers you have, the more likely you are to lose index data when the shared-file server is abnormally closed. Thus, if many index buffers are allocated, and the server workstation is switched off with a transaction still in process, or if no RF function has been called, an automatic index rebuild is performed the next time the server is loaded.

    Note that these considerations are especially important when you specify a small number of simultaneously open files with the /F loading parameter.


    Tuning the LANDP for OS/2 query server




    ehc_0x00

    Since the query server is highly dependant on the database configuration parameters, in terms of performance, you may want to modify some of these parameters in order to increase server throughput.

    It is not particularly helpful to increase the system cache for this purpose, because the IBM Database Server for OS/2 Warp, Version 4 handles its own disk cache. Instead, it is highly recommended to set the buffer pool size parameter in the Change Database Configuration Tool panel of the Database Manager to a suitable value for the query server, since it is a dynamic SQL server.

    To set the buffer pool size, select Configuration Tool in the Database Server main menu. After that, select Configuration and then Change Database. Here you can increase the number of pages for a buffer pool. 200 pages can be a good startup value. You may also need to change the Default application heap size to a larger setting.

    Other configuration parameters do not affect performance considerably, unless they generate contention problems in a concurrent environment. If this is your situation and your applications receive many RL return codes, you can then verify that these problems are not caused by lock escalation. If they are caused by lock escalation, increase the storage allocated for lock lists in the same panel.

    Even if these parameters are set to suitable values, contention problems may still occur. Deadlock and resource racing are normal in concurrent database environments. To avoid contention problems as much as possible, it is recommended that you change the isolation level of the server from repeatable read to cursor stability. You can do this by rebinding the requester program against the database to be used. Enter at the command line:

    SQLBIND EHCSQLRQ.BND database-name /I=CS
    

    You should write applications that access the query server in a way such that they can work properly with this isolation level.

    The server loading parameters /P, /T, and /F affect considerably the throughput of the server. The number of processes, /P, and the number of threads, /T are related to the number of workstations that are accessing the server at the same time. In order to improve performance, fast cursor operation, /F, is recommended for applications that make extensive use of the functions GN, GP, GU, and GW, or for applications that access large data tables.


    Tuning the LANDP for Windows ODBC query server for DB2




    ehcw

    The performance of the ODBC query server is highly dependent on the database configuration parameters and the ODBC configuration parameters. To increase server throughput, you may want to modify some of these parameters. See the vendors' manuals for ideas on performance tuning.

    In the ODBC Query Server LOADER statement, the /MT and /T parameters can be adjusted to increase throughput. These parameters handle the number of threads that are used to send requests to the ODBC Device Driver in use. /MT indicates the maximum number of threads that the ODBC Query Server can start (up to a maximum of 128). /T indicates the number of threads that the ODBC Query Server starts at initialization. For every request received that can not be passed to an existing thread, the ODBC Query Server starts a new thread until the /MT value is reached.

    To improve system throughput, you can increase the buffer pool size (buffpage parameter for DB2). To change this parameter, use the Command Line Processor or the Control Centre database configuration panel. For guidance, refer to the DB2 manuals. It may also be helpful to change the default Application Heapsize (applheapsz).

    If deadlock contention occurs (for example, SQL code SQL0911N returned through a LANDP return code QE), you can adjust additional parameters. Suggestions:

    1. In the ODBC device driver setup, change the Isolation Level (txnisolation) from repeatable read to cursor stability.
    2. In the database configuration panel, adjust these parameters:
      Interval for Checking Deadlock (dlchktime)
      Lock Timeout (locktimeout)

      For more guidance, refer to the DB2 manuals.



    Tuning the shared DOS directory services




    ehc_x000

    This section provides general recommendations for tuning the performance in a workgroup where you want to use the shared DOS directory services.

    If you install the shared DOS directory services in a workgroup, you have to take into account the buffer size customized for the shared DOS directory client workstations in order to calculate the buffer pool size for the server workstation.

    If you do not define a buffer pool size that is large enough, time-out situations may frequently occur. The client workstation will then display the following message:

    Not ready reading drive...
    Abort, Retry, Ignore?
    

    To achieve optimum performance, the buffer pool size of the server workstation should be large enough so as to allocate all incoming requests, which are received from all the client workstations. However, this solution could lead to a shortage of memory in the server workstation, therefore you should find a compromise between performance (that is, buffer size of the shared DOS directory client workstations) and memory requirements (buffer pool size of the shared DOS directory server workstation). This consideration is especially critical when you are going to make copies of large remote files.

    Sizing the client workstation buffer and the server workstation buffer pool must meet the specific requirements of every LANDP workgroup.


    Tuning Windows 3.1 under LANDP for DOS




    ehc_x000

    You can modify some Windows 3.1 settings in order to improve LANDP for DOS performance. For information about which Windows 3.1 settings to modify, refer to the SYSINI.WRI Windows file.

    You should investigate the following Windows 3.1 settings to achieve optimum system performance, depending on your specific environment:

    • MinTimeSlice
    • WinTimeSlice
    • KeyIdleDelay
    • KeyBoostTime

    Also, the Detect_Idle_Time setting of both the LANDP kernel and the LANDP application program information files (PIFs) should be set OFF in most cases to get better performance.

    You can also improve LANDP for DOS performance in a Windows environment by loading EHCWKDE after LANDP for DOS kernel on the same VM. EHCWKDE is supplied with LANDP for DOS in the EHCD600 subdirectory of the workstation where LANDP for DOS is installed. After unloading LANDP for DOS, press the Q key to exit EHCWKDE and continue working on this VM.


    System maintenance--VERSION




    ehcodwl

    This chapter contains information about the VERSION utility program. This utility program is helpful in the maintenance of LANDP products and in the problem determination process.

    The VERSION utility program determines the current version level of LANDP product components and keeps track of maintenance fixes installed on the components. The program also generates information that can be helpful when resolving LANDP problems. IBM support representatives will require this information if you request assistance.


    Using the VERSION utility program




    ehcodw

    The VERSION utility program performs the following functions:
    • Determines the current version of the component program files
    • Determines the last authorized program analysis report (APAR) applied to:

      • LANDP product components
      • FBSS, PC/Integrator, and PC Integrator/2 programs
    • Displays the program name, program version, and last-applied APAR level

    When you run the VERSION utility program, it creates a file called VERSION.TXT.

    The VERSION program writes to this file the component program name, version, APAR information.

    You can run the VERSION utility program on any LANDP workstation.

    Starting the VERSION utility program

    Start the VERSION utility program from the EHCMAINT directory on the OS/2 or Windows customization workstation, or from the directories that contain the LANDP product components on the production site workstation.

    To start the program, do the following:

    1. Complete one of the following steps:
    2. Enter the following command:
      VERSION [path1] [/o:path2]
      

      where:

      path1
      Is the path and drive that the VERSION program searches. You should specify the path and drive where the LANDP programs are.

      If you do not specify this parameter, the VERSION utility program searches only the current directory and the LANDP reserved subdirectories.

      /o:path2
      Is the target drive and path where the VERSION utility program places the output file, VERSION.TXT.

      If you do not specify this parameter, the VERSION program places VERSION.TXT in the current directory.

    Reading the output

    The VERSION utility program generates the following output when it runs successfully, and all information is available:

    ID=ssssssss     VL=vrmxx     nnnnnnn     ffffffff.fff
    

    ID=ssssssss
    Is the name of the program.

    VL=vrmxx
    Is the version level, where:

    vr is a variable that identifies which LANDP Version 6 components use a program:

    D6
    LANDP for DOS
    O6
    LANDP for OS/2
    N6
    LANDP for Windows
    L6
    LANDP for Linux
    B6
    LANDP for DOS and LANDP for OS/2
    S6
    LANDP for OS/2 and LANDP for Windows
    U6
    LANDP for DOS and LANDP for Windows
    A6
    LANDP for DOS, LANDP for OS/2, LANDP for Windows, and LANDP for Linux
    K6
    LANDP for Windows, LANDP for OS/2, and LANDP for Linux
    H6
    LANDP for OS/2 and LANDP for Linux
    Z6
    LANDP for Windows and LANDP for Linux
    P6
    LANDP for DOS, LANDP for OS/2, and LANDP for Windows

    For the FBSS products, PC/Integrator, and PC Integrator/2, v is the version and r is the release.

    m is the modification level.

    xx is a sequence number that corresponds to the number of modifications that have been applied to the LANDP program.

    nnnnnnn
    Is the last APAR applied to the program.

    ffffffff.fff
    The name of the file.

    For information and procedures for installing program fixes, see Applying program fixes--APPLYFIX.


    Version Utility on Linux




    ehcl

    On Linux, the version utility program behaves differently from the VERSION utility program on DOS, OS/2 and Windows. Rather than looking at a single directory, version looks at the current environment and does the following:
    • Determines the actual executable file that will be run within the currently defined environment
    • Determines the current version of the component program files
    • Determines the last authorized program analysis report (APAR) or program temporary fix (PTF) that has been applied to the LANDP component
    • Determines the library levels and their locations within the system
    • Displays the program name, program version, APAR or PTF level, library dependencies and path of the program executable for LANDP for Linux

    When version is run, it creates an output file called version.txt and writes the program-related information to this file.

    Starting version on a LANDP for Linux workstation

    Before starting the version utility, make sure that you are running from a shell with the current LANDP environment set up.

    To run version, issue the following command:

          version [-o output]
     
    where output is the name of the output file. The default is version.txt.
    

    For more information about the version utility, refer to the LANDP Problem Determination.


    Applying program fixes--APPLYFIX




    ehcodwl

    This chapter describes how to install program fixes for LANDP product components. Program fixes are provided by the IBM Support Center (ISC). A fix is sometimes called an authorized program analysis report (APAR).

     

     


    About program fix files




    ehcodwl

    The IBM Support Center uses the following naming convention for program fix files:
    filename.ext
    

    where:

    filename
    Is the fix identification number.

    ext
    Is the file extension, which is the first three characters from the VL field in the VERSION.TXT file. See Using the VERSION utility program for information about VERSION.TXT.

    An example of a program fix file name might be:

    HC52249.D60
    

    You must install program fix files on the workstation that is used for customization. To install program fixes, refer to the information that relates to the LANDP product components you are updating.


    Using the APPLYFIX utility program

    Use the APPLYFIX utility program if you are installing program fixes for a LANDP product component.

    Note:
    APPLYFIX has to be run from an OS/2 or Windows customization workstation to apply fixes to any component of LANDP.

    The APPLYFIX utility program performs the following functions:

    Starting the process




    ehcow

    To start the apply-fix process, do the following:
    1. Go to a command prompt on the customization workstation.
    2. Make EHCMAINT the current directory.
    3. From EHCMAINT, enter the following command:
      APPLYFIX [d:][\path\]filename.ext [/all]
      

      where:

      d
      Is the source drive that contains the fix file.

      path
      Is the directory where the program fix resides.

      filename.ext
      Is the name of the program fix file.

      /all
      Applies all the changes from the program fix file, without showing the contents of the file.

    Notes:

    1. You can use wildcard characters instead of specifying the program fix file name and extension.

    2. You can start the APPLYFIX program with the parameter /?, if you want online instructions about using the program.

    3. You can press the F1 key for more online help after the program is started.

    Examples

    Installing program fixes

    If you do not specify the /all option, the APPLYFIX utility program displays a screen containing information about the program fixes. From this screen, you can do the following:

    The APPLYFIX utility program checks the component ID, the release, the version level, and the directory where the program fix is to be installed. It then installs the fix and replaces product component files, as required.

    The APPLYFIX utility program updates two history files by recording the changes made when program fixes were installed. The history files are named LANDP.HST and TOTS.HST. Both files reside in the EHCMAINT directory.

    LANDP.HST and TOTS.HST are text files. You can view or print the files using the TYPE or PRINT commands from a command prompt.

    After you install program fixes, the updated product components can be copied to diskette or other media for transfer to the workstations in your workgroups.

    Backing up and retrieving program files

    When the APPLYFIX utility program replaces a file, it saves a backup copy of the replaced file in a directory named FIXSTORE. The file is saved with its program name and its version level number as the extension.

    Example LANDP Version 6 backup file names

    In the above list xx is a numeric value identifying the version of the backed-up program.

    You can retrieve files in the FIXSTORE directory by running the APPLYFIX utility program. You would start the APPLYFIX program, specifying the backup directory and program file that you want to retrieve. For example:

    APPLYFIX ..\FIXSTORE\SPV.AXX
    
    Note:
    After many updates, the FIXSTORE directory may occupy a large amount of disk space. Make sure you maintain and administer the FIXSTORE files correctly.

    Graphical Customization Editor




    ehcow

    The LANDP graphical customization editor is designed to help with the editing of customization data. It allows you to view LANDP workgroups graphically and edit the parameters for LANDP common data, workgroups, workstations, servers and clients.

    This chapter provides tutorial and reference material to help you to use this graphical editor.

    The tutorial is in three parts and takes you through the main features of the LANDP customization editor. More advanced topics are covered in the Reference section.

    This chapter is not meant to be read from start to finish, because not all of the functions are critical to daily operations.

    Near the back of this chapter is a Glossary, which explains some of the jargon used here.


    Tutorial Part 1: Editing workgroup parameters

    Part 1 of the tutorial shows you how to navigate through the editor, how to add new common parameters, workstations, servers and clients, and how to edit their properties and parameters.

    The tutorial explains how to customize a basic workgroup with four workstations, with an SNA server and a system management server.

    Getting started

    To run the LANDP customization editor you must have one of the following operating systems installed on your computer:

    You also need to have the Java Runtime Environment (JRE) Version 1.3, or later, installed.

    To run LANDP customization, double-click on the "LANDP customization editor" icon that is in a directory display window on the screen. The main editor window appears with the title 'LANDP customization editor' as a heading.

    The main editor window

    The main editor window (see Figure 11) has three main areas:

    Figure 11. Main Editor Window


    ehcgce1

    The central tabbed pane contains two panes for editing common parameters and workgroup parameters:

    Click on each of the tabs to view the different parameter definition areas. If objects disappear off the bottom of a list, a scroll-bar appears at the right of the list. Use this to scroll through the entire list.

    Adding a new workgroup

    Figure 12. Add Workgroup


    ehcgce2

    Now click on the workgroup parameters pane, and then click on the 'Add Workgroup' button. A new window should appear with a title at the top: [LANDP customization - New workgroup]. This window is where the properties for each new workgroup are created, and is the first of the new workgroup guide.

    The guide is split into four pages:

    The guide pages always contain four buttons at the bottom righthand side of the page:

    When the guide closes, a new workgroup icon appears in the tree on the left of the tabbed pane, and the parameter pane for the workgroup is displayed with the parameters entered for the workgroup displayed in their respective fields.

    The workgroup parameter window is split into two panes, one for general parameters and one for advanced parameters.

    The button bar

    Figure 13. Button bar


    ehcgce3

    We have already used the button bar to add a new workgroup. The other functions available from the button bar, from left to right, are:

    The first two buttons allow you to open and save common parameter files (COMMON.SPC files) and workgroup parameter files (LANCONF.SPC files).

    Three buttons are supplied to cut, copy and paste data. Data selected in a tree can be copied or cut, and then pasted to a tree that has data in the same format. For example, common vectors can only be pasted to a common vector list.

    The other buttons allow new data to be added using guides.

    The button bar can also be separated from the editor window by selecting it and dragging it. It then appears in a window of its own. To place it back on the editor window, select the 'X' button in the top right hand corner.

    Adding a new workstation

    Figure 14. New Workstation


    ehcgce4

    Now click on the 'Add a new workstation' button. A new window appears with a title 'LANDP customization - New Workstation.'

    The guide is split into three pages:

    This guide contains the same control buttons as the 'New Workgroup' guide.

    Click on the 'Finish' button to add the workstation. The window should close, and you should see a new icon in the workgroup parameters tree representing the new workstation. The name of the workstation name is displayed next to the icon.

    Now try adding some more workstations with the following names and operating systems:

    Once you have added these, you should have four icons representing workstations in the workgroup tree view with the four names of the workstations.

    Select workstation 'AA' in the list, and its properties page should be displayed. The workstation properties window is similar to the workgroup properties window in that it is split into two panes, one showing the general properties, and the other showing the advanced properties.

    Now click on the 'Add server' button.

    Adding a New Server

    Figure 15. New Server


    ehcgce5

    Click on the 'Add Server' button on the button bar. The server editing guide now opens. There are just two pages.

    The first page contains the workgroup and workstation fields, as well as the name field. Type in 'SNA' in the name field, which is a combo-box. The server can also be selected from the drop-down list. The other two fields should be filled in automatically with 'SAMPLE1' and 'AA' respectively. Select the 'Next' button. The second page is displayed.

    The second page contains fields for selecting a model, expanded memory selection and loading parameters. Ignore these and select 'Finish'. A server icon appears in the tree under Workstation AA. The server parameter window is also displayed to the right.

    Some servers have extra parameters that can be specified. These are displayed in the advanced pane. There can be from two to thirty fields that can be edited. Click on the 'Advanced' tab to display these parameters. For details see Appendix D, Editing configuration data.

    At the bottom of the window are two buttons, 'Cancel' and 'OK'. Selecting 'Cancel' restores the parameters to their values before they were edited. Selecting 'OK' saves the changes made.

    Figure 11 shows that the name of the field is shown, followed by the range of permissible values, and whether that parameter is required or optional.

    Two types of field are used.

    The first is the standard text entry box. Simply click a mouse button when the cursor is over the field, and the caret (a thin blinking line) appears in the box.

    The second type of field is a choice box. When you click on the arrow at the right hand side of the choice box, a list appears showing the values that can be selected. Click on one of these values and it appears in the choice box.

    Experiment with these data entry methods, and then click on 'OK' to save the parameters. Now return to the general server properties editing window by selecting the 'General' tab. Try adding another server with name 'TRDLC' and experiment with the advanced parameter editing window.

    Adding and Editing Clients

    To add clients, follow the procedure for adding servers described in Adding a New Server, but click on the 'Add Client' button on the button bar. The guide is slightly different.

    The first page contains the fields for specifying which workgroup and client workstation to add the client to. It also allows selection for which workstation is providing the resources, or the servers.

    The second page allows client selection, from a list of available clients from the workstation providing resources. In this case, it should only contain 'SNA##' because this is the only resource from workstation AA that can have a client.

    With any resource that ends with a '#' or a '##', a session ID or suffix is needed. Enter '01' in the suffix field. This uniquely identifies the client on the workstation it is added to. An alias parameter can also be supplied. This parameter is optional and is not needed now.

    Add two new clients with names 'SNA01 and 'SNA02'. To edit the parameters, follow the same procedure as for servers. The clients, when added, should appear in the tree view.

    Editing clients and servers and their parameters forms the main part of creating or editing a LANDP customization file. Therefore, familiarization with these procedures is essential for using the software effectively. The specific details about each parameter are listed in Appendix D, Editing configuration data.

    Saving and Opening

    Saving

    To save the workgroup details, either select the save icon from the button bar, or use the drop down menu from the top of the screen and click on the 'File' menu.

    Figure 16. The file menu


    ehcgce6

    A menu appears. Click on the 'Save' menu item and a new window opens with a title 'Save'. This is a standard file menu. Enter the name of the workgroup list as 'LANCONF.SPC' in the file name field, and click on the 'OK' button to save it in the currently selected directory. Click on the 'Cancel' button to exit the save window without saving.

    Opening

    To open a new workgroup list, select the 'Open' menu item from the file menu on the workgroup list window. From this file window, locate the directory where the files are stored, and double-click on the file that you want to open. Alternatively, type in the path name of the directory in the file name field.

    When you have experimented with adding workstations, clients and servers, and editing their parameters, save your file as 'LANCONF.SPC.

    Well done. You have now finished the first part of the tutorial.


    Tutorial Part 2: Editing common parameters

    This section of the tutorial covers the editing of common parameters. It is very similar to the editing of workgroup parameters, but there are a few differences.

    First, select the common parameters tab on the main editor window. The tree on the left should display a common vector list with a list of vectors. These are the default vectors for LANDP customization, and is the equivalent to running the 'CREATE' command (see The CREATE utility program).

    Selecting one of the vectors in the tree displays the parameters for that vector in the panel on the right of the editor. Try selecting some of the different vectors. Selecting any of the 'XLATETBL' vectors displays a list of parameters. This is the only type of parameter that is unique to common vectors. Now click on the 'Add Vector' button.

    Adding a new vector

    Figure 17. Add Common Vector


    ehcgce7

    A new window should appear with a title at the top: [LANDP customization - New Common Vector]. This window is the first page for the new vector guide, which has two pages:

    Some vectors can be appropriate for more than one server. This is not a problem, since whatever vector you define is available to the other servers once LANDP has been customized. When you click 'Finish', the guide disappears and a new vector icon is displayed in the common vector list. The parameters for that vector are displayed in the main editor to the right of the tree view.

    Try adding the following vectors for a new shared file record:

    Saving and Opening

    Saving

    To save the common vector list, either select the save icon from the button bar, or use the drop down menu from the top of the screen and click on the 'File' menu.

    A menu appears. Click on the 'Save' menu item and a new window opens with a title 'Save'. This is a standard file menu. Enter the name of the vector list as 'COMMON.SPC' in the file name field, and click on the 'OK' button to save it in the currently selected directory.

    LANDP only uses one common vector list when running the customization process (see Tutorial Part 3: Validating and distributing) which is located in the customization root directory (EHC/EHCCUS). Click on the 'Cancel' button to exit the save window without saving.

    Opening

    To open a new common vector list, select the 'Open' menu item from the file menu on the workgroup list window.

    From this file window, locate the directory where the files are stored, and double-click on the file you want to open. It is called 'COMMON.SPC'.

    Alternatively, type in the path name of the directory in the file name field.

    When you have experimented with adding common vectors, and editing their parameters, save the file as 'COMMON.SPC.'

    An example of a common vector file is in the LANDP install directory, EHC\EHCCUS\SAMPLE2.


    Tutorial Part 3: Validating and distributing

    This section of the tutorial covers the validation and distribution of customization data. Validation is a process which checks the customization files for errors. Distribution is the process whereby the customization files are used to generate the lists of files needed for each LANDP workstation, and then send them to the required paths.

    There are three different types of customization files:

    The COMMON.SPC and MODELS.SPC files must be located in the EHCCUS directory created by the installation program. Each LANCONF.SPC file should be contained in a separate directory. These directories can be located either in the EHCCUS directory or in any directory that you create at the same level as the EHCCUS directory. You can also create a directory for each group of workgroup configurations to be defined.

    Validation

    Start validation either by selecting the 'Validate' button from the button bar or from the 'Tools' menu.

    A new window appears that displays the validation guide. This is split into two pages:

    The guide window is replaced by a status window that shows the progress of the validation process.

    If the validation is successful, a message appears to indicate this. If you then select 'OK' the status window is closed.

    If an error occurs, the incorrect data is displayed in the status window, together with an indication of where the error is, and how to fix it. Once the file has been edited to fix the problem, the file can be saved, and the validation process can be restarted. This process might need to be repeated several times if a large number of files are being processed.

    Distribution

    Start distribution either by selecting the 'Distribute' button from the button bar or from the 'Tools' menu.

    A new window appears that displays the distribution guide. This is split into four pages:

    The guide window is replaced by a status window that shows the progress of the distribution process.

    If the distribution process completes successfully, a message appears to indicate this. If you then select 'OK' the status window is closed.

    If an error occurs, the incorrect data is displayed in the status window, together with an indication of where the error is, and how to fix it. Once the file has been edited to fix the problem, the file can be saved, and the 'Continue' button can be selected from the guide window to continue distribution. This process might need to be repeated several times if a large number of files are being processed.


    What to do next

    By now you should have quite a good working knowledge of the LANDP customization editor. However, there are still some essential functions that haven't been touched upon yet.

    The menus

    Some of the functions in the LANDP customization editor haven't been mentioned yet, and you should know where to find them.

    File

    This covers functions affecting the whole workgroup list, such as saving and loading.

    Edit

    View

    Tools

    Help

    Limitations

    There are some things that can't be done with the LANDP customization editor.

    Creating Dynamic Workgroups

    Once you have specified workgroup details, and the software has been distributed to all the workstations, it is likely that in the future changes might need to be made. For example, an extra workstation might need to be added.

    However, the workgroup can not simply be edited to add or modify data once the software has all been distributed. For example, once the workgroup is up and running, a new workstation can not be added simply by reloading the workgroup file, adding the new workstation and distributing the files to that new workstation.

    This is because each workstation in the workgroup needs to know about every other workstation in the workgroup for the client/server relationships to operate successfully. This means that all the software needs to be redistributed to all workstations whenever a workgroup is changed.

    Selecting and copying multiple objects

    Within the customization editor, only one object in a tree view can be copied at the same time.

    Re-sizing the editor screen

    The customization editor uses a fixed screen size which can be viewed at a minimum resolution of 800 x 600. This cannot be re-sized.

    Help

    Online help is available by selecting the Help menu.

    Selecting 'Help Topics' opens the main help window with a list of topics providing further assistance.

    'Books Online' directs you to the LANDP website that gives information about the latest support and any fixes that might be needed.

    The 'About Box' gives information about the current version of the Customization Editor. This information is required if you request any assistance directly.

    Common problems

    Error messages in the LANDP customization editor appear when you run the validation and distribution commands on a particular workgroup customization file. The error is displayed in the status window. See Tutorial Part 3: Validating and distributing for more details.

    I cannot close the windows.

    Most windows have 'OK' and 'Cancel' buttons on them, often at the bottom of the window. The bottom of the window might have moved off the bottom of the screen. Click on the title bar of the window and drag it towards the top of the screen. If there are no obvious buttons, use the 'X' button in the top right corner of the window. No data is lost if you do this.

    Clicking on the graphical icons does not select them.

    To select a workstation on the workgroup window, or a client or server on the workstation window, click on the object with the left mouse button.

    I cannot see all the workstations/servers/clients in the tree view.

    In the workgroup parameters pane, scroll down using the scroll bar at the right of the tree view. Alternatively, adjust the screen resolution to a higher resolution.

    I cannot find all the parameters for the server or client objects.

    Click on the 'Advanced' tab on the workgroup parameter editing window to view the separate parameter editing pane.

    I cannot see all the vectors in the tree view. In the common parameters pane, scroll down using the scroll bar at the right of the tree view. Alternatively, adjust the screen resolution to a higher resolution.

    The data that I entered has been lost.

    When you have finished entering data for a vector, select the OK button in the bottom right of the main panel to save the new values.

    Reference

    Clients

    Clients are shown on the workgroup parameter pane as nodes on the tree view, each with an icon and the client name. Each workstation must have at least one client or server connected to it.

    The parameters for each client are displayed in the 'General' properties pane on the main editor window. Each client has a name, as well as an alias name, which is used by applications when requesting services. Some clients have extra parameters which can be edited by clicking on the 'Advanced' button to open the advanced properties pane.

    Adding a client To add a new client, click on the 'New Client' button on the button bar or 'Edit' menu. The 'new client' guide opens. Enter the name of the client, and the name of the workstation providing the services. Enter other parameters if required. Select the 'Finish' button to store the details.

    Removing a client Select the clients icon in the tree view on the workgroup parameter pane and press the right mouse button to display the pop-up menu from the list. Select the 'Delete' option, and the chosen client is removed.

    Common Vectors

    Common vectors define data that is common to all workstations and workgroups. They consist of defaults, tables, record definitions and profiles. The list of currently defined vectors is displayed in a tree view, and can be viewed by selecting the 'Common Parameters' tab on the main editor window. To edit a vector, simply select it and its parameters appear to the right of the tree view.

    Adding a common vector To add a new common vector, either select the 'New Common Vector' button from the button bar on the main editor window, or select it from the 'Edit' menu. The 'New Common Vector' guide opens. Select the server and type of common vector that is required, select 'Finish' and the guide closes. The newly created vector is added to the common vector list, and its parameters are displayed on the right hand side of the editor window.

    Removing a common vector To remove a common vector, select it and press the right mouse button. A pop-up menu is displayed. Select the 'Delete' option, and the common vector is removed.

    Distribution

    Distribution is the process which generates the lists of files needed for each LANDP workstation, and then sends them to the required paths. Start the distribution process by selecting 'Distribute' from the button bar or 'Tools' menu. The distribution guide opens. Select the customization directories that require distributing, and which types of data. Selecting 'Generate' starts the file generation process for each workstation. The final page of the guide provides the ability to distribute the files to either a single path for the entire workgroup, or individual paths for each workstation.

    Errors If an error occurs during distribution, some information about the problem is displayed in the status window together with an indication of where the error is, and how to fix it. Once this has been edited to fix the problem, the file can be saved, and the 'Continue' button can be selected from the status window to continue distribution. This process might need to be repeated several times if a large number of files are being processed.

    Files

    The whole aim of the LANDP customization editor is to enable easy editing of the LANDP configuration data files. These files contain data for defining LANDP workgroups.

    There are three different files used in LANDP customization:

    For more information about these files, see Preparation of customization data.

    OpeningTo open new configuration files, select the 'Open Workgroup List' option from the 'File' menu on the Workgroup List menu. Then use the filer window to locate the folder that contains the files you want to open, select the file and then click on the 'OK' button to open the file.

    SavingTo save the workgroup files, select the 'Save Workgroup List' option on the 'File' menu on the workstation list window. Use the filer window to select the folder where you want to save the data, and click on the 'OK' button.

    Searching

    To search for a particular object (for example, Workstation) enter the name in the search field above a tree view in the main editor window. If more than one search term is found, select the search button again to proceed to the next match.

    Servers

    Servers are shown on the workgroup parameter pane as nodes on the tree view, each with an icon and the server name. Each workstation must have at least one server or server connected to it. The parameters for each server are displayed in the 'General' properties pane on the main editor window. Each server has a name, as well as some optional parameters which can be defined. Some servers have extra parameters which can be edited by clicking on the 'Advanced' button to open the advanced properties pane.

    Adding a server To add a new server, click on the 'New Server' button on the button bar or 'Edit' menu. The 'new server' guide opens. Enter the name of the server, and any other parameters if required. Select the 'Finish' button to store the details.

    Removing a server Select the servers icon in the tree view on the workgroup parameter pane and press the right mouse button to display the pop-up menu from the list. Select the 'Delete' option, and the server is removed.

    Validation

    Validation is a process which checks the customization files for errors and inconsistencies. Start the validation process by selecting 'Validate' from the button bar or 'Tools' menu. The validation guide opens. Select the customization directories that require validation, and which types of data. Select 'Finish'. This closes the guide and opens a status window that displays the progress of the validation.

    Errors If an error occurs during validation, some information about the error is displayed in the status window, together with an indication of where the error is, and what you need to do to fix it. Once this has been edited to fix the problem, the file can be saved, and the 'Continue' button can be selected from the status window to continue validation. This process might need to be repeated several times if a large number of files are being processed.

    Workgroups

    A workgroup is used in LANDP to describe a group of workstations that are connected together and share common resources. The workgroup parameter pane shows a list of all the workgroups currently loaded and all the workstations contained in the workgroups in the tree view. The workgroup properties editing pane is displayed when a workgroup icon is selected in the tree view.

    Editing workgroups Workgroups contain workstations. The buttons on the button bar and 'Edit' menu allow addition of workstations. Workstations can be removed by selecting the workstation in the tree view, selecting the right mouse button to open the pop-up window and selecting 'Delete'. Workgroup properties can be edited from the workgroup properties window.

    Adding workgroups Workgroups can be added from the workgroup parameters pane. Select the 'Add Workgroup Button' or select 'Add Workgroup' from the 'Edit' menu. See the tutorial section for more details on adding a workgroup.

    Removing workgroups Workgroups can be removed from the current workgroup list. Select the workgroup from the workgroup list in the tree view, select the right mouse button and select 'Delete' from the pop-up menu.

    Workgroup lists

    The workgroup list contains all the workgroups currently loaded. These are displayed on the workgroup list window. To open an existing workgroup list, use the 'Open Workgroup List' option from the 'File' menu. To create a new workgroup list, select the 'New Workgroup List' option from the 'File' menu. To save a workgroup list click on the 'Save Workgroup List' option on the 'File' menu.

    Workstations

    Workstations are the core objects in LANDP customization. A group of workstations constitutes a workgroup, and workstations can share services provided by other workstations using the client/server architecture.

    Editing Workstations A workstation can be edited by selecting it from the list in the tree view of the workgroup parameters pane. The workstation parameters are displayed. Double-clicking on the icon in the tree view expands and collapses the list of clients and servers which are connected to the workstation. Clients and servers can be edited, removed or added from a workstation.

    Adding Workstations Workstations can be added to a workgroup by clicking on the 'Add Workstation' button on the button bar. Selecting 'Add Workstation' from the 'Edit' menu has the same effect. For more information on adding workstations, see the tutorial section.

    Removing Workstations Workstations can be removed from the current workgroup list. Select the workstation from the list in the tree view, select the right mouse button and select 'Delete' from the pop-up menu.

    Some terms used in this chapter

    Box
    A rectangular area into which data can be entered

    Buttons
    When clicked on, perform the operation that is described by the text on the button

    Caret
    The red line that shows where the next letter you type appears

    Clicking
    The action of pressing the left mouse button once and releasing it (or, if you are left-handed and have the mouse set for left-handed use, the right button)

    Choice box
    A box containing a menu that appears when you click on a small triangular button, usually at the right end of the box

    Field
    A box which contains a value, or into which values can be entered

    Menu
    A list of options that appears when you click on a menu button

    Mouse pointer
    The graphical icon showing where the mouse is pointing to on the screen

    Appendixes


    Part 7. Appendixes, Glossary, and Bibliography

    This part includes various appendixes, showing a hands-on example and providing detailed vector descriptions for user servers, common data, and configuration data.


    Appendix A. An example

    To help you get a feeling for various LANDP configurations, some samples are provided on the LANDP CD-ROM. After installing LANDP, you will find them in path

       ...\EHCCUS\SAMPLEn\
    

    This appendix describes SAMPLE1, which shows the steps to customize a basic workgroup of three workstations. It provides a guide through the customization process, with basic modifications to the configuration.

    SAMPLE1 is located in path

       ...\EHCCUS\SAMPLE1\
    

    If you wish to modify or test this example, or find out more information about how it was written and configured, please refer to the individual chapters of this manual.


    Background

    SAMPLE1 shows all the steps and procedures needed to customize and obtain software for distribution to the work sites.

    The example involves the following steps:

    1. Installing
    2. Creating common vectors
    3. Editing common vectors
    4. Validating common vectors
    5. Editing workgroup vectors
    6. Validating workgroup vectors
    7. Obtaining software for distribution
    8. Distributing the software

    The workgroup in the example looks like this:



    ehcgr064

    All workstations use SNA sessions to communicate with the host applications, and have the following requirements:

    AA
    Workstation AA is DOS 7.1.

    It contains the token-ring DLC server (TRDLC) and the SNA server (SNA##).

    BB
    Workstation BB is DOS 7.1.

    It uses two sessions of the SNA server in workstation AA, and receives services from the 3270 emulator.

    CC
    Workstation CC is OS/2 Warp V4 or later.

    It uses two sessions of the SNA server in workstation AA.

    Step 1. Installing

    Because the example is a mixed workgroup with both DOS and OS/2 workstations, you must have LANDP for DOS and LANDP for OS/2 installed in your customization workstation.

    Example 1 assumes that you have installed LANDP in directory C:\LANDP The common and models customization files will be put in subdirectory EHCCUS, which is created by the installation program. All procedures will be called from the same subdirectory: C:\LANDP\EHCCUS.

    Note:
    For NetBIOS support, you need to copy the following device drivers from the LAN Support Program installation diskette to the EHCD600 directory:

    Step 2. Creating common vectors

    Some servers in your workgroup may need common data specifications. For a reference list of which vectors you have to specify, refer to Vectors - a quick reference. If you do not need to specify common vectors, go directly to Step 5. Editing workgroup vectors.

    In the example, defaults are required at common level. Therefore, you will create the common data default definitions.

    To create the default definitions, start from the EHCCUS subdirectory (C:\LANDP\EHCCUS) and enter the following command:

       CREATE
    

    The common data default definitions are created in the internal repository, and contain all the default values for your common data.

    To generate the common vectors, enter:

       GENSPEC COMMON
    

    You may leave the default data and continue with defining workgroup vectors. If you want to see the data you have created, or want to make modifications to them, go to the next step.

    Step 3. Editing common vectors

    You created the common data default definitions in Step 2. This also created a COMMON.SPC file in the EHCCUS subdirectory. This file can be edited by entering the following command from the same subdirectory:

       EDITSPC COMMON
    

    Your COMMON.SPC file is now open and you can start editing.

    In the example, you want to add an additional key definition for the 3270 emulator keyboard table. The key definition will be: SCAN/ASCII 6D/00/END EMULATION.

    To add the key definition, take the default KBD3270 vector (with keyword EXTEN=KBD) and add one keyword:

       KEY=(6D,00,'END EMULATION')
    
    Note:
    The graphical customization editor can also be used to edit common data specifications. See Graphical Customization Editor for more information.

    Step 4. Validating common vectors

    When you have specified the common vectors, you can check that they are correct. To call the validation program, enter from the same EHCCUS subdirectory:

       VALSPEC COMMON
    

    The definitions of the COMMON.SPC file are validated, with a maximum allowed return code of 0.

    If there are errors, attention items, or informative messages, the CUSPARM.LST file is created in the same subdirectory. This file contains the vectors and pointers to the messages or errors. Correct the data, and run the validation program again.

    Once the common data definitions have been edited and validated, you can go on to define your workgroup specifications.

    Step 5. Editing workgroup vectors

    All the data for setting up workgroup definitions have to be defined for each workgroup customization.

    The subdirectory where the workgroup definitions for this example will reside, is called SAMPLE1. Again, start from the EHCCUS subdirectory, and enter:

       EDITSPC SAMPLE1 LAN
    

    The LANCONF.SPC file is now open and ready to be edited. It is located in path C:\LANDP\EHCCUS\SAMPLE1.

    If the path does not exist, or if you specify a different group and workgroup identification, the program asks if you want to create it. Enter Y, and the file LANCONF.SPC is created in the directory you specified.

    All the vectors containing workgroup definitions for SAMPLE1 have to be written in this file. The LANCONF.SPC file is now open and you can start editing.

    Note:
    The graphical customization editor can also be used to edit workgroup configuration data. See Graphical Customization Editor for more information.

    The workgroup vectors for the example are described below:

    Workgroup configuration

    This is an example of a LANCONF vector, which specifies the configuration for the workgroup:

       LANCONF    GROUP=EHCCUS,
                  NAME=SAMPLE1,
                  WSNAMES=(AA,BB,CC)
    

    Workstation configurations

    After defining the LANCONF vector, the next step is to add the vectors for the individual workstation definitions.

    This is the vector for workstation AA:

       LWSCONF     NAME=AA,
                   TYPE=DOS,
                   SERVER=(TRDLC),
                   PAR&TKR=(48,04,04,00000001,00000099,017,00000),
                   SERVER=(SNA##)
                   PAR&SNA=(ANY,SRV)
    

    The parameter values for this vector are:

    Keyword Parameter Values
    NAME
    AA
    Is the workstation identifier.

    TYPE
    DOS
    Is the operating system.

    SERVER
    TRDLC
    Loads the token-ring DLC server.

    PAR&TKR
    48
    Is the number of buffers.
    04
    Both host and workstation use SAP 04.
    00000001
    Is the workstation TR locally administered address (400000000001).
    00000099
    Is the host TR locally administered address (400000000099).
    017
    Is ID block 017.
    00000
    Is ID Number 00000.

    SERVER
    SNA##
    Loads the SNA server.

    PAR&SNA
    ANY
    Session can be initiated by application or host.
    SRV
    BID command managed by SNA server.

    This is the vector for workstation BB:

       LWSCONF     NAME=BB,
                   TYPE=DOS,
                   CLIENT=(SNA01,AA),
                   SES&SNA=(AA,01,31),
                   CLIENT=(SNA02,AA),
                   SES&SNA=(AA,02,32),
                   SERVER=(EMU32701),
                   PAR&3270;=(Y,N),
                   SES&3270;=(AA,1,33,TKR,ATR,DIS,KBD,SESSION1)
    

    The parameter values for this vector are:

    Keyword Parameter Values
    NAME
    BB
    Is the workstation identifier.

    TYPE
    DOS
    Is the operating system.

    CLIENT
    SNA01,AA
    Uses session 01 of the SNA server loaded in AA.

    SES&SNA
    AA,01,31
    SNA session 01 provided by server in AA will use SNA LU number 31.

    CLIENT
    SNA02,AA
    Uses session 02 of the SNA server loaded in AA.

    SES&SNA
    AA,02,32
    SNA session 02 provided by server in AA will use SNA LU number 32.

    SERVER
    EMU32701
    Loads the 3270 emulator, session 1.

    PAR&3270
    Y,N
    (Y) means, HLLI will be used. (N) means, cryptographic support will not be used.

    SES&3270
    AA,1,33,TKR
    3270 emulator session 1 uses SNA server through token-ring DLC in AA. The SNA LU number is 33.
    ATR
    Is the table default for color display.
    DIS
    Is the table default for EBCDIC to ASCII translation.
    KBD
    Is the table default for keyboard definitions.
    SESSION1
    Is the host application session identification.

    This is the vector for workstation CC:

       LWSCONF     NAME=CC,
                   TYPE=OS/2,
                   CLIENT=(SNA01,AA),
                   SES&SNA=(AA,01,11),
                   CLIENT=(SNA02,AA),
                   SES&SNA=(AA,02,12)
    

    The parameter values for this vector are:

    Keyword Parameter Values
    NAME
    CC
    Is the workstation identifier.

    TYPE
    OS/2
    Is the operating system (OS/2 Warp V4.0 or later).

    CLIENT
    SNA01,AA
    Uses session 01 of the SNA server loaded in AA.

    SES&SNA
    AA,01,11
    SNA session 01 provided by server in AA will use SNA LU number 11.

    CLIENT
    SNA02,AA
    Uses session 02 of the SNA server loaded in AA.

    SES&SNA
    AA,02,12
    SNA session 02 provided by server in AA will use SNA LU number 12.

    Step 6. Validating workgroup vectors

    You may wish to check whether the workgroup vectors are correct, especially if you have made any modifications to the example file. To call the validation program, from the same subdirectory enter:

       VALSPEC LAN \SAMPLE1
    

    The definitions of the LANCONF.SPC file for SAMPLE1 are validated, with a maximum allowed return code of 0.

    If there are errors, attention items, or information messages, the CUSPARM.LST file is created in the same subdirectory. This file contains the vectors and pointers to the messages or errors. Correct the data, and run the validation program again.

    When the workgroup data definitions have been edited and validated, you can go on to obtain the diskettes for distribution to your work sites.

    Step 7. Obtaining software for distribution

    Obtaining software for distribution is a two-stage process:

    1. Convert data for one or all workgroups into run-time configuration files for each workstation. Enter the following command:
         GENRUN LAN \SAMPLE1
      

      The run-time files and a file containing a list of software required for each workstation (GETTING.SPC) have now been created. In the example, these files are created in path: C:\LANDP\EHCCUS\SAMPLE1\ws-name.

    2. Copy the software for each workstation to diskettes or to any desired path. Enter the following command:
         GETTING  \SAMPLE1 WS=ALL 1 A:
      

      This command copies all the configuration files for all workstations in SAMPLE1 to diskettes in drive A. Make sure you have a formatted disk inserted in drive A.

    Step 8. Distributing the software

    Each diskette produced in Step 7. Obtaining software for distribution contains the files for one workstation in the LANDP workgroup.

    To distribute the software to a workstation in the workgroup, you need to take the appropriate diskette to the workstation, then copy the files to the workstation. For example, you might use the following commands:

      MD C:\EHC
      XCOPY A:*.* C:\EHC
    

    When the LANDP software is installed, and the necessary changes have been made to the CONFIG.SYS file, you can run LANDP using the AUTOFBSS command.


    Appendix B. User servers




    ehcodwl

    User servers are part of the common data, and thus have to be located and specified in the COMMON.SPC file. Two examples of different user server specifications are provided at the end of all the vector descriptions.

    User server vectors - descriptions

    This section provides information about each user server vector.

    DEFSERV vector

    Defines a user server and its corresponding characteristics. Define one DEFSERV vector for each server you are going to develop and use.

    A quick reference


    Vector Position None
    List of keywords

    NAME, TYPE, SCOPE, DESCRIP, OBJECT, OBJPAR, SUBDIR, LOADER, LOADPAR, PRIORITY, EXPMEM, INSTANCE, LANUNIQ, ALLCLI, FIRSTLVL, LASTLVL

    Vector relates to Second level vectors PREVLOAD, POSTLOAD, DEVICE, SVRREQS, and DISTRIB
    Vector format DEFSERV NAME=xxxxxxxx,
    [TYPE=xxxxxx,]
    [SCOPE=xxxxxx,]
    [DESCRIP=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,]
    [OBJECT=xxxxxxxx.yyy,]
    [OBJPAR='   ',]
    [SUBDIR=xxxxxxxx,,]
    [LOADER=xxxxxx,,]
    [LOADPAR='   ',]
    [PRIORITY=x,]
    [EXPMEM=x,]
    [INSTANCE=1|N,]
    [LANUNIQ=Y|N,]
    [ALLCLI=Y|N,]
    [FIRSTLVL=F31|F11|L10|L20|L30|L40|L50|L60]
    [LASTLVL=F31|F11|L10|L20|L30|L40|L50|L60]

    NAME, TYPE, and SCOPE define the user server.

    OBJECT and the other keywords up to and including EXPMEM specify parameters related to AUTOFBSS.BAT and AUTOFBSS.CMD.

    Keyword
    Description

    NAME
    Is a required keyword to specify the name of the user server.

    The parameter value is a string of up to eight alphanumeric characters, starting with an alphabetical character. It must be unique among the server names.

    TYPE
    Is an optional keyword to specify the operating system of the workstation where the user server will be installed.

    The parameter value can be:

    DOS
    For the DOS operating system
    OS/2
    For the OS/2 operating system
    NT
    For the Microsoft Windows operating system
    LINUX
    For the Linux operating system

    The default is DOS.

    SCOPE
    Is an optional keyword to define the scope of the user server.

    The parameter value can be:

    LOCAL
    The server can have only local clients
    REMOTE
    The server can have only remote clients
    BOTH
    The server can have both local and remote clients

    The default is BOTH.

    DESCRIP
    Is an optional keyword to provide a description of the user server.

    The parameter value is a string of up to 40 characters. It must be enclosed within quotes.

    OBJECT
    Is an optional keyword to specify the name and extension of the user server executable module.

    For DOS, OS/2, and Windows servers, the parameter has the following format:

      xxxxxxxx.yyy
    

    The name must be the name of the server, which you specified in the NAME keyword, and the extension can be:

    EXE
    COM
    BAT
    CMD

    The default is the server name specified in the NAME keyword, and the EXE extension.

    For Linux servers, the parameter does not include a file extension. The name must be the name of the server that you specified in the NAME keyword.

    OBJPAR
    Is an optional keyword to specify the user server parameters. These parameters will be added after the server name in the corresponding statement of the AUTOFBSS file.

    The parameter value is a string of up to 40 characters, and the contents will appear in the loading statement in the same format as specified. It must be enclosed between quotes.

    If &WSID  appears in the string, it will be converted to workstation identification.

    SUBDIR
    Is an optional keyword to specify the directory where the object module is located. The directory must be located at the same level as the EHCCUS directory.

    The parameter value is a string of up to eight characters. The defaults are:

    EHCD000
    For DOS type servers
    EHCO000
    For OS/2 type servers (16 or 32 bits)
    EHCN000
    For Windows type servers (32 bits)
    EHCL000
    For Linux type servers

    If you specify EHCD, EHCO, EHCN, or EHCL for DOS type servers, OS/2 type servers, Windows type servers, or Linux type servers respectively, the customization program converts the values to those corresponding to the current release; for example, to the EHCD600 or EHCO600 values, if you are running LANDP for DOS or LANDP for OS/2.

    It is not recommended that you specify these values or use these directories; instead, you should locate the user servers in a separate directory. Thus, the path of the user servers does not depend on the product release.

    LOADER
    Is an optional keyword to specify the loading program that will be used to load the user server.

    The parameter value can be:

    NO (no loading statement is generated in the AUTOFBSS file)
    LOADER (adds a statement to the AUTOFBSS file to invoke a server through the LANDP loader)
    DETACH
    START
    LSI
    CALL

    The default is LOADER.

    For Windows servers, the only parameter values supported are LOADER and NO. LOADER defaults to starting the server as a Windows service.

    For Linux servers, the only parameter values supported are LOADER, NO, and START. START results in a statement being added to autofbss to start the server in a detached command shell. This will result in a statement of the form 'servername params&'.

    For DOS servers, the parameter value LOADER will be changed to LOADERE, if overridden with other specifications.

    LOADPAR
    Is an optional keyword to specify the parameters for the loading program. This parameter will be added to the loading statement in the AUTOFBSS file, after the name of the loading program.

    The parameter value is a string of up to 40 characters. It must be enclosed between quotes.

    PRIORITY
    Is an optional keyword to specify the order in which the loading statements will appear in the AUTOFBSS file.

    The parameter value ranges from 1 to 9. The value 1 involves the highest priority; the value 9 involves the lowest priority. The default is 3.

    All the loading statements with the same priority will be generated before the loading statements with lower priority. For example, all the statements with priority 1 will be processed before any statement with priority 2 is processed.

    EXPMEM
    Is an optional keyword to specify whether the user server can be loaded into expanded memory. The parameter applies only to DOS type servers.

    The parameter value can be Y or N. The default is N.

    INSTANCE
    Is an optional keyword to specify whether the user server should be loaded once or once for every session made with the server. The value can be either 1 or N. The value must be 1 for a server loaded as a Windows service. The default is 1.

    LANUNIQ
    Is an optional keyword to specify that only one workstation in the workgroup can have this server. The value can be either Y or N. The default is N.

    ALLCLI
    Is an optional keyword to specify that every workstation in the workgroup is automatically a client of this server. The value can be either Y or N. The default is N. If you specify Y, you must also specify LANUNIQ=Y.

    FIRSTLVL
    Is an optional keyword that specifies the first level of LANDP that can run the user server.

    The parameter value can be:

    F31
    FBSS Version 3.1
    F11
    FBSS/2 Version 1.1
    L10
    LANDP Version 1.0
    L20
    LANDP Version 2.0
    L30
    LANDP Version 3.0
    L40
    LANDP Version 4.0
    L50
    LANDP Version 5.0
    L60
    LANDP Version 6.0

    The default is F11. If you omit the FIRSTLVL keyword, all levels of LANDP can run the server (unless qualified by the value specified in LASTLVL).

    LASTLVL
    Is an optional keyword that specifies the last level of LANDP that can run the user server.

    The parameter value can be:

    F31
    FBSS Version 3.1
    F11
    FBSS/2 Version 1.1
    L10
    LANDP Version 1.0
    L20
    LANDP Version 2.0
    L30
    LANDP Version 3.0
    L40
    LANDP Version 4.0
    L50
    LANDP Version 5.0
    L60
    LANDP Version 6.0

    The default is L60. If you omit the LASTLVL keyword, all levels of LANDP can run the server (unless qualified by the value specified in FIRSTLVL).

    DEVICE vector

    Defines a statement to be added to the CONFIG.SYS or CONFIG.ADD file, when the user server is selected for the corresponding workstation.

    Define one DEVICE vector for each statement required by the server. The statements will be added in the order you define them.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords UNIQUEID, TEXT
    Vector relates to None
    Vector format DEVICE [UNIQUEID=xxxxxxxx,]
    TEXT='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

    Keyword
    Description

    UNIQUEID
    Is an optional keyword to define an identifier that will be used to avoid duplications in the CONFIG.SYS or CONFIG.ADD file, when more than one server requires the same statement. A unique identifier must be assigned to equal statements in different DEVICE vectors, no matter for which server you are defining the statement.

    The parameter value is a string of up to eight alphanumeric characters.

    TEXT
    Is a required keyword to define a complete CONFIG.SYS or CONFIG.ADD statement, which will be generated for the workstations with the server.

    The parameter value is a string of up to 64 alphanumeric characters, and must be enclosed between quotes.

    DISTRIB vector

    Specifies a file to be copied to the workstation where the user server is loaded.

    Define one DISTRIB vector for each file to be copied. Server executable files and device drivers do not require DISTRIB vectors.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords FILENAME, SUBDIR, UNIQUEID, NEWNAME
    Vector relates to LANCONF vector (LANGUAGE keyword)
    Vector format DISTRIB [FILENAME=xxxxxxxx.yyy,]
    [SUBDIR=xxxxxxxx,]
    [UNIQUEID=xxxxxxxx,]
    [NEWNAME=xxxxxxxx.yyy]

    Keyword
    Description

    FILENAME
    Is an optional keyword to define the filename and the extension of the file to be copied.

    The parameter has the following format:

      xxxxxxxx.yyy
    

    If the alphanumeric field contains the &NLS string, this string will be replaced by the parameter value assigned in the LANGUAGE keyword of the LANCONF value. You can specify &NLS as the extension, because once it is replaced by the language identifier, it will become a three-character string.

    When the target workstation is of type Linux, this parameter can have the format:

      xxxxxxxx
    

    SUBDIR
    Is an optional keyword to specify the directory where the file is located in the customization workstation. The directory must be located at the same level as the EHCCUS directory.

    The parameter value is a string of up to eight characters. The defaults are:

    EHCD000
    For DOS type servers
    EHCO000
    For OS/2 type servers (16 or 32 bits)
    EHCN000
    For Windows type servers (32 bits)
    EHCL000
    For Linux type servers

    UNIQUEID
    Is an optional keyword to define an identifier that will be used to avoid duplications in the GETTING.SPC file, when more than one server requires the same file. A unique identifier must be assigned to equal files in different DISTRIB vectors, no matter for which server you are specifying the file.

    The parameter value is a string of up to eight alphanumeric characters.

    NEWNAME
    Is an optional keyword to define the filename and the extension of the file, once copied to the target path.

    The parameter has the following format:

      xxxxxxxx.yyy
    

    When the target workstation is of type Linux, the file name and extension can be lower-case. The parameter can have the format:

      xxxxxxxx
    

    PARPORT vector

    Specifies the parallel ports used by the user server. You can specify up to three ports.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords PORT1, PORT2, PORT3
    Vector relates to None
    Vector format PARPORT PORT1=xxxx,
    [PORT2=xxxx,]
    [PORT3=xxxx]

    Keyword
    Description

    PORT1
    Is a required keyword to specify the first LPTx used by the server.

    The parameter value can be:

    LPT1
    LPT2
    LPT3

    PORT2
    Is an optional keyword to specify the second LPTx used by the server. It cannot be used, if the PORT1 keyword is not specified.

    The parameter value can be:

    LPT1
    LPT2
    LPT3

    It cannot be the same as the value specified in the PORT1 keyword.

    PORT3
    Is an optional keyword to specify the third LPTx used by the server. It cannot be used, if the PORT1 and PORT2 keywords are not specified.

    The parameter value can be:

    LPT1
    LPT2
    LPT3

    It cannot be the same as the value specified in the PORT1 or PORT2 keywords.

    POSTLOAD vector

    Defines statements that will be generated in the AUTOFBSS file, following the user server loading statement.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords UNIQUEID, CONDID, TEXT
    Vector relates to None
    Vector format POSTLOAD [UNIQUEID=xxxxxxxx,]
    [CONDID=xxxxxxxx,]
    TEXT='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

    Keyword
    Description

    UNIQUEID
    Is an optional keyword to define an identifier that will be used to avoid duplications in the AUTOFBSS file, when more than one server requires the same statement. A unique identifier must be assigned to equal statements in different POSTLOAD vectors, no matter for which server you are defining the statement.

    The parameter value is a string of up to eight alphanumeric characters.

    CONDID
    Is an optional keyword to specify the identifier (UNIQUEID) of a condition to process this vector. If the vector where the UNIQUEID has been specified is included in the AUTOFBSS.xxx file, this vector will also be included.

    The parameter value is a string of up to eight alphanumeric characters, and must match a UNIQUEID keyword in another specified vector.

    TEXT
    Is a required keyword to define statements that are generated into the AUTOFBSS file following the server loading statements.

    The parameter value is a string of up to 64 alphanumeric characters, and must be enclosed between quotes.

    PREVLOAD vector

    Defines statements that will be generated in the AUTOFBSS file, before the user server loading statement.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords UNIQUEID, CONDID, TEXT
    Vector relates to None
    Vector format PREVLOAD [UNIQUEID=xxxxxxxx,]
    [CONDID=xxxxxxxx,]
    TEXT='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

    Keyword
    Description

    UNIQUEID
    Is an optional keyword to define an identifier that will be used to avoid duplications in the AUTOFBSS file, when more than one server requires the same statement. A unique identifier must be assigned to equal statements in different PREVLOAD vectors, no matter for which server you are defining the statement.

    The parameter value is a string of up to eight alphanumeric characters.

    CONDID
    Is an optional keyword to specify the identifier (UNIQUEID) of a condition to process this vector. If the vector where the UNIQUEID has been specified is included in the AUTOFBSS.xxx file, this vector will also be included.

    The parameter value is a string of up to eight alphanumeric characters, and must match a UNIQUEID keyword in another specified vector.

    TEXT
    Is a required keyword to define statements that are generated into the AUTOFBSS file following the server loading statements.

    The parameter value is a string of up to 64 alphanumeric characters, and must be enclosed between quotes.

    SVRREQS vector

    Specifies LANDP prerequisite server for the user server.

    Define one SVRREQS vector for each prerequisite to be specified.

    A quick reference


    Vector Position Follows DEFSERV vector, or any of its second level vectors
    List of keywords COND, TYPE, SVRNAME
    Vector relates to None
    Vector format SVRREQS [COND=x,]
    [TYPE=x,]
    SVRNAME=xxxxxxxx

    Keyword
    Description

    COND
    Is an optional keyword to define the condition of the requirement.

    The parameter value can be:

    S
    The user server is specified in a SERVER keyword
    C
    The user server is specified in a CLIENT keyword

    The default is S.

    TYPE
    Is an optional keyword to define the type of the requirement.

    The parameter value can be:

    S
    The workstation provides services of the required server
    C
    The required server is specified as a client in the same workstation

    The default is C.

    SVRNAME
    Is a required keyword to specify the name of the server.

    The parameter value is a string of up to eight alphanumeric characters.


    User server examples

    /* Vector DEFSERV  USERSVR1 server definition */
           DEFSERV  NAME=USERSVR1,
                    OBJECT=USERSVR1.EXE,
                    OBJPAR='/TBL /&WSID',
                    LOADPAR='/w:e /&:e',
                    EXPMEM=Y
     
           DEVICE   UNIQUEID=ID1,
                    TEXT='DEVICE=DRIVER1.SYS /a /b /c'
     
           DEVICE   UNIQUEID=ID2,
                    TEXT='DEVICE=DRIVER2.SYS /a /b /c'
     
           DISTRIB  FILENAME=PGM.EXE,
                    UNIQUEID=ID3,
                    NEWNAME=USERPGM.EXE
     
           DISTRIB  FILENAME=FILE002.&NLS,
                    UNIQUEID=ID4,
                    NEWNAME=FILE.MSG
     
           PARPORT PORT1=LPT1
     
           POSTLOAD UNIQUEID=ID5,
                    TEXT='echo on Server loaded successfully'
     
           PREVLOAD UNIQUEID=ID6,
                    TEXT='USERPGM.EXE /1'
     
            SVRREQS  SVRNAME=SNA##
     
    /* Vector DEFSERV. USERSVR2 server definition */
           DEFSERV  NAME=USERSVR2,
                    PRIORITY=4,
                    OBJECT=USERSVR2.EXE,
                    OBJPAR=('/123'),
                    LOADPAR='/&:e'
     
           DEVICE   UNIQUEID=ID1,
                    TEXT='DEVICE=DRIVER1.SYS /a /b /c'
     
           POSTLOAD TEXT='echo on Server loaded successfully'
     
     
           PREVLOAD UNIQUEID=ID7,
                    CONDID=ID1,
                    TEXT='Pause Please, check the printer'
     
           PREVLOAD UNIQUEID=ID8,
                    CONDID=ID9,
                    TEXT='Pause Please, Power off the printer'
    

    For the example server definitions, the CONFIG.SYS file contains the following statements:

            DEVICE=DRIVER1.SYS /a /b /c
            DEVICE=DRIVER2.SYS /a /b /c
    

    For the example server definitions, the AUTOFBSS.BAT file contains the following statements (assuming ws = AA)

            Pause Please check the printer
            LOADER /&:e USERSVR2.EXE /123
            echo on Server loaded successfully
            USERPGM.EXE /1
            LOADERE /w:e /&:e USERSVR1.EXE /TBL /AA
            echo on Server loaded successfully
    

    In addition, the file FILE.MSG will be in the distribution diskette.


    Appendix C. Editing common data




    ehcodwl

    This appendix provides information about data that is common for all or for several workstations or workgroups. This is called common data, and is specified and stored in vector format in the COMMON.SPC file, located in the EHCCUS directory.

    Common vectors contain defaults, tables, record definitions, and profiles. They also contain definitions for user servers.

    Data for user servers is stored and processed together with other common data in the COMMON.SPC file. For information on how to define user servers, refer to Appendix B, User servers.

    For information on how to store customization data in specification files, refer to Customization data structure, especially if you plan to use embedded files (see page "Embedded specification files") or partial files (see page "Partial specification files").


    Creating and editing common vectors

    Before you start creating and editing common vectors, consider the following:

    1. The customization program provides two alternative procedures to prepare and process specification files.

      The EDITSPC program is used to edit specification files.

      You can apply this procedure to the COMMON.SPC file, and display and modify the common vectors.

      If you want to display online information about this procedure, from the EHCCUS directory, enter:

        EDITSPC ?
      

      To start the procedure, from the EHCCUS directory, enter:

        EDITSPC COMMON
      

      If you use the OS/2 Enhanced Editor with the LANDP customization editing tool, the LANDP choice is listed in the action bar of the editor window. For information about that tool, select the View doc option in the pull-down that appears when you choose LANDP.

      The EDITSPC program is included here only for compatibility with previous LANDP releases. The same function can be achieved by using the new graphical Customization Editor which, in addition to being easier to use, also provides improved functionality.

      The graphical Customization Editor allows you to edit specification files. See Graphical Customization Editor for more information.

      The graphical Customization editor can also be used to invoke the CREATE and GENSPEC procedures that are described in the following paragraphs.

      Note:
      For all the vectors that have default values, you can specify only the required values in the COMMON.SPC file, and after the VALSPEC and GENSPEC procedures have been performed, the default values will be created by the program.
    2. The customization program provides a procedure to create default common data, if it does not exist.

      The default common data is created in the internal repository. If the COMMON.SPC file already exists, the procedure also processes that file.

      To start the procedure, from the EHCCUS directory, enter:

        CREATE
      
    3. The customization program provides a procedure to generate common vectors from the common data in the internal repository.

      The common vectors are generated in the COMMON.SPC file, located in the EHCCUS directory. The order in which the vectors appear in the file is not relevant.

      To start the procedure, from the EHCCUS directory, enter:

        GENSPEC COMMON
      

      For further information on that procedure, refer to Generating data.


    Common vectors - an overview

    Common vectors contain the following information.

    User servers are part of common data. They must be created and processed in the COMMON.SPC file. If you want to define and add your own user servers, refer to Appendix B, User servers.

    Vector Name Defines: Is valid for: Go to page:
    BPPPARM Optional identifications for printer device parameters Banking printer program server "BPPPARM vector"
    COLSQTBL Alternate Collating Sequence Table Shared-file server "COLSQTBL vector"
    DEFAULTS Hotkeys and session identifications 3270 emulator, 3287 Printer Emulator, Banking Printer Program "DEFAULTS vector"
    DISPLATT Display attribute tables 3270 Emulator, Banking Interactive Workstation Program "DISPLATT vector"
    EJOUPRF Electronic journal profile Electronic journal server "EJOUPRF vector"
    EJOUREC Record names to be used as electronic journal records Electronic journal server "EJOUREC vector"
    FORM4710 4710 printer device parameters (document and journal formats) Banking printer program server "FORM4710 vector"
    FORM4720 4720 printer device parameters (document, journal, passbook, and REMS formats) Banking printer program server "FORM4720 vector"
    FORM47X2 Financial printer device parameters (document, journal, passbook, and REMS formats) Financial printer server "FORM47X2 vector"
    FORM4748 4748 printer device parameters (document and passbook formats) 4748 printer server "FORM4748 vector"
    FORM4770 4770 printer device parameters (document and journal formats) 4770 printer server "FORM4770 vector"
    FORWDS Forwarding data set inside a forwarding profile Forwarding server "FORWDS vector"
    FORWPRF Forwarding profile Forwarding server "FORWPRF vector"
    KBD3270 Keyboard table definitions 3270 Emulator "KBD3270 vector"
    KBD3270X Extended keyboard table definitions 3270 Emulator "KBD3270X vector"
    KBDBIWP Keyboard table definitions Banking Interactive Workstation Program "KBDBIWP vector"
    KSCCBIWP Scan code translation table Banking Interactive Workstation Program "KSCCBIWP vector"
    KSTRBIWP Key stroke translation table Banking Interactive Workstation Program "KSTRBIWP vector"
    LUPOOL LUs and LU logical groups SNA server and functional areas that use SNA services "LUPOOL vector"
    MSRINTBL MSR/E input conversion table Banking Interactive Workstation Program for MSR/E server "MSRINTBL vector"
    MSROUTBL MSR/E output conversion table Banking Interactive Workstation Program for MSR/E server "MSROUTBL vector"
    P3287ATT Time-out and common parameters 3287 printer emulator "P3287ATT vector"
    PINPTBL PIN pad conversion table Banking Interactive Workstation Program for PIN pad server "PINPTBL vector"
    RCMSLNF RCMS logical names file RCMS server "RCMSLNF vector"
    RECDEF Record definitions Electronic journal server, Store-for-forwarding server, Shared-file server, System manager server "RECDEF vector"
    RECFIELD Field definitions inside a record definition Electronic journal server, Store-for-forwarding server, Shared-file server, System manager server "RECFIELD vector"
    SFORWPRF Store-for-forwarding profile Store-for-forwarding server "SFORWPRF vector"
    SFORWREC Record names to be used as store-for-forwarding records Store-for-forwarding server "SFORWREC vector"
    SHFLDBD Shared-file database description (DBD) inside a shared-file profile Shared-file server "SHFLDBD vector"
    SHFLPCB Program control block (PCB) to access the previously defined DBDs Shared-file server "SHFLPCB vector"
    SHFLSGM Segmented keys Shared-file server "SHFLSGM vector"
    SMGRPRF System manager profile System manager server "SMGRPRF vector"
    SMGRUSER System manager user profile System manager server "SMGRUSER vector"
    SOFTPACK Non-LANDP files to be distributed with the GETTING utility Not applicable "SOFTPACK vector"
    XLAT2TBL ASCII/EBCDIC and EBCDIC to ASCII translation tables Applications using XLATE "XLAT2TBL vector"
    XLATETBL Translation tables 3270 emulator, 3287 printer emulator, Banking Interactive Workstation Program, Remote Change Management Services, Forwarding server "XLATETBL vector"
    X25DIR X.25 directory tables SNA server "X25DIR vector"

    Common vectors - descriptions

    This section provides information about each common vector, including examples.

    The products for which the vectors apply are shown in boxes at the beginning of each vector description. These include PC/Integrator and PC Integrator/2 where FBSS data is involved.

    BPPPARM vector

    Defines DEVPARM defaults used by the banker printing program.

    This vector is optional. If it is not specified, a default vector will be created. It can only be specified once.

    For examples of default (DUMMY*) FORM4710, FORM4720, and FORM47X2 vectors, see the respective vector sections.

    A quick reference


    Vector position None
    List of keywords PAR4710, PAR4720, PAR4712, PAR4722, CHSTRID
    Keywords relate to
    Keyword
    Relates to keywords
    PAR4710
    NAME (FORM4710 vector)
    PAR4720
    NAME (FORM4720 vector)
    PAR4712
    NAME (FORM47X2 vector)
    PAR4722
    NAME (FORM47X2 vector)
    CHSTRID
    EXTEN (XLATETBL vector)

    Vector format BPPPARM [PAR4710=xxxxxxxx,]
    [PAR4720=xxxxxxxx,]
    [PAR4712=xxxxxxxx,]
    [PAR4722=xxxxxxxx,]
    [CHSTRID=(   ),]
    [CHSTRID=(   )]

    Keyword
    Description

    PAR4710
    Is an optional keyword to define the identification for the default DEVPARM when emulating the IBM 4710 Receipt/Validation Printer.

    The parameter value is string of up to eight alphanumeric characters. The default is DUMMYDOC.

    PAR4720
    Is an optional keyword to define the identification for the default DEVPARM when emulating the IBM 4720 Forms/Passbook Printer.

    The parameter value is a string of up to eight alphanumeric characters. The default is DUMMYDOC.

    PAR4712
    Is an optional keyword to define the identification for the default DEVPARM when using the financial printer.

    The parameter value is a string of up to eight alphanumeric characters. The default is DUMMYJOU.

    PAR4722
    Is an optional keyword to define the identification for the default DEVPARM when using the financial printer.

    The parameter value is a string of up to eight alphanumeric characters. The default is DUMMYDOC.

    CHSTRID
    Is an optional keyword to associate the EBCDIC to ASCII translation tables used by the BPP with the 1-byte value that is used in the 4700 application to change translation tables.

    You can specify one keyword for each character string table you want to define.

    The keyword has two parameters:

    1. The first parameter is the identification of the EBCDIC to ASCII table, and must match the keyword EXTEN of the XLATETBL vector (TYPE=EA47X2).
    2. The second parameter specifies the 1-byte value that is used to change translation tables via the 4700 DEVPARM instructions with flag byte 20. It must be unique for this vector.

    BPPPARM vector example

    /* Vector BPPPARM  Default Example */
     
             BPPPARM  PAR4710=DUMMYDOC,
                      PAR4720=DUMMYDOC,
                      PAR4712=DUMMYJOU,
                      PAR4722=DUMMYDOC,
                      CHSTRID=(017,11)
    

    COLSQTBL vector

    Defines an alternate collating sequence table for the shared-file server.

    Define one COLSQTBL vector for each alternate collating sequence table you want to use in your workgroups. If this vector is not specified, a default vector will be created.

    A quick reference


    Vector position None
    List of keywords NAME, SUBEXT, DATA0X to DATAFX
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    SHFLPRF (SHFLDBD vector)

    Vector format COLSQTBL NAME=xxxxxxxx,
    [SUBEXT=x,]
    DATA0X=(   ),
    DATA1X=(   ),
    :
    DATAFX=(   )

    Keyword
    Description

    NAME
    Is a required keyword to define the name of the alternate collating sequence table. It must match the name of the shared-file profile (set of SHFLDBDs) that will use this table. This name is defined in the SHFLPRF keyword of the SHFLDBD vector.

    The parameter value is a string of up to eight characters, which must adhere to DOS specifications for file names. It must be unique among all COLSQTBL vectors.

    SUBEXT
    Is an optional keyword to specify the third character of the extension of the alternate collating sequence table. It must match the value specified in the third parameter of the key definitions (keywords KEYxx) of the shared-file profile (set of SHFLDBDs) that will use this table.

    The parameter value can be any hexadecimal character, except for 0. The default is Q.

    The extension becomes SEx, where x is the specified value. Thus, the default extension is SEQ.

    When working under OS/2, only the alternate collating sequence table with extension SEQ can be substituted by the Default Country Collating Table.

    DATA0X to DATAFX
    Are required keywords to define the table contents. The parameter value is a string of 16 parameters, each one with 1-byte values from '00' to 'FF'.

    DATA0X must contain the alternate collating sequence characters corresponding to ASCII characters '00' to '0F', DATA1X to ASCII '10' to '1F', and so on.

    COLSQTBL vector example

     /* Vector COLSQTBL  Default Example */
     
      COLSQTBL NAME=CONFIGUR,
               SUBEXT=1,
               DATA0X=(00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F),
               DATA1X=(10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F),
               DATA2X=(20,21,22,23,24,25,26,27,28,29,2A,2B,2C,2D,2E,2F),
               DATA3X=(30,31,32,33,34,35,36,37,38,39,3A,3B,3C,3D,3E,3F),
               DATA4X=(40,41,42,43,44,45,46,47,48,49,4A,4B,4C,4D,4E,4F),
               DATA5X=(50,51,52,53,54,55,56,57,58,59,5A,5B,5C,5D,5E,5F),
               DATA6X=(60,61,62,63,64,65,66,67,68,69,6A,6B,6C,6D,6E,6F),
               DATA7X=(70,71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F),
               DATA8X=(80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F),
               DATA9X=(90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F),
               DATAAX=(A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF),
               DATABX=(B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF),
               DATACX=(C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF),
               DATADX=(D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF),
               DATAEX=(E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF),
               DATAFX=(F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF)
    

    DEFAULTS vector

    Defines required parameters for the supervisor and emulators.

    Define as many DEFAULTS vectors as are required in your installation. If this vector is omitted, a default vector will be created.

    The DEFAULTS vectors will be referenced on workgroup level in the keyword DEFAULTS of the LANMODEL or LANCONF vectors.

    The parameters that you define in the DEFAULTS vector are:

    A quick reference


    Vector position None
    List of keywords NAME, DEBUGHK, OPERHK, SMOPHK, TMR0SCC, TMR0ASC, TIMEOUT, E3270HK1 to E3270HK5, E3287SI1 to E3287SI5, BPPSI1 to BPPSI4, DBCSCTRY, DBCSPATH, PROCNAME
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    DEFAULTS
     
    (LANCONF and LANMODEL vectors)
    E3270HKx
    SES&3270 (parameter 8)
    BPPSIx
    SES&BPP (parameter 7)
    E3287SIx
    SES&3287 (parameter 9)

    Vector format DEFAULTS [NAME=xxxxxxxx,]
    [DEBUGHK=xx,]
    [OPERHK=xx,]
    [SMOPHK=xx,]
    [TMR0SCC=xx,]
    [TMR0ASC=xx,]
    [TIMEOUT=xxxx,]
    [E3270HK1=(   ),]
    [E3270HK2=(   ),]
    [E3270HK3=(   ),]
    [E3270HK4=(   ),]
    [E3270HK5=(   ),]
    [E3287SI1=xxxxxxxx,]
    [E3287SI2=xxxxxxxx,]
    [E3287SI3=xxxxxxxx,]
    [E3287SI4=xxxxxxxx,]
    [E3287SI5=xxxxxxxx,]
    [BPPSI1=xxxxxxxx,]
    [BPPSI2=xxxxxxxx,]
    [BPPSI3=xxxxxxxx,]
    [BPPSI4=xxxxxxxx,]
    [DBCSCTRY=(   ),]
    [DBCSPATH=path,]
    [PROCNAME=xxxxxxxx]

    Keyword
    Description

    NAME
    Is an optional keyword to define the name of the set of defaults.

    The parameter value is a field with up to eight alphanumeric characters, and must be unique among the DEFAULTS vectors defined. The default is GENERAL.

    DEBUGHK
    LANDP for DOS: Is an optional keyword to define the scan code for the hotkey that, when pressed with the Alt key, activates the trace and debug tool.

    The parameter value is a 1-byte field. The default is 45 (NumLock).

    OPERHK
    LANDP for DOS: Is an optional keyword to define the scan code for the hotkey that, when pressed with the Alt key, activates the operator interface.

    The parameter value is a 1-byte field. The default is 44 (F10).

    SMOPHK
    LANDP for DOS: Is an optional keyword to define the scan code for the hotkey that, when pressed with the Alt key, activates the system manager operator.

    The parameter value is a 1-byte field. The default is 3E (F4).

    TMR0SCC
    LANDP for DOS: Is an optional keyword to define the scan code sent to the application when timer 0 (keyboard time-out), elapses.

    LANDP for OS/2: The keyword can be set to any extended ASCII character.

    LANDP for Windows: The keyword can be set to the extended ASCII characters Alt F1-F10 and Ctrl F1-F10.

    The parameter value is a 1-byte field. The default is 01 (Esc), which is returned when timer 0 elapses if TMR0SCC is not coded or is set to a value other than those specified above.

    TMR0ASC
    Is an optional keyword to define the ASCII code sent to the application when timer 0 (keyboard time-out), elapses.

    The parameter value is a 1-byte field. The default is 1B (Esc).

    TIMEOUT
    Is an optional keyword to define the time (in seconds) after which the supervisor returns a time-out return code when a LAN call has not been answered.

    The parameter value is a field with up to four digits, and can range from 1 to 3600. The default is 30 seconds.

    E3270HK1 to E3270HK5
    DOS, OS/2 VDM, Windows NT VDM: Are optional keywords to define the scan codes for the keys that, when pressed with the Alt key, activate the corresponding 3270 emulator program. It also defines its host/application identification.

    A maximum of five 3270 emulator programs can be installed in one workstation.

    Each keyword has two parameters in the format (xx,yyyyyyyy), where:

    xx
    Are two hexadecimal digits for the scan code used

    yyyyyyyy
    Are up to eight alphanumeric digits for the host/application identification.

    By default, the host/application identification is blank.

    The defaults for the respective scan codes (examples, page ***) are:

    E3270HK1
    3F (F5)
    E3270HK2
    40 (F6)
    E3270HK3
    41 (F7)
    E3270HK4
    42 (F8)
    E3270HK5
    43 (F9)
    Multiple Emulators

    The hotkeys can be defined so that the workstation operator activates the next successive emulator as the previous one is ended. This is referred to as chaining emulators.To chain four emulators so that the next emulator is activated when the preceding emulator is ended, ensure that the hotkey to enter an emulator is the same as at least one of the the hotkeys used to exit the emulator. Exit hotkeys are defined in the KBD3270 vector.

    Table 7. Chained Emulators: Example 1

    Emulator Entry Hotkey Exit Hotkeys
    1 ALT+F2 Alt+F2, Alt+F10
    2 ALT+F2 Alt+F2, Alt+F10
    3 ALT+F2 Alt+F2, Alt+F10
    4 ALT+F2 Alt+F2, Alt+F10

    The first time ALT+F2 is pressed, Emulator 1 is activated:

    • If ALT+F2 is pressed again, Emulator 2 is activated
    • If ALT+F2 is pressed again, Emulator 3 is activated
    • If ALT+F2 is pressed again, Emulator 4 is activated
    • If ALT+F2 is pressed again, Emulator 1 is activated

    Pressing ALT+F10 exits the emulation mode.

    Notice that if ALT+F2 is pressed when the workstation is not in emulation mode, Emulator 1 is always activated. Using this configuration, it is not possible to directly activate any emulator other than Emulator 1 when the workstation is not in emulation mode.

    To be able to activate a specific emulator, define a unique entry hotkey for each emulator.

    Table 8. Chained Emulators: Example 2

    Emulator Entry Hotkey Exit Hotkeys
    1 ALT+F2 Alt+F3, Alt+F4, Alt+F5, Alt+F10
    2 ALT+F3 Alt+F2, Alt+F4, Alt+F5, Alt+F10
    3 ALT+F4 Alt+F2, Alt+F3, Alt+F5, Alt+F10
    4 ALT+F5 Alt+F2, Alt+F3, Alt+F4, Alt+F10

    Whether the workstation is in emulation mode or not:

    • If ALT+F2 is pressed, Emulator 1 is activated
    • If ALT+F3 is pressed, Emulator 2 is activated
    • If ALT+F4 is pressed, Emulator 3 is activated
    • If ALT+F5 is pressed, Emulator 4 is activated

    Pressing ALT+F10 exits the emulation mode.

    The scan codes for the E3270HK1-E3270HK5 keywords must be those returned by INT15H. The values for the keys can be found in Technical Reference for your workstation. Examples of correct values for the keywords are:
    3B (F1) 44 (F10)
    3C (F2) 57 (F11)
    3D (F3) 58 (F12)
    3E (F4) 01 (Esc)

    E3287SI1 to E3287SI5
    DOS, OS/2 VDM, Windows NT VDM: Are optional keywords to define the host/application identification for 3287 printer emulator sessions.

    A maximum of five 3287 printer emulator sessions can be installed in one workstation. Define the sessions you need in any order.

    The parameter value is a field of up to eight alphanumeric characters. By default, all five host/application identifications are blank.

    BPPSI1 to BPPSI4
    PC/Integrator and PC Integrator/2: Is an optional keyword to define the host/application identification for banking printer program ports 1 to 4.

    A maximum of four banking printer programs can be installed in one workstation for LANDP for DOS, three for LANDP for OS/2, and one for LANDP for Windows (supported in the DOS-box). Define the sessions you need in any order.

    The parameter value is a field of up to eight alphanumeric characters. By default, all four programs are blank.

    DBCSCTRY
    Is an optional keyword to specify the identifier of the language to be used when working in DBCS mode. You can also specify that DBCS support is not used.

    The parameter value can be:

    082
    Korea (not supported on LANDP for Windows or LANDP for Linux)
    086
    People's Republic of China
    088
    Taiwan
    NO
    DBCS support not used

    The default is NO.

    The keyword has two parameters in the format (xxx,yyyy), where:

    xxx
    Is the identifier of the language to be used.

    yyyy
    Is the number of the code page to be used for that country.

    If Korea (082) is specified, a second subparameter must also be specified designating the code page used in the LANDP workgroup. The supported code page is 949.

    If People's Republic of China (086) is specified, a second subparameter must also be specified designating the code page used in the LANDP workgroup. The supported code pages are 1381 and 1386. For Linux workstations, for Linux codeset GBK, you should specify 1386.

    If Taiwan (088) is specified, a second subparameter must also be specified. In this case, the supported code pages are 938 and 950. For example to specify Taiwan as the DBCSCTRY using code page 950, you would specify:

      DBCSCTRY=(088,950)
    

    For Linux workstations, for Linux codeset BIG5, you should specify 950.

    Additionally, for People's Republic of China (086), a third subparameter may be specified designating the code page of the host computer. The supported code pages are 935 and 1388. For example, to specify PRC as the DBCSCTRY using LANDP workgroup code page 1386 and host code page 1388, you would specify

      DBCSCTRY=(086,1386,1388)
    

    DBCSPATH
    Is an optional keyword to specify the path where the TBLASC.088, TBLEBC.088, and TBLTAI.088 files are located. It applies only when working with the Taiwan DBCS code pages 938 or 950, (DBCSCTRY=(088,938)) or (DBCSCTRY=(088,950)).

    The parameter value is a string of up to 30 alphanumeric characters. The format must be:

      d:\[directory1\[directory2\[directory3\]]]
    

    A maximum of three levels is permitted for the path. The default is C:\.

    PROCNAME
    Is an optional keyword to specify the name of the procedure to start the LANDP program.

    The parameter value is a field with up to eight alphanumeric characters. The default is AUTOFBSS.

    DEFAULTS vector example

     /* Vector DEFAULTS  Default Example */
     
             DEFAULTS NAME=GENERAL,
                      DEBUGHK=45,
                      OPERHK=44,
                      SMOPHK=3E,
                      TMR0SCC=01,
                      TMR0ASC=1B,
                      TIMEOUT=30,
                      E3270HK1=(3F),
                      E3270HK2=(40),
                      E3270HK3=(41),
                      E3270HK4=(42),
                      E3270HK5=(43)
    

    DISPLATT vector

    Defines color display attribute tables for the 3270 emulator or the banking interactive workstation program. These are the colors that you want to appear on your workstation display for each field attribute. You may want to assign a different color set for each 3270 or banking interactive workstation program in a workstation.

    Specify one vector for each table you want to use in your workgroups.

    Table 9 shows the display colors that can be used.

    Table 9. Display Colors

    Color code Color
    0 Black
    1 Blue
    2 Green
    3 Cyan
    4 Red
    5 Magenta
    6 Brown
    7 Light Grey
    8 Dark Grey
    9 Light Blue
    A Light Green
    B Light Cyan
    C Light Red
    D Light Magenta
    E Yellow
    F White

    A quick reference


    Vector position None
    List of keywords TYPE, EXTEN, DEFCOLRS, BACKGRD, HIGHPROT, NORMPROT, HIGHUNPR, NORMUNPR, STATUS, BLUE, RED, PINK, GREEN, TURQUOIS, YELLOW, WHITE, HIGHDFLT, NORMDFLT
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    SES&3270 (parameter 5),
    PAR&BIWP (parameter 13)

    Vector format DISPLATT TYPE=xxxx,
    EXTEN=xxx,
    [DEFCOLRS=xxxxx,]
    [BACKGRD=x,]
    [HIGHPROT=x,]
    [NORMPROT=x,]
    [HIGHUNPR=x,]
    [NORMUNPR=x,]
    [BLUE=x,]
    [RED=x,]
    [PINK=x,]
    [GREEN=x,]
    [TURQUOIS=x,]
    [YELLOW=x,]
    [WHITE=x,]
    [HIGHDFLT=x,]
    [NORMDFLT=x,]
    [STATUS=xx]

    Keyword
    Description

    TYPE
    Is a required keyword to define the table type. The parameter values are:
    3270
    For a 3270 color display attribute table
    BIWP
    For a BIWP color display attribute table

    EXTEN
    Is a required keyword to give an identification for a 3270 or BIWP display attribute table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all DISPLATT vectors.

    DEFCOLRS
    Is an optional keyword to define the default color scheme for all the keywords that follow. The keyword applies to TYPE=3270 only. The parameter values are:

    MONO
    Use monochrome colors as the default color scheme. This is the default.

    DARK
    Use dark colors as the default color scheme. (This is the suggested color scheme for blinking text.)

    LIGHT
    Use light colors as the default color scheme. (This is the suggested color scheme for non-blinking text.)

    The attribute values for the three default color schemes are as follows:

    Keyword      DEFCOLRS=MONO      DEFCOLRS=DARK      DEFCOLRS=LIGHT
    -------      -------------      -------------      -------------
    BACKGRD      0 (Black)          0 (Black)          0 (Black)
    HIGHPROT     F (White)          7 (Light grey)     F (White)
    NORMPROT     7 (Light grey)     1 (Dark blue)      9 (Light blue)
    HIGHUNPR     F (White)          4 (Dark red)       C (Light red)
    NORMUNPR     7 (Light grey)     2 (Dark green)     A (Light green)
    STATUS       7 (Light grey)     2 (Dark green)     A (Light green)
    (background)
    STATUS       0 (Black)          0 (Black)          0 (Black)
    (foreground)
    BLUE         7 (Light grey)     1 (Dark blue)      9 (Light blue)
    RED          7 (Light grey)     4 (Dark red)       C (Light red)
    PINK         F (White)          5 (Dark magenta)   D (Light magenta)
    GREEN        7 (Light grey)     2 (Dark green)     A (Light green)
    TURQUOIS     F (White)          3 (Dark cyan)      B (Light cyan)
    YELLOW       F (White)          6 (Brown)          E (Yellow)
    WHITE        F (White)          7 (Light grey)     F (White)
    HIGHDFLT     F (White)          7 (Light grey)     F (White)
    NORMDFLT     7 (Light grey)     2 (Dark green)     A (Light green)
    
    Note:
    To maintain upward compatibility with older versions of LANDP, the default color scheme for DISPLATT is MONO, which assigns the colors white or light grey to the extended color DISPLATT keywords.

    If you have changed your BACKGRD color to white or light grey, you will receive message EHC02204 to tell you that the background and foreground colors for the attribute you have chosen should not be the same (because that data will not be visible). You can ignore this message if you do not intend to use extended color on this display.

    If you want to use extended color, you should specify DEFCOLRS=DARK or DEFCOLRS=LIGHT and then specify any variations from the default scheme that you want.

    If you do not want to use extended color, you might want to do this anyway, to suppress the messages.

    BACKGRD
    Is an optional keyword to define the background color attribute. This parameter will be common for HIGHPROT, NORMPROT, HIGHUNPR, NORMUNPR, DEFCOLRS, BLUE, RED, PINK, GREEN, TURQUOIS, YELLOW, WHITE, HIGHDFLT, and NORMDFLT fields.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    HIGHPROT
    Is an optional keyword to define the foreground color attribute for base color high intensity protected fields.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    NORMPROT
    Is an optional keyword to define the attribute for base color normal intensity protected fields.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    HIGHUNPR
    Is an optional keyword to define the attribute for base color high intensity unprotected fields.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    NORMUNPR
    Is an optional keyword to define the attribute for base color normal intensity unprotected fields.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    BLUE
    Is an optional keyword to define the attribute for extended color blue characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    RED
    Is an optional keyword to define the attribute for extended color red characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    PINK
    Is an optional keyword to define the attribute for extended color pink characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    GREEN
    Is an optional keyword to define the attribute for extended color green characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    TURQUOIS
    Is an optional keyword to define the attribute for extended color turquoise characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    YELLOW
    Is an optional keyword to define the attribute for extended color yellow characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    WHITE
    Is an optional keyword to define the attribute for extended color white characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    HIGHDFLT
    Is an optional keyword to define the attribute for extended color default high intensity characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    NORMDFLT
    Is an optional keyword to define the attribute for extended color default (normal intensity) characters and fields. The keyword applies to TYPE=3270 only.

    The parameter value is a 1-hexadecimal digit. The default is the value derived from the DEFCOLRS keyword.

    STATUS
    Is an optional keyword to define the attributes for the status symbol line.

    The parameter is a value of two digits, with the first one specifying the background, and the second one the foreground color.

    The parameter value is a 2-hexadecimal digit. The default is the values derived from the DEFCOLRS keyword.

    The keyword does not apply to DBCS mode. When working in DBCS mode, the value used by the 3270 emulator is 07, which is black foreground on a light grey background.

    DISPLATT vector example

     /* Vector DISPLATT (TYPE=3270):  Example */
     
             DISPLATT TYPE=3270,
                      EXTEN=ATR,
                      DEFCOLRS=LIGHT,
                      BLUE=3            /* Change blue to dark cyan */
    

    EJOUPRF vector

    Defines an electronic journal server profile. Define one EJOUPRF vector for each electronic journal profile you want to specify.

    This vector must be followed by as many EJOUREC vectors as different records will be used in this electronic journal profile.

    You can choose among two electronic journal server environments: physical or logical. In the physical environment, each file is accessed through a physical journal name that is assigned by the application. In the logical environment, you can have up to 99 logical journals that the application can access by name within each physical journal.

    A quick reference


    Vector position None. Is followed by at least one EJOUREC vector.
    List of keywords NAME, DATASETS, MAXNUML, SEPSESS, MAXACC, SHFLPRF, DBDPATH, DBDPATH6, SPLIT, KEY02 to KEY15
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR&EJOU (parameter 1)
    SHFLPRF
    SHFLPRF (SHFLDBD vector)
    KEYxx
    NAME (RECFIELD vector)

    Vector format EJOUPRF NAME=xxxxxxxx,
    [DATASETS=xx,]
    [MAXNUML=xx,]
    [SEPSESS=x,]
    [MAXACC=xxxxx,]
    SHFLPRF=xxxxxxxx,
    DBDPATH=path,
    DBDPATH6=path,
    SPLIT=length,
    [KEY02=xxxxxxxx,]
    :
    [KEY15=xxxxxxxx]

    Keyword
    Description

    NAME
    Is a required keyword to define the name of the electronic journal profile.

    The parameter value is a field of up to eight alphanumeric characters plus the special characters $, %, #, and @. It must be unique among all EJOUPRF vectors.

    DATASETS
    Is an optional keyword to define the number of data sets (files) to be used as physical electronic journals.

    The parameter value is a field with up to two numeric characters, ranging from 1 to 70. The default is 3.

    MAXNUML
    Is an optional keyword to define the number of logical electronic journals to be used.

    The parameter value is a field with up to two numeric characters, ranging from 0 to 99. The default is 0. When you select 0, only the physical journal environment is used.

    SEPSESS
    Is an optional keyword to define a method for providing integrity for data access to the electronic journal server records.

    Specify Y (Yes) if you want session integrity to be handled by the electronic journal server, independently of your own shared-file session. The default is N (No).

    MAXACC
    Is an optional keyword to define the maximum number of accesses in search operations. This is the maximum number of searches made before the search operation is ended and control is returned to the application.

    The parameter value is a field with up to five numeric characters and it can range from 1 to 32767. The default is 200.

    SHFLPRF
    Is a required keyword to define the name of the shared-file profile to be used.

    You can use the name of a shared-file profile already defined in the keyword SHFLPRF of the SHFLDBD vector, or a new name. If you provide a new profile name, the corresponding shared-file profile will be created by the customization program.

    In any case, the customization will add the DBD and PCB definitions required for this electronic journal profile to the shared-file profile.

    The same shared-file profile can only be used by one electronic journal profile.

    If you use the electronic journal server and the store-for-forwarding in the same workstation, you must use the same shared-file profile for both of them.

    The parameter value is a field with up to eight alphanumeric characters. It must be unique among the EJOUPRF vectors.

    DBDPATH
    Is a required keyword for LANDP for OS/2, LANDP for Windows, and LANDP for DOS, to define the path where the electronic journal data and index files will be located. This path must exist prior to running the LANDP family programs in a workstation with the shared-file server services.

    The parameter value is the complete path (drive plus subdirectories). The number of subdirectories must not exceed four, and has to end with a back slash (\). It must at least contain three characters.

    DBDPATH6
    Is a required keyword for LANDP for Linux. It defines the path where the data and index files are located in a Linux system.

    The parameter value is the complete path including the subdirectories. It must not exceed 56 characters, and must be enclosed within single quotes ('). Each subdirectory name included in the path must have one character at least, and 30 characters at most. A backslash ('\') must not be present after the last subdirectory name.

    As with the DBDPATH keyword, the path must exist prior to running the LANDP family programs in a workstation with the shared file server.

    SPLIT
    Is a required keyword to define the length of the user record that can be kept in one electronic journal record. If the record size exceeds the number specified, it will be split into two or more segments.

    Parameter values range from 62 to 4096 minus the size of the header that is appended. The header is the length of all the defined keys (including the electronic journal hidden key EJHIDKEY which is 8 bytes long) plus 36.

    KEY02 to KEY15
    Are optional parameters to define the names of the fields used as keys. These field names must be defined in at least one of the records specified in the EJOUREC vectors that follow this vector.

    Fields in a record can be selected as electronic journal keys only if they are in character, unsigned ASCII numeric, or hexadecimal, and their length is fixed and less than 50 bytes.

    If fields specified as keys are defined in more than one record, the characteristics of the field must match.

    The keys must be specified sequentially; for example, KEY05 cannot be specified if KEY04 was omitted. The first key (KEY01) is not defined because it is the electronic journal hidden key.

    EJOUPRF vector example

     /* Vectors EJOUPRF and EJOUREC Examples */
     
             EJOUPRF  NAME=EJPRF01,
                      DATASETS=10,
                      MAXNUML=5,
                      SEPSESS=N,
                      MAXACC=200,
                      SHFLPRF=SFPROF01,
                      DBDPATH=C:\TELLER\EJOU\,
                      SPLIT=1024,
                      KEY02=REC1FL01,
                      KEY03=REC2FL03,
                      KEY04=REC1FL02,
                      KEY05=REC2FL01
     
             EJOUREC  RECNAME=RECORD01
    

    EJOUREC vector

    Defines the names of the record structures defined with the RECDEF vector which will be used as electronic journal records.

    At least one EJOUREC vector must be specified following an EJOUPRF vector.

    A quick reference


    Vector position Follows EJOUPRF vector
    List of keywords RECNAME
    Keywords relate to
    Keyword
    Relates to keywords
    RECNAME
    NAME (RECDEF vector)

    Vector format EJOUREC RECNAME=xxxxxxxx

    Keyword
    Description

    RECNAME
    Is a required keyword to specify the name of a record defined with the RECDEF vector which will be used as an electronic journal record.

    The parameter value is a field with up to eight alphanumeric characters, and must match the name given in keyword NAME of a RECDEF vector. Records that have fields with names AND or OR cannot be used as electronic journal records.

    EJOUREC vector example

     /* Vectors EJOUPRF and EJOUREC Examples */
     
             EJOUPRF  NAME=EJPRF01,
                      DATASETS=10,
                      MAXNUML=5,
                      SEPSESS=N,
                      MAXACC=200,
                      SHFLPRF=SFPROF01,
                      DBDPATH=C:\TELLER\EJOU\,
                      SPLIT=1024,
                      KEY02=REC1FL01,
                      KEY03=REC2FL03,
                      KEY04=REC1FL02,
                      KEY05=REC2FL01
     
             EJOUREC  RECNAME=RECORD01
    

    FORM4710 vector

    Defines default parameters (DEVPARM) for banking printer program when emulating a 4710 printer.

    The following figure shows the layout of the document pages for a 4710 printer:

    Figure 18. Document dimensions for IBM 4710 printer customization

    ehcgr046

    A quick reference


    Vector position None
    List of keywords See keyword TYPE
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR4710 (BPPPARM vector)

    Vector format FORM4710 TYPE=xxxx,
    NAME=xxxxxxxx,
    [AUTONL=x,]
    [CPI=xx,]
    [LINELEN=xx,]
    [VRTOFFSL=x,]
    [PAGESIZE=x,]
    [STARTKEY=x,]
    [WRNLINE=x]

    Keyword
    Description

    TYPE
    Is a required keyword to define the type of object. The type can be DOCU for document, or JOUR for journal.

    Depending on the type you selected, you define a different set of keywords:

    DOCU
    NAME (required), CPI, LINELEN, PAGESIZE, WRNLINE, VRTOFFSL, AUTONL, STARTKEY

    JOUR
    NAME (required), CPI, LINELEN, PAGESIZE, WRNLINE

    NAME
    Is a required keyword to define the unique name of the form parameters you specify. The name can have a maximum of eight alphanumeric characters, A to Z and 0 to 9, plus the special characters $, %, #, and @.

    AUTONL
    Is an optional keyword to define automatic skip to next line. The values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    The default is Y.

    CPI
    Is an optional keyword to define printing density (number of characters per inch). Allowed values are 10 or 12. The default is 10.

    LINELEN
    Is an optional keyword to define the maximum number of characters being written in one line. The values depend on the value defined for CPI: (Dimension B)

    The default is the maximum value for the CPI specified.

    VRTOFFSL
    Is an optional keyword to define the number of lines between the first printable line and the line occupied by the tractor clamping mechanism. (See dimension C in Figure 18.)

    The value specified for VRTOFFSL plus the one for PAGESIZE must not be greater than 4. If WRNLINE is greater than 0, VRTOFFSL must not be greater than WRNLINE. The default is 0.

    PAGESIZE
    Is an optional keyword to define the page size. (Dimension A)

    STARTKEY
    Is an optional keyword to define a start key for each operation. The parameter values are:

    Y (Yes)
    Each operation will be started when pressing the start key.

    N (No)
    Each operation will be automatically started.

    The default is N.

    WRNLINE
    Is an optional keyword to define the number of the line at which a attention item is reported to the application (refer to G in Figure 18). Allowed values are from 0 to the specified PAGESIZE. The default is 0. (Dimension D)

    Notes:

    1. If the attention line is specified as 0, no attention line checking is done.

    2. The value must be 0 if the PAGESIZE is 0.

    FORM4710 vector example

     /* Vector FORM4710 (Journal) Example */
     
             FORM4710 TYPE=JOUR,
                      NAME=JOURNAL1,
                      CPI=10,
                      LINELEN=40,
                      PAGESIZE=60,
                      WRNLINE=58
     
    /* Vector FORM4710 (Document) Defaults Example */
     
             FORM4710 TYPE=DOCU,
                      NAME=DUMMYDOC,
                      PAGESIZE=1,
                      WRNLINE=0,
                      LINELEN=40,
                      CPI=10,
                      VRTOFFSL=4,
                      AUTONL=Y,
                      STARTKEY=Y
    

    FORM4720 vector

    Defines default parameters (DEVPARM) for banker printing program when emulating a 4720 printer.

    The following figure shows the layout of the passbook pages for a 4720 printer:

    Figure 19. Passbook Dimensions for IBM 4720 Printer Customization

    ehcgr047

    A quick reference


    Vector position None
    List of keywords See keyword TYPE
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR4720 (BPPPARM vector)

    Vector format FORM4720 TYPE=xxxx,
    NAME=xxxxxxxx,
    [AUTONL=x,]
    [BKWIDTH=xxx,]
    [CPI=xx,]
    [DISPLACE=x,]
    [DBLREC=x,]
    [FOLDBEG=xx,]
    [FOLDSKIP=x,]
    [FOLDTYPE=x,]
    [HRZOFFS=x,]
    [JOURADV=x,]
    [LINELEN=xx,]
    [LPI=x,]
    [MAXSKEW=x,]
    [REMSMODE=x,]
    [NEWDOC=x,]
    [VRTOFFSL=x,]
    [VRTOFFSS=x,]
    [PAGESIZE=xx,]
    [QUALITY=x,]
    [STARTKEY=x,]
    [WRNLINE=x]

    Keyword
    Description

    TYPE
    Is a required keyword to define the type of object. The type can be:
    DOCU for document
    JOUR for journal
    PASS for passbook
    REMS for the REMS facility.

    Depending on the type you selected, you define a different set of keywords:

    DOCU
    NAME, LPI, CPI, MAXSKEW, LINELEN, PAGESIZE, WRNLINE, QUALITY, VRTOFFSS, VRTOFFSL, AUTONL, STARTKEY, JOURADV

    JOUR
    NAME, LPI, CPI, LINELEN, PAGESIZE, WRNLINE

    PASS
    NAME, LPI, CPI, MAXSKEW, FOLDTYPE, LINELEN, PAGESIZE, FOLDBEG, FOLDSKIP, VRTOFFSS, VRTOFFSL, AUTONL, STARTKEY, HRZOFFS

    REMS
    NAME, REMSMODE, DISPLACE, NEWDOC, DBLREC, BKWIDTH

    Use the keywords only with their corresponding types. Otherwise, you will get an error.

    NAME
    Is a required keyword to define the name of the object. The parameter value is a field of up to eight alphanumeric characters, and must be unique among the FORM4720 vectors.

    AUTONL
    Is an optional keyword to define an automatic skip to the next line.. Its values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    The default is Y.

    BKWIDTH
    Is an optional keyword to define the book width of the open document in millimeters (mm). The allowed values are from 127 to 212. The default is 210 (refer to 'T' in Figure 19).

    CPI
    Is an optional keyword to define printing density (number of characters per inch). The numbers are written in one inch (2.54 cm).

    Allowed values are 10, 12, or 16. The default is 10.

    DISPLACE
    Is an optional keyword to define whether the magnetic stripe is 20 mm above the bottom edge of the passbook or not.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    DBLREC
    Is an optional keyword to define whether you want the REMS device to encode in double record mode (the record is written twice to the magnetic stripe) or not.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    FOLDBEG
    Is an optional keyword to define the last line or character position before the center-fold skip for horizontal or vertical passbooks (refer to 'D' in Figure 19).

    For horizontal fold passbooks, the maximum value must not be greater than the specified PAGESIZE value.

    For vertical fold passbooks, the maximum value must not be greater than the specified LINELEN value.

    For both types of center fold, the default is 10.

    FOLDSKIP
    Is an optional keyword to define the total number of lines or character positions skipped for horizontal fold or vertical fold passbooks. (See dimension 'E' in Figure 19.)

    The center fold skip can be any value provided that, when added to the page size (PAGESIZE for horizontal fold passbooks) or to the line length (LINELEN for vertical fold passbooks), the sum is less than or equal to the maximum logical page size or the maximum printer line length respectively.

    For vertical passbooks, the default is 4.

    FOLDTYPE
    Is an optional keyword to define the type of center fold. The values are H (horizontal) or V (vertical). The default is H.

    HRZOFFS
    Is an optional keyword to define the horizontal character offset. That is, the number of characters that the first print character is to be offset beyond the minimum distance from the left edge. (See dimension 'F' in Figure 19). The value, when added to the line length (LINELEN) and center fold skip (FOLDTYPE) in a vertical fold passbook, must be less than or equal to the maximum line length. The default is 0.

    JOURADV
    Is an optional keyword to define automatic line advance each time a line is printed in a document. Its values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    LINELEN
    Is an optional keyword to define the maximum line length (number of characters being written in one line). (See dimension 'H' in Figure 19).

    The maximum values depend on the value defined for character density CPI. They are:

    If 0 is specified, the maximum value is assumed. The default is 80.

    LPI
    Is an optional keyword to define the line density, that is, the number of lines written in one inch (2.54 cm). The parameter specified determines the maximum page size (PAGESIZE).

    The parameter values are 5 or 6 lines per inch. The default is 5.

    MAXSKEW
    Is an optional keyword to define the maximum slant of the document placed in the printer. If the allowed skew is exceeded, the document is rejected, and must be reinserted. The maximum skew depends on the initial vertical offset chosen.

    The parameter values are:

    The default is 1.

    NEWDOC
    Is an optional parameter. Its values are:

    Y (Yes)
    If you want the program to be notified of a change-of-document between reading the magnetic stripe and printing the passbook.

    N (No)
    No notification is required.

    The default is N.

    PAGESIZE
    Is an optional keyword to define the page size, that is, the number of print lines per page. (See dimension 'A' and 'B' in Figure 19.)

    The maximum number of lines depends on the line density (LPI) chosen and, in horizontal fold passbooks, the center fold skip.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    QUALITY
    Is an optional keyword to define quality print.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    REMSMODE
    Is an optional keyword to define the REMS recording mode. The parameter values are A (for ANSI mode) or D (for DIN mode).

    The default is D.

    STARTKEY
    Is an optional keyword to define a start key for each operation. The parameter values are:

    Y (Yes)
    Each operation will be started when the start key is pressed.

    N (No)
    Each operation will be automatically started.

    The default is N.

    VRTOFFSL
    Is an optional keyword to define the number of lines between the first printable line and the line occupied by the tractor clamping mechanism.

    (See dimension 'C' in Figure 19.)

    The value specified for VRTOFFSL plus the values for PAGESIZE and VRTOFFSS (and FOLDSKIP for horizontal passbook) must not be greater than the maximum page size.

    The default is 0.

    VRTOFFSS
    Is an optional keyword to define the offset step, that is, a slight adjustment to print the first vertical position of a document that has preprinted boxes. It defines the number of 1/90-inch steps that the print line is to be offset beyond the minimum distance from the top or bottom edge of a cut form.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    18 if LPI is 5
    15 if LPI is 6

    The default is 0.

    WRNLINE
    Is an optional keyword to define the number of the line at which an attention item is reported to the application. (See dimension 'G' in Figure 19.) Allowed values are from 0 to the specified PAGESIZE. The default is 0.

    Notes:

    1. If the attention line is specified as 0, no attention line checking is done.

    2. The value must be 0 if the PAGESIZE is 0.

    FORM4720 vector example

      /* Vector FORM4720 (Passbook) Example */
     
             FORM4720 TYPE=PASS,
                      NAME=PASS001,
                      LPI=5,
                      CPI=10,
                      MAXSKEW=1,
                      FOLDTYPE=V,
                      LINELEN=70,
                      PAGESIZE=38,
                      FOLDBEG=30,
                      FOLDSKIP=1,
                      VRTOFFSS=0,
                      VRTOFFSL=0,
                      HRZOFFS=10,
                      AUTONL=Y,
                      STARTKEY=N
    
     /* Vector FORM4720 (Document) Default Example */
     
             FORM4720 TYPE=DOCU,
                      NAME=DUMMYDOC,
                      PAGESIZE=1,
                      WRNLINE=0,
                      LINELEN=82,
                      STARTKEY=Y,
                      AUTONL=Y,
                      LPI=5,
                      CPI=10,
                      VRTOFFSL=0,
                      VRTOFFSS=0,
                      JOURADV=N,
                      QUALITY=N
    

    FORM47X2 vector

    Defines financial printer device parameters for documents, journals, passbooks, and REMS objects.

    Define one FORM47X2 vector for each financial printer object you want to use in your workgroups (documents, journals, passbooks, or REMS).

    The following figure shows the layout of the 4772 and 9068 passbook pages:

    Figure 20. Passbook Dimensions for IBM 4772 and 9068 Printer Customization

    ehcgr048

    The following figure shows the layout of the document pages:

    Figure 21. Document Dimensions for IBM 4009, 4712, 4722, 4772, 9068 and 9069 Printer Customization

    ehcgr049

    A quick reference


    Vector position None
    List of keywords See keyword TYPE
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR4712 and PAR4722 (BPPPARM vector)

    Vector format FORM47X2 TYPE=xxxx,
    NAME=xxxxxxxx,
    [AUTONL=x,]
    [BKWIDTH=xxx,]
    [BOTTVAL=xxx,]
    [CPI=xx,]
    [DBLLINE=x,]
    [DBLREC=x,]
    [DBLSTRK=x,]
    [DISPLACE=x,]
    [EMPHASIZ=x,]
    [FOLDBEG=xx,]
    [FOLDSKIP=x,]
    [FOLDTYPE=x,]
    [HIGHCHR=x,]
    [HRZOFFS=x,]
    [LINELEN=xx,]
    [LPI=x,]
    [MAXSKEW=x,]
    [NEWDOC=x,]
    [PAGESIZE=xx,]
    [QUALITY=x,]
    [REMSMODE=x,]
    [SHARED=x,]
    [STARTKEY=x,]
    [VRTOFFSI=x,]
    [VRTOFFSL=x,]
    [VRTOFFSS=x,]
    [WIDECHR=x,]
    [WRNLINE=x]

    Keyword
    Description

    TYPE
    Is a required keyword to define the type of object. The parameter values are DOCU, JOUR, PASS, or REMS. Following are the keywords which have to be defined for each type:

    DOCU
    NAME, LPI, CPI, VRTOFFSI, MAXSKEW, LINELEN, PAGESIZE, WRNLINE, QUALITY, DBLSTRK, EMPHASIZ, VRTOFFSS, VRTOFFSL, HRZOFFS, AUTONL, STARTKEY, SHARED, BOTTVAL, DBLLINE, HIGHCHR, WIDECHR

    JOUR
    NAME, LPI, CPI, LINELEN, PAGESIZE, WRNLINE, QUALITY, DBLSTRK, EMPHASIZ, SHARED

    PASS
    NAME, LPI, CPI, VRTOFFSI, MAXSKEW, FOLDTYPE, LINELEN, PAGESIZE, FOLDBEG, FOLDSKIP, VRTOFFSS, VRTOFFSL, HRZOFFS, AUTONL, STARTKEY, SHARED

    REMS
    NAME, REMSMODE, DISPLACE, NEWDOC, DBLREC, BKWIDTH

    Use the keywords only with their corresponding types. Otherwise, you will get an error.

    NAME
    Is a required keyword to define the name of the object. The parameter value is a field of up to eight alphanumeric characters, and must be unique among the FORM47X2 and FORM4770 vectors.

    AUTONL
    Is an optional keyword to define an automatic skip to next line. Its values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    The default is Y.

    BKWIDTH
    Is an optional keyword to define the book width of the open document in millimeters (mm). The allowed values are from 127 to 212. The default is 210 (refer to 'I' in Figure 20.).

    BOTTVAL
    Is an optional keyword to define whether the bottom edge validation will be ON or OFF.

    The maximum size for the printable area of a document to be checked is 2 inches.

    The default is OFF.

    CPI
    Is an optional keyword to define printing density (number of characters per inch). Allowed values are 10, 12, 15, or 17 (for 17.1). The default is 10.

    DISPLACE
    Is an optional keyword to define whether the magnetic stripe is 10 mm above the bottom edge of the passbook or not.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    DBLLINE
    Is an optional keyword to define whether double line feed is skipped when printing, or not.

    The parameter applies only to the 4772 printer. The parameter value can be either Y (Yes) or N (No). The default is N.

    DBLREC
    Is an optional keyword to define whether you want the REMS device to encode in double record mode (the record is written twice to the magnetic stripe) or not.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    DBLSTRK
    Is an optional keyword to define double strike printing mode.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    EMPHASIZ
    Is an optional keyword to define emphasized characters.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    FOLDBEG
    Is an optional keyword to define the last line or character position before the center-fold skip for horizontal or vertical passbooks (refer to 'D' in Figure 21.).

    For horizontal fold passbooks, the minimum value is 1, and the maximum must not be greater than the specified PAGESIZE value.

    For vertical fold passbooks, the minimum value is 1, and the maximum must not be greater than the specified LINELEN value.

    If 0 is specified, the fold skip is considered to be in the page center for horizontal fold passbooks, and in the line center for vertical fold passbooks. The default is 10.

    FOLDSKIP
    Is an optional keyword to define the total number of lines or character positions skipped for horizontal fold or vertical fold passbooks. (Refer to 'E' in Figure 20)

    The center fold skip can be any value such that, when added to the page size (PAGESIZE for horizontal fold passbooks) or to the line length (LINELEN for vertical fold passbooks), the sum is less than or equal to the maximum logical page size or the maximum printer line length respectively.

    The default is 4.

    FOLDTYPE
    Is an optional keyword to define the type of center fold. The values are H (horizontal) or V (vertical). The default is H.

    HIGHCHR
    Is an optional keyword to define whether characters are printed with double height, or not.

    The parameter applies only to the 4772 printer, and when double line feed is selected through the DBLLINE keyword. The parameter value can be either Y (Yes) or N (No). The default is N.

    HRZOFFS
    Is an optional keyword to define the horizontal character offset. That is, the number of characters that the first print character is to be offset beyond the minimum distance from the left edge (refer to 'F' in figures Figure 20 and Figure 21 on page Figure 21).

    The value, when added to the line length and center fold skip in a vertical fold passbook, must be less than or equal to the maximum line length. The default for PASS type objects is 0, and for DOCU type objects 1.

    See parameter LINELEN (maximum line length) for reference.

    LINELEN
    Is an optional keyword to define the maximum line length (number of characters being written in one line) (refer to 'H' in figures Figure 20 and Figure 21 on page Figure 21).

    The parameter values depend on the value defined for CPI, and on the printer supported by the financial printer server. The allowed values range from 0 to the following CPI values:

    The maximum value will be assumed if you specify 0 in any object type.

    LPI
    Is an optional keyword to define the number of lines written in one inch (2.54 cm). The parameter specified determines the maximum PAGESIZE.

    The parameter values depend on the object type:

    MAXSKEW
    Is an optional keyword to define the maximum slant of the document placed in the printer.

    If the allowed skew is exceeded, the document is rejected, and must be reinserted. The maximum skew depends on the initial vertical offset chosen.

    The parameter values are:

    The default is 1.

    NEWDOC
    Is an optional keyword to define whether the program must be notified of a change of document between two different Read/Encode magnetic stripe operations.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    PAGESIZE
    Is an optional keyword to define the page size, that is, the number of print lines per page. (See dimension 'A' and 'B' in Figure 20.)

    The maximum number of lines depends on the line density (LPI) chosen and, in horizontal fold passbooks, the center fold skip. It also depends on the printer supported by the financial printer server.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    QUALITY
    Is an optional keyword to define quality print.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    REMSMODE
    Is an optional keyword to define the REMS recording mode. The parameter values are:

    D
    ISO/DIN mode

    E
    ISO/DIN mode on track 1

    I
    IBM 3604/4704 mode

    J
    IBM 3604/4704 mode on track 2

    The default is D.

    SHARED
    Is an optional keyword to define if the printer will be used in shared A/B mode.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    If you select Y for this keyword, you also have to select Y for keyword STARTKEY.

    STARTKEY
    Is an optional keyword to define a start key for each operation. The parameter values are:

    Y (Yes)
    Each operation will be started when pressing the start key.

    N (No)
    Each operation will be automatically started.

    The default is N.

    If you have selected Y for keyword SHARED, you also have to select Y here.

    VRTOFFSI
    Is an optional keyword to define the initial vertical offset, that is, the top margin lines. Parameter values are 0 (3.9 mm offset) or 1 (6.6 mm offset). The default is 0.

    VRTOFFSL
    Is an optional keyword to define the number of lines between the first printable line and the line occupied by the tractor clamping mechanism (refer to 'C in figures Figure 20 and Figure 21 on page Figure 21).

    The value specified for VRTOFFSL plus the values for PAGESIZE and VRTOFFSS (and FOLDSKIP for horizontal passbook) must not be greater than maximum page size. The default is 0.

    VRTOFFSS
    Is an optional keyword to define the offset step, that is, a slight adjustment to print the first vertical position of a document that has preprinted boxes. It defines the number of 1/90-inch steps that the print line is to be offset beyond the minimum distance from the top or bottom edge of a cut form.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    The default is 0.

    WIDECHR
    Is an optional keyword to define whether characters are printed with double width, or not.

    The parameter applies only to the 4772 printer. The parameter value can be either Y (Yes) or N (No). The default is N.

    WRNLINE
    Is an optional keyword to define the number of the line at which an attention item is reported to the application. Allowed values are from 0 to the specified PAGESIZE. The default is 0. (refer to 'G in figures Figure 20 and Figure 21 on page Figure 21).
    Note:
    If the attention line is specified as 0, no attention line checking is done.

    FORM47X2 vector example

      /* Vector FORM47X2 (Passbook) Example */
     
             FORM47X2 TYPE=PASS,
                      NAME=PASS001,
                      LPI=5,
                      CPI=10,
                      MAXSKEW=1,
                      FOLDTYPE=V,
                      LINELEN=70,
                      PAGESIZE=38,
                      FOLDBEG=30,
                      FOLDSKIP=1,
                      VRTOFFSS=0,
                      VRTOFFSL=0,
                      HRZOFFS=10,
                      AUTONL=Y,
                      STARTKEY=N,
                      SHARED=N
    
      /* Vector FORM47X2 (REMS) Example */
     
             FORM47X2 TYPE=REMS,
                      NAME=REMS01,
                      REMSMODE=D,
                      DISPLACE=Y,
                      NEWDOC=N,
                      DBLREC=N,
                      BKWIDTH=135
     
    
    /* Vector FORM47X2 (Document) Default Example */
     
             FORM47X2 TYPE=DOCU,
                      NAME=DUMMYDOC,
                      PAGESIZE=0,
                      WRNLINE=0,
                      VRTOFFSS=0,
                      VRTOFFSL=0,
                      LINELEN=0,
                      SHARED=N,
                      STARTKEY=Y,
                      AUTONL=Y,
                      CPI=10,
                      LPI=5,
                      QUALITY=N,
                      DBLSTRK=N,
                      EMPHASIZ=N,
                      MAXSKEW=1,
                      BOTTVAL=OFF,
                      VRTOFFSI=1
     
    /* Vector FORM47X2 (Journal) Default Example */
     
             FORM47X2 TYPE=JOUR,
                      NAME=DUMMYJOU,
                      PAGESIZE=0,
                      WRNLINE=0,
                      LINELEN=0,
                      QUALITY=N,
                      DBLSTRK=N,
                      EMPHASIZ=N,
                      LPI=6,
                      CPI=10,
                      SHARED=N
    

    FORM4748 vector


    ehcodw

    Defines 4748 printer device parameters for documents and passbooks objects.

    Define one FORM4748 vector for each 4748 printer object you want to use in your workgroups (documents or passbooks).

    The following figure shows the layout of the document pages:

    Figure 22. Document Dimensions for IBM 4748 Printer Customization

    ehcgr049

    The following figure shows the layout of the passbook pages:

    Figure 23. Passbook Dimensions for IBM 4748 Printer Customization

    ehcgr048

    A quick reference


    Vector position None
    List of keywords See keyword TYPE
    Keywords relate to
    Vector format FORM4748 TYPE=xxxx,
    NAME=xxxxxxxx,
    [AUTONL=x,]
    [BKWIDTH=xxx,]
    [BOTTVAL=xxx,]
    [CPI=xx,]
    [DBLREC=x,]
    [DBLSTRK=x,]
    [DISPLACE=x,]
    [EMPHASIZ=x,]
    [FOLDADDS=xx,]
    [FOLDBEG=xx,]
    [FOLDSKIP=x,]
    [FOLDTYPE=x,]
    [FONT=x,]
    [HISPEED=x,]
    [HRZOFFS=x,]
    [INITPOS=xxxxx,]
    [LINELEN=xx,]
    [LPI=x,]
    [MAXSKEW=x,]
    [NEWDOC=x,]
    [PAGESIZE=xx,]
    [REMSMODE=x,]
    [SHARED=x,]
    [STARTKEY=x,]
    [VRTOFFSL=x,]
    [VRTOFFSS=x,]
    [WRNLINE=x]

    Keyword
    Description

    TYPE
    Is a required keyword to define the type of object. The parameter values are DOCU, PASS, or REMS. Following are the keywords which have to be defined for each type:

    DOCU
    NAME, LPI, CPI, MAXSKEW, LINELEN, PAGESIZE, WRNLINE, DBLSTRK, EMPHASIZ, VRTOFFSS, VRTOFFSL, HRZOFFS, AUTONL, STARTKEY, SHARED, BOTTVAL, HISPEED, FONT

    PASS
    NAME, LPI, CPI, MAXSKEW, FOLDTYPE, LINELEN, PAGESIZE, FOLDADDS, FOLDBEG, FOLDSKIP, DBLSTRK, VRTOFFSS, VRTOFFSL, HRZOFFS, AUTONL, STARTKEY, SHARED, FONT

    REMS
    NAME, BKWIDTH, DBLREC, DISPLACE, INITPOS, NEWDOC, REMSMODE

    Use the keywords only with their corresponding types. Otherwise, you will get an error.

    NAME
    Is a required keyword to define the name of the object. The parameter value is a field of up to eight alphanumeric characters, and must be unique among the FORM4748 vectors.

    AUTONL
    Is an optional keyword to define automatic skip to the next line. Its values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    The default is Y.

    BKWIDTH
    Is an optional keyword to define the width of an open passbook in millimeters. The parameter value is a numeric field with three digits, in the range 120 through 213. The default is 210. It is valid only when TYPE=REMS. (Refer to 'I' in Figure 23.)

    BOTTVAL
    Is an optional keyword to define whether the bottom edge validation will be ON or OFF.

    The maximum size for the printable area of a document to be checked is 2 inches.

    The default is OFF.

    CPI
    Is an optional keyword to define printing density (number of characters per inch). Allowed values are 10, 12, 13, or 15.

    Value 12 cannot be specified if you assign value 1, 3, or 5 to FONT keyword; value 13 or 15 cannot be specified if you assign value 1, 2, 3, or 5 to FONT keyword. The default is 10.

    DBLREC
    Is an optional keyword to define whether you want the REMS device to encode using double record mode (the record is written twice to the magnetic stripe). It is valid only when TYPE=REMS.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    DBLSTRK
    Is an optional keyword to define double strike printing mode.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    DISPLACE
    Is an optional keyword to define whether the magnetic stripe is 10 mm above the bottom edge of the passbook. It is valid only when TYPE=REMS.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    EMPHASIZ
    Is an optional keyword to define emphasized characters.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    FOLDADDS
    Is an optional keyword to specify a slight adjustment in the fold (horizontal or vertical, depending on FOLDTYPE) of the passbook. FOLDADDS defines by how much the print line is to be offset from the fold skip start position, in units of 1/120-inch. It is valid only when TYPE=PASS.

    The default is 0.

    The maximum number of xx for horizontal folds is:

    24 if LPI is 5
    20 if LPI is 6

    The maximum number of xx for vertical folds is:

    18 if LPI is 10
    15 if LPI is 12
    13 if LPI is 13
    12 if LPI is 15

    FOLDBEG
    Is an optional keyword to define the last line or character position before the center-fold skip for horizontal or vertical passbooks (refer to 'D' in Figure 23).

    For horizontal fold passbooks, the minimum value is 1, and the maximum must not be greater than the specified PAGESIZE value.

    For vertical fold passbooks, the minimum value is 1, and the maximum must not be greater than the specified LINELEN value.

    If 0 is specified, the fold skip is considered to be in the page center for horizontal fold passbooks, and in the line center for vertical fold passbooks. The default is 10.

    FOLDSKIP
    Is an optional keyword to define the total number of lines or character positions skipped for horizontal fold or vertical fold passbooks. (See dimension 'E' in Figure 23.)

    The center fold skip can be any value such that, when added to the page size (PAGESIZE for horizontal fold passbooks) or to the line length (LINELEN for vertical fold passbooks), the sum is less than or equal to the maximum logical page size or the maximum printer line length respectively.

    The default is 4.

    FOLDTYPE
    Is an optional keyword to define the type of center fold. The values are H (horizontal) or V (vertical). The default is H.

    FONT
    Is an optional keyword to define the type characters for the 4748 printer. The values are:
    0
    Mincho-12 (requires CPI=10, 12, 13, or 15)
    1
    DP Gothic-10 (requires CPI=10)
    2
    Prestige Elite-12 (requires CPI=10, or 12)
    3
    Courier-10 (requires CPI=10)
    4
    Mincho-12 (requires CPI=10, 12, 13, or 15)
    5
    Mincho-10 (requires CPI=10)

    The default is 0.

    HISPEED
    Is an optional keyword to define high speed printing mode.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    HRZOFFS
    Is an optional keyword to define the horizontal character offset. That is, the number of characters that the first print character is to be offset beyond the minimum distance from the left edge (refer to 'F' in Figure 23).

    The value, when added to the line length and center fold skip in a vertical fold passbook, must be less than or equal to the maximum line length. The default for PASS type objects is 0, and for DOCU type objects 1.

    See parameter LINELEN (maximum line length) for reference.

    INITPOS
    Is an optional keyword to define the initial print line position when a passbook is inserted. It is valid only when TYPE=REMS.

    The parameter value can be either FIRST or REMS. The default is FIRST.

    LINELEN
    Is an optional keyword to define the maximum line length (number of characters being written in one line). (Refer to 'H' in Figure 23.)

    The parameter values depend on the value defined for CPI. The allowed values range from 0 to the following CPI values:

    82 if CPI is 10
    99 if CPI is 12
    110 if CPI is 13
    123 if CPI is 15

    If you specify 0, the maximum value will be assumed. The default is 80.

    LPI
    Is an optional keyword to define the number of lines written in one inch (2.54 cm). The parameter specified determines the maximum PAGESIZE.

    The parameter values depend on the object type. They are::

    MAXSKEW
    Is an optional keyword to define the maximum slant of the document or passbook object placed in the printer.

    The parameter values are:

    NEWDOC
    Is an optional keyword to define whether the program must be notified of a change of document between two different read/encode magnetic stripe operations. It is valid only when TYPE=REMS.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    PAGESIZE
    Is an optional keyword to define the page size, that is, the number of print lines per page. (See dimension 'A' and 'B' in Figure 23.)

    The maximum number of lines depends on the line density (LPI) chosen and, in horizontal fold passbooks, the center fold skip.

    The parameter values are a numeric field with up to three digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    REMSMODE
    Is an optional keyword to define the REMS recording mode. It is valid only when TYPE=REMS.

    The parameter values are:

    D
    ISO/DIN mode
    I
    IBM 3604/4704 mode

    The default is D.

    SHARED
    Is an optional keyword to define if the printer will be used in shared A/B mode.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    If you select Y for this keyword, you also have to select Y for keyword STARTKEY.

    STARTKEY
    Is an optional keyword to define a start key for each operation. The parameter values are:

    Y (Yes)
    Each operation will be started when pressing the start key.

    N (No)
    Each operation will be automatically started.

    The default is N.

    If you have selected Y for keyword SHARED, you also have to select Y here.

    VRTOFFSL
    Is an optional keyword to define the number of lines between the first printable line and the line occupied by the tractor clamping mechanism (refer to 'C' in Figure 23).

    The value specified for VRTOFFSL plus the values for PAGESIZE and VRTOFFSS (and FOLDSKIP for horizontal passbook) must not be greater than maximum page size. The default is 0.

    VRTOFFSS
    Is an optional keyword to define the offset step, that is, a slight adjustment to print the first vertical position of a document that has preprinted boxes. It defines the number of 1/120-inch steps that the print line is to be offset beyond the minimum distance from the top or bottom edge of a cut form.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed.

    Maximum values are:

    The default is 0.

    WRNLINE
    Is an optional keyword to define the number of the line at which an attention item is reported to the application. Allowed values are from 0 to the specified PAGESIZE. The default is 0. (Refer to 'G' in Figure 23).
    Note:
    If the attention line is specified as 0, no attention line checking is done.

    FORM4748 vector example

      /* Vector FORM4748 (Document) Example */
     
             FORM4748 TYPE=DOCU,
                      NAME=DOC01,
                      LPI=5,
                      CPI=10,
                      MAXSKEW=1,
                      LINELEN=80,
                      PAGESIZE=60,
                      WRNLINE=0,
                      DBLSTRK=N,
                      EMPHASIZ=N,
                      VRTOFFSS=0,
                      VRTOFFSL=0,
                      HRZOFFS=1,
                      AUTONL=Y,
                      STARTKEY=N,
                      SHARED=N,
                      BOTTVAL=OFF,
                      HISPEED=N,
                      FONT=4
    

    FORM4770 vector


    ehcmos2

    Defines 4770 printer device parameters for documents and journals objects.

    Define one FORM4770 vector for each 4770 printer object you want to use in your workgroups (documents or journals).

    The following figure shows the layout of the document pages:

    Figure 24. Document Dimensions for IBM 4770 Printer Customization

    ehcgr049

    A quick reference


    Vector position None
    List of keywords See keyword TYPE
    Keywords relate to  
    Vector format FORM4770 TYPE=xxxx,
    NAME=xxxxxxxx,
    [AUTONL=x,]
    [FONT=x,]
    [HRZOFFS=xx,]
    [LINELEN=xx,]
    [PAGESIZE=x,]
    [SPACING=x,]
    [UPSDOWN=x,]
    [VRTOFFSL=x,]
    [VRTOFFSS=xx,]
    [WIDECHR=x,]
    [WRNLINE=x]

    Keyword
    Description

    TYPE
    Is a required keyword to define the type of object. The parameter values are DOCU or JOUR. Following are the keywords which have to be defined for each type:

    DOCU
    NAME, AUTONL, FONT, HRZOFSS, LINELEN, PAGESIZE, SPACING, UPSDOWN, VRTOFFSL, VRTOFFSS, WIDECHR, WRNLINE

    JOUR
    NAME, AUTONL, FONT, SPACING, UPSDOWN, WIDECHR

    Use the keywords only with their corresponding types. Otherwise, you will get an error.

    NAME
    Is a required keyword to define the name of the object. The parameter value is a field of up to eight alphanumeric characters, and must be unique among the FORM47X2 and FORM4770 vectors.

    AUTONL
    Is an optional keyword to define an automatic skip to next line. Its values are:

    Y (Yes)
    The printer automatically goes to the next line when the text exceeds the last position on the current line.

    N (No)
    An error message will be issued when the line length is exceeded.

    The default is Y.

    FONT
    Is an optional keyword to define the type characters for the 4770 printer. The parameter value can be:
    S
    Standard
    L
    Large
    B
    Bold

    The default is S.

    HRZOFFS
    Is an optional keyword to define the horizontal character offset. That is, the number of characters that the first print character is to be offset beyond the minimum distance from the left edge. (Refer to 'F' in Figure 24).

    The value, when added to the line length, must be less than or equal to the maximum line length. The default is 0.

    See parameter LINELEN (maximum line length) for reference.

    LINELEN
    Is an optional keyword to define the maximum line length (number of characters being written in one line). (Refer to 'H' in Figure 24).

    The value, when added to the horizontal character offset, must be less than or equal to the maximum line length. The default is 0.

    The maximum line length is:

    16
    FONT=L, SPACING=T, and WIDECHR=Y; or FONT=B, SPACING=T, and WIDECHR=Y

    17
    FONT=L, SPACING=L, and WIDECHR=Y; or FONT=B, SPACING=L, and WIDECHR=Y

    21
    FONT=S, SPACING=T, and WIDECHR=Y

    24
    FONT=S, SPACING=L, and WIDECHR=Y

    32
    FONT=L, SPACING=T, and WIDECHR=N; or FONT=B, SPACING=T, and WIDECHR=N

    35
    FONT=L, SPACING=L, and WIDECHR=N; or FONT=B, SPACING=L, and WIDECHR=N

    42
    FONT=S, SPACING=T, and WIDECHR=N

    48
    FONT=S, SPACING=L, and WIDECHR=N

    PAGESIZE
    Is an optional keyword to define the page size, that is, the number of print lines per page. (See dimension 'A' in Figure 24.)

    The value, when added to the value specified in the VRTOFFSL keyword, must be less than or equal to the maximum page length.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed. The default is 0.

    The maximum page length is:

    6
    SPACING=T
    8
    SPACING=L

    SPACING
    Is an optional keyword to define the horizontal and vertical density of characters.

    The parameter value can be either T (text) or L (logo). The default is T.

    UPSDOWN
    Is an optional keyword to define whether inverted printing (upside-down mode) will be used, or not.

    The parameter value can be Y, to use inverted printing, or N, not to use it. The default is N.

    VRTOFFSL
    Is an optional keyword to define the number of lines between the first printable line and the real first printing line. (Refer to 'C' in Figure 24).

    The value, when added to the value specified in the PAGESIZE keyword, must be less than or equal to the maximum page length. The default is 0.

    VRTOFFSS
    Is an optional keyword to define the offset step, that is, a slight adjustment to print the first vertical position of a document that has preprinted boxes. It defines the number of 1/90-inch steps that the print line is to be offset beyond the minimum distance from the top or bottom edge of a cut form.

    The parameter values are a numeric field with up to two digits, ranging from 0 to the maximum value allowed. The default is 0.

    Maximum values are:

    12
    SPACING=L
    15
    SPACING=T

    WIDECHR
    Is an optional keyword to define whether characters are printed with double width, or not.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    WRNLINE
    Is an optional keyword to define the number of the line at which an attention item is reported to the application. Allowed values are from 0 to the specified PAGESIZE. The default is 0. (Refer to 'D' in Figure 24).
    Note:
    If the attention line is specified as 0, no attention line checking is done.

    FORM4770 vector example

     /* Vector FORM4770 (Document) Example */
     
             FORM4770 TYPE=DOCU,
                      NAME=DOCU01,
                      AUTONL=Y,
                      FONT=S,
                      HRZOFSS=0,
                      LINELEN=48,
                      PAGESIZE=6,
                      SPACING=T,
                      UPSDOWN=N,
                      VRTOFFSL=0,
                      VRTOFFSS=0,
                      WIDECHR=N,
                      WRNLINE=0
     
    /* Vector FORM4770 (Journal) Example */
     
             FORM47X2 TYPE=JOUR,
                      NAME=JOUR01,
                      AUTONL=Y,
                      FONT=S,
                      SPACING=T,
                      UPSDOWN=N,
                      WIDECHR=N
    

    FORWDS vector

    Defines parameters for forwarding a data set, that is, sending a data set to the host. Up to 64 FORWDS vectors can be defined in a forwarding server profile. The number of FORWDS vectors must match the number of data sets defined in the store-for-forwarding profile used.

    A quick reference


    Vector position Follows FORWPRF vector. This vector can exist up to 64 times for each FORWPRF vector.
    List of keywords SESSION, TRANSACT, PRTY, EBCDICXL, AUTTRANS
    Keywords relate to
    Keyword
    Relates to keywords
    SESSION
    SES&FORW (parameter 2)
    EBCDICXL
    EXTEN (XLATETBL vector)

    Vector format FORWDS SESSION=x,
    TRANSACT=xxxxxxxx,
    [PRTY=xx,]
    [EBCDICXL=x,]
    [AUTTRANS=x]

    Keyword
    Description

    SESSION
    Is a required keyword to define the forwarding session used to send this data set.

    The parameter value is a number from 1 to 3, depending on the number of sessions defined in the forwarding profile, and cannot be omitted.

    TRANSACT
    Is a required keyword to define the transaction code used when sending records to the host. This code is translated to EBCDIC before sending it to the host.

    If the host session (SxTYPE in the FORWPRF vector) was IMS, this parameter is an alphanumeric field of up to eight characters. If the host session was CICS, the field has up to four characters. You can include blanks if the transaction code does not fill the field.

    PRTY
    Is a keyword to define the priority level for this data set.

    This keyword is required, if DSPRTY=Y was specified in the FORWPRF vector. If not, it must be omitted.

    The parameter value can be any number from 0 to 99, where 0 means no priority and 99 corresponds to the highest priority. The default is 0. Two data sets cannot have the same priority in the same session.

    EBCDICXL
    Is an optional keyword to define if ASCII to EBCDIC translation of fields defined as character or ASCII numeric will be performed before sending data to the host.

    In DBCS mode those fields defined as pure DBCS or mixed, SBCS and DBCS, are also translated.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    AUTTRANS
    Is an optional keyword to define automatic start for the data set transmission.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    If automatic transmission is selected, the forwarding server periodically checks if there is data to be transmitted and automatically starts up. New transactions can be stored while the forwarding is in process. If transmission is stopped by an application, the transaction must be explicitly restarted by the application.

    If AUTTRANS=N, the application is responsible for starting and stopping transmissions.

    FORWDS vector example

     /* Vectors FORWPRF and FORWDS Examples */
     
             FORWPRF  NAME=FORWPRF1,
                      BLKFAC=1,
                      DSPRTY=Y,
                      ALTSESS=Y,
                      S1TYPE=CICS,
                      S1MAXCHR=256,
                      S1RESTO=30,
                      S1RETTO=300,
                      S1TYPDLC=SDLC,
                      S1APPNAM=C1C3C4F1,
                      S2TYPE=IMS,
                      S2MAXCHR=256,
                      S2RESTO=30,
                      S2RETTO=300,
                      S2TYPDLC=SDLC,
                      S2APPNAM=C1C3C2F2
     
             FORWDS   SESSION=1,
                      TRANSACT=TR01,
                      PRTY=03,
                      EBCDICXL=Y,
                      AUTTRANS=Y
     
             FORWDS   SESSION=2,
                      TRANSACT=TR02,
                      PRTY=02,
                      EBCDICXL=N,
                      AUTTRANS=Y
    

    FORWPRF vector

    Defines a forwarding server profile. One vector has to be specified for each profile you are going to use in your workgroups. You can define up to three forwarding sessions in each profile. It may be necessary to define more than one profile, in order to:

    This vector must be followed by as many FORWDS vectors as store-for-forwarding data sets have been defined in the SFORWPRF vector that will be used with this profile.

    A quick reference


    Vector position None. Can be followed by up to 64 FORWDS vectors.
    List of keywords NAME, BLKFAC, DSPRTY, ALTSESS, S1TYPE, S1MAXCHR, S1RESTO, S1RETTO, S1TYPDLC, S1APPNAM, S1INITS1, S1INITS2, S2TYPE, S2MAXCHR, S2RESTO, S2RETTO, S2TYPDLC, S2APPNAM, S2INITS1, S2INITS2, S3TYPE, S3MAXCHR, S3RESTO, S3RETTO, S3TYPDLC, S3APPNAM, S3INITS1, S3INITS2
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR&FORW (parameter 1)

    Vector format FORWPRF NAME=xxxxxxxx,
    [BLKFAC=xx,]
    [DSPRTY=x,]
    [ALTSESS=x,]
    S1TYPE=xxxx,
    [S2TYPE=xxxx,]
    [S3TYPE=xxxx,]
    [S1MAXCHR=xxx,]
    [S2MAXCHR=xxx,]
    [S3MAXCHR=xxx,]
    [S1RESTO=xxxx,]
    [S2RESTO=xxxx,]
    [S3RESTO=xxxx,]
    [S1RETTO=xxxx,]
    [S2RETTO=xxxx,]
    [S3RETTO=xxxx,]
    S1TYPDLC=xxxxx,
    [S2TYPDLC=xxxxx,]
    [S3TYPDLC=xxxxx,]
    S1APPNAM=xxxxxxxx,
    [S2APPNAM=xxxxxxxx,]
    [S3APPNAM=xxxxxxxx,]
    S1INITS1=xxxxx,
    [S2INITS1=xxxxx,]
    [S3INITS1=xxxxx,]
    S1INITS2=xxxxx,
    [S2INITS2=xxxxx,]
    [S3INITS2=xxxxx]

    Keyword
    Description

    NAME
    Is a required keyword to define the name of the forwarding server profile. The name can have a maximum of eight alphanumeric characters, plus the special characters $, %, #, and @.

    BLKFAC
    Is an optional keyword to define the maximum number of transaction records grouped together in one host transaction.

    The parameter value must be a numeric field from 1 to 99. The default is 1.

    If a number other than 1 is specified, the forwarding server automatically blocks the data. A block can contain the records from one store-for-forwarding server data set only. The blocking of records is limited by the available buffer space for building the blocks.

    If the number of records to be transmitted is less than the blocking factor, a short block is sent. If records or blocks are longer than 4096 bytes or exceed the maximum size of the chain element specified, the records are sent as a SNA chained message. The host application that receives the forwarded data must be able to receive chained messages and to recover the individual records.

    For more information about the block transmission, refer to the LANDP Severs and System Management book.

    DSPRTY
    Is an optional keyword to define if you want to assign priorities to each forwarding data set.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    ALTSESS
    Is an optional keyword to define the transmission priority for all of the three forwarding sessions. The parameter value can be either Y (Yes) or N (No). Select Y if you want the same priority for each; they will automatically alternate. If you select N, transmission will be in the order of the session numbers (1, 2, 3). The default is Y.

    In the following keywords, S1 means session 1, S2 session 2, and S3 session 3.

    Keyword
    Description

    S1TYPE
    S1TYPE is a required keyword to define the type of host application for session 1. The parameter must be either IMS or CICS. It cannot be omitted.

    S2TYPE and S3TYPE
    Are optional keywords to define the type of host application programs for sessions 2 and 3. The parameter value can be either IMS, CICS, or N/A.

    If S2TYPE is N/A, it deletes the definition of session 2. In this case, you cannot define session 3. The default is N/A.

    If S3TYPE is N/A, it deletes the definition of session 3. The default is N/A.

    S1MAXCHR, S2MAXCHR, and S3MAXCHR
    Are optional keywords to define the maximum number of bytes sent in a SNA chain element.

    The parameter value is a numeric field from 1 to 4096 bytes. If this keyword is omitted, the default is 256.

    This keyword cannot be specified, if the respective session was N/A.

    S1RESTO, S2RESTO, and S3RESTO
    Are optional keywords to define the time out value for the forwarding server to wait for the SNA session to be established.

    The parameter value is a numeric field from 1 to 1500. If this keyword is omitted, the default is 30 seconds.

    This keyword cannot be specified, if the respective session was N/A.

    S1RETTO, S2RETTO, and S3RETTO
    Are optional keywords to define the time period after an unsuccessful attempt to establish a SNA session, before another attempt is made.

    The parameter value is a numeric field from 1 to 1500. If this keyword is omitted, the default is 300 seconds.

    This keyword cannot be specified, if the respective session was N/A.

    S1TYPDLC, S2TYPDLC, and S3TYPDLC
    S1TYPDLC, S2TYPDLC, and S3TYPDLC are keywords to define the type of data link control.

    Parameter values are SDLC (synchronous), TRDLC (token ring), DCADLC (device cluster adapter), or X25DLC.

    This keyword is required for each session that is NOT N/A.

    S1APPNAM, S2APPNAM, and S3APPNAM
    S1APPNAM, S2APPNAM, and S3APPNAM are keywords to define the name of the host application program for the INITSELF command.

    The parameter values are fields with a length from 8 to 16 hexadecimal characters.

    The SNA server builds the complete INITSELF string using this name. If this keyword is specified for a session, SxINITSx keyword must be omitted.

    Any session that is not N/A requires either APPNAM or SxINITS1 (and SxINITS2). The INITSELF string must be specified using either one or the other.

    This keyword cannot be specified, if the respective session was N/A.

    S1INITS1, S2INITS1 and S3INITS1
    S1INITS1, S2INITS1, and S3INITS1 are keywords to define the first part of the INITSELF string, starting with X'010681' or X'810681'. The length of the complete string must be greater than or equal to 38 digits and less than or equal to 94 digits.

    Up to 48 hexadecimal digits can be specified as part 1 of the INITSELF string.

    If these keywords are specified for the respective session, SxAPPNAM keywords must be omitted.

    This keyword cannot be specified, if the respective session was N/A.

    S1INITS2, S2INITS2 and S3INITS2
    S1INITS2, S2INITS2, and S3INITS2 are keywords to define the INITSELF string continuation. Up to 46 hexadecimal digits can be specified as part 2 of the INITSELF string.

    If these keywords are specified for the session, SxAPPNAM keyword must be omitted.

    This keyword cannot be specified, if the respective session was N/A.

    FORWPRF vector example

     /* Vectors FORWPRF and FORWDS Examples */
     
             FORWPRF  NAME=FORWPRF1,
                      BLKFAC=1,
                      DSPRTY=Y,
                      ALTSESS=Y,
                      S1TYPE=CICS,
                      S1MAXCHR=256,
                      S1RESTO=30,
                      S1RETTO=300,
                      S1TYPDLC=SDLC,
                      S1APPNAM=C1C3C4F1,
                      S2TYPE=IMS,
                      S2MAXCHR=256,
                      S2RESTO=30,
                      S2RETTO=300,
                      S2TYPDLC=SDLC,
                      S2APPNAM=C1C3C2F2
     
             FORWDS   SESSION=1,
                      TRANSACT=TR01,
                      PRTY=03,
                      EBCDICXL=Y,
                      AUTTRANS=Y
     
             FORWDS   SESSION=2,
                      TRANSACT=TR02,
                      PRTY=02,
                      EBCDICXL=N,
                      AUTTRANS=Y
    

    KBD3270 vector


    ehcodw

    Defines a keyboard table for the 3270 Emulator. Specify one vector for each 3270 keyboard table you want to use in your workgroups.

    The 3270 keyboard table allows you to associate function codes or data with the SCAN/ASCII code combination generated by every key on the keyboard.

    There is a help facility for calling the scan and ASCII codes for each key on your keyboard. From the EHCCUS subdirectory, enter:

      EHCSC
    

    and you will get an interactive help panel where you can enter any key to find out the specified values.

    The KBD3270 vector relates to the vector that defines the translation table generated by the keyboard ASCII codes with the EBCDIC host translation, XLATETBL TYPE=AE3270. You associate the two vectors by defining the same value for keyword EXTEN.

    There is a limit on the number of keys that can be defined by using the KBD3270 vector. This limit depends on the size of the data strings associated with the keys and is, typically, about 80 or 90 key definitions. If you need to define more keys than this, use the KBD3270X vector to provide the extra definitions.

    The following figure contains the scan and ASCII codes for the default key assignments for the 3270 Emulator program functions, when using an English keyboard. This is the default KBD3270 vector (KBD3270 vector with EXTEN=KBD), the source for which can be generated using GENSPEC after a CREATE. You can then change or add values.

    Table 10. Keyboard Key Codes

    Scan code ASCII code Keyboard key Function
    01 00 Alt+Esc End emulation
    01 1B Esc Reset
    0E 08 Backspace Cursor left and delete
    0F 00 SHIFT+TAB Backtab
    0F 09 Tab Tab
    10 00 Alt+Q Alternate cursor
    1C 0D Enter New line
    1E 00 Alt+A Attention
    1F 00 Alt+S System request
    20 00 Alt+D Dup
    21 00 Alt+F Field mark
    2E 00 Alt+C Cursor selection
    3B 00 F1 PF1
    3C 00 F2 PF2
    3D 00 F3 PF3
    3E 00 F4 PF4
    3F 00 F5 PF5
    40 00 F6 PF6
    41 00 F7 PF7
    42 00 F8 PF8
    43 00 F9 PF9
    44 00 F10 PF10
    47 00 HOME (numeric pad) Home
    47 E0 HOME Home
    48 00 ^ (numeric pad) Cursor up
    48 E0 ^ Cursor up
    4A 2D - Clear
    4B 00 < (numeric pad) Cursor left
    4B E0 < Cursor left
    4D 00 > (numeric pad) Cursor right
    4D E0 > Cursor right
    4E 2B + Enter
    4F 00 End (numeric pad) Erase EOF
    4F E0 End Erase EOF
    50 00 V (numeric pad) Cursor down
    50 E0 V Cursor down
    52 00 Insert (numeric pad) Toggle insert
    52 E0 Insert Toggle insert
    53 00 Del (numeric pad) Delete
    53 E0 Del Delete
    54 00 SHIFT+F1 PF13
    55 00 SHIFT+F2 PF14
    56 00 SHIFT+F3 PF15
    57 00 SHIFT+F4 PF16
    58 00 SHIFT+F5 PF17
    59 00 SHIFT+F6 PF18
    5A 00 SHIFT+F7 PF19
    5B 00 SHIFT+F8 PF20
    5C 00 SHIFT+F9 PF21
    5D 00 SHIFT+F10 PF22
    68 00 Alt+F1 PA1
    69 00 Alt+F2 PA2
    6C 00 Alt+F5 End emulation
    85 00 F11 PF11
    86 00 F12 PF12
    87 00 SHIFT+F11 PF23
    88 00 SHIFT+F12 PF24
    E0 0D Enter (numeric pad) Enter

    You can edit the KBD3270 vector to use the following scan code values for additional emulated 3270 keyboard keys.

    Table 11. Emulated Keyboard Key Codes

    Scan code ASCII code Keyboard key
    01 FF Left CTRL
    02 FF Left ALT
    04 FF Right CTRL
    08 FF Right ALT
    10 FF Scroll Lock
    20 FF Num Lock
    40 FF Caps Lock
    80 FF Sys Req

    You can combine these by OR-ing the values together. For example:

      Left CTRL + Scroll Lock = 11,FF
    

    A quick reference


    Vector position None
    List of keywords EXTEN, KEY
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    EXTEN (XLATETBL vector),
    SES&3270 (parameter 7),
    EXTEN (KBD3270X vector)

    Vector format KBD3270 EXTEN=xxx,
    KEY=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to a 3270 keyboard definition table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all KBD3270 vectors.

    When defining a 3270 emulator, parameter 7 of the SES&3270 keyword is a pointer to this identification.

    KEY
    Is a required keyword to define keys. There must be one KEY keyword for every key you want to assign function codes or data to.

    This keyword has three parameters:

    1. The first parameter specifies the scan code for the key. The parameter value is a 1-byte field.
    2. The second parameter specifies the ASCII code for the key. The parameter value is a 1-byte field.
    3. The third parameter value specifies the associated function code or data for the key.

      Mixing function and data strings is allowed when linking them with a plus (+) sign. The whole parameter is defined between single quotes ('). Data strings must be defined between double quotes ("). Function codes can match functions as described in Table 10. The following can also be specified:

      Erase input
      Reset
      Release emulator
      Insert off
      PA3

      For example:

        'HOME+"data string"+PF4'
      

      If single or double quotes are part of a data string, they must be doubled.

    KBD3270 vector example

     /* Vector KBD3270 Default Example */
     
             KBD3270  EXTEN=KBD,
                      KEY=(48,E0,'CURSOR UP'),
                      KEY=(50,E0,'CURSOR DOWN'),
                      KEY=(4B,E0,'CURSOR LEFT'),
                      KEY=(4D,E0,'CURSOR RIGHT'),
                      KEY=(52,E0,'TOGGLE INSERT'),
                      KEY=(53,E0,'DELETE'),
                      KEY=(47,E0,'HOME'),
                      KEY=(4F,E0,'ERASE EOF'),
                      KEY=(48,00,'CURSOR UP'),
                      KEY=(50,00,'CURSOR DOWN'),
                      KEY=(4B,00,'CURSOR LEFT'),
                      KEY=(4D,00,'CURSOR RIGHT'),
                      KEY=(52,00,'TOGGLE INSERT'),
                      KEY=(53,00,'DELETE'),
                      KEY=(47,00,'HOME'),
                      KEY=(4F,00,'ERASE EOF'),
                      KEY=(1C,0D,'NEW LINE'),
                      KEY=(E0,0D,'ENTER'),
                      KEY=(4E,2B,'ENTER'),
                      KEY=(4A,2D,'CLEAR'),
                      KEY=(01,1B,'RESET'),
                      KEY=(01,00,'END EMULATION'),
                      KEY=(6C,00,'END EMULATION'),
                      KEY=(0F,09,'TAB'),
                      KEY=(0F,00,'BACKTAB'),
                      KEY=(0E,08,'CURSOR LEFT+DELETE'),
                      KEY=(3B,00,'PF1'),
                      KEY=(3C,00,'PF2'),
                      KEY=(3D,00,'PF3'),
                      KEY=(3E,00,'PF4'),
                      KEY=(3F,00,'PF5'),
                      KEY=(40,00,'PF6'),
                      KEY=(41,00,'PF7'),
                      KEY=(42,00,'PF8'),
                      KEY=(43,00,'PF9'),
                      KEY=(44,00,'PF10'),
                      KEY=(85,00,'PF11'),
                      KEY=(86,00,'PF12'),
                      KEY=(55,00,'PF14'),
                      KEY=(56,00,'PF15'),
                      KEY=(57,00,'PF16'),
                      KEY=(58,00,'PF17'),
                      KEY=(59,00,'PF18'),
                      KEY=(5A,00,'PF19'),
                      KEY=(5B,00,'PF20'),
                      KEY=(5C,00,'PF21'),
                      KEY=(5D,00,'PF22'),
                      KEY=(87,00,'PF23'),
                      KEY=(88,00,'PF24'),
                      KEY=(68,00,'PA1'),
                      KEY=(69,00,'PA2'),
                      KEY=(20,00,'DUP'),
                      KEY=(21,00,'FIELD MARK'),
                      KEY=(10,00,'ALTERNATE CURSOR'),
                      KEY=(2E,00,'CURSOR SELECTION'),
                      KEY=(1F,00,'SYSTEM REQUEST'),
                      KEY=(54,00,'PF13'),
                      KEY=(1E,00,'ATTENTION')
    

    KBD3270X vector


    ehcodw

    Defines additional keys for a keyboard table for the 3270 emulator. Specify one vector for each of your 3270 keyboard tables that need more key definitions.

    When you need more key definitions for a keyboard table, specify a KBD3270X vector with the same value for its EXTEN keyword as you gave to the table that requires the additional keys.

    A quick reference


    Vector position None
    List of keywords EXTEN, KEY
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    EXTEN (KBD3270 vector),
    EXTEN (XLATETBL vector)
    SES&3270 (parameter 7)

    Vector format KBD3270X EXTEN=xxx,
    KEY=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to a 3270 keyboard definition table. A KBD3270 vector providing the first half of the keyboard definition table must also exist in the COMMON.SPC file.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must match the EXTEN value of a KBD3270 vector.

    When defining a 3270 emulator, parameter 7 of the SES&3270 keyword is a pointer to this identification.

    KEY
    Is a required keyword to define keys. There must be one KEY keyword for every key you want to assign function codes or data to.

    This keyword has three parameters:

    1. The first parameter specifies the scan code for the key. The parameter value is a 1-byte field.
    2. The second parameter specifies the ASCII code for the key. The parameter value is a 1-byte field.
    3. The third parameter value specifies the associated function code or data for the key.

      Mixing function and data strings is allowed when linking them with a plus (+) sign. The whole parameter is defined between single quotes ('). Data strings must be defined between double quotes ("). Function codes can match functions as described in Table 10. The following can also be specified:

      Erase input
      Reset
      Release emulator
      Insert off
      PA3

      For example:

        'HOME+"data string"+PF4'
      

      If single or double quotes are part of a data string, they must be doubled.

    KBD3270X vector example

     /* Vector KBD3270X Example */
     
             KBD3270X EXTEN=KBD,
                      KEY=(1E,00,'HOME+"HOST1"+ENTER'),
                      KEY=(3E,00,'HOME+"HOST2"+ENTER')
    

    KBDBIWP vector

    Defines a keyboard table for the Banking Interactive Workstation Program (BIWP). Specify one vector for each BIWP keyboard table you want to use in your workgroups.

    The BIWP keyboard table allows you to associate function codes or data with the SCAN/ASCII code combination generated by every key on the keyboard.

    There is a help facility for calling the scan and ASCII codes for each key on your keyboard. From the EHCCUS subdirectory, enter:

      EHCSC
    

    and you will get an interactive help panel where you can enter any key to find out the specified values.

    The keyboard definition vector is associated with three other vectors. The first two are optional, the third is required.

    1. The vector that defines the table used to simulate a keystroke sent from keyboard to 4700 (KSTRBIWP vector).
    2. The vector that defines the table used to simulate a scan code sent from keyboard to 4700 (KSCCBIWP vector).
    3. The vector that defines the table to translate the ASCII codes generated by the keyboard with EBCDIC sent to 4700 (XLATETBL TYPE=AEBIWP).

    You associate the four vectors by defining the same value for the keyword EXTEN.

    The keyboard table used by the BIWP can be changed from the 4700 application with the SWAPTT instructions. When the active keyboard table is changed, the active tables for all the group of vectors with the same EXTEN keyword will also be changed accordingly.

    The following figure shows the defaults provided for the default keyboard table. You can change or add values.

    Table 12. Keyboard Key Defaults

    Function Scan/ASCII Codes Keyboard key
    JUMP (see notes below the table) 01 00 (see notes below the table) [Alt] + [Esc]
    RESET 01 1B [Esc]
    BACKSPACE + SEG DELETE 0E 08 [Backspace]
    MSR/E CANCEL 12 00 [Alt] + [E]
    PIN pad CANCEL 19 00 [Alt] + [P]
    EOM, X'FF' 1C 0D [Return]
    CANCEL 2E 00 [Alt] + [C]
    MONITOR 32 00 [Alt] + [M]
    BACKSPACE 4B 00 [Left arrow]
    BACKSPACE 4B E0 (see notes below the table) [Left arrow]
    ADVANCE 4D 00 [Right arrow]
    ADVANCE 4D E0 (see notes below the table) [Right arrow]
    EOM, X'FF' 4E 2B [+]
    END OF INPUT 4F 00 [End]
    END OF INPUT 4F E0 (see notes below the table) [End]
    TOG.SEG. INSERT 52 00 [Ins]
    TOG.SEG. INSERT 52 E0 (see notes below the table) [Ins]
    SEGMENT DELETE 53 00 [Del]
    SEGMENT DELETE 53 E0 (see notes below the table) [Del]
    JUMP (see notes below the table) 6C 00 [Alt] + [F5]
    JUMP (see notes below the table) 6D 00 [Alt] + [F6]
    JUMP (see notes below the table) 6E 00 [Alt] + [F7]
    JUMP (see notes below the table) 6F 00 [Alt] + [F8]
    JUMP (see notes below the table) 70 00 [Alt] + [F9]
    ERASE END OF SEG. 75 E0 (see notes below the table) [Ctrl] + [End]
    EOM, X'FF' E0 0D (see notes below the table) [Enter]

    Notes:

    1. 101/102-key keyboard extended function.

    2. The JUMP function is provided for DOS only. In OS/2, Task Manager handles this function. The key combinations defined for the JUMP function are not operational under OS/2.

    A quick reference


    Vector position None
    List of keywords EXTEN, APPLIC, EAEXTEN, KEY
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    EXTEN (KSCCBIWP, KSTRBIWP, and XLATETBL vectors),
    PAR&BIWP (parameter 14)
    EAEXTEN
    EXTEN (XLATETBL vector)

    Vector format KBDBIWP EXTEN=xxx,
    [APPLIC=xxxxxxxx,]
    [EAEXTEN=xxx,]
    KEY=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to a BIWP keyboard definition table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all KBDBIWP vectors.

    The parameter value cannot be UNI, since it is a reserved name.

    When defining a BIWP emulator, parameter 18 of the SES&BIWP keyword is a pointer to this identification.

    APPLIC
    Is an optional keyword that defines the application identification that will be used with the 4700 SWAPTT instruction.

    The parameter value can have a maximum of eight alphanumeric characters, plus the special characters $, %, #, and @. It must be unique among all KBDBIWP vectors.

    It will be translated to EBCDIC using the international code pages 850 and 500.

    EAEXTEN
    Is an optional keyword to define the extension of the EABIWP table that is included in the group specified with the APPLIC keyword. This table, together with the KSTRBIWP and KSCCBIWP vectors, will be changed by the 4700 SWAPTT instruction.

    If you want to change this table, you must define it.

    The parameter value is a 3-character string and must adhere to DOS specifications for file extensions. It must match the parameter of the EXTEN keyword in a XLATETBL vector (TYPE=EABIWP).

    KEY
    Is a required keyword to define keys. There must be one KEY keyword for every key definition.

    This keyword has three parameters:

    1. The first parameter specifies the scan code for the key. The parameter value is a two hexadecimal field.
    2. The second parameter specifies the ASCII code for the key. The parameter value is a two hexadecimal field.
    3. The third parameter value specifies the associated function code or data for the key.

      The whole parameter is defined between single quotes ('). Mixing function code and data is allowed when linking them by using a plus (+) sign.

      ASCII data strings are defined between double quotes ("). Hexadecimal or EBCDIC data strings are defined between double quotes and are preceded by a colon (:). They will be a group of hexadecimal pairs with the EBCDIC values.

      Function codes can match functions as described in Table 12.

      The following can also be specified:

      EOMA
      EOMB
      EOM, EID
      SEG. INSERT OFF
      NOP

      If singlequotes, double quotes, or colons are part of a data string, they must be doubled.

    When defining the function codes for the functions

    EOM
    EOMA
    EOMB
    EOM, EID

    the function code must be followed by a plus (+) sign and two hexadecimal digits corresponding to the EOM mask.

    Note that when defining the function code for the EOM, EID function, you can specify only one byte. As SMSEID is a 1-byte field, the customization program requires that you enter a 1-byte character string before assigning the EOM, EID function to a key. This 1-byte character string is placed in SMSEID. To generate more than one character, you must define two concatenated character strings: one with the byte to be placed in SMSEID, and one with the rest of the characters.

    For example, to define an EOM, EID key that generates EBCDIC C2 in the SMSEID field and EBCDIC C1 in the user segment, with the EOM mask being FF, the value for the third parameter must be:

      '":C1"+":C2". +'EOM,EID+FF'
    

    KBDBIWP vector example

     /* Vector KBDBIWP Default Example */
     
             KBDBIWP  EXTEN=KBD,
                      APPLIC=DEFAULT,
                      EAEXTEN=DIS,
                      KEY=(01,1B,'RESET'),
                      KEY=(70,00,'JUMP'),
                      KEY=(2E,00,'CANCEL'),
                      KEY=(32,00,'MONITOR'),
                      KEY=(E0,0D,'EOM+FF'),
                      KEY=(1C,0D,'EOM+FF'),
                      KEY=(4B,00,'BACKSPACE'),
                      KEY=(4D,00,'ADVANCE'),
                      KEY=(4D,E0,'ADVANCE'),
                      KEY=(4B,E0,'BACKSPACE'),
                      KEY=(53,00,'SEG. DELETE'),
                      KEY=(52,00,'TOG.SEG. INSERT'),
                      KEY=(53,E0,'SEG. DELETE'),
                      KEY=(52,E0,'TOG.SEG. INSERT'),
                      KEY=(0E,08,'BACKSPACE+SEG. DELETE'),
                      KEY=(19,00,'PIN PAD CANCEL'),
                      KEY=(12,00,'MSR/E CANCEL'),
                      KEY=(4F,E0,'END OF INPUT'),
                      KEY=(75,E0,'ERASE END OF SEG'),
                      KEY=(4E,2B,'EOM+FF'),
                      KEY=(4F,00,'END OF INPUT'),
                      KEY=(01,00,'JUMP'),
                      KEY=(6C,00,'JUMP'),
                      KEY=(6D,00,'JUMP'),
                      KEY=(6E,00,'JUMP'),
                      KEY=(6F,00,'JUMP')
    

    KSCCBIWP vector

    Defines an issue-keyboard-scan code translation table for the Banking Interactive Workstation Program.

    This vector is used to match scan codes and their associated shift states, which are used by the application when using the BIWP issue-keyboard-scan code function with the keyboard definition vector (KBDBIWP). You associate a KSCCBIWP vector with a KBDBIWP vector by defining the same value for the keyword EXTEN in both vectors.

    Define as many KSCCBIWP vectors as different BIWP keyboard definition vectors you are going to use through the issue-keyboard-scan code function.

    If this vector is omitted, an empty table will be created.

    A quick reference


    Vector position None
    List of keywords EXTEN, KEY
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    EXTEN (KBDBIWP, KSTRBIWP, and XLATETBL vectors)

    Vector format KSCCBIWP EXTEN=xxx,
    KEY=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to a BIWP issue-keyboard-scan code translation table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be the same as defined in the associated KBDBIWP vector.

    KEY
    Is a required keyword for scan code definition. There must be one keyword for every shift state/scan code combination defined.

    The keyword has four parameters.

    The first and second parameters define the shift state and scan code values that will be used by the application when using the BIWP issue-keyboard-scan code function. The shift state/scan code combination must be unique in the table.

    The third and fourth parameters define the SCAN and ASCII codes of a key defined in the associated KBDBIWP vector.

    KSCCBIWP vector example

     /* Vector KSCCBIWP Example */
     
             KSCCBIWP EXTEN=KBD,
                      KEY=(S,06,4D,E0),
                      KEY=(U,32,4B,00),
                      KEY=(U,33,E0,0D),
                      KEY=(U,34,1C,0D)
    

    KSTRBIWP vector

    Defines a present-keystroke translation table for Banking Interactive Workstation Program.

    This vector is used to define how the keystrokes, used by the application when using the present-keystroke function, match with the keyboard definition vector (KBDBIWP). You associate a KSTRBIWP vector with a KBDBIWP vector by defining the same value for the keyword EXTEN in both vectors. Specify one vector for each BIWP keyboard definition vector you are going to use through the present-keystroke function.

    If the KSTRBIWP vector is omitted, an empty table will be generated.

    The following figure shows the values defined in the default KSTRBIWP vector (KSTRBIWP vector with keyword EXTEN=KBD).

    Table 13. Present-keystroke defaults

    Function Scan/ASCII Codes Keystroke Values
    EOM, FF 1C 0D 0D
    RESET 01 1B 00
    BACKSPACE 4B 00 03
    ADVANCE 4D 00 04
    BACKSPACE + SEGMENT DELETE 0E 08 08

    A quick reference


    Vector position None
    List of keywords EXTEN, KEY
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    EXTEN (KBDBIWP, KSCCBIWP, and XLATETBL vectors)

    Vector format KSTRBIWP EXTEN=xxx,
    KEY=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to identify a BIWP present-keystroke table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be the same as defined in the associated KBDBIWP vector, in the EXTEN keyword.

    KEY
    Is a required keyword to define a keystroke. There must be one KEY keyword for every keystroke defined.

    The keyword has three parameters:

    1. The first parameter defines the 1-byte value that will be used by the application with the BIWP present-keystroke function. It must be unique in the table.
    2. The second parameter is the 1-byte SCAN code of the associated key defined in the KBDBIWP vector.
    3. The third parameter is the 1-byte ASCII code of the associated key defined in the KBDBIWP vector.

    KSTRBIWP vector example

     /* Vector KSTRBIWP  Default Example */
     
             KSTRBIWP EXTEN=KBD,
                      KEY=(0D,1C,0D),
                      KEY=(03,4B,00),
                      KEY=(04,4D,00),
                      KEY=(08,0E,08),
                      KEY=(00,01,1B)
    

    LUPOOL vector


    ehcmdos

    Defines LUs for host communication using the SNA server with LU pooling on a DOS workstation. One vector is required for each LU to be pooled. All the LUs to be used by the SNA server must be in the same LUPOOL table - in other words, they must have the same NAME parameter value.

    A quick reference


    Vector position None
    List of keywords NAME, GROUPID, DLC, LUNUMBER
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR&SNA
    GROUPID
    SES&SNA

    Vector format LUPOOL NAME=xxxxxxxx,
    GROUPID=xx,
    DLC=xxx,
    LUNUMBER=xxx

    Keyword
    Description

    NAME
    Is a required keyword to specify the name of the LUPOOL table.

    The parameter value is a string of up to eight alphanumeric characters and may contain the special characters #, _, %, or @.

    GROUPID
    Is a required keyword to identify the logical group of LUs.

    The parameter value is a string of two characters: the first character must be alphabetical, and the second one numerical.

    DLC
    Is a required keyword to specify the DLC type used with the LU.

    For DLCs other than X.25, the parameter value can be:

    SDL
    Synchronous Data Link Control (SDLC)
    TKR
    Token-ring
    DCA
    Device Cluster Attachment (DCA)

    For X.25 DLCs, the parameter value ranges from 1 to 999, and corresponds to the virtual circuit definition identification.

    LUNUMBER
    Is a required keyword to specify the LU number. This corresponds to the LOCADDR on the host VTAM definition.

    The parameter value ranges from 1 to 254, and must be unique for the data link control (DLC) or virtual circuit.

    LUPOOL vector example

     /* Vector LUPOOL Example */
     
             LUPOOL   NAME=LUPOOL1,
                      GROUPID=P1,
                      DLC=SDL,
                      LUNUMBER=1
     
    

    MSRINTBL vector

    Defines an input translation table for the Banking Interactive Workstation Program when reading the MSR/E. Define one MSRINTBL vector for every MSR/E input table that you want to use in your workgroups.

    A quick reference


    Vector position None
    List of keywords EXTEN, TRKOPER, DELAY, TR2CHR0 to TR2CHRF, TR3CHR0 to TR3CHRF
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    PAR&BIWP (parameter 17)

    Vector format MSRINTBL EXTEN=xxx,
    [TRKOPER=(   ),]
    [DELAY=xx,]
    [TR2CHR0=(   ),]
    [TR3CHR0=(   )]

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to an input translation table for the MSR/E.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all MSRINTBL vectors.

    When defining a BIWP server, one of the parameters of the PAR&BIWP keyword is a pointer to this identification.

    TRKOPER
    Is an optional keyword to define the operational MSR/E tracks.

    The keyword has two parameters:

    1. The first parameter specifies which tracks are going to be read. The possible values are:
      2
      Only track 2 will be read
      3
      Only track 3 will be read
      B
      Both tracks 2 and 3 will be read

      The default is 2.

    2. The second parameter specifies whether track 2 will be written. The parameter value can be either Y (Yes) or N (No). The default is Y.

    DELAY
    Is an optional keyword to specify the maximum amount of time, in seconds, between MSR/E reads.

    The parameter value ranges from 1 to 60. The default is 5.

    TR2CHR0 to TR2CHRF
    Are optional keywords to associate data or end of message indicators to every character (0 to F), read from track 2. TR2CHR0 is the keyword related to track 2 character 0, TR2CHR1 to track 2 character 1, and so on. You must write the corresponding TR2CHRx for every character in track 2 that you want to generate data or EOM indicator. If the keyword is omitted for a character in track 2, no data or EOM indicator will be sent to the 4700 when it is read.

    Each keyword has two parameters:

    1. The first parameter specifies the 1-byte value to be sent. It must be enclosed between double quotes ("). If the character is an EBCDIC value, it must be preceded by a colon (:), and written in hexadecimal notation.

      The default is no defined character.

    2. The second parameter specifies the end of message indicator associated with the character, and takes the following values:
      EOM
      If character is associated with EOM
      CEOM
      If character is associated with conditional EOM
      EID
      If character is associated with EID
      CEID
      If character is associated with conditional EID
      NONE
      If character is not associated with any indicator

      The default is NONE.

    TR3CHR0 to TR3CHRF
    Are optional keywords associated with track 3. If specified, they will follow the same rules as TR2CHR0 to TR2CHRF.

    MSRINTBL vector example

    /* Vector MSRINTBL  Default Example */
             MSRINTBL EXTEN=MSR,
                      TRKOPER=(2,Y),
                      TR2CHR0=(":F0",NONE),
                      TR2CHR1=(":F1",NONE),
                      TR2CHR2=(":F2",NONE),
                      TR2CHR3=(":F3",NONE),
                      TR2CHR4=(":F4",NONE),
                      TR2CHR5=(":F5",NONE),
                      TR2CHR6=(":F6",NONE),
                      TR2CHR7=(":F7",NONE),
                      TR2CHR8=(":F8",NONE),
                      TR2CHR9=(":F9",NONE),
                      TR2CHRC=(":7C",EOM),
                      TR2CHRD=(":7D",NONE),
                      TR2CHRE=(":7E",NONE),
                      TR3CHR0=(":F0",NONE),
                      TR3CHR1=(":F1",NONE),
                      TR3CHR2=(":F2",NONE),
                      TR3CHR3=(":F3",NONE),
                      TR3CHR4=(":F4",NONE),
                      TR3CHR5=(":F5",NONE),
                      TR3CHR6=(":F6",NONE),
                      TR3CHR7=(":F7",NONE),
                      TR3CHR8=(":F8",NONE),
                      TR3CHR9=(":F9",NONE),
                      TR3CHRA=(":FA",NONE),
                      TR3CHRC=(":7C",NONE),
                      TR3CHRE=(":7E",NONE)
    

    MSROUTBL vector

    Defines an output translation table for the Banking Interactive Workstation Program when writing to the MSR/E. Define one MSROUTBL vector for every MSR/E output table that you want to use in your workgroups.

    A quick reference


    Vector position None
    List of keywords EXTEN, OPTIONS, OUTCHR0 to OUTCHRF
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    PAR&BIWP (parameter 18)

    Vector format MSROUTBL EXTEN=xxx,
    [OPTIONS=(   ),]
    [OUTCHR0=(   )]

    Keyword
    Description

    EXTEN
    Is a required keyword to define an output table for the MSR/E.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all MSROUTBL vectors.

    When defining a BIWP, one of the parameters of the PAR&BIWP keyword is a pointer to this identification.

    OPTIONS
    Is an optional keyword to define parameters to perform output operations. If it is omitted, defaults will be assumed. The keyword has three parameters:
    1. The first parameter specifies the encoding mode. It can take the values DIN, IBM, or ISO. The default is IBM.
    2. The second parameter specifies whether the track will be written using single (1) or double (2) record encoding. The default is 2.
    3. The third parameter specifies whether or not to use the suppress heading A option with the IBM encoding mode.

      The parameter value can be either Y (Yes) or N (No). The default is N.

    OUTCHR0 to OUTCHRF
    Are optional keywords to associate the characters received from the 4700 application with the characters that will be encoded to the MSR/E (0 to F). OUTCHR0 is the keyword related to character 0, OUTCHR1 to character 1, and so on.

    You must write the corresponding OUTCHRx for every character you want to be written to the MSR/E. If the keyword is omitted for a character, it will not be written. Each keyword has three parameters:

    1. The first parameter specifies the 1-byte value that will be received from the 4700 application. The value must be a pair of hexadecimal digits and must be unique in the vector.
    2. The second parameter specifies whether the character is operational or not. The parameter value must be either Y (the character will be translated and encoded) or N (the character will be ignored). The default is Y.
    3. The third parameter specifies whether the character is associated with an EOM indicator or not. The parameter value can be either Y (Yes) or N (No). The default is N.

    MSROUTBL vector example

     /* Vector MSROUTBL  Default Example */
     
             MSROUTBL EXTEN=MSR,
                      OPTIONS=(IBM,2,N),
                      OUTCHR0=(F0,Y,N),
                      OUTCHR1=(F1,Y,N),
                      OUTCHR2=(F2,Y,N),
                      OUTCHR3=(F3,Y,N),
                      OUTCHR4=(F4,Y,N),
                      OUTCHR5=(F5,Y,N),
                      OUTCHR6=(F6,Y,N),
                      OUTCHR7=(F7,Y,N),
                      OUTCHR8=(F8,Y,N),
                      OUTCHR9=(F9,Y,N),
                      OUTCHRA=(00,N,N),
                      OUTCHRB=(00,N,N),
                      OUTCHRC=(7C,Y,Y),
                      OUTCHRD=(7D,Y,N),
                      OUTCHRE=(7E,Y,N),
                      OUTCHRF=(00,N,N)
    

    P3287ATT vector

    Defines an attribute table for the 3287 emulator.

    One vector has to be specified for each 3287 emulator attribute table that you want to use in your workgroups.

    A quick reference


    Vector position None
    List of keywords EXTEN, TIMEOUT, LSTDELIM, DEFCCHR, RESET
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    PAR&3287 (parameter 3)

    Vector format P3287ATT EXTEN=xxx,
    [TIMEOUT=xxxx,]
    [LSTDELIM=xxxxxxxx,]
    [DEFCCHR=xx,]
    [RESET=(   )]

    Keyword
    Description

    EXTEN
    Is a required keyword to give an identification to a 3287 attribute table, if more than one table is used. Otherwise it can be omitted and the default is TAB. The keyword does not apply to DBCS mode.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all P3287ATT vectors.

    When defining a 3287 printer emulator, one of the parameters of the PAR&3287 keyword is a pointer to this identification.

    TIMEOUT
    Is an optional keyword to define the number of seconds the 3287 printer emulator will wait before assuming that a listing has finished. At the end of the time interval, the emulator gives control to the next remote service or changes from local to remote (or remote to local) depending on operator's requirements. If the time-out expires without a print request having arrived, a listing is considered to have ended.

    The parameter value is a field with up to four characters and can take the values between 0 and 3600. The default is 15 seconds.

    LSTDELIM
    Is an optional keyword to define a name that the host application program provides to identify the beginning and the end of listings.

    The parameter value is a string of up to eight alphanumeric characters.

    The application sends a LISTL (LISTL=xxxxxxxx) that identifies the beginning of the identified listing. The emulator program considers the listing to be finished when the corresponding ENDL (ENDL=xxxxxxxx) is received. Normally, the application sends a form feed control character following the ENDL. If the ENDL is not received, the following happens:

    1. If the operator interface is loaded, the 3287 printer emulator program waits for a command from the operator.
    2. If the operator interface is not loaded, the emulator assumes that the listing has finished at the specified timeout.

    DEFCCHR
    Is an optional keyword to define the 1-byte ASCII value of the character that replaces any invalid control character. The default is 00.

    RESET
    Is an optional keyword to define the control characters used to reset the printer before starting a new listing.

    The parameter value is a field of up to 45 hexadecimal bytes. The hexadecimal bytes must be separated with a comma (,).

    You only need to define this keyword if you use a printer that uses different reset control characters from those for the printers explicitly supported by the 3287 emulator.

    P3287ATT vector example

     /* Vector P3287ATT  Default Example */
     
             P3287ATT EXTEN=TAB,
                      TIMEOUT=15,
                      DEFCCHR=00
    

    PINPTBL vector

    Defines an input translation table to be used by BIWP when reading the PIN pad. Define one PINPTBL vector for every PIN pad input table that you want to use in your workgroups.

    A quick reference


    Vector position None
    List of keywords EXTEN, FILLER, KEY0 to KEY9, KEYSCP, KEYSEP, KEYENDP
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    PAR&BIWP (parameter 16)

    Vector format PINPTBL EXTEN=xxx,
    [FILLER=x,]
    [KEY0=(   ),]
    [KEYSCP=(   ),]
    [KEYSEP=(   ),]
    [KEYENDP=(   )]

    Keyword
    Description

    EXTEN
    Is a required keyword to define a PIN pad input table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all MSROUTBL vectors.

    When defining a BIWP, one of the parameters of the PAR&BIWP keyword is a pointer to this identification.

    FILLER
    Is an optional keyword to define the ASCII character that will appear on the screen when any PIN pad key is pressed.

    The parameter value is one ASCII character. Special characters have to be put between single quotes (''). The default is an asterisk (*).

    KEY0 to KEY9
    Are optional keywords to associate the data or end of message indicators to every character (0 to 9), read from PIN pad. KEY0 is the keyword related to character 0, KEY1 to character 1, and so on.

    You must write the corresponding KEYx for every character in PIN pad for which you want to generate data or EOM indicator. If the keyword is omitted for a character, no data will be sent to the 4700 when this character is read. Each keyword has three parameters:

    1. The first parameter specifies the character that will be sent to the 4700 when the key is pressed. This parameter is required, if the keyword has been specified.

      The value must be a 2-byte digit and must be unique in the vector.

    2. The second parameter specifies whether the key is operational or not. The parameter value must be either H (the key is operational and hidden) or N (the key is not operational). The default is N.
    3. The third parameter specifies whether the key is associated with an EOM indicator or not. The parameter value can be either Y (Yes) or N (No). The default is N.

    KEYSCP
    Is an optional keyword to define the 2-byte value of the character to be sent to the 4700 when the start of the clear PIN indicator is read from the PIN pad. You can also associate an EOM indicator to it.

    If the keyword is omitted, the defaults will be assumed.

    The keyword has three parameters:

    1. The first parameter specifies the character that will be sent to the 4700 when the start of the clear PIN indicator is read.

      The value must be a 2-byte digit and must be unique in the vector.

      The default is 7F.

    2. The second parameter specifies whether the key is operational or not. The parameter value must be either H (the key is operational and hidden) or N (the key is not operational). The default is N.
    3. The third parameter specifies whether the key is associated with an EOM indicator or not. The parameter value can be either Y (Yes) or N (No). The default is N.

    KEYSEP
    Is an optional keyword to define the 2-byte value of the character to be sent to the 4700 when the start of the encrypted PIN indicator is read from the PIN pad. You can also associate an EOM indicator to it.

    If the keyword is omitted, the defaults will be assumed.

    The keyword has three parameters:

    1. The first parameter specifies the character that will be sent to the 4700 when the start of the encrypted PIN indicator is read.

      The value must be a 2-byte digit and must be unique in the vector.

      The default is 7E.

    2. The second parameter specifies whether the key is operational or not. The parameter value must be either H (the key is operational and hidden) or N (the key is not operational). The default is N.
    3. The third parameter specifies whether the key is associated with an EOM indicator or not. The parameter value can be either Y (Yes) or N (No). The default is N.

    KEYENDP
    Is an optional keyword to define the 2-byte value of the character to be sent to the 4700 when the end of PIN indicator is read from the PIN pad. You can also associate an EOM indicator to it.

    If the keyword is omitted, the defaults will be assumed.

    The keyword has three parameters:

    1. The first parameter specifies the character that will be sent to the 4700 when the end of PIN indicator is read.

      The value must be a 2-byte digit and must be unique in the vector.

      The default is 7F.

    2. The second parameter specifies whether the key is operational or not. The parameter value must be either H (the key is operational and hidden) or N (the key is not operational). The default is N.
    3. The third parameter specifies whether the key is associated with an EOM indicator or not. The parameter value can be either Y (Yes) or N (No). The default is N.

    PINPTBL vector example

     /* Vector PINPTBL  Default Example */
     
             PINPTBL  EXTEN=PIN,
                      FILLER=*,
                      KEY0=(F0,H,N),
                      KEY1=(F1,H,N),
                      KEY2=(F2,H,N),
                      KEY3=(F3,H,N),
                      KEY4=(F4,H,N),
                      KEY5=(F5,H,N),
                      KEY6=(F6,H,N),
                      KEY7=(F7,H,N),
                      KEY8=(F8,H,N),
                      KEY9=(F9,H,N),
                      KEYSCP=(7F,H,N),
                      KEYSEP=(7E,H,N),
                      KEYENDP=(7F,H,N)
    

    RCMSLNF vector




    ehcodw

    Defines remote change management services (RCMS) logical names according to NetView DM conventions.

    RCMS is primarily concerned with activities between the host and workstation, such as storing files sent from the host to the workstation, and sending files from the workstation to the host.

    Because the host and workstation use different code formats, RCMS needs an EBCDIC-to-ASCII translation table to convert the strings received from the host, and an ASCII-to-EBCDIC table for messages to the host. Both translation tables are defined in the XLATETBL vector for types AERCMS and EARCMS.

    You also need a logical name, relating the file identification in the host to the path and file name in the workstation.

    Files that are visible to the host and can be distributed by Netview Distribution Manager (DM) must follow predefined conventions. Editing the RCMS logical name file allows you to add, delete, and update host-to-workstation filename mapping. Thus, Netview DM can manage and control distribution of software and data resources. Identical logical names and workstation file paths are not permitted.

    One vector has to be defined for each RCMS logical name you want to specify.

    A quick reference


    Vector position None
    List of keywords NAME, PATH
    Vector format RCMSLNF NAME=xxxxxxxx,
    PATH=path

    Keyword
    Description

    NAME
    Is a required keyword to define the logical name that will be used in the host to identify a file or group of files in workgroup workstations.

    The parameter value is a string of up to eight characters starting with an alphabetical character. It must be unique among all RCMS logical names.

    PATH
    Is a required keyword to define the path and file name in the workstation.

    The parameter value is a string of up to 64 characters and must adhere to DOS specifications for path and file names. It must be unique among all RCMLNF vectors.

    RCMSLNF vector example

     /* Vector RCMSLNF Example */
     
             RCMSLNF  NAME=NAME001,
                      PATH=C:\LEVEL1\LEVEL2\LEVEL3\
    

    For more information on RCMS see LANDP Servers and System Management.

    RECDEF vector

    Defines a record structure. Every record you define has a name and can contain several fields. Every field in the record has a name and associated parameters to enable validation when the data is updated. Up to 92 fields can be defined in the RECFIELD vector.

    Up to 250 RECDEF statements can be defined.

    The record definition facility supports the following record formats:

    The record definition facility defines the record structures used by the following LANDP family servers:

    The validate record (VR) function of the System Manager server can be used to validate data against the record structure defined by the RECDEF vector.

    The applications and the user servers can also use the record structures defined with this vector.

    A quick reference


    Vector position None. Can be followed by up to 92 RECFIELD vectors.
    List of keywords NAME, DELIMIT, DECSEP
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    RECNAME (EJOUREC, SHFLDBD, and SFORWREC vectors)

    Vector format RECDEF NAME=xxxxxxxx,
    [DELIMIT=x,]
    [DECSEP=x]

    Keyword
    Description

    NAME
    Is a required keyword to define the name of a record structure.

    The parameter value is a string with up to eight alphanumeric characters. It must be unique for all the RECDEF vectors.

    This name can be referenced by the electronic journal server (EJOUREC vector), the shared-file server (SHFLDBD vector), or the store-for-forwarding server (SFORWREC vector).

    DELIMIT
    Is an optional keyword to define the character used to mark the end of a variable length field. A delimiter is required if the field is variable length.

    Parameter values are the special characters \, /, $, @, &, and %. They must be enclosed between single quotes. The default is '/'.

    If you specify pure DBCS or mixed, SBCS and DBCS, field format in an associate RECFIELD vector, characters \ and @ are not supported as delimiters.

    DECSEP
    Is an optional keyword to define the decimal separator, that is, the character to separate the integer part of a numeral from the fractional (decimal) part.

    The parameter value can either be the period (.) or the comma (,). They must be enclosed between single quotes. The default is the comma (,).

    RECDEF vector example

     /* Vectors RECDEF and RECFIELD Examples */
     
    /* RECORD1 Definition */
             RECDEF   NAME=RECORD1,
                      DELIMIT='/',
                      DECSEP=','
             RECFIELD NAME=REC1FL01,
                      LENGTH=4,
                      FORMAT=C,
                      DESCRIPT='TRANSACTION'
             RECFIELD NAME=FILLER1,
                      LENGTH=2,
                      FORMAT=C,
                      DESCRIPT='2 BYTE FILLER'
             RECFIELD NAME=REC1FL02,
                      LENGTH=10,
                      FORMAT=N,
                      DECIMALS=2,
                      DESCRIPT='AMOUNT'
             RECFIELD NAME=REC1FL03,
                      LENGTH=8,
                      FORMAT=N,
                      DECIMALS=0,
                      DESCRIPT='CLIENT NUMBER'
     
    /* RECORD2 Definition */
             RECDEF   NAME=RECORD2,
                      DELIMIT='/',
                      DECSEP=','
             RECFIELD NAME=REC2FL01,
                      LENGTH=10,
                      FORMAT=N,
                      DECIMALS=2,
                      DESCRIPT='BALANCE'
             RECFIELD NAME=REC2FL02,
                      LENGTH=4,
                      FORMAT=P,
                      DECIMALS=0,
                      DESCRIPT='CHECK TOTAL'
    
             RECFIELD NAME=REC2FL03,
                      LENGTH=4,
                      FORMAT=P,
                      DECIMALS=0,
                      DESCRIPT='CASH TOTAL'
    

    RECFIELD vector

    Defines a field inside a record structure.

    At least one RECFIELD vector must be specified following a RECDEF vector. Up to 92 RECFIELD vectors can follow a RECDEF vector.

    A quick reference


    Vector position Follows RECDEF vector. This vector can exist up to 92 times after a RECDEF vector.
    List of keywords NAME, DECIMALS, DESCRIPT, FORMAT, LENGTH
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    KEYxx (EJOUPRF, SHFLDBD, and SFORWPRF vectors),
    KEYFIELD (SHFLPCB vector)

    Vector format RECFIELD NAME=xxxxxxxx,
    [DECIMALS=x,]
    [DESCRIPT='   ',]
    [FORMAT=xx,]
    LENGTH=xxxx

    Keyword
    Description

    NAME
    Is a required keyword to define the field name.

    The parameter value is a string of up to eight alphanumeric characters plus the special characters $, %, #, and @. It must start with an alphanumeric character and must be unique within one RECDEF vector, but can be repeated in different RECDEF vectors.

    DECIMALS
    Is an optional keyword to define the number of decimal places in a field. This parameter only applies to the field format types N (ASCII numeric), SN (signed ASCII numeric), P (Packed), and SP (signed packed).

    The parameter value can be a number from 0 to 9, and must not be greater than the field length. The default is 0.

    DESCRIPT
    Is an optional keyword that contains the logical description of the field.

    The parameter value is a string with up to 30 alphanumeric characters. As this field may contain blanks or special characters, it must be enclosed between quotes. If quotes are part of the description, they must be doubled.

    FORMAT
    Is an optional keyword to define the field formats.

    The parameter values are:

    B
    Inverted binary
    C
    Character
    CD
    DBCS characters (pure DBCS)
    CM
    SBCS and DBCS characters (mixed, SBCS and DBCS)
    H
    Hexadecimal
    I
    Integer
    SI
    Signed Integer
    L
    Long Integer
    SL
    Signed long integer
    N
    ASCII numeric
    SN
    Signed ASCII numeric
    P
    Packed
    SP
    Signed packed

    Values CD and CM apply only to DBCS mode. The default is C.

    LENGTH
    Is a required keyword to define the length of the field.

    The parameter values are numeric characters from 0 to 4096. The allowed length depends on the field format:

    B, I, and SI
    2 (can be omitted)

    L, SL
    4 (can be omitted)

    C, CD, CM, H, N, and SN
    A number from 0 to 4096 (cannot be omitted). If you specify 0, the field has variable length, and the delimiter is used to indicate the end of the field. Type CD requires an even number.

    P and SP
    A number from 1 to 4096. The length of a packed field (P) is the display length excluding the decimal separator. If this packed field is signed (SP), you have to add one byte. The storage length of a packed field is the display length divided by two and rounded up.

    Variable fields in a record will be considered length 1. At run time, the sum of all lengths in a record cannot exceed 4096 bytes.

    RECFIELD vector example

     /* Vectors RECDEF and RECFIELD Examples */
     
    /* RECORD1 Definition */
             RECDEF   NAME=RECORD1,
                      DELIMIT='/',
                      DECSEP=','
             RECFIELD NAME=REC1FL01,
                      LENGTH=4,
                      FORMAT=C,
                      DESCRIPT='TRANSACTION'
             RECFIELD NAME=FILLER1,
                      LENGTH=2,
                      FORMAT=C,
                      DESCRIPT='2 BYTE FILLER'
             RECFIELD NAME=REC1FL02,
                      LENGTH=10,
                      FORMAT=N,
                      DECIMALS=2,
                      DESCRIPT='AMOUNT'
             RECFIELD NAME=REC1FL03,
                      LENGTH=8,
                      FORMAT=N,
                      DECIMALS=0,
                      DESCRIPT='CLIENT NUMBER'
     
    /* RECORD2 Definition */
             RECDEF   NAME=RECORD2,
                      DELIMIT='/',
                      DECSEP=','
             RECFIELD NAME=REC2FL01,
                      LENGTH=10,
                      FORMAT=N,
                      DECIMALS=2,
                      DESCRIPT='BALANCE'
             RECFIELD NAME=REC2FL02,
                      LENGTH=4,
                      FORMAT=P,
                      DECIMALS=0,
                      DESCRIPT='CHECK TOTAL'
    
             RECFIELD NAME=REC2FL03,
                      LENGTH=4,
                      FORMAT=P,
                      DECIMALS=0,
                      DESCRIPT='CASH TOTAL'
    

    SFORWPRF vector

    Defines a store-for-forwarding server profile. Define one SFORWPRF vector for each store-for-forwarding profile you want to specify.

    You must define as many records as you need in vectors RECDEF and RECFIELD.

    A quick reference


    Vector position None. Can be followed by at least one SFORWREC vector.
    List of keywords NAME, DATASETS, SEPSESS, MAXACC, SHFLPRF, DBDPATH, DBDPATH6, SPLIT, KEY02 to KEY15
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR&SFOR (parameter 1)
    SHFLPRF
    SHFLPRF (SHFLDBD vector)
    KEYxx
    NAME (RECFIELD vector)

    Vector format SFORWPRF NAME=xxxxxxxx,
    [DATASETS=xx,]
    [SEPSESS=x,]
    [MAXACC=xxxxx,]
    SHFLPRF=xxxxxxxx,
    DBDPATH=path,
    DBDPATH6=path,
    SPLIT=length,
    [KEY02=xxxxxxxx,]
    :
    [KEY15=xxxxxxxx]

    Keyword
    Description

    NAME
    Is a required keyword to define the name of the store-for-forwarding profile. The parameter value is a field with up to eight alphanumeric characters plus the special characters $, %, #, and @. It must be unique among all SFORWPRF vectors.

    DATASETS
    Is an optional keyword to define the number of different store-for-forwarding data sets to be used.

    The parameter value is a field with up to two characters, ranging from 1 to 64. The default is 3.

    If you are using the forwarding server, this value must be greater than or equal to the number of FORWDS vectors defined for the forwarding profile that will be used together with this profile. The other data sets will not be forwarded and can be accessed by the applications.

    SEPSESS
    Is an optional keyword to define the method for providing integrity for data access to the store-for-forwarding server records.

    Specify Y (Yes) if you want session integrity to be handled by the store-for-forwarding server, independently of your own shared-file server session. The default is N (No).

    MAXACC
    Is an optional keyword to define the maximum number of accesses in search operations. This is the maximum number of searches made before the search operation is ended and control is returned to the application.

    The parameter value is a string of up to 5 numeric characters, which can range from 1 to 32767. The default is 200.

    SHFLPRF
    Is a required keyword to define the name of the shared-file profile to be used. You can use the name of an already defined shared-file profile in the SHFLPRF keyword of the SHFLDBD vector, or a new name. If you provide a new profile name, the corresponding shared-file profile is created by the LANDP customization.

    In any case, the customization adds to the shared-file profile the DBD and PCB definitions required for this store-for-forwarding profile.

    The same shared-file profile can only be used by one store-for-forwarding profile. If you have the store-for-forwarding server and the electronic journal server in the same workstation, you must use the same shared-file profile for both of them.

    The parameter value is a field with up to eight alphanumeric characters. It must be unique among the SFORWPRF vectors.

    DBDPATH
    Is a required keyword for LANDP for OS/2, LANDP for Windows, and LANDP for DOS, to define the path where the store-for-forwarding data and index files are located. This path must exist prior to running the LANDP family programs in a workstation with the store-for-forwarding server services.

    The parameter value is the complete path (drive plus subdirectories). The number of subdirectories must not exceed four, and has to end with a back slash (\). It must at least contain three characters.

    DBDPATH6
    Is a required keyword for LANDP for Linux. It defines the path where the data and index files are located in a Linux system.

    The parameter value is the complete path including the subdirectories. It must not exceed 56 characters, and must be enclosed within single quotes ('). Each subdirectory name included in the path must have one character at least, and 30 characters at most. A backslash ('\') must not be present after the last subdirectory name.

    As with the DBDPATH keyword, the path must exist prior to running the LANDP family programs in a workstation with the shared file server.

    SPLIT
    Is a required keyword to define the length of the user record that can be kept in one store-for-forwarding record.

    Parameter values range from 62 to 4096 minus the size of the header that is appended. The header length is the length of all the defined keys (including the store-for-forwarding hidden key SFHIDKEY which is 8 bytes long), plus 36.

    If the record size exceeds the number specified, it will be split into two or more segments.

    KEY02 to KEY15
    Are optional parameters to define the names of the fields used as keys. These field names must be defined in at least one of the records specified in the SFORWREC vectors. If fields specified as keys are defined in more than one record, the characteristics of the field must match.

    Fields in a record can be selected as store-for-forwarding keys only if they are in character, unsigned ASCII numeric, or hexadecimal, and their length is fixed and less than 50 bytes.

    The keys must be specified sequentially; for example, KEY05 cannot be specified if KEY04 was omitted. The first key (KEY01) is not defined. It is always the store-for-forwarding hidden key SFHIDKEY.

    SFORWPRF vector example

     /* Vectors SFORWPRF and SFORWREC Examples */
     
             SFORWPRF NAME=SFFPRF01,
     
                      DATASETS=10,
                      SEPSESS=N,
                      MAXACC=200,
                      SHFLPRF=SFPROF01,
                      DBDPATH=C:\TELLER\SFORW\,
                      SPLIT=1024,
                      KEY02=REC1FL03,
                      KEY03=REC2FL02
     
            SFORWREC  RECNAME=RECORD1
            SFORWREC  RECNAME=RECORD2
    

    SFORWREC vector

    Defines the names of the records defined with the RECDEF vector which will be used as store-for-forwarding records.

    At least one SFORWREC vector must be specified following a SFORWPRF vector.

    A quick reference


    Vector position Follows SFORWPRF vector
    List of keywords RECNAME
    Keywords relate to
    Keyword
    Relates to keywords
    RECNAME
    NAME (RECDEF vector)

    Vector format SFORWREC RECNAME=xxxxxxxx

    Keyword
    Description

    RECNAME
    Is a required keyword to specify a name of a record which will be used as an store-for-forwarding record.

    The parameter value is a field with up to eight alphanumeric characters, and must match the name given in keyword NAME of RECDEF vector.

    If a record has a field with name AND or OR, the record cannot be selected as store-for-forwarding record.

    SFORWREC vector example

     /* Vectors SFORWPRF and SFORWREC Examples */
     
             SFORWPRF NAME=SFFPRF01,
     
                      DATASETS=10,
                      SEPSESS=N,
                      MAXACC=200,
                      SHFLPRF=SFPROF01,
                      DBDPATH=C:\TELLER\SFORW\,
                      SPLIT=1024,
                      KEY02=REC1FL03,
                      KEY03=REC2FL02
     
            SFORWREC  RECNAME=RECORD1
            SFORWREC  RECNAME=RECORD2
    

    SHFLDBD vector

    Defines a shared-file database description (DBD) for the shared-file server. You can define up to 2048 DBDs.

    For each shared-file server you create:

    A shared-file profile is made up of all the SHFLDBD vectors which have the same identification in keyword SHFLPRF.

    Define one SHFLDBD vector for each shared-file database that you want to use in a shared-file profile. A shared-file profile is defined or referenced in the SHFLPRF keyword of this vector.

    A quick reference


    Vector position None. Can be followed by as many SHFLPCB vectors as needed.
    List of keywords SHFLPRF, DBDNAME, RECNAME, COLLKEYS, PHYSREC, RECLEN, DBDPATH, DBDPATH6, DBFLNAME, KEY01 to KEY15
    Keywords relate to
    Keyword
    Relates to keywords
    SHFLPRF
    SHFLPRF (EJOUPRF and SFORWPRF vectors),
    NAME (COLSQTBL vector),
    PAR&SHFL (parameter 1)
    RECNAME
    NAME (RECDEF vector)

    Vector format SHFLDBD SHFLPRF=xxxxxxxx,
    DBDNAME=xxxxxxxx,
    [RECNAME=xxxxxxxx,]
    [COLLKEYS=x,]
    [PHYSREC=xxxxx,]
    [RECLEN=xxxxx,]
    DBDPATH=path,
    DBDPATH6=path,
    DBFLNAME=xxxxxxxx,
    [KEY01=(   )],
    .
    .
    [KEY15=(   )],
    [MINLOCKS=xxxxx,],
    [TLOCKS=xxxxx,]

    Keyword
    Description

    SHFLPRF
    Is a required keyword to define the name of the shared-file profile for this DBD. The parameter value is a string with up to eight alphanumeric characters.

    If you specify to use an alternate collating sequence table, you can define the table and reference the SHFLPRF name in the keyword NAME of the COLSQTBL vector.

    DBDNAME
    Is a required keyword to define the name of one DBD in a shared-file profile. The parameter value is a string with up to eight alphanumeric characters. It must be unique in the profile.

    Do not use names starting with FBEJ, since they are reserved for electronic journal DBDs. Those starting with FBSF are reserved for store-for-forwarding DBDs.

    Applications refer to a DBD by using one of the related program control blocks (SHFLPCB vectors).

    RECNAME
    Is an optional keyword with the name of a record structure (defined in the RECDEF vector) to be used as a pattern for name, length, and offset of the key fields.

    If specified, it must match the name given in a RECDEF vector, keyword NAME.

    If no record structure is referenced, the characteristics of each key field must be defined (KEY01 to KEY15). Records with variable length fields cannot be used as a pattern.

    COLLKEYS
    Is an optional keyword to define whether an alternate collating sequence table will be used or not.

    The parameter values are:

    Y (Yes) - the table will be used
    N (No) - the table will not be used

    The default is N.

    This definition is valid for the third parameter of the key definitions (keywords KEYxx). If you select Y, you can define for each key whether the alternate collating sequence table will be used or not. If you use the default, the keys must also be defaulted to N.

    PHYSREC
    Is an optional keyword to define the record split size. This enables the use of variable length records inside the shared file server databases. No record can be split into more than 200 physical records.

    The parameter value can be between 44 (minimum length) and the data record length specified in the RECLEN keyword.

    Each physical record contains 5 control bytes. Thus, the number of user data bytes in a physical record will be the parameter value you specify in the PHYSREC keyword minus 5.

    RECLEN
    Is a keyword to define the record length, that is, the number of bytes in each data record.

    If you have specified to use a previously defined record structure (keyword RECNAME), the keyword does not apply.

    If you have not specified it, the keyword is required. The parameter value can be between 44 (minimum length) and 26624 (maximum length).

    DBDPATH
    Is a required keyword for LANDP for OS/2, LANDP for Windows, and LANDP for DOS, to define the path where the data and index files will be located.

    The parameter value is the complete path (drive plus subdirectories). It must not exceed 56 characters, and contain at least 3 characters. Always include the final \ (backslash) after the last directory.

    The path must exist prior to running the LANDP family programs in a workstation with the shared-file server.

    DBDPATH6
    Is a required keyword for LANDP for Linux. It defines the path where the data and index files are located in a Linux system.

    The parameter value is the complete path including the subdirectories. It must not exceed 56 characters, and must be enclosed within single quotes ('). Each subdirectory name included in the path must have one character at least, and 30 characters at most. A backslash ('\') must not be present after the last subdirectory name.

    As with the DBDPATH keyword, the path must exist prior to running the LANDP family programs in a workstation with the shared file server.

    DBFLNAME
    Is a required keyword to define the name of the data and index files.

    The parameter value is a field with up to eight characters for the file name. The file extension must be omitted. They will be DAT for data, or IXn (or Inn for those nn greater than or equal to 10) for key index files.

    KEY01 to KEY15
    Are optional keywords to define the key fields.

    The keys must be specified sequentially; for example, KEY05 cannot be specified if KEY04 was omitted.

    If keyword KEY01 is omitted, only direct or sequential access will be allowed for this DBD.

    If you have not defined a record name in keyword RECNAME, all key parameters have to be specified. If RECNAME has been defined, the name, key class, and the use of alternate collating sequence table parameters must be specified. Key length and key offset, however, must not be specified.

    If you have selected the default (N) for an alternate collating sequence table (keyword COLLKEYS), do not specify the third parameter of these keywords.

    Each keyword has five parameters:

    1. The first parameter specifies the name of the key field. If RECNAME was specified, this name must reference a field in the record structure definition. The name will be used to refer to this key in the SHFLPCB vector.

      The parameter value is an alphanumeric field with up to eight characters.

    2. The second parameter specifies the key class. The parameter value can be:
      P
      Cannot be changed, unique
      S
      Can be changed, not unique
      M
      Cannot be changed, not unique
      D
      Can be changed, unique

      The default is S.

    3. The third parameter specifies information related to alternate collating sequence. The parameter value can be:

      N
      The key does not require alternate collating sequence.

      Y
      The key requires alternate collating sequence, using a table with extension SEQ.

      X
      The key requires alternate collating sequence, using a table with extension SEX, where X can be any hexadecimal character, except for 0.

      D
      The key requires DBCS-style alternate collating sequence.

      The parameter does not apply to segmented keys. The parameter value S applies only to DBCS mode. The default is N.

    4. The fourth parameter specifies either segmented key or the key field length, that is, the number of bytes the field contains.

      If you plan to define a segmented key, specify value 0. To specify a non-segmented key field length, the parameter value can be between 1 and 255.

    5. The fifth parameter specifies the key field offset, that is, the byte in the data record that denotes the beginning of a key. Byte numbering in the data record begins with 0.

      The parameter does not apply to segmented keys. The parameter value can be between 0 and 26623. The offset specified for a key plus the key length must not exceed the data record length.

    MINLOCKS
    Is an optional keyword that has no effect. It is provided as a migration aid from LANDP Version 1.0. If specified, it must be in the range 1 through 10922.

    TLOCKS
    Is an optional keyword that has no effect. It is provided as a migration aid from LANDP Version 1.0. If specified, it must be in the range 1 through 10922.

    SHFLDBD vector examples

     /* Vectors SHFLDBD, SHFLPCB, and SHFLSGM Examples */
     
             SHFLDBD  SHFLPRF=SAMPLE1,
                      DBDNAME=SAMP1DBD,
                      COLLKEYS=N,
                      RECLEN=100,
                      DBDPATH=D:\,
                      DBDPATH6='/var/opt/landp/acc',
                      DBFLNAME=SAMP1FIL,
                      KEY01=(F1P,P,,0),
                      KEY02=(F1S,S,N,15,5)
     
             SHFLPCB  PCBNAME=PCBS1
             SHFLPCB  PCBNAME=PCBSF1P,
                      KEYFIELD=F1P
             SHFLPCB  PCBNAME=PCBSF1S,
                      KEYFIELD=F1S
             SHFLSGM  SGMKEY=1,
                      SGM01=(YEAR,D,2,34),
                      SGM02=(MONTH,D,2,32),
                      SGM03=(DAY,D,2,30)
    
    /* Segmented keys using RECNAME */
     
             RECDEF   NAME=RECORDX,
                      DELIMIT='\',
                      DECSEP=','
             RECFIELD NAME=REC1FL01,
                      LENGTH=4,
                      FORMAT=C,
                      DESCRIPT='Transaction'
             RECFIELD NAME=FILLER1,
                      LENGTH=2,
                      FORMAT=C,
                      DESCRIPT='2-byte filler'
             RECFIELD NAME=REC1FL02,
                      LENGTH=10,
                      FORMAT=N,
                      DECIMALS=2,
                      DESCRIPT='Amount'
             RECFIELD NAME=REC1FL03,
                      LENGTH=8,
                      FORMAT=N,
                      DECIMALS=0
                      DESCRIPT='Client number'
     
             SHFLDBD  SHFLPRF=SFSPRF,
                      DBDNAME=DBD1,
                      RECNAME=RECORDX,
                      DBDPATH=E:\LANDP\DATA\,
                      DBFLNAME=SAMP1FIL,
                      KEY01=(SGMKEY,P,,0) 
             SHFLPCB  PCBNAME=PCBS1,
                      KEYFIELD=SGMKEY
             SHFLSGM  SGMKEY=1,
                      SGM01=(REC1FL03,D),
                      SGM02=(REC1FL01,D),
                      SGM03=(REC1FL02,D)
    

    SHFLPCB vector

    Defines a program control block (PCB) to access a previously defined DBD. You can define up to 2048 PCBs.

    At least one SHFLPCB vector has to be specified for each access to a key field you are going to define.

    A quick reference


    Vector position Follows SHFLDBD vector
    List of keywords PCBNAME, KEYFIELD
    Keywords relate to
    Keyword
    Relates to keywords
    KEYFIELD
    NAME (RECFIELD vector)

    Vector format SHFLPCB PCBNAME=xxxxxxxx,
    [KEYFIELD=xxxxxxxx]

    Keyword
    Description

    PCBNAME
    Is a required keyword to define a name of a program control block (PCB) to be used by the application to refer to a particular DBD.

    The parameter value is an alphanumeric field with up to eight characters. It must be unique among the SHFLPCB vectors for this profile.

    KEYFIELD
    Is an optional keyword to define the name of the key field used to access the DBD for this PCB. It is used for indexed sequential access and indexed direct access.

    The parameter value is the name given in the first parameter of the KEYxx keyword in the SHFLDBD vector.

    All key fields defined in the DBD must have a corresponding PCB, if you want the record to be accessed through this key.

    If the key name is omitted, the PCB is used for sequential or direct access (not indexed).

    SHFLPCB vector examples

    See SHFLDBD vector examples.

    SHFLSGM vector

    Defines a segmented key. Specify one SHFLSGM vector for each segmented key specified through the KEYxx keywords in the SHFLDBD vector.

    A quick reference


    Vector position Follows SHFLPCB vectors
    List of keywords SGMKEY, SGM01 to SGM32
    Keywords relate to
    Keyword
    Relates to keywords
    SGMKEY
    KEYxx (SHFLDBD vector)
    SGMxx
    RECNAME (SHFLDBD vector)

    Vector format SHFLSGM SGMKEY=xx,
    SGM01=(   ),
    [SGM02=(   ),]
    .
    .
    [SGM32=(   )]

    Keyword
    Description

    SGMKEY
    Is a required keyword to specify the segmented key.

    The parameter value is an integer, in the range 1 through 15, that is equivalent to the last two digits of the KEYxx keyword of the SHFLDBD vector. A leading zero must not be present (for example, if KEY01 is a segmented key, the corresponding SGMKEY value is 1).

    The total length of all the segments of a segmented key cannot exceed 255.

    SGM01 to SGM32
    Are keywords to define the segments of the segmented key. SGM01 is required. Keywords from SGM02 to SGM32 are optional, and can not be used if the previous one in the sequence has not been specified.

    Each keyword has six parameters:

    1. The first parameter specifies the name of the segment field. If RECNAME was specified in the SHFLDBD vector, this name must reference a field in the record structure definition.

      The parameter value is an alphanumeric field with up to eight characters.

    2. The second parameter specifies the segment type. The parameter value can be:
      D
      Data
      I
      Indicator
      L
      Locally nullable
      G
      Globally nullable

      The default is D.

    3. The third parameter specifies the segment field length, that is, the number of bytes the field contains.

      If RECNAME was specified in the SHFLDBD vector, the parameter does not apply. The parameter value can be between 1 and 255.

    4. The fourth parameter specifies the segment field offset, that is, the byte in the data record that denotes the beginning of the segment. Byte numbering in the data record begins with 0.

      If RECNAME was specified in the SHFLDBD vector, the parameter does not apply. The parameter value can be between 0 and 26623.

      The offset specified for a segment plus the segment length must not exceed the data record length (RECLEN keyword in SHFLDBD vector).

    5. The fifth parameter specifies information

      N
      The segment does not require alternate collating sequence.

      Y
      The segment requires alternate collating sequence, using a table with extension SEQ.

      X
      The segment requires alternate collating sequence, using a table with extension SEX, where X can be any hexadecimal character, except for 0.

      S
      The segment requires DBCS-style alternate collating sequence.

      The parameter value S applies only to DBCS mode. The default is N.

    6. The sixth parameter specifies the segment nullable value, that is, the character for comparison to make null a segment.

      The parameter does not apply to data or indicator segments, and is required for locally or globally nullable segments. The parameter value is a string of two hexadecimal digits.

    SHFLSGM vector examples

    See SHFLDBD vector examples.

    SMGRPRF vector

    Defines a system manager server profile. One vector has to be defined for each system manager server profile you want to use.

    There are two conditions that determine if record structures (defined in vector RECDEF) are used by the system manager server:

    1. LAN common data validation

      If the system manager server is to validate the LAN common data, the customization creates the LAN common data, based on the record structure of record FBSSGLUS. This record must be created before defining a system manager server profile.

    2. Application data validation

      If the system manager server is to validate the application data, a record structure named FBSSUSPR must exist and is used to build the application data. You must create this record structure before you define a system manager server profile.

    The records FBSSGLUS and FBSSUSPR can have up to 1024 bytes and cannot contain variable length fields.

    A quick reference


    Vector position None. If you define that system security will be used (SECLVL=Y), this vector must be followed by SMGRUSER vectors that define the authorization level of each user.
    List of keywords NAME, LANID, LOGSUPP, SECLVL, AUTSYNC, COMDTVAL, APPDTVAL, LOGFSIZE, LOGRECL, LEVELS, LEVELF, LEVELR, LEVELOA, LEVELM, MSGOPRCV, ALRHNDLR
    Keywords relate to
    Keyword
    Relates to keywords
    NAME
    PAR&SMGR (parameter 4)
    MSGOPRCV
    USERID (SMGRUSER vector)

    Vector format SMGRPRF NAME=xxxxxxxx,
    [LANID=xxxxxxxx,]
    [LOGSUPP=x,]
    [SECLVL=x,]
    [AUTSYNC=x,]
    [COMDTVAL=x,]
    [APPDTVAL=x,]
    [LOGFSIZE=xxx,]
    [LOGRECL=xxxx,]
    [LEVELS=x,]
    [LEVELF=x,]
    [LEVELR=x,]
    [LEVELOA=x,]
    [LEVELM=x,]
    [MSGOPRCV=x,]
    [ALRHNDLR=x]

    Keyword
    Description

    NAME
    Is a required keyword to define the system manager profile name.

    The parameter value is a string with up to eight alphanumeric characters plus the special characters $, %, #, and @. It must start with an alphabetical character, and must be unique among all SMGRPRF vectors.

    LANID
    Is an optional keyword to identify the workgroup. It is used by the system manager server to complete the hierarchy subvector of the alert as a service point (SP).

    The parameter value is a string with up to eight alphanumeric characters plus the special characters $, %, #, and @. The default is LANID.

    It is strongly recommended that the value matches the PU name defined in VTAM for the workstation providing SNA services for alerts. For OS/2 and Windows NT workstations, it is also recommended that the value matches SNA local node name (control point alias) defined in the communications provider configuration file, so that the RUNCMD files sent from the host computer can reach the LANDP workgroup.

    LOGSUPP
    Is an optional keyword to define whether you want to have system manager support for the system and user LOG (Y). The default is no (N).

    The LOG file is created and maintained by the LANDP System Manager server. It can only be deleted when the LANDP program is not running.

    If you select Y for this keyword, LOGFSIZE and LOGRECL keywords must be specified, or the default values will be taken. If you select N, these keywords do not apply.

    SECLVL
    Is an optional keyword to define if you want the system manager to control access to the LANDP family resources.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    If you select Y for this keyword, you must choose which authorization levels you want the system manager to control. You do this by using the LEVELx keywords of the same vector. You must also have a user assigned as system manager administrator, so the keyword LEVELOA must be Y.

    If you select N, no LEVELx=Y can be specified.

    AUTSYNC
    Is an optional keyword to define if the system manager will provide automatic synchronization of date and time in all personal computer and PS/2 workstations in the workgroup.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    COMDTVAL
    Is an optional keyword to define if the system manager performs validation of the LAN common data. This validation requires the FBSSGLUS record, defined in the RECDEF vector.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    APPDTVAL
    Is an optional keyword to define if the system manager performs validation of the application data. This is data about the user, not about user transactions. This validation requires the FBSSUSPR record, defined in the RECDEF vector.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LOGFSIZE
    Is an optional keyword to define the log file size. When the log file is full, it wraps and begins overlaying records at the beginning of the file. It is only applicable, if LOGSUPP=Y.

    The parameter values range from 10 to 500KB. The default is 100.

    LOGRECL
    Is an optional keyword to define the log record size. It is only applicable, if LOGSUPP=Y.

    The parameter values range from 128 to 1024 bytes of memory (that is 960 bytes of data). The default is 128.

    LEVELS
    Is an optional keyword to define whether the system manager server controls access to the debug and trace tools (DDT) and log files (LOG).

    This is security level S.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LEVELF
    Is an optional keyword to define whether the system manager server controls access to the LANDP family resources. This is security level F.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    If you have defined your workgroup to use LEVELF security, a user must be signed on with LEVELF authority to use any applications from a LANDP workstation.

    LEVELR
    Is an optional keyword to define whether the system manager server controls access to the shared DOS directory. This is security level R.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LEVELOA
    Is an optional keyword to define whether the system manager server controls access to administrator and operator functions. Authorization for access for system manager operators is security level O, for system manager administrators it is A.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    If you select Y for this keyword, at least one LEVELA=Y user must be specified in the SMGRUSER vector.

    LEVELM
    Is an optional keyword to define whether the system manager server controls access for administrator and operator functions from an application instead of from system manager operator. This is security level M.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    Select Y if you want to designate one or more users of the applications to have access to the administrator and operator functions.

    MSGOPRCV
    Is an optional keyword to define the user identification of the operator messages receiver. This user must have authorization level O. The name must be referenced in keyword USERID in one of the SMGRUSER vectors.

    The parameter value is a string of up to eight alphanumeric characters.

    If only one LEVELO=Y has been specified in the SMGRUSER vector, or if LOGSUPP=N has been defined, this keyword can be omitted. Otherwise, it must be specified.

    ALRHNDLR
    Is an optional keyword to define the Alert Handler User Exit.

    The parameter value is a string of up to eight alphanumeric characters. The default is EHCALRH.

    SMGRPRF vector example

     /* Vectors SMGRPRF and SMGRUSER Examples */
     
           SMGRPRF  NAME=SMGRPRF1,
                    LANID=MYLAN,
                    LOGSUPP=Y,
                    SECLVL=Y,
                    AUTSYNC=Y,
                    COMDTVAL=Y,
                    APPDTVAL=Y,
                    LOGFSIZE=200,
                    LOGRECL=512,
                    LEVELS=Y,
                    LEVELF=Y,
                    LEVELR=N,
                    LEVELOA=Y,
                    LEVELM=Y,
                    MSGOPRCV=BOBSM
    
            SMGRUSER USERID=BOBSM,
                    PASSWORD=BOBSMITH,
                    NAME='Bob Smith',
                    LANGUAGE=33,
                    LEVELS=Y,
                    LEVELR=N,
                    LEVELF=Y,
                    LEVELO=Y,
                    LEVELA=Y,
                    LEVELM=N,
                    APPLVL='12345ABCDE'
    

    SMGRUSER vector

    Defines a system manager user profile inside a system manager server profile. One SMGRUSER vector has to be defined for each system manager user profile you want to specify.

    If you have defined your workgroup to use LEVELF security, a user must be signed on with LEVELF authority to use any applications from a LANDP workstation.

    If no SMGRUSER vector is specified when keyword SECLVL=Y in SMGRPRF vector, the defaults will be USERID=SYSTEM and PASSWORD=MANAGER.

    A quick reference


    Vector position Follows SMGRPRF vector
    List of keywords USERID, PASSWORD, PSWCRYPT, NAME, LANGUAGE, LEVELS, LEVELR, LEVELF, LEVELO, LEVELA, LEVELM, APPLVL
    Keywords relate to
    Keyword
    Relates to keywords
    USERID
    MSGOPRCV (SMGRPRF vector)

    Vector format SMGRUSER USERID=xxxxxxxx,
    PASSWORD=xxxxxxxx,
    [PSWCRYPT=password encrypted,]
    [NAME='   ',]
    [LANGUAGE=xx,]
    [LEVELS=x,]
    [LEVELR=x,]
    [LEVELF=x,]
    [LEVELO=x,]
    [LEVELA=x,]
    [LEVELM=x,]
    [APPLVL='   ']

    Keyword
    Description

    USERID
    Is a required keyword to identify the system manager user.

    The parameter value is a string with up to eight alphanumeric characters plus the special characters $, %, #, and @. It must be unique within a system manager profile.

    PASSWORD
    Is a required keyword to define the user password to control user logon.

    The parameter value is a string with four to eight alphanumeric characters plus the special characters $, %, #, and @.

    PSWCRYPT
    This is not an input keyword. The PASSWORD specification will be converted by the GENSPEC program into its encrypted form, and will from then on appear under the PSWCRYPT keyword, which substitutes the PASSWORD keyword.

    This is a security provision. No changes can be made to the encrypted password. In order to change an user password in an already generated profile, you have to substitute the PSWCRYPT keyword by a PASSWORD keyword with the new information.

    NAME
    Is an optional keyword to define the user name.

    The parameter value is an alphanumeric field with a maximum of 30 characters. Since blanks are allowed in this field, it must be enclosed within quotes. If quotes are part of the name, they must be doubled.

    LANGUAGE
    Is an optional keyword to define a language code which will be defined in and used by your own applications.

    The parameter value is a numeric field with two characters, or blanks. For example, you can define language code 01 for Italian and assign this code to various users.

    LEVELS
    Is an optional keyword to define whether the user has access to the debug and trace tools (DDT) and log files (LOG).

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LEVELR
    Is an optional keyword to define whether the user has access to the shared DOS directory.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LEVELF
    Is an optional keyword to define whether the user has access to the LANDP family resources.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    LEVELO
    Is an optional keyword to define whether the user has access to system manager operator services.

    The parameter value can be either Y (Yes) or N (No). The default is N.

    If you want an user to receive the operator messages, you must define at least one user with authorization level O.

    LEVELA
    Is an optional keyword to define whether the user has access to system manager operator services for administrator functions.

    The parameter value can be either Y (Yes) or N (No). The default is Y.

    LEVELM
    Is an optional keyword to define whether the user has authorization to access operator and administrator functions from an application (instead of from the system manager operator).

    The parameter value can be either Y (Yes) or N (No). The default is N.

    APPLVL
    Is an optional keyword to define application authorization levels. Ten different authorization levels are allowed. The user application can use this information to control access to its user application functions.

    The parameter value is a field of up to 10 characters.

    SMGRUSER vector example

     /* Vectors SMGRPRF and SMGRUSER Examples */
     
           SMGRPRF  NAME=SMGRPRF1,
                    LANID=MYLAN,
                    LOGSUPP=Y,
                    SECLVL=Y,
                    AUTSYNC=Y,
                    COMDTVAL=Y,
                    APPDTVAL=Y,
                    LOGFSIZE=200,
                    LOGRECL=512,
                    LEVELS=Y,
                    LEVELF=Y,
                    LEVELR=N,
                    LEVELOA=Y,
                    LEVELM=Y,
                    MSGOPRCV=BOBSM
     
           SMGRUSER USERID=BOBSM,
                    PASSWORD=BOBSMITH,
                    NAME='Bob Smith',
                    LANGUAGE=33,
                    LEVELS=Y,
                    LEVELR=N,
                    LEVELF=Y,
                    LEVELO=Y,
                    LEVELA=Y,
                    LEVELM=N,
                    APPLVL='12345ABCDE'
    

    SOFTPACK vector

    Defines a list of non-LANDP files that are to be distributed with the LANDP runtime files. These files can be application programs, additional device drivers, bitmaps, or any other files required in the LANDP workstation.

    This vector can define two types of pack:

    A quick reference


    Vector position None
    List of keywords PACKNAME, FILENAME, FILEPATH
    Keywords relate to  
    Vector format SOFTPACK PACKNAME=xxxxxxxx,
    FILENAME=xxxxxxxx[.xxx],
    [FILEPATH=path]

    Keyword
    Description

    PACKNAME
    Is a required keyword to define the softpack name. This name is used to group all components of the same pack and to provide the name that is used when the pack is referenced by an LWSCONF or WSMODEL vector.

    FILENAME
    Is a required keyword, to specify either:

    FILEPATH
    Is an optional keyword that defines the full path of the file's location in the customization workstation. The name includes the drive, and all directory names.

    If FILENAME specifies a predefined pack of files, this keyword must be omitted.

    SOFTPACK vector example

     /* Sample of packs of files */
     
      SOFTPACK PACKNAME=PACKO1,
               FILENAME=FILE101.EXE,
               FILEPATH=C:\SUBDIR1\SUBDIR2\
     
      SOFTPACK PACKNAME=PACKO1,
               FILENAME=FILE102.EXE,
               FILEPATH=C:\SUBDIR1\SUBDIR2\
     
      SOFTPACK PACKNAME=PACKO2,
               FILENAME=FILE201.EXE,
               FILEPATH=C:\SUBDIR1\SUBDIR2\
     
      SOFTPACK PACKNAME=PACKO2,
               FILENAME=FILE202.EXE,
               FILEPATH=C:\SUBDIR1\SUBDIR2\
     
    /* Sample of pack of packs */
     
      SOFTPACK PACKNAME=GPACKO1,
               FILENAME=PACK01
     
      SOFTPACK PACKNAME=GPACKO1,
               FILENAME=PACK02
    

    XLATETBL vector

    Defines an ASCII to EBCDIC or an EBCDIC to ASCII translation table. One separate vector has to be specified for each table you are going to define.

    For each type of table, a default table will be created by CREATE. The vectors for these default tables can be generated using GENSPEC.

    A quick reference


    Vector position None
    List of keywords TYPE, EXTEN, DATA0X to DATAFX
    Keywords relate to
    Keyword
    Relates to keywords
    EXTEN
    SES&3270 (parameters 6 and 7),
    PAR&3287 (parameter 2),
    SES&BPP (parameter 5),
    PAR&BIWP (parameters 14 and 15),
    PAR&RCMS (parameters 8 and 9),
    PAR&FORW (parameter 2),
    EXTEN (KBDBIWP, KBD3270, and KBD3270X vectors),
    EAEXTEN (KBDBIWP vector),
    CHSTRID (BPPPARM vector)

    Vector format XLATETBL TYPE=xxxx,
    EXTEN=xxx,
    DATA0X=(   ),
    :
    DATAFX=(   )

    Keyword
    Description

    TYPE
    Is a required keyword to define the table type. It does not apply to DBCS mode.

    The parameter values can be one of the following:

    AE3270
    ASCII to EBCDIC translation for 3270 Emulation
    EA3270
    EBCDIC to ASCII translation for 3270 Emulation
    AEBIWP
    ASCII to EBCDIC translation for BIWP Emulation
    EABIWP
    EBCDIC to ASCII translation for BIWP Emulation
    AERCMS
    ASCII to EBCDIC translation for RCMS
    EARCMS
    EBCDIC to ASCII translation for RCMS
    AEFORW
    ASCII to EBCDIC translation for Forwarding
    EA47X2
    EBCDIC to ASCII translation for BPP Emulation
    EA3287
    EBCDIC to ASCII translation for 3287 Emulation

    EXTEN
    Is a required keyword to define the translation table identification.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all translation tables of the same type.

    DATA0X to DATAFX
    Are required keywords to define the table values. The parameter value is a string of 16 parameters, each one with a 1-byte digit from '00' to 'FF'.

    DATA0X must contain the translation information for digits '00' to '0F', DATA1X for '10' to '1F', and so on.

    For translation tables with the type EA3270, EA47X2, EA3287, and EABIWP, the keywords DATA0X, DATA1X, DATA2X, and DATA3X must not be specified.

    XLATETBL vector example

     /* Vector XLATETBL (TYPE=AE3270) Default Example */
     
       XLATETBL TYPE=AE3270,
                EXTEN=KBD,
                DATA0X=(00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F),
                DATA1X=(10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F),
                DATA2X=(40,4F,7F,7B,5B,6C,50,7D,4D,5D,5C,4E,6B,60,4B,61),
                DATA3X=(F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,7A,5E,4C,7E,6E,6F),
                DATA4X=(7C,C1,C2,C3,C4,C5,C6,C7,C8,C9,D1,D2,D3,D4,D5,D6),
                DATA5X=(D7,D8,D9,E2,E3,E4,E5,E6,E7,E8,E9,4A,E0,5A,5F,6D),
                DATA6X=(79,81,82,83,84,85,86,87,88,89,91,92,93,94,95,96),
                DATA7X=(97,98,99,A2,A3,A4,A5,A6,A7,A8,A9,C0,BB,D0,A1,41),
                DATA8X=(68,DC,51,42,43,44,47,48,52,53,54,57,56,58,63,67),
                DATA9X=(71,9C,9E,CB,CC,CD,DB,DD,DF,EC,FC,70,B1,80,41,B4),
                DATAAX=(45,55,CE,DE,49,69,9A,9B,AB,AF,BA,B8,B7,AA,8A,8B),
                DATABX=(41,41,41,41,41,65,62,64,41,41,41,41,41,B0,B2,41),
                DATACX=(41,41,41,41,41,41,46,66,41,41,41,41,41,41,41,9F),
                DATADX=(8C,AC,72,73,74,9F,75,76,77,41,41,41,41,6A,78,41),
                DATAEX=(EE,59,EB,ED,CF,EF,A0,AE,8E,FE,FB,FD,8D,AD,BC,BE),
                DATAFX=(CA,8F,BF,89,B6,B5,41,9D,90,BD,B3,41,FA,EA,41,41)
    

    XLAT2TBL vector

    Defines an ASCII to EBCDIC and an EBCDIC to ASCII translation table for the XLATE function of the PC/Integrator.

    One vector has to be specified for each table you want to use in your workgroups. All the parameters for this vector have to be specified, there is no default for them.

    A quick reference


    Vector position None
    List of keywords EXTEN, EADATA0X to EADATAFX, AEDATA0X to AEDATAFX
    Keywords relate to
    Vector format XLAT2TBL EXTEN=xxx,
    EADATA0X=(   ),
    :
    EADATAFX=(   ),
    AEDATA0X=(   ),
    :
    AEDATAFX=(   )

    Keyword
    Description

    EXTEN
    Is a required keyword to define a translation table.

    The parameter value is a 3-character alphanumeric string, and may contain the special characters #, $, %, and @. It must be unique among all translation tables.

    EADATA0X to EADATAFX
    Are required keywords to define the EBCDIC to ASCII table values. The parameter value is a string of 16 parameters, each one with a 1-byte digit from '00' to 'FF'. These digits specify the ASCII value to be translated.

    EADATA0X must contain the translation information for digit '00' to '0F', EADATA1X for '10' to '1F', and so on.

    AEDATA0X to AEDATAFX
    Are required keywords to define the ASCII to EBCDIC table values. The parameter value is a string of 16 parameters, each one with a 1-byte digit from '00' to 'FF'. These digits specify the EBCDIC value to be translated.

    AEDATA0X must contain the translation information for digit '00' to '0F', AEDATA1X for '10' to '1F', and so on.

    XLAT2TBL vector example

     /* Vector XLAT2TBL Example */
     
     XLAT2TBL EXTEN=TB1,
              EADATA0X=(00,01,02,03,37,2D,2E,2F,16,05,25,0B,0C,0D,0E,0F),
              EADATA1X=(10,11,12,13,3C,3D,32,26,18,19,3F,27,1C,1D,1E,1F),
              EADATA2X=(40,4F,7F,7B,5B,6C,50,7D,4D,5D,5C,4E,6B,60,4B,61),
              EADATA3X=(F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,7A,5E,4C,7E,6E,6F),
              EADATA4X=(7C,C1,C2,C3,C4,C5,C6,C7,C8,C9,D1,D2,D3,D4,D5,D6),
              EADATA5X=(D7,D8,D9,E2,E3,E4,E5,E6,E7,E8,E9,4A,E0,5A,5F,6D),
              EADATA6X=(79,81,82,83,84,85,86,87,88,89,91,92,93,94,95,96),
              EADATA7X=(97,98,99,A2,A3,A4,A5,A6,A7,A8,A9,C0,6A,D0,A1,07),
              EADATA8X=(20,21,22,23,24,15,06,17,28,29,2A,2B,2C,09,0A,1B),
              EADATA9X=(30,31,1A,33,34,35,36,08,38,39,3A,3B,04,14,3E,E1),
              EADATAAX=(41,42,43,44,45,46,47,48,49,51,52,53,54,55,56,57),
              EADATABX=(58,59,62,63,64,65,66,67,68,69,70,71,72,73,74,75),
              EADATACX=(76,77,78,80,8A,8B,8C,8D,8E,8F,90,9A,9B,9C,9D,9E),
              EADATADX=(9F,A0,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7),
              EADATAEX=(B8,B9,BA,BB,BC,BD,BE,BF,CA,CB,CC,CD,CE,CF,DA,DB),
              EADATAFX=(DC,DD,DE,DF,EA,EB,EC,ED,EE,EF,FA,FB,FC,FD,FE,FF),
              AEDATA0X=(00,01,02,03,9C,09,86,7F,97,8D,8E,0B,0C,0D,0E,0F),
              AEDATA1X=(10,11,12,13,9D,85,08,87,18,19,92,8F,1C,1D,1E,1F),
              AEDATA2X=(80,81,82,83,84,0A,17,1B,88,89,8A,8B,8C,05,06,07),
              AEDATA3X=(90,91,16,93,94,95,96,04,98,99,9A,9B,14,15,9E,1A),
              AEDATA4X=(20,A0,A1,A2,A3,A4,A5,A6,A7,A8,5B,2E,3C,28,2B,21),
              AEDATA5X=(26,A9,AA,AB,AC,AD,AE,AF,B0,B1,5D,24,2A,29,3B,5E),
              AEDATA6X=(2D,2F,B2,B3,B4,B5,B6,B7,B8,B9,7C,2C,25,5F,3E,3F),
              AEDATA7X=(BA,BB,BC,BD,BE,BF,C0,C1,C2,60,3A,23,40,27,3D,22),
              AEDATA8X=(C3,61,62,63,64,65,66,67,68,69,C4,C5,C6,C7,C8,C9),
              AEDATA9X=(CA,6A,6B,6C,6D,6E,6F,70,71,72,CB,CC,CD,CE,CF,D0),
              AEDATAAX=(D1,7E,73,74,75,76,77,78,79,7A,D2,D3,D4,D5,D6,D7),
              AEDATABX=(D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7),
              AEDATACX=(7B,41,42,43,44,45,46,47,48,49,E8,E9,EA,EB,EC,ED),
              AEDATADX=(7D,4A,4B,4C,4D,4E,4F,50,51,52,EE,EF,F0,F1,F2,F3),
              AEDATAEX=(5C,9F,53,54,55,56,57,58,59,5A,F4,F5,F6,F7,F8,F9),
              AEDATAFX=(30,31,32,33,34,35,36,37,38,39,FA,FB,FC,FD,FE,FF)
    

    X25DIR vector


    ehcodw

    Defines an entry in a X.25 directory table. These tables contain communications provider directories and their associated X.25 subscriber numbers. A table can contain up to 100 entries.

    The customization program creates an ASCII run-time file, named SNAX25D.CFG, which contains that information.

    One vector has to be specified for each entry in the table. All the parameters for this vector have to be specified. There is no default for them.

    A quick reference


    Vector position None
    List of keywords TBLNAME, DIRNAME, SUBSNUMB
    Keywords relate to
    Keyword
    Relates to keywords
    TBLNAME
    SBSX25

    Vector format X25DIR TBLNAME=xxxxxxxx,
    DIRNAME=xxxxxxxx,
    SUBSNUMB=xxxxxxxxxxxxxxx

    Keyword
    Description

    TBLNAME
    Is a required keyword to specify the name of the X.25 directory table that contains the entry.

    The parameter value is a string of up to eight alphanumeric characters, and must be unique among all X.25 directory tables.

    DIRNAME
    Is a required keyword to specify the name of the subscriber number in the communications provider definitions.

    The parameter value is a string of up to eight alphanumeric characters, and must be unique among all the entries in the X.25 directory table.

    SUBSNUMB
    Is a required keyword to specify the subscriber address. For international calls, the subscriber number must be preceded by the country identification and the country subcode.

    The parameter value is a string of up to 15 digits, and must be unique among all the entries in the X.25 directory table.

    X25DIR vector example

     /* Vector X25DIR Example */
     
     X25DIR   TBLNAME=X25TBL01,
              DIRNAME=PARTNER1,
              SUBSNUMB=123456789012345
    

    Appendix D. Editing configuration data




    ehcodwl

    This appendix provides information about:
    • Data that is specific for each workgroup.

      This is called workgroup configuration data, and is specified in vector format and stored in the LANCONF.SPC files.

      Each workgroup configuration requires a separate LANCONF.SPC file, which must be located in a separate directory. See Customization directory structure.

    • Data for models.

      This is called model configuration data, and is specified in vector format and stored in the MODELS.SPC file located in the EHCCUS directory.


    For information on how to store customization data in specification files, refer to Customization data structure, especially if you plan to use embedded files (see page "Embedded specification files") or partial files (see page "Partial specification files").

    The appendix also explains how to use models to define your workgroup configurations.

    The following graphic shows the vectors in the .SPC files, and the references that can be specified to use the model configurations. The references are specified at keyword level.



    ehcgr050


    Creating and editing configuration vectors

    Before you start creating and editing configuration vectors, consider the following:

    1. The customization program provides two alternative procedures to prepare and process specification files.

      The EDITSPEC program is used to edit specification files.

      You can apply this procedure to the LANCONF.SPC or MODELS.SPC files, and display and modify the configuration vectors.

      If you want to display online information about this procedure, from the EHCCUS directory, enter:

        EDITSPC ?
      

      To start the procedure for a workgroup configuration file (LANCONF.SPC), from the EHCCUS directory enter:

        EDITSPC xxxxxxxx LAN
      

      where xxxxxxxx is the name of the subdirectory in the EHCCUS directory where the LANCONF.SPC file is located.

      If the file does not exist, the procedure creates a subdirectory with the name you provide, and an empty file named LANCONF.SPC located in that subdirectory.

      If the subdirectory where the LANCONF.SPC file is located is not in the EHCCUS directory, but in an other directory at the same level, you have to specify also this directory. In this case, the command to enter is:

        EDITSPC  yyyyyyyy xxxxxxxx LAN
      

      where yyyyyyyy is the name of a directory at the same level as EHCCUS.

      If the file or the directories do not exist, the procedure creates the directories with the names you provide, and an empty file named LANCONF.SPC located in that path.

      To start the procedure for the model configuration file (MODELS.SPC), from the EHCCUS directory, enter:

        EDITSPC MODELS
      

      If you use the OS/2 Enhanced Editor with the LANDP customization editing tool, the LANDP choice is listed in the action bar of the editor window. For information about that tool, select the View doc option in the pull-down that appears when you choose LANDP.

      Note:
      EDITSPC program is included here only for compatibility with previous LANDP releases. The same function can be achieved by using the new graphical Customization Editor that, in addition to being easier to use, also provides improved functionality. The graphical Customization Editor allows you to edit specification files. See Graphical Customization Editor for more information. The graphical Customization Editor can also be used to invoke the GENSPEC procedure that is described in the next few paragraphs.
    2. The customization program provides a procedure to generate configuration vectors from the configuration data in the internal repository.

      The configuration vectors are generated either in the LANCONF.SPC files, or in the MODELS.SPC file, located in the EHCCUS directory. The order in which the vectors appear in the files is not relevant.

      To start the procedure for the workgroup configuration vectors, from the EHCCUS directory, enter:

        GENSPEC LAN
      

      To start the procedure for the model configuration vectors, from the EHCCUS directory, enter:

        GENSPEC MODELS
      

      For further information on that procedure, refer to Generating data.


    Editing workgroup configuration data

    To edit workgroup configuration data:

    When editing a configuration vector, if you refer to a model configuration vector, the definitions in the model configuration vector become the default parameter values for the configuration vector you are editing. To change some values, include the corresponding keywords in the vector and assign to them the new parameter values. Note that you can include keywords that are not included in the model configuration vector.

    When defining a workgroup configuration and referring to a workgroup model configuration, you may have to do some of the tasks in the following table. The table shows the tasks and the actions you have to take.

    Task Action
    Delete a workstation from a workgroup model configuration
    • Include the LWSCONF vector corresponding to that workstation, specifying DELETE as the workstation model configuration name

    Add a workstation to a workgroup model configuration
    • Include the WSNAMES keyword in the LANCONF vector, specifying that workstation, and
    • Include the LWSCONF vector corresponding to that workstation, containing the workstation information

    Delete a server from a workstation model configuration
    • Include the SERVER keyword in the LWSCONF vector, specifying that server, and
    • Specify DELETE as the server model configuration name

    Add a server to a workstation model configuration
    • Include the SERVER keyword in the LWSCONF vector, specifying that server
    • Include the server information in the SERVER keyword and, if needed, in the following keywords
      • PARXXXXX
      • SESXXXXX

    Delete access to the services provided by a functional area from a workstation model configuration
    • Include the LWSCONF vector corresponding to that workstation, specifying DELETE as the alias of the resource in the CLIENT keyword

    Delete access to the services provided by a functional area to a workstation model configuration
    • Include the CLIENT keyword in the LWSCONF vector, specifying that server
    • Include the server information in the CLIENT keyword and, if needed, in the SESXXXXX keyword

    When you generate the LANCONF.SPC file through the generation procedure, using the customization data stored in the internal repository, the order in which the vectors appear in the file may be different from the order in which you wrote them.


    Workgroup configuration vectors - descriptions

    This section provides information about each workgroup configuration vector, including examples.

    LANCONF vector

    Contains workgroup information, and must be the first vector in the workgroup configuration file. An example for this vector is provided under LANCONF vector examples.

    A quick reference


    Vector position First vector in the LANCONF.SPC file. It can be followed by up to 250 LWSCONF vectors.
    List of keywords

    GROUP, NAME

    MODEL

    DEFAULTS, LANADAPT, LANGUAGE, RPLOAD, SUFFIX, XPORT, TCPPORT, ADAPTNUM, NETBUFF, WSNAMES, PARLIP, NWSIDDUP

    Keywords relate to
    Keyword
    Relates to keywords
    MODEL
    MODNAME (LANMODEL vector)
    ADAPTNUM
    ADAPTNUM (LWSCONF vector)
    DEFAULTS
    NAME (DEFAULTS vector)
    WSNAMES
    NAME (LWSCONF vector)
    NETBUFF
    NETBUFF (LWSCONF vector)

    Vector format LANCONF [GROUP=xxxxxxxx,]
    NAME=xxxxxxxx,
    [MODEL=xxxxxxxx,]
    [DEFAULTS=xxxxxxxx,]
    [LANADAPT=x,]
    [LANGUAGE=xxx,]
    [RPLOAD=x,]
    [SUFFIX=x,]
    [XPORT=x,]
    [TCPPORT=xxxxx,]
    [ADAPTNUM=xxx,]
    [NETBUFF=xx,]
    [NWSIDDUP=x,]
    [PARLIP=x,]
    WSNAMES=(   )

    The keywords in the first line in the list identify the workgroup configuration. The MODEL keyword refers to a workgroup model configuration. Other keywords define the workgroup configuration.

    Keyword
    Description

    GROUP
    Is an optional keyword to specify the name of the group of workgroup configurations to which the workgroup configuration belongs. This name must match the name of the directory where the workgroup configuration directory is located. For information on directory structure, refer to Customization directory structure.

    The combination of the name assigned in the GROUP keyword and the name assigned in the NAME keyword must be unique for the whole installation.

    The parameter value is a name of up to 8 alphanumeric characters. The default is EHCCUS.

    NAME
    Is a required keyword to specify the name of the workgroup configuration. This name must match the name of the directory-- where the LANCONF.SPC file is located. For information on directory structure, refer to Customization directory structure.

    The combination of the name assigned in the GROUP keyword and the name assigned in the NAME keyword must be unique for the whole installation.

    The parameter value is a name of up to 8 alphanumeric characters.

    MODEL
    Is an optional keyword to specify the name of the workgroup model configuration to be used to define the workgroup configuration.

    The parameter value must match the value assigned in the MODNAME keyword in a LANMODEL vector.

    DEFAULTS
    Is an optional keyword to specify the set of defaults to be used in the workgroup.

    The parameter value must match the value assigned in the NAME keyword in a DEFAULTS vector. The default is GENERAL.

    LANADAPT
    Is an optional keyword to specify the type of hardware adapter to be used in the workgroup. The keyword applies only when there is at least one DOS workstation in the workgroup, and NetBIOS is used as transport protocol.

    The parameter value can be:

    T
    Token-ring
    P
    PC network
    O
    Other types (for example, Ethernet)

    The default is T. LANDP always uses the primary adapter, not the alternate one.

    LANGUAGE
    Is an optional keyword to specify the identifier of the language to be used. The customization program copies the files that contain messages in the corresponding language.

    The parameter value can be:

    001
    English
    034
    Spanish
    086
    Simplified Chinese

    The default is 001. When working in DBCS mode, only English and Simplified Chinese are supported. Note that you can only specify 086 if the DBCSCTRY entry on the DEFAULTS vector is also set to 086.

    RPLOAD
    Is an optional keyword to specify whether 4700 virtual volume remote program load is used in the workgroup. The keyword applies only to DOS workstations, and when the PC/Integrator virtual volume support is loaded in a workstation in the workgroup.

    The parameter value can be Y, to use virtual volume remote program load, or N, not to use it. The default is N.

    SUFFIX
    Is an optional keyword to specify that the workgroup name is to be added, as a suffix to the workstation IDs to identify the workstations when establishing the LANDP session.

    If the suffix is to be used, the workgroup name must be unique for each LANDP workgroup in the same network.

    The suffix enables you to have workstations with the same name in different LANDP workgroups, which belong to the same network. This suffix can be changed at run-time using the LAN variable run-time parameters program (VARPARM.EXE).

    The parameter value can be Y, to add the suffix, or N, not to add it. The default is N.

    XPORT
    Is an optional keyword to specify the transport protocol used to carry requests/replies through the workgroup.

    You can also specify the transport protocol at workstation level using the XPORT keyword in the LWSCONF vector. The value specified at the workstation level overrides the value specified at workgroup level.

    The parameter value can be:

    N
    NetBIOS (LANDP for DOS, LANDP for OS/2, and LANDP for Windows only)
    P
    TCP/IP (when used for DOS workstations, the PC/TCP implementation is used)
    T
    TCP/IP (when used for DOS workstations, the IBM TCP/IP implementation is used)

    The default is N.

    For a DOS workstation:

    For non-DOS workstations, P and T values both have the same effect as T for a DOS workstation.

    TCPPORT
    Is an optional keyword to specify the TCP/IP port number used by LANDP. It applies only to those workstations to which the P or T parameter value has been assigned using the XPORT keyword.

    The parameter value can be in the range 1024 through 65535. The default is 52699.

    ADAPTNUM
    LANDP for DOS, LANDP for OS/2, and LANDP for Windows: Is an optional keyword to specify the adapter number(s) used by NetBIOS. The keyword applies only to those workstations in the workgroup that are assigned, through the XPORT keyword, to use the NetBIOS transport protocol.

    You can also specify the adapter number at workstation level, through the ADAPTNUM keyword in the LWSCONF vector. The value specified at workstation level overrides the value specified at workgroup level.

    The parameter value ranges from 0 to 255. The default is provided at workstation level.

    For OS/2 and Windows workstations, you can also specify parameter values in the form: (x,x...), where x can range from 0 to 255, but where no number is repeated. This enables you to specify a range of adapters, thus supporting up to four adapters in a single workstation.

    NETBUFF
    LANDP for DOS: Is an optional keyword to specify the size of the NetBIOS buffer for all the DOS workstations in the workgroup.

    You can also specify the size of the NetBIOS buffer at workstation level, through the NETBUFF keyword in the LWSCONF vector. The value specified at workstation level overrides the value specified at workgroup level.

    The parameter value ranges from 1 to 56. The default is provided at workstation level.

    WSNAMES
    Is a required keyword to specify the names of the workstations in the workgroup configuration. The keyword can specify up to 250 parameters, because this is the maximum number of workstations in a workgroup supported by the LANDP family.

    Each parameter is the name of a workstation in the workgroup configuration. The parameter value is a name of up to 2 alphanumeric characters. The value must match the value assigned in the NAME keyword in the LWSCONF vector that contains information about the workstation.

    NWSIDDUP
    Is an optional keyword that can be used to avoid receiving return codes which indicate that a duplicate workstation identifier (WSID) has been defined.

    The parameter values are Y (to suppress duplicate WSID return codes) and N (to display these return codes). The default is N.

    All WSIDs across all workgroups must be unique if you distribute your LANDP software by using NetView/DM. In this case, you must take action on the return codes issued by VALSPEC which indicate that a duplicate WSID has been issued. The first six characters of each workgroup name (NAME) must be unique. The two-character workstation name (WSNAME) is appended to create the eight-character WSID. Avoid the return codes by ensuring that the first six characters of all workgroup names are unique.

    If you do not distribute your LANDP software by using NetView/DM, you can suppress return codes by setting the appropriate VALSPEC parameter. Be aware, however, that this also suppresses other return codes that you might need to respond to. Alternatively, set the NWSIDDUP parameter to Y to suppress return codes for duplicate WSIDs.

    PARLIP
    Is an optional keyword to define LANDP Internet Protocol parameters.

    You can also specify these parameters at workstation level, through the PARLIP keyword in the LWSCONF vector. The value specified at workstation level overrides the value specified at workgroup level.

    You can specify up to 3 parameters:

    1. Availability probe datagrams.

      This parameter specifies whether availability probe datagrams will be sent at regular intervals when a session has no normal traffic.

      The parameter value can be Y, to send availability probe datagrams, or N, not to send them. The default is Y.

    2. Space for retransmission table.

      This parameter specifies the storage, in bytes, to be allocated for the retransmission table.

      This table is used by the LANDP Internet Protocol to save information about datagrams sent, in case they should be retransmitted. The information is deleted when the receiver acknowledges reception.

      The parameter applies only to DOS workstations. The parameter value ranges from 256 to 65000.

      The default is defined using the following formula:

        Default value = 910 * ((n * 40) / (n + 34))
      

      where n is the number of related workstations.

    3. LANDP Internet Protocol address checking.

      This parameter specifies whether checking for related workstations with undefined IP addresses will be carried out.

      The parameter value can be Y or N. Y checks that all LANDP Internet Protocol addresses are defined; processing stops if any undefined addresses are found. N allows some addresses to be undefined at this time; processing continues. The default is Y.

    LANCONF vector examples

    /* Following is the EXAMPLE 1, which corresponds to keyword      */
    /* specifications for a workgroup that uses NetBIOS as transport */
    /* protocol.                                                     */
     
     
     
             LANCONF  GROUP=EHCCUS,
                      NAME=LAN1,
                      WSNAMES=(AA,BB,CC)
     
    

    /* Following is the EXAMPLE 2, which corresponds to keyword    */
    /* specifications for a workgroup that uses TCP/IP as transport */
    /* protocol.                                                   */
     
             LANCONF  GROUP=EHCCUS,
                      NAME=TCPIP1,
                      WSNAMES=(AA,BB),
                      DEFAULTS=GENERAL,
          /* Transport protocol through workgroup is TCP/IP */
                      XPORT=T,
          /* TCP/IP port used by LANDP is port 52699 */
                      TCPPORT=52699,
                      SUFFIX=Y
     
    

    LWSCONF vector

    Contains information about a particular workstation in the workgroup configuration, including functional area definitions. The keywords that define the functional areas are explained in the corresponding sections. Those sections provide examples of the keyword definitions that can be included in the LWSCONF vectors for the respective functional areas.

    A quick reference


    Vector position None. Follows a LANCONF vector. There can be up to 250 LWSCONF vectors in the same LANCONF.SPC file.
    List of keywords

    NAME

    WSID, MODEL

    TYPE, SYSLVL, PRODLVL, SOFTPACK, FRAME, RPLOAD, POOLSIZE, XPORT, PARLIP, PARLIPEX, LANDPDCE, ADAPTNUM, NETBUFF, DBCSXLAT, PARWIN, SBC, SERVER, CLIENT, PARxxxxx, SESxxxxx

    Keywords relate to
    Keyword
    Relates to keywords
    ADAPTNUM
    ADAPTNUM (LANCONF vector)
    MODEL
    MODNAME (WSMODEL vector)
    NETBUFF
    NETBUFF (LANCONF vector)
     
    MODNAME (SVRMODEL vector)
    PARLIP
    XPORT (LANCONF vector)
    PARLIPEX
    XPORT (LANCONF vector)
    XPORT
    XPORT (LANCONF vector)

    Vector format LWSCONF NAME=xx,
    [WSID=xxxxxxxx,]
    [MODEL=xxxxxxxx,]
    [TYPE=(   ),]
    [SYSLVL=x,]
    [PRODLVL=xxx,]
    [SOFTPACK=xxxxxxxx,]
    [FRAME=xxxx,]
    [RPLOAD=x,]
    [POOLSIZE=xxx,]
    [XPORT=x,]
    [PARLIP=(   ),]
    [PARLIPEX=(   ),]
    [LANDPDCE=x,]
    [ADAPTNUM=xxx,]
    [NETBUFF=xx,]
    [DBCSXLAT=x,]
    [PARWIN=xx,]
    [SBC=(   ),]
    [SERVER=(   ),]
    [CLIENT=(   ),]
    [PARxxxxx=(   ),]
    [SESxxxxx=(   )]

    The NAME keyword identifies the workstation in the workgroup configuration. The MODEL keyword refers to a workstation model configuration.

    Next keywords define the workstation in the workgroup configuration. The PARxxxxx and SESxxxxxx keywords specify the parameters used to define some functional areas.

    Keyword
    Description

    NAME
    Is a required keyword to specify the name of the workstation in the workgroup configuration. The name becomes the workstation ID, and the name of the directory where the customization information about the workstation is located after generating run-time files. For information on directory structure, refer to Customization directory structure.

    The parameter value is a name of up to 2 alphanumeric characters. The value is used as the name of the workstation when you need to specify that name in other keywords, for example, because the services provided by this workstation are required in the configuration you are defining.

    See the NWSIDDUP parameter of LANCONF for details of how to avoid receiving return codes about duplicate workstation identifiers.

    WSID
    Is an optional keyword to specify the name of the workstation when distributing using a distributed server. (See Distributing software using a distribution server.)

    The parameter value is a name of up to 8 alphanumeric characters, and should be unique across all workstations and workgroups. The default is the first 6 characters of the workgroup name, concatenated with the workstation name.

    MODEL
    Is an optional keyword to specify the name of the workstation model configuration to be used to define the workstation in the workgroup configuration.

    To point to a workstation model configuration, the parameter value must match the value assigned in the MODNAME keyword in a WSMODEL vector. To delete a workstation from a workgroup model configuration, the parameter value must be DELETE.

    TYPE
    Is an optional keyword to specify the operating system installed in the workstation.

    You can specify up to 2 parameters:

    1. Operating system.

      The parameter value can be:

      DOS
      One of the following operating systems, or later versions, depending on the country:
      • IBM DOS 2000 (DOS 7.1)
      • IBM DOS T2000 (Traditional Chinese)
      • IBM DOS H2000 (Korean)
      • IBM DOS P2000 (Simplified Chinese)

      OS/2
      One of the following operating systems, or later versions, depending on the country:
      • IBM OS/2 Warp V4
      • IBM OS/2 T4.0
      • IBM OS/2 H4.0
      • IBM OS/2 P4.0

      NT
      One of the following operating systems:
      • Microsoft Windows NT Version 4
      • Microsoft Windows 2000
      • Microsoft Windows XP Professional

      LINUX
      One of the following distributions of Linux for Intel:
      • Red Hat 7.2
      • SuSE 7.1
      • TurboLinux 7.0
      • Caldera 3.1

      The default is DOS.

    2. Windows 3.1 support.

      This parameter specifies whether Windows 3.1/3.11 support is to be used. It applies only to DOS or OS/2 workstations.

      To use Windows 3.1 support, the parameter value must be WIN. To use Windows for Workgroups support, the parameter value must be WFW. This specifies that no additional LAN support needs to be added for this workstation.

      The parameter is optional. It is not supported for TYPE=NT (Windows) and TYPE=LINUX.

    SYSLVL
    Is an optional keyword to specify the operating system version installed in the workstation. The keyword applies only to DOS workstations.

    If it is specified, the parameter value must be 7, meaning DOS V.7.x.

    PRODLVL
    Is an optional keyword to specify the LANDP version installed in the workstation.

    The parameter value can be:

    L60
    LANDP Version 6.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 6.0 for OS/2, if you define a TYPE=OS/2 workstation.

    LANDP Version 6.0 for Windows, if you define a TYPE=NT workstation.

    LANDP Version 6.0 for Linux, if you define a TYPE=LINUX workstation.

    L50
    LANDP Version 5.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 5.0 for OS/2, if you define a TYPE=OS/2 workstation.

    LANDP Version 5.0 for Windows NT, if you define a TYPE=NT workstation.

    L40
    LANDP Version 4.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 4.0 for OS/2, if you define a TYPE=OS/2 workstation.

    LANDP Version 4.0 for Windows NT, if you define a TYPE=NT workstation.

    L30
    LANDP Version 3.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 3.0 for OS/2, if you define a TYPE=OS/2 workstation.

    L20
    LANDP Version 2.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 2.0 for OS/2, if you define a TYPE=OS/2 workstation.

    L10
    LANDP Version 1.0 for DOS, if you define a TYPE=DOS workstation.

    LANDP Version 1.0 for OS/2, if you define a TYPE=OS/2 workstation.

    F31
    FBSS Version 3.1, if you define a TYPE=DOS workstation.

    F11
    FBSS/2 Version 1.1, if you define a TYPE=OS/2 workstation.

    The default is the latest LANDP product version for the operating system installed in the workstation you define.

    SOFTPACK
    Is an optional keyword to specify the name of a pack of files to be distributed with the LANDP runtime files for this workstation. This name must be defined in the PACKNAME parameter of a SOFTPACK vector in COMMON.SPC.

    FRAME
    Is an optional keyword to specify the segment address of a 64KB frame of free memory space that is needed to load servers in expanded memory. The keyword applies only to DOS workstations.

    The parameter value ranges from C000 to E000, in increments of 400(hex). The default is C000.

    RPLOAD
    Is an optional keyword to specify whether 4700 virtual volume remote program load is used in the workstation. The keyword applies only to DOS workstations, and when the PC/Integrator virtual volume support is loaded in a workstation in the workgroup.

    The parameter value can be Y, to use virtual volume remote program load, or N, not to use it. The default is N.

    POOLSIZE
    LANDP for DOS: Is an optional keyword to specify the size of the buffer pool, in KB. This means the number of kilobytes (KB) that should be reserved for the internal buffer pool to allocate incoming/outgoing requests from/to remote workstations, and requests from servers loaded into expanded memory to servers that are also loaded into expanded memory.

    The parameter value ranges from 7 to 512. The value is limited by the available memory.

    The default is [1.25 x n], where n is the number of workstations that receive services from the workstation you are defining, or provide services to it.

    For workstations that provide or receive shared DOS directory services, the customization program recalculates the default accordingly.

    XPORT
    Is an optional keyword to specify the transport protocol, or protocols, used to carry requests or replies through the workgroup.

    You can also specify the transport protocol at workgroup level using the XPORT keyword in the LANCONF vector. The value specified at the workstation level overrides the value specified at workgroup level.

    The parameter values can be:

    N
    NetBIOS (Supported on DOS, OS/2, or Windows)
    T
    TCP/IP (Supported on DOS (IBM TCP/IP implementation), OS/2, Windows, and Linux)
    P
    TCP/IP (Supported on DOS - PC/TCP implementation)
    NT
    Both NetBIOS and TCP/IP (Supported on OS/2 and Windows)
    TN
    Same as parameter value NT. Both NetBIOS and TCP/IP (Supported on OS/2 and Windows)

    The default is the value specified on the XPORT keyword of the LANCONF vector.

    Related workstations, where one is configured as a client of the other, must have at least one transport in common.

    PARLIP
    Is an optional keyword to define LANDP Internet Protocol parameters. This keyword applies only if the defaulted or specified value for the transport protocol in the XPORT keyword is TCP/IP.

    You can specify up to 3 parameters:

    1. Availability probe datagrams.

      This parameter specifies whether availability probe datagrams will be sent at regular intervals when a session has no normal traffic.

      The parameter value can be Y, to send availability probe datagrams, or N, not to send them. The default is Y.

    2. Space for retransmission table.

      This parameter specifies the storage, in bytes, to be allocated for the retransmission table.

      This table is used by the LANDP Internet Protocol to save information about datagrams sent, in case they should be retransmitted. The information is deleted when the receiver acknowledges reception.

      The parameter applies only to DOS workstations. The parameter value ranges from 256 to 65000.

      The default is defined using the following formula:

        Default value = 910 * ((n * 40) / (n + 34))
      

      where n is the number of related workstations.

    3. LANDP Internet Protocol address checking.

      This parameter specifies whether checking for related workstations with undefined IP addresses will be carried out.

      The parameter value can be Y or N. Y checks that all LANDP Internet Protocol addresses are defined; processing stops if any undefined addresses are found. N allows some addresses to be undefined at this time; processing continues. The default is Y.

    PARLIPEX
    LANDP for DOS: Is an optional keyword to define LANDP Internet Protocol parameters. This keyword applies only if the defaulted or specified value for the transport protocol in the XPORT keyword is TCP/IP.

    You can specify one parameter:

    1. Expanded memory selection.

      The parameter value can be:

      Y
      The LANDP Internet Protocol is loaded in expanded memory
      N
      The LANDP Internet Protoco is loaded in conventional memory

      The default is N.

    ADAPTNUM
    LANDP for DOS, LANDP for OS/2, LANDP for Windows: Is an optional keyword to specify the adapter number used by the workstation.

    This keyword applies only if the defaulted or specified value of the transport protocol in the XPORT keyword is NetBIOS.

    You can also specify the adapter number at workgroup level, through the ADAPTNUM keyword in the LANCONF vector. The value specified at workstation level overrides the value specified at workgroup level.

    The parameter value ranges from 0 to 255. The default is 0, or the value specified at workgroup level.

    For OS/2 and Windows workstations, you can also specify parameter values in the form: (x,x...), where x can range from 0 to 255, but where no number is repeated. This enables you to specify a range of adapters, thus supporting up to four adapters in a single workstation.

    NETBUFF
    LANDP for DOS: Is an optional keyword to specify the size of the NetBIOS buffer, in KB. This means the number of KB that should be reserved for the internal buffer to be shared with the NetBIOS manager layer in order to receive data from remote workstations.

    You can also specify the size of the NetBIOS buffer at workgroup level, through the NETBUFF keywork in the LANCONF vector. The value specified at workstation level overrides the value specified at workgroup level.

    The parameter value ranges from 1 to 56. The default is 4, or the value specified at workgroup level.

    DBCSXLAT
    LANDP for DOS (DBCS mode): Is an optional keyword to specify whether the ASCII-EBCDIC translation server will be loaded.

    The parameter value can be:

    N
    The server will not be loaded.
    Y
    The server will be loaded in conventional memory.
    E
    The server will be loaded in expanded memory.

    The default is N.

    PARWIN
    LANDP for DOS: Is an optional keyword to specify the maximum storage, in KB, required by Windows 3.1 parameters and user data.

    The parameter value ranges from 4 to 56. The customization data provides no default.

    SBC
    LANDP for Windows, LANDP for OS/2: Is an optional keyword to specify that this workstation operates in an SBC environment (for example, WTS or WSoD) as an SBC client or server. Appendix G, LANDP using Server Based Computing outlines how LANDP can be integrated into the SBC directory structure.

    Use of this keyword facilitates the generation of the appropriate lists of files for the SBC server directories. See also Distributing software.

    A workgroup might include one or more SBC server workstations.

    All workstations in an SBC server/client group must be running on the same operating system (either all OS/2 or all Windows). Also, all workstations in an SBC server/client group must be running on the same version of LANDP. This avoids the possibility of incompatible versions of files being grouped on the SBC server.

    You can specify up to two parameters:

    1. SBC server/client selection. This parameter is required. It has two valid values:
      S
      The workstation operates as an SBC server.
      C
      The workstation operates as an SBC client.
    2. Name of the SBC server workstation. This parameter is required if the first parameter is 'C'. The parameter is a string of up to two alphanumeric characters. It identifies the SBC server workstation.

    SERVER
    Is an optional keyword to define some functional areas to be loaded in a workstation. Each functional area requires a SERVER keyword. At least one SERVER or CLIENT keyword is required in each LWSCONF vector.

    You can specify up to 4 parameters:

    1. Server name used by the applications.

      The parameter is required. The parameter value is a string of up to 8 alphanumeric characters.

      Refer to the table in Vectors - a quick reference for the values (string in parenthesis) corresponding to the functional areas.

      The following servers require that the server suffix (##) is substituted by the corresponding value to completely identify the server:

      • EHCMQ##
      • EHCODB##
      • EHCSFD##
      • EHCSFR##
      • EHCSQL##
      • ELECJO##
      • MSRE47##
      • PINP47##
      • SHFILE##

      The following servers require a suffix to identify the session to be used:

      • BIWPx
      • BPPx
      • EMU3270x
      • LDA7x

      Note that BIWP and LDA 7 program need the suffix only when they are installed in a DOS workstation.

      If the following servers are to be run in either an OS/2 or a Windows VDM, the server names to be specified are:

      BIWP
      VBIWPx
      LDA7
      VLDA7x
      BPP
      VBPPx (Windows only)

      where x is a suffix that identifies the session.

      To specify user servers, the parameter value must be the value specified in the NAME keyword of the DEFSERV vector. Those vectors are located in the COMMON.SPC file. See Appendix B, User servers.

    2. Model name.

      The parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the MODNAME keyword in a SVRMODEL vector.

      To delete a server from a workstation model, the parameter value must be DELETE.

    3. Expanded memory selection.

      The parameter applies only to DOS workstations. It is optional. The parameter value can be:

      Y
      The server is loaded in expanded memory
      N
      The server is loaded in conventional memory

      The default is N.

    4. Loading parameters.

      This parameter specifies a string that will be added to the loading statement of the server.

      The parameter is optional. The parameter value is a string of up to 40 characters, enclosed between quotes.

    CLIENT
    Is an optional keyword to define a functional area to be used by a workstation. At least one SERVER or CLIENT keyword is required in each LWSCONF vector.

    You can specify up to 3 parameters:

    1. Name of the resource providing services. The name specified can be used by the applications, when requesting services.

      The following resources are always local, and do not require this parameter:

      • BIWP
      • BMLS
      • BPP
      • DCADLC
      • DDT
      • EHCCOMP
      • EHCLRMG
      • EHCSAM
      • EHCTCP
      • EHCTRACW
      • EHCVDMGR
      • EMU3270
      • EMU3287
      • FORWARD
      • LDA7
      • OPER
      • PBMS
      • PRTMGR
      • PT4721
      • RCMS
      • RDVVOLS
      • SDLC
      • SFQUERY
      • SMOP
      • TRDLC
      • VFILE
      • X25DLC
      • X25DLC2

      In any other case, the parameter is required. The parameter value is a string of up to 8 alphanumeric characters.

      Refer to the table in Vectors - a quick reference for the values (string in parenthesis) corresponding to the functional areas.

      The following servers require that the server suffix (##) is substituted by the corresponding value to completely identify the server:

      • EHCODB##
      • EHCSFD##
      • EHCSFR##
      • EHCSQL##
      • ELECJO##
      • MSRE47##
      • PINP47##
      • PR47X2##
      • PR4770##
      • SHFILE##

      In the following resources, the suffix identifies the session used by the server:

      • EHCMQ##
      • MSRE47##
      • PINP47##
      • PR47X2##
      • PR4748##
      • PR4770##
      • SNA##
      • X25NAT##

      To specify user servers, the parameter value must be the value specified in the NAME keyword of the DEFSERV vector. Those vectors are located in the COMMON.SPC file. See Appendix B, User servers.

      A modified SNA interface that allows for more than 30 user sessions per workstation is available when the SNA services are provided from an OS/2 or Windows workstation. When using this interface, the session identifier may be any two ASCII characters. To customize for the modified interface, use a server name of just SNA, instead of SNA followed by the session identifier, in the CLIENT keyword of the LWSCONF vector. Only one CLIENT=(SNA,xx) keyword is required, no matter how many sessions are to be used

    2. Name of the workstation where the resource is located.

      The parameter is required. The parameter value must match the value assigned in the NAME keyword in the LWSCONF vector corresponding to the workstation where the server is loaded.

      When you define a workstation model configuration, and some services are locally provided, you can specify &W as the name of the workstation where the corresponding server is loaded. When you assign the &W value in the CLIENT keyword in a WSMODEL vector, the customization program substitutes the value &W for the name of the workstation that uses the model.

    3. Alias of the resource. It can be used by the applications, when requesting services, as if it were the name of the resource.

      The parameter applies only to LANDP for OS/2, LANDP for Windows, and LANDP for Linux workstations. The parameter is optional. The parameter value is a string of up to 8 alphanumeric characters. It can be neither the name of a resource nor the alias of another resource used in the workstation.

      Note:
      LANDP restricts you to a maximum of 120 alias definitions for each workstation in a workgroup.

      This parameter is also used to delete a client from a workstation model. The parameter value must be DELETE, and is applicable to any type of workstation in this case.

    PARxxxxx, SESxxxxx
    Specify the parameters used to define some functional areas. The xxxxx string stands for the functional area identifier; for example, &3270 identifies the 3270 emulator.

    The PARxxxxxx keywords are used to specify all the parameters for those servers that are loaded only once in the workstation, and handle a single resource. For servers that are loaded more than once in the workstation or handle multiple resources, the PARxxxxx keywords only specify the common information. In this case, the information specific for each particular server or resource is specified using the SESxxxxxx keywords.

    The PARxxxxx and SESxxxxx keywords corresponding to all the functional areas are explained in the following sections.

    LWSCONF vector examples

    /* Following is EXAMPLE 1, which corresponds to keyword     */
    /* specifications for a workstation that runs DOS.          */
     
             LWSCONF  NAME=D1,
                      TYPE=DOS,
                      PRODLVL=L60,
                      SOFTPACK=SHDIRC,
                      FRAME=C000,
                      SERVER=DDT,
                      SERVER=(EMU32701,,Y),
                      PAR&3270=(N,N),
                      SES&3270=(D1,1,P1,,AT1,DI1,KBD),
                      SERVER=(EMU32702,,Y),
                      SES&3270=(D1,2,P1,,AT1,DIS,KBD,HOST2,43,80),
                      SERVER=(EMU32703,,Y),
                      SES&3270=(O1,3,P1,,ATR,DIS,KBD,HOST3,27,132),
                      SERVER=(EMU32704,,Y),
                      SES&3270=(O1,4,P2,,ATR,DIS,KBD,HOST4),
                      SERVER=(OPER,,Y),
                      SERVER=SDLC,
                      PAR&SDLC=(20,01,N,Y,N,03D,01234,TURN,65,C1C1C1C1C1),
                      SERVER=(SNA##,,Y),
                      PAR&SNA=(APPL,SRV,,,LUPOOL1,Y)
     
    /* Following is EXAMPLE 2, which corresponds to keyword     */
    /* specifications for a workstation that runs OS/2.         */
     
             LWSCONF  NAME=O1,
                      TYPE=(OS/2),
                      PRODLVL=L60,
                      SERVER=SNA##,
                      PAR&SNA=(APPL,SRV),
                      SERVER=(EHCVDMGR,,N),
                      SERVER=EMU32701,
                      PAR&3270=(N,Y),
                      SES&3270=(O1,1,,,ATR,DIS,KBD,HOST1),
                      SERVER=EMU32702,
                      SES&3270=(O1,2,,,ATR,DIS,KBD,HOST2)
     
    

    BIWP definitions

    The Banking Interactive Workstation Program (BIWP) requires one PAR&BIWP keyword.

    If BIWP will run in an OS/2 or a Windows VDM, the name of the server in the SERVER keyword must be VBIWPx instead of BIWPx. Additionally, the keyword to be included in the LWSCONF, WSMODEL, or SVRMODEL vector, must be PAR&VBIW instead of PAR&BIWP. The parameters you can specify in a PAR&VBIW keyword are the same as those that can be specified in a PAR&BIWP keyword.

    Keyword
    Description

    PAR&BIWP
    Is a required keyword to define BIWP parameters, when BIWP is specified in a SERVER keyword.

    You can specify up to 19 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. BIWP emulated session number.

      When BIWP is installed in a DOS workstation or is used in an OS/2 or Windows VDM, the parameter is required. The parameter value ranges from 1 to 5, and must be unique for the workstation where BIWP is installed.

      The parameter must be omitted when BIWP is installed in a OS/2 workstation. The parameter value is defaulted to 1.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only.

      The parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)
    5. Cursor usage.

      This parameter defines how the cursor will work on the screen.

      The parameter is optional. The parameter value can be:

      Y
      To make the cursor remain on the screen from the first I/O operation until switching off the screen
      R
      To make the cursor remain on the screen while a read operation is in progress
      N
      Not to use the cursor

      The default is R.

    6. Read operation usage.

      This parameter defines how a read operation will be posted when the input segment is full and a character is typed.

      The parameter is optional. The parameter value can be Y, to post the read operation complete without status, or N, to post it with a wrong length status. The default is Y.

    7. Default end of message (EOM) mask.

      The parameter is optional. The parameter value is a hexadecimal number of two digits. The default is FF.

    8. Indicator 1 alarm selection.

      The parameter is optional. The parameter value can be Y, to make the alarm sound when the indicator 1 of the BIWP display is turned on, or N, not to make it sound. The default is N.

    9. Indicator 2 alarm selection.

      The parameter is optional. The parameter value can be Y, to make the alarm sound when the indicator 2 of the BIWP display is turned on, or N, not to make it sound. The default is N.

    10. Indicator 3 alarm selection.

      The parameter is optional. The parameter value can be Y, to make the alarm sound when the indicator 3 of the BIWP display is turned on, or N, not to make it sound. The default is N.

    11. SYSTEM indicator alarm selection.

      The parameter is optional. The parameter value can be Y, to make the alarm sound when the SYSTEM indicator of the BIWP display is turned on, or N, not to make it sound. The default is N.

    12. MSR/E ready alarm selection.

      The parameter applies only when BIWP uses IBM 4717 MSR/E. It is optional.

      The parameter value can be Y, to make the alarm sound when MSR/E is ready to encode, or N, not to make it sound. The default is N.

    13. Display color attributes.

      This parameter identifies the color attributes table used for the workstation display.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the color attributes table. It must match the value assigned in the EXTEN keyword in a DISPLATT vector with TYPE = BIWP.

    14. Display translation table.

      This parameter identifies the table that is used to translate from 4700 system EBCDIC to personal computer system ASCII, when receiving from the 4700 system.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a XLATETBL vector with TYPE = EABIWP.

    15. Keyboard translation table.

      This parameter identifies the translation table used for the workstation keyboard.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a KBDBIWP vector.

    16. PIN pad input table.

      This parameter identifies the table used by BIWP to read the input provided through the PIN pad.

      The parameter applies only when BIWP uses IBM 4718 PIN Pad. The parameter value is a string of three alphanumeric characters, which is the identifier of the PIN pad input table. It must match the value assigned in the EXTEN keyword in a PINPTBL vector.

    17. MSR/E input table.

      This parameter identifies the table used by BIWP to read the input provided through the MSR/E.

      The parameter applies only when BIWP uses IBM 4717 MSR/E. The parameter value is a string of three alphanumeric characters, which is the identifier of the MSR/E input table. It must match the value assigned in the EXTEN keyword in a MSRINTBL vector.

    18. MSR/E output table.

      This parameter identifies the table used by BIWP to encode data to the MSR/E.

      The parameter applies only when BIWP uses IBM 4717 MSR/E. The parameter value is a string of three alphanumeric characters, which is the identifier of the MSR/E output table. It must match the value assigned in the EXTEN keyword in a MSROUTBL vector.

    19. Application session identification.

      This parameter identifies the session that is used for the application program.

      The parameter is optional. If specified, it overrides the value assigned in the E3270HKx keyword in the DEFAULTS vector. The parameter value is a string of up to 8 alphanumeric characters.

    BIWP example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      PRODLVL=L60,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
              /* Banking Interactive Workstation Program DOS server definition.
                 Example. */
              SERVER=(BIWP1),
                      PAR&BIWP=(AA,1,013,TKR,R,Y,FF,
                               N,N,N,N,N,ATR,DIS,KBD)
     
             LWSCONF  NAME=BB,
                      TYPE=OS2,
                      PRODLVL=L60,
            /* Banking Interactive Workstation Program server OS/2  definition.
               Example. */
                      SERVER=(BIWP1),
                      PAR&BIWP=(AA,1,014,TKR,R,Y,FF,
                               N,N,N,N,N,ATR,DIS,KBD)
     
             LWSCONF  NAME=CC,
                      TYPE=NT,
                      PRODLVL=L60,
           /* Banking Interactive Workstation Program Windows NT VDM server
              definition.
              Example. */
                      SERVER=EHCVDMGR,
                      SERVER=VBIWP1,
                      PAR&VBIW=(AA,1,,,Y,Y,FF,N,N,N,Y,Y,ATR,DIS,KBD,,,,),
                      SERVER=VLDA71,
                      PAR&VLDA=(AA,1)
    

    Banking printer program definitions

    The banking printer program (BPP) requires one SES&BPP keyword per session.

    If BPP will run in a Windows VDM, the name of the server in the SERVER keyword must be VBPPx instead of BPPx. Additionally, the keyword that is included in the LWSCONF, WSMODEL, or SVRMODEL vector, must be SES&VBPP instead of SES&BPP. The parameters that you can specify in a SES&VBPP keyword are the same as those that can be specified in a SES&BPP keyword.

    Keyword
    Description

    SES&BPP
    Is a required keyword to define a banking printer program (BPP) session, when BPP is specified in a SERVER keyword.

    You can specify up to 7 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Printer port number.

      When BPP is installed in a DOS workstation, or in a Windows VDM, the parameter value ranges from 1 to 4. When BPP is installed in a OS/2 workstation, the parameter value ranges from 1 to 3.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only.

      The parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)
    5. Translation table.

      This parameter identifies the table that is used to translate from 4700 system EBCDIC to ASCII, when transmitting to the printer.

      The parameter value is the extension of the file containing the EBCDIC to ASCII translation table. It must match the value assigned in the EXTEN keyword in the XLATETBL vector.

    6. Translation table dynamic change selection.

      The parameter is optional. The parameter value can be Y, to use this capability, or N, not to use it. The default is N.

    7. Host application session identification.

      The parameter is optional. If specified, it overrides the value assigned in the BPPSIx keyword in the DEFAULTS vector. The parameter value is a string of up to 8 alphanumeric characters.

    Banking printer program example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      PRODLVL=L60,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
                      SERVER=(PR47X2##),
                      PAR&47X2=(N,C,9600,4722,N,C,9600,4722,Y),
        /* Banking Printer Program DOS server definition. Example. */
                      SERVER=(BPP1),
                      SES&BPP=(AA,1,019,TKR,017,N)
    
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      SERVER=(PR47X2##),
                      PAR&47X2=(N,C,9600,4722,N,C,9600,4722,Y),
        /* Banking Printer Program OS/2 server definition. Example. */
                      SERVER=(BPP1),
                      SES&BPP=(AA,1,020,TKR,017,N)
    
             LWSCONF  NAME=CC,
                      TYPE=NT,
                      PRODLVL=L60,
        /* Banking Printer Program NT VDM server definition. Example. */
                      SERVER=EHCVDMGR,
                      SERVER=VBIWP1,
                      PAR&VBIW=(AA,1,,,Y,Y,FF,N,N,N,Y,Y,ATR,DIS,KBD,,,,),
                      SERVER=VLDA71,
                      PAR&VLDA=(AA,1),
                      SERVER=VBPP1,
                      SES&VBPP=(AA,1,,,017,N)
    

    Batch machine loader server definitions


    ehcodmos2

    The batch machine loader server requires one PAR&BMLS keyword.

    Keyword
    Description

    PAR&BMLS
    Is a required keyword to define the batch machine loader server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. Program name.

      This parameter specifies the name of the program called by the batch machine loader server when a message is pending in the message queue.

      The parameter is required. The parameter value has the following format:

        nnnnnnnn.eee
      

      where:

      nnnnnnnn
      Is the filename

      eee
      Is the extension of the file that contains the program.
    2. Public object post box user name.

      The parameter is optional. The parameter value is a string of up to 8 alphanumeric characters. The default is the filename of the client program (parameter 1).

    3. Path.

      This parameter specifies the path where the client program runs.

      The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    Batch machine loader server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      SERVER=SMGR,
                      PAR&SMGR=(,,,SMGRPRF,C:\SMGR\,C:\SMGR\,C:\SMGR\,C:\SMGR\),
    /* Batch machine loader server definition.  Example */
                      SERVER=BMLS,
                      PAR&BMLS=(MESSAGP.EXE,MESSAGEP,C:\PATHM\),
    /* Object post box client definition. Example */
                      CLIENT=(OPBS,BB)
     
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
                      SERVER=SHFILE01,
                      PAR&SHFL=(PROFSFS,3,8,Y,0),
    /* Object post box server definition. Example */
                      SERVER=OPBS,
                      PAR&OPBS=(C:\OPBSDB\),
                      CLIENT=(SHFILE01,BB)
    

    Device cluster attachment DLC definitions

    The DCADLC server requires one PAR&DCA keyword.

    Keyword
    Description

    PAR&DCA
    Is a required keyword to define the DCADLC server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. Number of buffers.

      The parameter is optional. The parameter value ranges from 10 to 100. (1 buffer = 272 bytes in memory, 256 bytes of data.) The default is 64.

    2. Maximum number of retries.

      This parameter specifies the number of retries after negative responses that are admitted before resetting the DCA card.

      The parameter is optional. The parameter value ranges from 1 to 100. The default is 10.

    3. Time-out.

      This parameter specifies the seconds after a non-answered request, that are admitted before resetting the DCA card.

      The parameter is optional. The parameter value ranges from 1 to 60. The default is 30.

    Device cluster attachment DLC example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      CLIENT=(SNA01,AA),
                      SES&SNA=(AA,01,010,DCA),
    /* DCA server definition. Example. */
                      SERVER=(DCADLC),
                      PAR&DCA=(64,10,30)
    

    Electronic journal server definitions




    ehcodwl

    The electronic journal server requires one PAR&EJOU keyword.

    Keyword
    Description

    PAR&EJOU
    Is a required keyword to define the electronic journal server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. Profile name.

      If only one electronic journal server profile is defined, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the NAME keyword in the EJOUPRF vector.

    2. Maximum record size.

      The parameter is optional. The parameter value ranges from 1 to 4, meaning the size in KBs. If that keyword is not specified, the default is 1.


    Electronic journal server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      SERVER=SMGR,
                      PAR&SMGR=(,,,SMGRPRF,C:\SMGR\,C:\SMGR\,C:\SMGR\,C:\SMGR\),
                      SERVER=(SHFILEBA),
                      PAR&SHFL=(PROFSFS,10,3,Y),
                      SERVER=(SFQUERY),
                      CLIENT=(SHFILEBA,AA),
    /* Electronic journal server definition. Example. */
                      SERVER=(ELECJO01),
                      PAR&EJOU=(PROFEJOU,1)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Electronic journal client definition. Example. */
                      CLIENT=(ELECJO01,AA)
    

    Forwarding server definitions




    ehcodwl

    The forwarding server requires one PAR&FORW keyword, and as many SES&FORW keywords as forwarding sessions are defined in the profile used.

    Keyword
    Description

    PAR&FORW
    Is a required keyword to define the forwarding server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. Profile name.

      If only one forwarding server profile is defined, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the NAME keyword in the FORWPRF vector.

    2. Translation table.

      This parameter identifies the table that is used to translate from personal computer system ASCII to host computer EBCDIC, when transmitting from the workstation to the host computer.

      The parameter does not apply to DBCS mode. It is optional, if only one translation table is defined. The parameter value is the name of the translation table. It must match the value assigned in a XLATETBL vector with TYPE = AEFORW.

    3. Maximum record size.

      The parameter is optional. The parameter value ranges from 1 to 4, meaning the size in KBs. The default is 1.

    SES&FORW
    Is a required keyword to define a forwarding server session, when the server is specified in a SERVER keyword. One keyword is required for each forwarding session defined.

    You can specify up to 5 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Forwarding session number.

      The parameter is required. The parameter value ranges from 1 to 3, and must match the value assigned in the SESSION keyword in the FORWDS vector.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services for forwarding session.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only that is not X.25.

      For workstations with more than one DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    5. Session device name.

      This parameter specifies the name of the device on the AS/400 that is used for communication purposes.

      The parameter applies only when the SNA services are provided by a OS/400 system.

      The parameter is optional. The parameter value is a string of up to 10 alphanumeric characters.

      The default is QCFBZZFORx. Note that x is the forwarding session number, ranging from 1 to 3, specified in the second parameter.

    Forwarding server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(SHFILEBA),
                      PAR&SHFL=(PROFSFS,10,3,Y),
                      CLIENT=(SHFILEBA,AA),
                      SERVER=SMGR,
                      PAR&SMGR=(,,,SMGRPRF,C:\SMGR\,C:\SMGR\,C:\SMGR\,C:\SMGR\),
                      SERVER=(SFQUERY),
                      SERVER=(SFORFORW),
                      PAR&SFOR=(PROFSTOR,1),
                      CLIENT=(SFORFORW,AA),
    /* Forwarding server definition. Example. */
                      SERVER=(FORWARD),
                      PAR&FORW=(PROFFORW,OUT,1),
                      SES&FORW=(AA,1)
    

    Java file distribution definitions




    ehcowl

    The Java 'server' definition requires one PAR&JAVA keyword.

    For convenience in LANDP customization, the Java file distribution is being treated like a LANDP server. The Java Manager enables Java clients to interact with the LANDP supervisor, but does not run as a service, or register itself with the supervisor.

    Use of the Java 'server' definition results in the files that provide Java support being included for distribution to the current workstation.

    Keyword
    Description

    PAR&JAVA
    Is a required keyword to define the Java distribution parameters, when JAVA is specified in a SERVER keyword.

    You can specify up to 5 parameters:

    1. Generation of Java Manager startup statement.

      This parameter is optional. The parameter value can be:

      Y
      This creates the statement 'START LDPJMAN' in the AUTOFBSS file to start the Java Manager.
      N
      If this is specified, no statement is created in the AUTOFBSS file to start the Java Manager. This is the default value.
    2. Number of dispatcher processes.

      This parameter specifies the number of dispatcher processes that are created for immediate use by the Java Manager. The parameter value can be in the range 1 through 32. The default value is 4.This parameter is ignored if parameter 1 is N.

    3. Distribution of J/XFS (J/eXtensions for Financial Services) printer classes. These classes that deliver the Java enablement for printing are distributed in the Java archive file LDP47X2.JAR.

      This parameter is optional. Its value can be Y to distribute the file, or N to not distribute the file. The default value is N.

    4. Distribution of J/XFS MSR/E classes. These classes that deliver the Java enablement for MSR/E support, are distributed in the Java archive file LDPMSRE.JAR.

      This parameter is optional. Its value can be Y to distribute the file, or N to not distribute the file. The default value is N.

    5. Distribution of J/XFS PINpad classes. These classes that deliver the Java enablement for PINpad support, are distributed in the Java archive file LDPPINP.JAR.

      This parameter is optional. Its value can be Y to distribute the file, or N to not distribute the file. The default value is N.

    Java distribution example

    /* Java distribution definition. Example. */
             LWSCONF  NAME=AA,
                      TYPE=LINUX,
                      SERVER=JAVA,
                      PAR&JAVA=(Y,6,N,N,Y)
    

    LANDP link server definitions




    ehcowl

    The LANDP link server requires one optional PAR&LINK keyword, and can have from 1 to 10 SES&LINK keywords.

    Keyword
    Description

    PAR&LINK
    Is a required keyword to define the LANDP link server parameters when the server is specified in a SERVER keyword. You can specify up to three parameters:
    1. TCP/IP port number

      Range 1024 through 65535, default 52699.

      To make a connection, the exporting LANDP link server and the importing LANDP link server must use the same TCP/IP port.

    2. Connection retry interval in seconds

      Range 0 through 3276. A value of 0 means no retry. The default retry interval is 30 seconds.

      This parameter is only permitted when the SES&LINK import keyword is also specified.

    3. Exporter network name

      The TCP/IP network name or the IP address of the workstation running the exporting LANDP link server. Network names can be up to 35 characters, and must be resolvable to IP addresses by the domain name server or local HOSTS file. IP addresses must be in dotted decimal notation.

      This parameter must be present when, and only when, the SES&LINK import keyword is also specified.

    SES&LINK
    Is a required keyword that can appear up to 10 times to define a list of services to be imported or exported.

    You can specify either two or three parameters:

    1. Import or export

      This parameter is required. The parameter value can be:

      I
      Import the service name that follows

      E
      Export the service name that follows
    2. Service name

      This parameter is required, and its value is the name of the service to be imported or exported. The same name cannot appear more than once in the list of services to be imported. The same name cannot appear more than once in the list of services to be exported.

      The following LANDP service names cannot be imported or exported: SPV, LAN, EHCLIP, SMGR, EHCSAM, EHCTRACW.

    3. Service alias name or workstation name

      When defining a service to be imported, the value of this optional parameter is an alias name for the service. If an alias is specified, the imported service will be made available with the corresponding alias name. If the alias parameter is absent, the imported service will be made available without name change.

      No two services can be imported with the same name. If an import name has trailing '#' characters, then the corresponding alias name must have the same trailing '#' characters.

      When defining a service to be exported, the value of this required parameter is the name of the workstation providing the service.

      Note that, if a service is imported with a name or alias that is not the name of a LANDP-supplied service, a server definition (DEFSERV) statement for it must appear in COMMON.SPC.

    LANDP link server example

    This example imports the SHFILE01 service into workstation AA in workgroup WG1, and exports it from workstation BB in workgroup WG2:

                  LANCONF     NAME=WG1,
                              WSNAMES=(AA,AB)
                  
                  LWSCONF     NAME=AA,       /* Workstation AA in workgroup WG1 */
                              SERVER=(EHCLINK,,N),
                              PAR&LINK=(,,BB.HURSLEY.IBM.COM),
                              SES&LINK=(I,SHFILE01)
     
                  LWSCONF     NAME=AB,       /* Workstation AB in workgroup WG1 */
                              CLIENT=(SHFILE01,AA)
     
                  LANCONF     NAME=WG2,
                              WSNAMES=(BB)
                  
                  LWSCONF     NAME=BB,       /* Workstation BB in workgroup WG2 */
                              SERVER=(SHFILE01,,N),
                              PAR&SHFL=(PRF1,10,3,N,0,100,,N1,10),
                              SERVER=(EHCLINK,,N),
                              PAR&LINK=(),
                              SES&LINK(E,SHFILE01,BB)
     
    

    Logical device address 7 program definitions

    The logical device address (LDA) 7 program requires one PAR&LDA7 keyword.

    If the LDA 7 program will run in an OS/2 or a Windows VDM, the name of the server in the SERVER keyword must be VLDA7x instead of LDA7x. Additionally, the keyword to be included in the LWSCONF, WSMODEL, or SVRMODEL vector must be PAR&VLDA instead of PAR&LDA7. The parameters you can specify in a PAR&VLDA keyword are the same as those that can be specified in a PAR&LDA7 keyword.

    Keyword
    Description

    PAR&LDA7
    Is a required keyword to define the LDA 7 program parameters, when the program is specified in a SERVER keyword.

    You can specify up to 4 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. BIWP emulated session number.

      When the LDA 7 program is installed in a DOS workstation, or is used in OS/2 VDM or Windows, this parameter is required.

      The parameter value ranges from 1 to 5, and must be unique for the workstation where BIWP and the LDA 7 program are installed. It must match the value assigned as the BIWP emulated session number (parameter 2) in the PAR&BIWP keyword.

      When the LDA 7 program is installed in a OS/2 workstation, the parameter must be omitted. The default is 1.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only.

      The parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

    Logical device address 7 program example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      PRODLVL=L60,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
                      SERVER=(BIWP3),
                      PAR&BIWP=(AA,3,013,TKR,R,Y,FF,
                               N,N,N,N,N,ATR,DIS,KBD),
    /* Logical Device Address 7 Program DOS server definition. Example. */
                      SERVER=(LDA73),
                      PAR&LDA7=(AA,3,011,TKR)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
                      PRODLVL=L60,
                      SERVER=(BIWP3),
                      PAR&BIWP=(AA,3,014,TKR,R,Y,FF,
                               N,N,N,N,N,ATR,DIS,KBD),
    /* Logical Device Address 7 Program OS/2 server definition. Example. */
                      SERVER=(LDA73),
                      PAR&LDA7=(AA,3,012,TKR)
     
             LWSCONF  NAME=CC,
                      TYPE=NT,
                      PRODLVL=L60,
    /* Logical Device Address 7 Program Windows NT VDM server definition. Example. */
                      SERVER=EHCVDMGR,
                      SERVER=VBIWP1,
                      PAR&VBIW=(AA,1,,,Y,Y,FF,N,N,N,Y,Y,ATR,DIS,KBD,,,,),
                      SERVER=VLDA71,
                      PAR&VLDA=(AA,1)
    

    MQSeries Link server definitions.




    ehcow

    The LANDP MQSeries Link server requires one PAR&MQ keyword.

    Keyword
    Description

    PAR&MQ
    Is a required keyword to define the MQSeries server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 6 parameters:

    1. MQSeries queue manager name.

      This parameter specifies the name of the queue manager to which the server is to connect. The parameter is a string of up to 24 bytes. All alphabetic characters are processed as upper case. Special characters '_' and '.' can be used in the name. Alternatively, this parameter can define an environment variable, for example, '%MQMNAME%'. If this parameter is omitted, EHCMQ## connects to the MQSeries default queue manager.

    2. Maximum message length.

      This parameter specifies the maximum message length permitted by the MQSeries Link server. This is used to restrict the maximum message length to something less than or equal to the default of 57000 bytes. It can have a value between 1000 and 57000.

    3. Message detail level.

      This parameter specifies the message detail level to be written to the log file. If this parameter is omitted, the default is for logging to be off. The values E|W|I can be specified where E=error level, W=warning level and I=information level. I includes levels W and E, W includes level E.

    4. Log file path.

      This data string specifies the log file path, which can include a drive identifier if required. The log file is where the session log files are created.

      The data string must be less than 30 bytes in length.

      If the data string is omitted, default values are used. The drive defaults to the drive of the current working directory for the EHCMQ## process. If a drive is specified, a path should also be defined. When the path is omitted it defaults to 'EHCMQLOG'. If both drive and path are omitted 'EHCMQLOG' is created as a subdirectory of the current working directory for the EHCMQ## process.

      A log file is created for each session. The log file is named as XXhhmmss.ddd where:

      XX is the workstation identifier of the LANDP client that initiated the session.
      hhmmss is the session start time in hours, minutes, seconds.
      ddd is the day of the year in the range 001 to 366.
    5. Total number of permitted sessions.

      This parameter specifies the maximum number of different sessions the server can process at the same time. The parameter, which is optional, can be given a value in the range from 1 to 64. The default is 32.

    6. Number of MQ connections.

      This parameter specifies the number of MQ connections that should be made at startup. Every session requires a MQ connection, which can be made at startup or as session requests are received. The parameter value can be in the range 0 to the total number of permitted sessions. The parameter is optional with a default value of 0. When this option is non-zero, the LOADER server's timeout probably needs to be increased. Refer to Loading statements for LANDP for OS/2 servers or Loading statements for LANDP for Windows servers.

    MQ server example

          MQSeries Link server example
     
                     LWSCONF NAME=AA,
                             TYPE=OS/2,
          /* MQSeries Link server definition. Example. */
                             SERVER=(EHCMQ##),
                             PAR&MQ=(EHC_QM,32000,W,D:\EHC_QM\,64,4)
                     LWSCONF NAME=BB,
                             TYPE=DOS,
          /* LANDP link server client definition. Example, two sessions */
                             CLIENT=(EHCMQ01,AA),
                             CLIENT=(EHCMQ02,AA)
    

    MSR/E server definitions




    ehcodwl

    When the magnetic stripe reader/encoder (MSR/E) server is loaded in a LANDP workstation, it requires a PAR&MSRE keyword for the workstation that provides services.

    Keyword
    Description

    PAR&MSRE
    Is a required keyword to define the MSR/E server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. MSR/E device.

      This parameter specifies the product attached to the workstation that provides the MSR/E device to be supported by the server.

      The parameter is required. The parameter value can be:

      4717
      IBM 4717 Magnetic Stripe Reader/Encoder (not supported on LANDP for Windows or LANDP for Linux)
      4777
      IBM 4777 Magnetic Stripe Reader/Encoder
      4778
      IBM 4778 PIN Pad Magnetic Stripe Reader
    2. COM port.

      This parameter specifies the COM port where the product that provides the MSR/E device will be attached.

      The parameter applies only if value 4777 or 4778 was specified in parameter 1.

      On LANDP for DOS and LANDP for OS/2, the parameter value can be in the range 1 through 4, or M. If the mouse port is to be used, specify M.

      On LANDP for Windows and LANDP for Linux, the parameter value can be in the range 1 through 8. The mouse port attachment is not supported.

      The default is 1.

      If 4778 PIN pad capabilities are to be used, the value must match that specified in the PAR&PINP keyword.

    MSR/E server example

             LWSCONF  NAME=AA,
                      TYPE=NT,
                      PRODLVL=L60,
    /* Magnetic Stripe Reader/Encoder server definition. Example */
                      SERVER=(MSRE4701),
                      PAR&MSRE=(4777,1)
    

    Native X.25 server definitions




    ehc_xx00

    The native X.25 server requires one PAR&XNAT keyword for the workstation that provides services, and one SES&NSVC keyword for each switched virtual circuit used by the client workstation.

    When the native X.25 services are provided by a DOS workstation, only the SES&NSVC keywords are required.

    Keyword
    Description

    PAR&XNAT
    LANDP for OS/2: Is a required keyword to define the native X.25 server parameters, when this server is specified in a SERVER keyword.

    You can specify up to 4 parameters:

    1. Telephone number selection.

      The parameter is optional. The parameter value can be Y, to include your telephone number in the packet call, or N, not to include it. The default is N.

    2. Your country identification.

      The parameter is optional. The parameter value is a number of three digits. Valid values for your country can be obtained from the telecommunications company. The default is 000.

    3. Your country subcode.

      The parameter is optional. The parameter value ranges from 0 to 9. Valid values for your country can be obtained from the telecommunications company. The default is 0.

    4. Your subscriber number.

      The parameter is required, if you have assigned the Y value to the first parameter (telephone number selection). If not, the parameter is optional.

      The parameter value is a number of up to 11 digits.

    SES&NSVC
    Is a required keyword to define a native X.25 server session, when this server is specified in a CLIENT keyword. One keyword is required for each native X.25 session defined, that will be used from this client workstation.

    You can specify up to 9 parameters:

    1. Name of the workstation providing X.25 Native services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Session identification.

      The parameter is required. The parameter value ranges from 1 to 15, and must be unique for each client workstation. This includes all the circuits: native X.25, SNA, or user communication server.

    3. Connection type.

      The parameter is optional. The parameter value can be:

      INCO
      Incoming
      OUTG
      Outgoing

      It must match the value assigned in the PAR&X25D keyword, or on the X.25 profile. The default is OUTG.

    4. Destination identification.

      The parameter is required for incoming virtual circuits, and optional for outgoing circuits. The parameter value is a string of up to 8 alphanumeric characters.

    5. Partner subscriber address.

      This parameter specifies the subscriber address of the partner you want to communicate with. For international calls, the subscriber number must be preceded by the country identification and the country subcode.

      The parameter is optional for incoming virtual circuits, and required for outgoing circuits. The parameter value is a string of up to 15 digits.

    6. User data field. This parameter specifies information of your own that is sent across the communication line every time a call is made.

      The parameter is optional. The parameter value is a string of up to 4 bytes (eight hexadecimal characters).

      Facility code

      Parameters 7, 8, and 9 define the transmission facilities. The information is optional and made up of up to 63 bytes (126 hexadecimal characters). Refer to the X.25 Codification Facilities Rules from your X.25 Network provider.

    7. Facility code (part 1).

      The parameter is optional. The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    8. Facility code (part 2).

      To specify this code, facility code (part 1) must be completely filled.

      The parameter is optional. The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    9. Facility code (part 3).

      To specify this code, facility code (part 1) and facility code (part 2) must be completely filled.

      The parameter is optional. The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    Native X.25 server example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(X25DLC2),
                      PAR&X252=(20,Y,7,3,PROFILE,214,1,231020107),
    /* Native X.25 server definition (using the IBM X.25
       Interface Coprocessor/2). Example */
                      SERVER=(X25NAT##),
                      CLIENT=(X25NAT01,AA),
                      SES&NSVC=(AA,01,OUTG,INBB,203456988)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Native X.25 client definition. Example */
                      CLIENT=(X25NAT01,AA),
                      SES&NSVC=(AA,01,OUTG,INBB,203456988)
    

    Object post box server definitions


    ehcmos2

    The object post box server requires one PAR&OPBS keyword.

    Keyword
    Description

    PAR&OPBS
    Is a required keyword to define the object post box server parameters, when the server is specified in a SERVER keyword.

    You can specify one parameter:

    1. Database path.

      This parameter specifies the path where the object post box server databases are located.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    Object post box server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
          /* Object post box server definition.  Example */
                      SERVER=(OPBS),
                      PAR&OPBS=(C:\OPBSDB\)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
          /* Object post box client definition.  Example */
                      CLIENT=(OPBS,AA)
    

    ODBC Query server definitions


    ehcmwin

    The ODBC query server requires one PAR&ODB keyword.

    Keyword
    Description

    PAR&ODB
    Is a required keyword to define the ODBC query server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 5 parameters:

    1. Configuration name.

      This parameter specifies the default Data Source name as defined in the ODBC Driver Manager.

      The parameter is optional. The parameter value is a string of up to 20 alphanumeric characters. The default is CONFIGUR.

    2. Number of initial worker threads.

      The number of worker threads grows depending on the amount of throughput. This parameter represents the number of worker threads to be started at initialization.

      The parameter is optional. The parameter value is in the range from 1 through 128, but must be less than or equal to parameter 3. The default is 5.

    3. Maximum number of worker threads.

      If system resources are scarce, this parameter puts a lower threshold on the number of worker threads EHCODB## can start after initialization.

      This parameter is optional. The parameter value is in the range from 1 through 128, but must be greater than or equal to parameter 2. The default is 128.

    4. Maximum sessions per workstation.

      This parameter specifies the maximum number of sessions that can be concurrently open on a workstation.

      This parameter is optional. The parameter value is in the range from 1 through 64. The default is 10.

    5. Request time-out.

      This parameter specifies the time, in seconds, that the ODBC query server waits for a reply from the data source before giving a time-out response.

      The parameter is optional. The parameter value ranges from 10 to 32767. The default is 15.

    ODBC query server example

             LWSCONF  NAME=AA,
                      TYPE=NT,
          /* ODBC query server definition.  Example */
                      SERVER=(EHCODB01),
                      PAR&ODB=(BASEMIX,4,14,10,30)
     
             LWSCONF  NAME=AB,
                      TYPE=NT,
          /* ODBC query server client definition.  Example */
                      CLIENT=(EHCODB01,AA)
    

    PIN pad server definitions




    ehcodwl

    When the PIN pad server is loaded in a LANDP workstation, it requires one PAR&PINP keyword for the workstation that provides services.

    Keyword
    Description

    PAR&PINP
    Is a required keyword to define the PIN pad server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. PIN pad device.

      This parameter specifies the product attached to the workstation that provides the PIN pad device to be supported by the server.

      The parameter is required. The parameter value can be:

      4718
      IBM 4718 Personal Identification Number Keypad (not supported on LANDP for Windows or LANDP for Linux)
      4778
      IBM 4778 PIN Pad Magnetic Stripe Reader
    2. COM port.

      This parameter specifies the COM port where the product that provides the PIN pad device will be attached.

      The parameter applies only if value 4778 was specified in parameter 1. On LANDP for DOS and LANDP for OS/2, the parameter value can be in the range 1 through 4, or M. If the mouse port is to be used, specify M.

      On LANDP for Windows and LANDP for Linux, the parameter value can be in the range 1 through 8. The mouse port attachment is not supported.

      The default is 1.

      If 4778 magnetic stripe reader capabilities are to be used, the value must match that specified in the PAR&MSRE keyword.

    3. Magnetic stripe reader selection.

      This parameter specifies whether 4778 magnetic stripe reader capabilities are to be used, or not.

      The parameter applies only if value 4778 was specified in parameter 1. It is optional. The parameter value can be Y, to use 4778 magnetic stripe reader capabilities, or N, not to use them. The default is Y.

    PIN pad server example

             LWSCONF  NAME=BB,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* PIN pad server definition. Example */
                      SERVER=(PINP4702),
                      PAR&PINP=(4778,2,Y)
    

    Query server definitions


    ehcmos2

    The query server requires one PAR&SQL keyword.

    Keyword
    Description

    PAR&SQL
    Is a required keyword to define the query server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 11 parameters:

    1. Configuration name.

      This parameter specifies the Database Manager database name.

      The parameter is optional. The parameter value is a string of up to 8 alphanumeric characters. The default is CONFIGUR.

    2. Maximum concurrent requests.

      This parameter specifies the maximum number of requests the server can process at the same time.

      The parameter is optional. The parameter value ranges from 1 to 128. The default is 5.

    3. Maximum simultaneous commit units.

      This parameter specifies the maximum number of requests from different sessions the server processes at the same time.

      The parameter is optional. The parameter value ranges from 1 to 128. The default is 4.

    4. Maximum sessions per terminal.

      This parameter specifies the maximum number of applications running EHCSQL## sessions plus the number of extra sessions per workstation using the Open Session (OS) function.

      The parameter is optional. The parameter value ranges from 1 to 64. The default is 10.

    5. Shared file response time emulation selection.

      The parameter is optional. The parameter value can be Y, to get uniform response time, or N, not to specify it. The default is Y.

    6. Request time-out.

      This parameter specifies the time, in seconds, the query server waits for a reply from SQL before giving a time-out response.

      The parameter is optional. The parameter value ranges from 10 to 32767. The default is 15.

    7. Reserved.
    8. Reserved.
    9. Reserved.
    10. Reserved.
    11. ODBC flag.

      This parameter, if set to Y, indicates that the ODBC query server EHCODB## is to be invoked rather than the query server EHCSQL##. Valid values are Y and N. The default is N.

      On a Windows workstation, only Y is valid. On an OS/2 workstation, only N is valid.

    Query server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
    /* Query server definition. Example. */
                      SERVER=(EHCSQL01),
                      PAR&SQL=(CONFIGUR,5,4,10,Y,15)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Query client definition. Example. */
                      CLIENT=(EHCSQL01,AA)
    

    RCMS definitions




    ehcodw

    The remote change management services (RCMS) require one PAR&RCMS keyword.

    Keyword
    Description

    PAR&RCMS
    Is a required keyword to define RCMS, when RCMS is specified in a SERVER keyword.

    You can specify up to 9 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    3. DLC type.

      The parameter applies only if the SNA services are provided by a DOS workstation. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    4. Session device name

      This parameter specifies the name of the device on the AS/400 that is used for communication purposes.

      The parameter applies only when the SNA services are provided by an OS/400 system.

      The parameter is optional. The parameter value is a string of up to 10 alphanumeric characters. The default is QCFBZZRCMS.

    5. System file path.

      This parameter specifies the directory where the logical names file (RCMS.LNF), the RCMS.ACK file, and the EBCDIC-to-ASCII and ASCII-to-EBCDIC translation tables are located in the production workstation at run-time.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    6. Process file path.

      This parameter specifies the directory where RCMS is to store the events occurring during the process, as well as the message file, and log file.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    7. Reserved.
    8. ASCII-to-EBCDIC translation table.

      If only one table is defined, the parameter is optional. The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a XLATETBL vector with TYPE=AERCMS.

      In DBCS mode the parameter specifies the translation mode. The parameter value can be:

      S
      Standard ASCII-EBCDIC and EBCDIC-ASCII translation

      P
      ASCII-EBCDIC translation with ASCII SI/SO characters changed to EBCDIC SI/SO characters, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to ASCII SI/SO characters

      B
      Standard ASCII-EBCDIC translation, and EBCDIC-ASCII translation with EBCDIC SI/SO characters changed to blanks.
    9. EBCDIC-to-ASCII translation table.

      If only one table is defined, the parameter is optional. The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a XLATETBL vector with TYPE=EARCMS.

      In DBCS mode the parameter does not apply.

    RCMS example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* Remote Change Management Services server definition. Example. */
                      SERVER=(RCMS),
                      PAR&RCMS=(AA,021,TKR,,C:\RCMSYS\,
                               C:\RCMPRO\,,OUT,INP)
    

    Shared DOS directory services definitions


    ehcmdos

    The shared DOS directory server requires one PAR&SHDR keyword. You can also specify one SES&SHDR keyword for each client workstation.

    Keyword
    Description

    PAR&SHDR
    Is an optional keyword to define the shared DOS directory server parameters, when the server is specified in a SERVER keyword.

    You can specify one parameter:

    1. Number of entries for the shared DOS directory server.

      This parameter specifies the number of entries in the profile table that describes the relationship between the short name and the directories.

      The parameter is optional. The parameter value ranges from 1 to 99. The default is 10.

    SES&SHDR
    Is an optional keyword to define the data area used by the shared DOS directory server, when the server is specified in a CLIENT keyword.

    You can specify two parameters:

    1. Name of the workstation providing shared DOS directory services.

      The parameter is required, if you specify the keyword. The parameter value is a string of up to 2 alphanumeric characters.

    2. Request/reply data area size.

      This parameter specifies the size of the data area, in K.

      The parameter is required, if you specify the keyword. The parameter value ranges from 1 to 56. The default is 4.

    Shared DOS directory services example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
    /* Shared DOS directory server definition. Example. */
                      SERVER=(SHRDIR),
                      PAR&SHDR=(10)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Shared DOS directory client definition. Example. */
                      CLIENT=(SHRDIR,AA),
                      SES&SHDR=(AA,10)
    

    Shared-file distributor definitions


    ehcmos2

    The shared-file distributor requires one PAR&SFD keyword.

    Keyword
    Description

    PAR&SFD
    Is a required keyword to define the shared-file distributor parameters, when the server is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. Creation of statistics file selection.

      The parameter is optional. The parameter value can be Y, to create a file to collect statistics, or N not to create the file. The default is N.

    2. Number of threads.

      This parameter specifies the number of threads to attend and process requests in parallel.

      The parameter is optional. The parameter value ranges from 1 to 252. The default is 2.

    Shared-file distributor example

             LWSCONF  NAME=M1,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file distributor definition.  Example. */
                      SERVER=EHCSFD01,
                      PAR&SFD=(Y,2),
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE01,
                      PAR&SHFL=(BASEDB11,5,10,Y,3,,EHCSFD01),
    /* Shared-file distributor client definition. */
                      CLIENT=(EHCSFD01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
     
             LWSCONF  NAME=M2,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE02,
                      PAR&SHFL=(BASEDB12,5,10,Y,3,,EHCSFD01),
    /* Shared-file distributor client definition. */
                      CLIENT=(EHCSFD01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
     
             LWSCONF  NAME=M3,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE03,
                      PAR&SHFL=(BASEDB13,5,10,Y,3,,EHCSFD01),
    /* Shared-file distributor client definition. */
                      CLIENT=(EHCSFD01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
     
    

    Shared-file replicator definitions


    ehcmos2

    The shared-file replicator requires one PAR&SFR keyword.

    Keyword
    Description

    PAR&SFR
    Is a required keyword to define the shared-file replicator parameters, when the server is specified in a SERVER keyword.

    You can specify up to 4 parameters:

    1. Creation of statistics file selection.

      The parameter is optional. The parameter value can be Y, to create a file to collect statistics, or N not to create the file. The default is N.

    2. Number of threads.

      This parameter specifies the number of threads to attend and process requests in parallel.

      The parameter is optional. The parameter value ranges from 1 to 252. The default is 2.

    3. Shared-file replicator owner.

      This parameter specifies the full name of the owner of the shared-file replicator.

      The parameter value can be:

      EHCSFD##
      Shared-file distributor with identification ##, where the ## suffix has been substituted to completely identify the distributor.

      EHCSFR##
      Shared-file replicator with identification ##, where the ## suffix has been substituted to completely identify the replicator.
    4. PCB list file.

      This parameter specifies the filename of a file with extension PCN, which will contain the list of PCBs to be accessed by the shared-file replicator.

      The parameter is optional. The parameter value is a string with up to 8 alphanumeric characters. The default is EHCSFRPC.

    Shared-file replicator example

             LWSCONF  NAME=M1,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file replicator definition.  Example. */
                      SERVER=EHCSFR01,
                      PAR&SFR=(Y,2,,BASEDB11),
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE01,
                      PAR&SHFL=(BASEDB11,5,10,Y,3,,EHCSFR01),
    /* Shared-file replicator client definition. */
                      CLIENT=(EHCSFR01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
     
             LWSCONF  NAME=M2,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE02,
                      PAR&SHFL=(BASEDB11,5,10,Y,3,,EHCSFR01),
    /* Shared-file replicator client definition. */
                      CLIENT=(EHCSFR01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
     
             LWSCONF  NAME=M3,
                      TYPE=OS/2,
                      PRODLVL=L60,
    /* Shared-file server definition.  Example. */
                      SERVER=SHFILE03,
                      PAR&SHFL=(BASEDB11,5,10,Y,3,,EHCSFR01),
    /* Shared-file replicator client definition. */
                      CLIENT=(EHCSFR01,M1),
    /* Shared-file server client definitions. */
                      CLIENT=(SHFILE01,M1),
                      CLIENT=(SHFILE02,M2),
                      CLIENT=(SHFILE03,M3)
    

    Shared-file server definitions




    ehcodwl

    The shared-file server requires one PAR&SHFL keyword.

    Keyword
    Description

    PAR&SHFL
    Is a required keyword to define the shared-file server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 9 parameters:

    1. Profile name.

      This parameter specifies the name of the shared-file server profile to be used.

      If only one shared-file server profile is specified in all the SHFLDBD vectors you define, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the SHFLPRF keyword in a SHFLDBD vector.

      If shared-file replicator is to be used, all shared-file servers owned by the same shared-file replicator must use the same profile.

    2. Number of additional buffers.

      Each additional buffer requires 1KB of memory.

      The parameter is optional. The parameter value ranges from 0 to 484. The default is 0.

    3. Number of additional sessions.

      The electronic journal, store-for-forwarding, and forwarding servers require an extra session. If those servers are loaded, the parameter is required.

      If the application obtains additional sessions with the Open Session (OS) function, or if a separate session is defined for the electronic journal or the store-for-forwarding server, you must add those sessions.

      The object post box server also requires an extra session.

      The parameter value ranges from 0 through 243 (OS/2, Windows, and Linux), or from 0 through 245 (DOS). The value plus the number of client workstations must not be higher than 243 (OS/2, Windows, and Linux), or 245 (DOS). The default is 0.

    4. Creation of statistics file selection.

      The parameter is optional. The parameter value can be Y, to create a file to collect statistics, or N not to create the file. The default is N.

    5. Log management type

      The parameter is optional. The parameter value can be:

      0
      Dynamic and static log with a unique log file
      1
      Dynamic log with a unique log file
      2
      Dynamic and static log with two log files
      3
      Dynamic log with two log files

      The default is 0.

    6. Number of files open at a time.

      The parameter is optional. The parameter value ranges from 10 to 245.

    7. Shared-file server owner.

      This parameter specifies the full name of the owner of the shared-file server.

      The parameter applies only to OS/2 workstations. However, it does not apply if the shared-file server is used by:

      • Electronic journal server
      • Object post box server
      • Store-for-forwarding server

      The parameter is optional. The parameter value can be:

      EHCSFD##
      Shared-file distributor with identification ##, where the ## suffix has been substituted to completely identify the distributor.

      EHCSFR##
      Shared-file replicator with identification ##, where the ## suffix has been substituted to completely identify the replicator.
    8. Workstation name on which a backup XLR server is to be run for this active Shared File server.

      Active and backup workstations can be OS/2, Windows, or Linux. Each XLR workstation must run the Service Availability Manager.

      The parameter is optional.

    9. Delay in seconds before the backup takes over from a failed active XLR server. This parameter is meaningful only if parameter 8 is specified.

      The parameter is optional.

      Range 0-999. Default 0 (no automatic takeover).

    Shared-file server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
    /* Shared file server definition. Example. */
                      SERVER=(SHFILEBA),
                      PAR&SHFL=(PROFSFS,10,3,Y,0,60)
     
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
    /* Shared file client definition. Example. */
                      CLIENT=(SHFILEBA,AA)
     
    

    Shared-file server example with XLR

    In the following example, the active server (SHFILE01) is configured on the workstation O1, with a backup on N1. A takeover by the backup occurs 10 seconds after detection of a failure by the active. EHCSAM must run on both these workstations. EHCSAM is also configured to run on workstation O2. The purpose of EHCSAM on O2 is to maintain state information, which is useful if either XLR workstation is not available during the startup of the workgroup EHCCUS.

    LANCONF  GROUP=EHCCUS,      /* Workgroup Definition  */
             NAME=XLR,
             SUFFIX=Y,
             WSNAMES=(O1,O2,O3,N1)
     
    LWSCONF  NAME=O1,           /* Workstation definition O1 */
             PRODLVL=L60,
             TYPE=OS/2,
     
             SERVER=EHCSAM,     /* Service Availability Manager */
     
             SERVER=(EHCVDMGR), /* Multiple virtual DOS machine relay definition */
     
             SERVER=(SHFILE01),  /* Shared-file server definition */
             PAR&SHFL=(SHFLPRF1,10,3,N,0,100,,N1,10),
     
             CLIENT=(SHFILE01,O1) /* Client definitions */
     
    LWSCONF  NAME=O2,            /* Workstation definition O2 */
             PRODLVL=L60,
             TYPE=OS/2,
     
             SERVER=EHCSAM,      /* Service Availability Manager */
     
             SERVER=(EHCVDMGR),  /* Multiple virtual DOS machine relay definition */
    

             CLIENT=(SHFILE01,O1)  /* Client definitions */
    LWSCONF  NAME=O3,            /* Workstation definition O3 */
             PRODLVL=L60,
             TYPE=OS/2,
     
             SERVER=(EHCVDMGR),  /* Multiple virtual DOS machine relay
                                                         definition */
     
             CLIENT=(SHFILE01,O1) /* Client definition */
    LWSCONF  NAME=N1,             /* Workstation definition N1 */
             PRODLVL=L60,
             TYPE=NT,
     
             SERVER=EHCSAM,       /* Service Availability Manager */
     
             SERVER=(EHCVDMGR),   /* Multiple virtual DOS machine relay
                                                         definition */
     
             CLIENT=(SHFILE01,O1)
     
    

    SNA server definitions




    ehcodwl

    The SNA server on Linux is available only through TCP/IP server emulation.

    The SNA server requires one PAR&SNA keyword for the workstation that provides services, and one SES&SNA keyword for each session used by the client workstation.

    When the SNA services are provided from an OS/2 or Windows workstation that does not use LU pool support, only the PAR&SNA keyword is required.

    When the SNA servers are provided from a DOS workstation and RLE compression is to be used, the EHCCOMP server must be defined in the same workstation.

    When the SNA server is used with X.25 DLC, one SES&SPVC keyword for each permanent circuit, and one SES&SSVC keyword for each switched circuit, managed by the SNA server, are also required.

    When the SNA server is used with X.25 DLC, and you plan to use the define connection (DC) or query connection (QC) functions, one SBSX25 keyword is required.

    Keyword
    Description

    PAR&SNA
    Is a required keyword to define the SNA server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 7 parameters (on LANDP for Windows, only parameters 1 and 2 can be used).

    1. Session initialization.

      This parameter specifies who initializes the session.

      The parameter is optional. The parameter value can be:

      APPL
      The application initializes the session.

      ANY
      Either the application or the host computer initializes the session.

      The default is APPL.

    2. BID command management.

      This parameter specifies who manages the BID command.

      The parameter is optional. The parameter value can be:

      SRV
      The SNA server manages the BID command.
      APPL
      The application manages the BID command.

      The default is SRV.

    3. Correlation table size.

      The parameter applies only to OS/2 workstations. The parameter value ranges from 1 to 255.

    4. Wrap selection.

      The parameter applies only to OS/2 workstations. The parameter value can be:

      W
      To use wrap
      N
      Not to use wrap

      The default is N.

    5. LU pool table.

      The parameter applies only to DOS workstations. The parameter value must match the value specified in the NAME keyword of a LUPOOL vector.

    6. Server-managed cryptography.

      The parameter applies only to OS/2 workstations. The parameter value can be:

      Y
      To have cryptography managed by the server.
      N
      If cryptography will not be managed by the server.

      The default is N.

      Server-managed cryptography uses the communications provider exits, ACSRENCR.DLL and ACSRDECR.DLL, which are supplied with LANDP, and the TSS SECY server.

    7. Master key for server-managed cryptography.

      The parameter applies only to OS/2 workstations, and is only valid if server-managed cryptography has been specified (if parameter 6 = Y).

      If specified, this parameter must be a string of 1 to 16 alphanumeric characters. If it is not specified, the key defaults to TMKssww where ss is the session ID and ww is the workstation ID.

    SES&SNA
    Is a required keyword to define a SNA server session when the server is specified in a CLIENT keyword. One keyword is required for each SNA session defined.

    The keyword is required when the SNA services are provided from an OS/2 or Windows workstation that uses LU pool support.

    You can specify up to 5 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. SNA session identifier.

      This number is used by a server or application to identify the SNA session.

      The parameter is required. The parameter value ranges from 01 to 30, and must be unique for the client workstation. It must contain two digits.

      A modified SNA interface that allows for more than 30 user sessions per workstation is available when the SNA services are provided from an OS/2 or Windows workstation. When using this interface, the session identifier may be any two ASCII characters. If LU pooling support is required, provide an SES&SNA keyword for each session to be pooled. If CLIENT=(SNA,xx) has been specified in LWSCONF, the SNA session identifier in the SES&SNA keyword may be any two ASCII characters.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only when the SNA services are provided from a DOS workstation, and the session does not use pooling support. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value must match the value assigned as the virtual circuit definition identification (parameter 1) in a SES&SPVC keyword or SES&SSVC keyword.

    5. Session device name.

      This parameter specifies the name of the device on the AS/400 that is used for communication purposes.

      The parameter applies only when the SNA services are provided by an OS/400 system. The parameter value is a string of up to 10 alphanumeric characters.

    SES&SPVC
    LANDP for DOS: Is a required keyword to define the X25DLC and X25DLC2 server sessions, when the SNA server is specified in a SERVER keyword, and there are X.25 permanent circuits using SNA support.

    You can specify up to 4 parameters:

    1. Virtual circuit identification.

      This parameter identifies the virtual circuit, and is used for reference purposes when defining the SNA session that will use it.

      The parameter is required. The parameter value ranges from 1 to 999. The value must be unique for all the circuits, permanent and virtual, that are used through the SNA server.

    2. Permanent virtual circuit number.

      The parameter is required. The parameter value ranges from 1 to the number of permanent virtual circuits defined either in the PAR&X25D keyword or in the X.25 profile. It must be unique for the SES&SPVC keywords.

    3. Identification block.

      The parameter is optional. The parameter value is a hexadecimal number of three digits. The value must match the information in the host computer.

    4. Identification number.

      The parameter is optional. The parameter value is a hexadecimal number of five digits. The value must match the information in the host computer.

      The combination of the constant X'0200', the identification block, and the identification number results in the exchange identifier (XID), which is only used for switched connections. For permanent SNA circuits, the XID is optional.

    SES&SSVC
    LANDP for DOS: Is a required keyword to define the X25DLC and X25DLC2 servers sessions, when the SNA server is specified in a SERVER keyword, and there are X.25 switched circuits using SNA support.

    The number of SES&SSVC keywords included can be greater than the number of switched virtual calls defined either in the PAR&X25D keyword or in the X.25 profile. However, at run-time the number of switched virtual calls working simultaneously is limited by the number of switched virtual circuits defined.

    You can specify up to 10 parameters:

    1. Virtual circuit identification.

      This parameter identifies the virtual circuit, and is used for reference purposes when defining the SNA session that will use it.

      The parameter is required. The parameter value ranges from 1 to 999. The value must be unique for all the circuits, permanent and virtual, that are used through the SNA server.

    2. Partner subscriber address.

      This parameter specifies the subscriber address of the partner you want to communicate with. For international calls, the subscriber number must be preceded by the country identification and the country subcode.

      The parameter is required. The parameter value is a string of up to 15 digits.

    3. Identification block.

      The parameter is required. The parameter value is a hexadecimal number of three digits. The value must match the information in the host computer.

    4. Identification number.

      The parameter is required. The parameter value is a hexadecimal number of five digits. The value must match the information in the host computer.

      The combination of the constant X'0200', the identification block, and the identification number results in the exchange identifier (XID).

    5. Type of connection.

      The type of connection selected must match those defined during the customization of the X.25 communications adapter card, and the values assigned either in the PAR&X25D keyword, or in the X.25 profile.

      To assign a circuit as incoming, you must have selected at least one incoming or one both-way call during configuration of the adapter.

      To assign a circuit as outgoing, you must have selected at least one outgoing or one both-way call during configuration of the adapter.

      The parameter is optional. The parameter value can be:

      INCO
      Incoming calls
      BOTH
      Both-way calls
      OUTG
      Outgoing calls

      The default is OUTG.

    6. Physical unit (PU) identification.

      The parameter is optional. The parameter value is a string of 8 bytes (16 hexadecimal characters) and must match the host computer definitions.

    7. User data field.

      This is information of your own that is sent across the communication line every time a call is made.

      The parameter is optional. The parameter value is a string of up to 4 bytes (eight hexadecimal characters).

      Facility code

      Parameters 8, 9, and 10 define the transmission facilities. The information is optional and made up by up to 63 bytes (126 hexadecimal characters). Refer to the X.25 Codification Facilities Rules from your X.25 Network provider.

    8. Facility code (part 1).

      The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    9. Facility code (part 2).

      To specify this code, facility code (part 1) must be completely filled. The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    10. Facility code (part 3).

      To specify this code, facility code (part 1) and facility code (part 2) must be completely filled. The parameter value is a string of up to 21 bytes (42 hexadecimal characters).

    SBSX25
    LANDP for OS/2: Is a required keyword to specify the name of the X.25 directory table, when the SNA server is used with X.25 DLC and you plan to use the define connection (DC) or query connection (QC) functions.

    The parameter value must match the value assigned to the TBLNAME keyword of a X25DIR vector.

    SNA server examples

    Example 1
             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* SNA server definition. Example. */
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV)
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
    /*             or TYPE=NT,         */
    /* SNA client definition. Example. */
                      CLIENT=(SNA01,AA),
                      SES&SNA=(AA,01,018,TKR)
    Example 2
             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(X25DLC2),
                      PAR&X252=(20,Y,7,3,PROFILE,214,1,231020107),
    /* SNA server definition (using the IBM X.25 Interface
       Coprocessor/2) for permanent circuits. Example */
                      SES&SPVC=(001,1)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* SNA client definition (using the IBM X.25 Interface
       Coprocessor/2) for permanent circuits. Example */
                      CLIENT=(SNA02,AA),
                      SES&SNA=(AA,02,019,001)
    Example 3
             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(X25DLC2),
                      PAR&X252=(20,Y,7,3,PROFILE,214,1,231020107),
    /* SNA server definition (using the IBM X.25 Interface
       Coprocessor/2) for virtual circuits. Example */
                      SES&SSVC=(002,231020107,017,80011,BOTH)
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* SNA client definition (using the IBM X.25 Interface
       Coprocessor/2) for virtual circuits. Example */
                      CLIENT=(SNA02,AA),
                      SES&SNA=(AA,02,019,002)
    

    Store-for-forwarding server definitions


    ehcodwl

    The store-for-forwarding server requires one PAR&SFOR keyword.

    Keyword
    Description

    PAR&SFOR
    Is a required keyword to define the store-for-forwarding server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. Profile name.

      If only one store-for-forwarding server profile is defined, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the NAME keyword in the SFORWPRF vector.

    2. Maximum record size.

      The parameter is optional. The parameter value ranges from 1 to 4, meaning the size in KBs. If that keyword is not specified, the default is 1.

    Store-for-forwarding server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      SERVER=SMGR,
                      PAR&SMGR=(,,,SMGRPRF,C:\SMGR\,C:\SMGR\,C:\SMGR\,C:\SMGR\),
                      SERVER=(SHFILEBA),
                      PAR&SHFL=(PROFSFS,10,3,Y),
                      CLIENT=(SHFILEBA,AA),
                      SERVER=(SFQUERY),
    /* Store for forwarding server definition. Example. */
                      SERVER=(SFORFORW),
                      PAR&SFOR=(PROFSTOR,1)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Store for forwarding client definition. Example. */
                      CLIENT=(SFORFORW,AA)
    

    Synchronous data link control definitions


    ehcmdos

    The SDLC server requires one PAR&SDLC keyword.

    Keyword
    Description

    PAR&SDLC
    Is a required keyword to define the SDLC server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 25 parameters:

    1. Number of buffers.

      The parameter is optional. The parameter value ranges from 8 to 999 (1 buffer = 290 bytes in memory, 256 bytes of data). The default is 8.

    2. Physical address in the host computer of the physical unit (PU).

      The parameter is required. The parameter value is a hexadecimal number of two digits.

    3. NRZI (non return to zero inverted) selection.

      The parameter is optional. The parameter value can be Y, to use NRZI, or N, not to use NRZI. The default is N.

    4. Switched line selection.

      The parameter is optional. The parameter value can be Y, when using a switched line, or N, when using a point-to-point line. The default is Y.

    5. Connection under application selection.

      The parameter is optional. The parameter value can be:

      Y
      The application starts communication, by sending a Connect (CN) function call to the SNA server.

      N
      The SDLC server starts communication automatically.

      The default is N.

    6. Identification block.

      When working with point-to-point lines, the parameter is optional. The parameter value is a hexadecimal number of three digits.

    7. Identification number.

      When working with point-to-point lines, the parameter is optional. The parameter value is a hexadecimal number of five digits.

      The value must match the information in the host computer. The combination of the constant X'0200', the identification block, and the identification number results in the exchange identifier (XID), which is only used for switched connections.

    8. Line mode.

      The parameter is optional. The parameter value can be TURN, for turnaround required, or CRTS, for constant request to send. When using a two-wire line, you must select TURN; when using a four-wire line, you can select any of the values. The default is TURN.

    9. Line time-out.

      This parameter specifies the time-out in seconds.

      The parameter value ranges from 10 to 65. The default is 65.

    10. System Service Control Point (SSCP) name.

      The parameter is optional. The parameter value is a hexadecimal number of ten digits.

      If specified, the SNA server validates the SSCP name that receives in the ACTPU (activate physical unit) command.

    11-25. System Service Control Point (SSCP) name. See information for parameter 10.

    Synchronous data link control example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      CLIENT=(SNA01,AA),
                      SES&SNA=(AA,01,006,SDL),
    /* SDLC server definition. Example. */
                      SERVER=(SDLC),
                      PAR&SDLC=(58,AA,N,Y,Y,017,00067,TURN)
    

    System manager operator definitions


    ehc_xx00

    The system manager operator requires one PAR&SMOP keyword.

    Keyword
    Description

    PAR&SMOP
    Is a required keyword to define the system manager operator parameters, when the system manager operator is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. Audio signal selection.

      The audio signal notifies the operator of a pending message.

      The parameter is optional. The parameter value can be Y, to use the audio signal, or N, not to use it. The default is N.

    2. Video signal selection.

      The video signal notifies the operator of a pending message.

      The parameter is optional. The parameter value can be Y, to use the video signal, or N, not to use it. The default is N.

    3. Path.

      This parameter specifies the directory where the system manager operator files are located in the production workstation at run-time.

      The parameter is required and applies only to DOS workstations. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    System manager operator example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=SMGR,
                      PAR&SMGR=(,,,SMGRPRF,C:\SMGR\,C:\SMGR\,C:\SMGR\,C:\SMGR\),
    /* System manager operator server definition. Example. */
                      SERVER=(SMOP),
                      PAR&SMOP=(Y,Y,C:\SMOP\FILES\)
    

    System manager server definitions




    ehcodwl

    The system manager server requires one PAR&SMGR keyword.

    Keyword
    Description

    PAR&SMGR
    Is a required keyword to define the system manager server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 10 parameters:

    1. Name of the workstation providing SNA services for alerts.

      The parameter applies only when using alerts. In this case, it is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. DLC type used by the workstation providing SNA services for alerts.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    3. Path for alerts.

      This parameter specifies the directory where the file to temporary store alerts is located in the production workstation at run-time. The file is automatically created by the system manager server at run-time, in the path you specify.

      The parameter value is a string of up to 30 alphanumeric characters.

      On LANDP for OS/2, LANDP for Windows, LANDP for DOS, the format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      On LANDP for Linux, the parameter value is the complete path, including subdirectories. It must not exceed 30 characters, and must be enclosed in single quotation marks. A backslash character must be present after the last subdirectory name. The format must be:

        /directory1/[directory2/[directory3/]]
      

      A maximum of three levels is permitted for the path.

    4. Profile name.

      If only one system manager server profile is defined, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters, and must match the value assigned in the NAME keyword in the SMGRPRF vector.

    5. Path for user profiles.

      This parameter specifies the directory where the user profiles are located in the production workstation at run-time.

      If you have defined user profiles, the parameter is required. The parameter value is a string of up to 30 alphanumeric characters. On LANDP for OS/2, LANDP for Windows, LANDP for DOS, the format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      On LANDP for Linux, the parameter value is the complete path, including subdirectories. It must not exceed 30 characters, and must be enclosed in single quotation marks. A backslash character must be present after the last subdirectory name. The format must be:

      /directory1/[directory2/[directory3/]]
      

      A maximum of three levels is permitted for the path.

    6. Path for common data.

      This parameter specifies the directory where the common data is located in the production workstation at run-time.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. On LANDP for OS/2, LANDP for Windows, LANDP for DOS, the format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      On LANDP for Linux, the parameter value is the complete path, including subdirectories. It must not exceed 30 characters, and must be enclosed in single quotation marks. A backslash character must be present after the last subdirectory name. The format must be:

      /directory1/[directory2/[directory3/]]
      

      A maximum of three levels is permitted for the path.

    7. Path for the log file.

      This parameter specifies the directory where the log file is located in the production workstation at run-time.

      If log support is used, the parameter is required. The parameter value is a string of up to 30 alphanumeric characters. On LANDP for OS/2, LANDP for Windows, LANDP for DOS, the format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      On LANDP for Linux, the parameter value is the complete path, including subdirectories. It must not exceed 30 characters, and must be enclosed in single quotation marks. A backslash character must be present after the last subdirectory name. The format must be:

      /directory1/[directory2/[directory3/]]
      

      A maximum of three levels is permitted for the path.

    8. Path for the record definition file.

      This parameter specifies the directory where the file containing the record definitions is located in the production workstation at run-time.

      The parameter is required if you have specified COMDTVAL = Y or APPDTVAL = Y in the SMGRPRF vector, or if the system manager server will perform record validation.

      The parameter value is a string of up to 30 alphanumeric characters.On LANDP for OS/2, LANDP for Windows, LANDP for DOS, the format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      On LANDP for Linux, the parameter value is the complete path, including subdirectories. It must not exceed 30 characters, and must be enclosed in single quotation marks. A backslash character must be present after the last subdirectory name. The format must be:

      /directory1/[directory2/[directory3/]]
      

      A maximum of three levels is permitted for the path.

    9. Drive for the FBSS#GDT backup.

      The parameter specifies the drive where the FBSS#GDT backup is located in the production workstation at run-time.

      The parameter is optional. The parameter value is an alphabetic character. The customization program provides no default for this parameter.

      This parameter is not supported on Linux. If required, the value should be entered on the -D loader parameter (see "System manager server").

    10. Netview operator ID.

      This parameter specifies the Netview operator ID that receives messages at the host computer.

      The parameter is optional. The parameter value is a string of up to 8 ASCII characters. The customization program provides no default for this parameter.

    System manager server example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(SDLC),
                      PAR&SDLC=(58,AA,N,Y,Y,017,00067,TURN),
    /* System manager server definition. Example. */
                      SERVER=(SMGR),
                      PAR&SMGR=(AA,SDL,C:\SMGR\ALERTS\,PROFSMGR,
                       C:\SMGR\USERS\,C:\SMGR\COMMON\,
                       C:\SMGR\LOG\,C:\SMGR\RECORDS\)
    

    TCP/IP wide area communications server definitions




    ehcodwl

    The TCP/IP wide area communications server requires one PAR&TCP keyword for the workstation that provides services, and one SES&TCP keyword for each line of the EHCTCP.INI file. This file is used to map LANDP sessions with SNA and PPC servers to TCP/IP protocols, ports and internet addresses.

    Keyword
    Description

    PAR&TCP
    Is a required keyword to define the TCP/IP wide area communications server parameters when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters.

    1. Maximum number of sessions.

      The parameter applies only to DOS workstations. The parameter value can range from 5 through 2048. The default is 5. The number of sessions required is one for each user session, plus two for each Dependent LU Server (DLUS).

    2. SNA server emulation.

      The parameter value can be:

      Y
      To emulate the SNA server.
      N
      To not emulate the SNA server.

      The default is N.

      Note:
      When emulating the SNA server, a SERVER statement for the SNA server must be included for this workstation. In the case of DOS workstations, although a SERVER statement for the SNA server is required, further SERVER statements for DLC servers are not required because the DLC function is provided by TCP/IP. Also, the LU number and DLC type parameters (on the various SES& and PAR& keywords relating to SNA sessions) are not required.
    3. PPC server emulation.

      The parameter value can be:

      Y
      To emulate the PPC server.
      N
      To not emulate the PPC server.

      The default is N.

      Note:
      When emulating the PPC server, a SERVER statement for the PPC server must be included for this workstation.
    Note:
    Parameters 2 and 3 cannot both be Y on DOS workstations.

    Keyword
    Description

    SES&TCP
    Is an optional keyword that can appear more than once when the EHCTCP server is specified in a server keyword. Each occurrence defines a line of the EHCTCP.INI file.

    You can specify 3 or 4 parameters:

    1. The name of the session or other resource to be defined.

      This parameter is required. It is a string of up to 8 characters. One or more characters can be replaced with '#' to indicate that this definition applies to names with any character in that position. The last character can be '*' to indicate that this definition applies to names with any suffix in place of the '*'. See below, for some examples of the parameter's use.

    2. Type of definition.

      This parameter is required. See below, for some examples of the parameter's use.

    3. Value for definition.

      This parameter is required. See below, for some examples of the parameter's use.

    4. Comment.

      An optional comment of up to 30 characters enclosed in quotes.

    These generate a line in the EHCTCP.INI file of the form:

    Name=      Type:  Value  ;Comment 
    

    The purpose of the EHCTCP.INI file is to provide the information required to map LANDP sessions with SNA and PPC servers to TCP/IP protocols, services, ports and internet addresses. Supported protocols include TELNET tn3270, MPTN(AnyNet), and TCP/IP sockets. IP addresses can be in dotted notation, or can be names that are to be resolved by the domain name server or HOSTS file.

    SNA server sessions are identified by 'SNA', followed by the workstation ID, followed by the session ID. For example: SNAGW12 is session 12 on workstation GW.

    PPC server sessions are identified by the local and partner LU aliases.

    Starting from the beginning of the file, the first match to the session identifier is used. '#' represents any character and '*' represents any suffix. For example, SNAGW12 will match SNA##12 and SNAGW*, whichever is first.

    Example TCP/IP wide area communications server definitions

    Some of the following examples have been formatted for ease of readability. In SES&TCP statements, all blanks separating parameters must be removed. The last three examples show valid formatting.

    To aid clarity, a mixture of uppercase characters, lowercase characters, and blanks, is allowed in the EHCTCP.INI file. However, the file is treated as uppercase in use, because all network names must be uppercase.

    Example: EMU3270 server sessions to Telnet protocol

    This example shows how to map EMU3270 server sessions (SNA sessions 51 through 55) from all workstations in the workgroup to the TELNET tn3270 protocol and service on a host called winmvs20.

    SES&TCP=(SNA##5#, Telnet, winmvs20, 'All EMU3270 -> winmvs20 TELNET'),
    

    The TCP/IP port number associated with the telnet service in the local TCP/IP SERVICES file is used. If no such association exists, port 23 is used.

    Example: PPC server session to MPTN (AnyNet) protocol

    This example shows the definitions required to map a PPC server session to MPTN (AnyNet) protocol. The local LU alias is IYAET000, the partner LU alias is IYCKSPP1 and the mode is CICSISC0.

    The first line maps the partner LU alias to the port and IP address to be used. The IP address is in dotted notation just to demonstrate the range of possibilities.

    The second line maps the local LU alias to the fully qualified SNA network name of the LU.

    The third line maps the partner LU alias to the fully qualified SNA network name of the LU.

    The last line defines the LU6.2 conversation mode. The value parameter must be two or three numbers separated by a period. The first is the total number of sessions (in the range 1 through 32767), the second is the number of contention winner sessions (in the range 0 through number of sessions), and the third is the maximum RU size (in the range 256 through 65536). If the third number is omitted, or is set to 0, an implementation-defined default will be used for the maximum RU size.

    SES&TCP=(IYCKSPP1,MPTN,  9.20.101.41,   'TCP/IP service and IP address'),
    SES&TCP=(IYAET000, LocalLU,  GBIBMIYA.IYAET000, 'Local LU fully qualified name'),
    SES&TCP=(IYCKSPP1, RemoteLU, GBIBMIYA.IYCKSPP1, 'Partner LU fully qualified name'),
    SES&TCP=(CICSISC0, MODE,     10.5.4096,              '10 sessions, 5 winners, 4K RU'),
    

    The TCP/IP port number associated with the MPTN service in the local TCP/IP SERVICES file is used. If no such association exists, port 397 is used.

    Note that, on Linux, port numbers below 1024 can only be used by programs with root permissions. You can either run EHCTCP with root permissions, or configure it and the partner host to use an alternative port number. You can override the assignment of port number to service with the line below:

    SES&TCP=(Mptn, Service,        Port50397,              'Alternative MPTN port'),
    

    Example: SNA server session to MPTN (AnyNet) protocol

    This example shows the definitions that are required to map SNA server sessions to MPTN (AnyNet) protocol. This requires a dependent LU server (DLUS) on the host computer for which we have used a local alias of DLUS1 (DLUS is a required prefix for this name).

    The first line maps all remaining SNA sessions (that is, not the EMU3270 sessions mapped earlier) to a pool of 8 LU numbers (2 through 9) on a dependent LU server with local alias DLUS1. DLUS is a required prefix for this name. The value parameter can be a single LU number in the range 2 through 255, or a pair of numbers that define an LU pool. In the latter case, the first number defines the lowest LU number in the pool and the second number defines the size of the pool. This line could be replaced by many lines, each mapping only one session to an LU number, or some combination of individual and pooled LU numbers.

    The second and third lines define the local and host fully qualified SNA network names that should be used for communication with the DLUS.

    The fourth line gives the protocol and IP address to be used.

    The fifth and sixth lines define the XID and the PU name that are required for communication with the DLUS.

    SES&TCP=(SNA*,  DLUS1,    2.8,               'Map to pool of LU numbers 2-9'),
    SES&TCP=(DLUS1, LocalLU,  GBIBMIYA.IYCUT310, 'Local node fully qualified name'),
    SES&TCP=(DLUS1, RemoteLU, GBIBMIYA.IYCUCDRM, 'Host node fully qualified name'),
    SES&TCP=(DLUS1, Mptn,  winmvs2a,             'TCP/IP service and IP address'),
    SES&TCP=(DLUS1, XID,      05DE3001,          'XID'),
    SES&TCP=(DLUS1, PUname,   IYCUR301,          'PU name'),
    

    Note that, when using the TCP/IP wide area communications server, the depenent LU names configured in VTAM must have a common alphanumeric prefix and a numeric suffix with a constant difference between the suffix and the LOCADDR.

    For example:

         IYCKT300 LU LOCADDR=2
         IYCKT301 LU LOCADDR=3
         IYCKT327 LU LOCADDR=29
         IYCKT481 LU LOCADDR=183
    

    Example: Connection of incoming TCP/IP sessions

    This example shows the definition that is required to allow the connection of incoming TCP/IP sessions. This is required for PPC server 'contention-loser' sessions and for SNA-dependent LU sessions (see the example above).

    The value is the number of connections that can be in the process of connecting at any one time (not the number of connections). A value of at least 2 is required for MPTN sessions. Increase the value if you find that incoming (contention-loser) PPC sessions fail to connect.

    SES&TCP=(Listen, Mptn, 2, 'Listen for 2 MPTN sessions'),
    

    Example: PPC server to TCP/IP sockets

    The PPC server OP request has a complex data field. However, it can be left completely blank if the default values are defined in the EHCTCP.INI file. The use of defaults is particularly appropriate when mapping PPC server sessions to TCP/IP sockets, because the only information that is needed is the TCP/IP address of the partner, and the port number to use.

    The following definitions are required for a 'contention-winner' session :

    SES&TCP=(FBSSLUPA,       Port54321,      testpc21),
    SES&TCP=(FBSSLULO,     LocalLU,        Dummy),
    SES&TCP=(FBSSLUPA,     RemoteLU,       Dummy),
    SES&TCP=(FBSSMODE,     Mode,           1.0),
     
    

    The corresponding 'contention-loser' session requires the following INI file definition:

      SES&TCP=(Listen,                Port54321,      1),
    

    Example:PPC server over TCP/IP (MPTN)

    LWSCONF NAME=AB,
            TYPE=OS/2,
            PRODLVL=L60,
    /* PPC server over TCP/IP */
            SERVER=(PPC,,N),
    /* TCP/IP wide area communications server */
            SERVER=(EHCTCP,,N),
            PAR&TCP=(,,Y),
            SES&TCP=(Listen,Mptn,2,'Listen for MPTN sessions'),
            SES&TCP=(IYAET000,LocalLU,GBIBMIYA.IYAET000,'Local LU alias'),
            SES&TCP=(IYCKSPP1,RemoteLU,GBIBMIYA.IYCKSPP1,'Partner LU alias'),
            SES&TCP=(IYCKSPP1,Mptn,winmvs20.ibm.com,'Port and IP address'),
            SES&TCP=(CICSISC0,MODE,2.1,'2 sessions, 1 winner'),
    /* PPC client */
            CLIENT=(PPC,AB)
    

    Example: Emulator sessions to SNA over TCP/IP (TELNET)

    LWSCONF NAME=AA,
            TYPE=DOS,
            PRODLVL=L60,
    /* SNA server over TCP/IP */
            SERVER=(SNA##,,N),
            PAR&SNA=(APPL,SRV),
    /* TCP/IP wide area communications server */
            SERVER=(EHCTCP,,N),
            PAR&TCP=(5,Y,),
            SES&TCP=(SNA##5#,Telnet,winmvs20,'Emulator session TELNET'),
    /* Emulator */
            SERVER=(EMU32701),
            PAR&3270=(N,N),
            SES&3270=(AA,1,,,ATR,DIS,KBD)
    

    Example: SNA server over TCP/IP (MPTN)

    LWSCONF NAME=AC,
            TYPE=OS/2,
            PRODLVL=L60,
    /* SNA server over TCP/IP */
            SERVER=(SNA##,,N),
            PAR&SNA=(APPL,SRV),
    /* TCP/IP wide area communications server */
            SERVER=(EHCTCP,,N),
            PAR&TCP=(,Y,),
            SES&TCP=(Listen,Mptn,1,'Listen for MPTN sessions'),
            SES&TCP=(SNA####,DLUS1,2.20,'Map all sessions to pool of 20'),
            SES&TCP=(DLUS1,LocalLU,GBIBMIYA.IYCUT310,'Local LU alias'),
            SES&TCP=(DLUS1,RemoteLU,GBIBMIYA.IYCUCDRM,'Partner LU alias'),
            SES&TCP=(DLUS1,Mptn,winmvs20.ibm.com,'Port and IP address'),
            SES&TCP=(DLUS1,XID,05DE3001,'XID'),
            SES&TCP=(DLUS1,PUname,IYCUR301'PU name'),
    /* SNA client */
            CLIENT=(SNA01,AC),
            SES&SNA=(AC,01,,,)
    

    Token-ring data link control definitions


    ehcmdos

    The TRDLC server requires one PAR&TKR keyword.

    Keyword
    Description

    PAR&TKR
    Is a required keyword to define the TRDLC server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 23 parameters:

    1. Number of buffers.

      The parameter is optional. The parameter value ranges from 16 to 216 (1 buffer = 272 bytes in memory, 256 bytes of data). The default is 48.

    2. Service access point (SAP) for the workstation.

      The parameter is optional. The parameter value is a hexadecimal number of two digits:

      • The first one ranges from 0 to E.
      • The second one can be 0, 4, 8, or C.

      The value 00 is not valid. The default is 04, which is the default SAP used by SNA nodes and identifies the path control as the data link user.

    3. Service access point (SAP) for the host.

      The parameter is optional. The parameter value is a hexadecimal number of two digits:

      • The first one ranges from 0 to E.
      • The second one can be 0, 4, 8, or C.

      The value 00 is not valid. The default is 04, which is the default SAP used by SNA nodes and identifies the path control as the data link user.

    4. Workstation address.

      This parameter specifies the locally administered address for the workstation.

      The parameter is required. The parameter value is a hexadecimal number of eight digits. It ranges from 00000000 to 7FFFFFFF.

      The address becomes a hexadecimal number of twelve digits:

      • The first four are 4000.
      • The other eight are those provided as the parameter value.

      Note that the workstation address must not be the same as the host address.

    5. Host address.

      This parameter specifies the locally administered address for the host.

      The parameter is required. The parameter value is a hexadecimal number of eight digits. It ranges from 00000000 to 7FFFFFFF. The address becomes a hexadecimal number with twelve digits:

      • The first four are 4000.
      • The other eight are those provided as the parameter value.

      Note that the specified address must not be the same as the address of the workstation.

    6. SNA XID block number.

      The parameter is optional. The parameter value is a hexadecimal number of three digits, and must match the information in the host computer. The default is 017.

    7. SNA XID identification number.

      The parameter is optional. The parameter value is a hexadecimal number of five digits, and must match the information in the host computer. The default is 00000.

      The combination of the constant X'0200', the block number, and the identification number results in the SNA exchange identifier (XID).

    8. System Service Control Point (SSCP) name.

      The parameter is optional. The parameter value is a hexadecimal number of ten digits.

      If specified, the SNA server validates the SSCP name that receives in the ACTPU (activate physical unit) command.

    9 to 23. System Service Control Point (SSCP) name.    See information for parameter 8.

    Token-ring data link control example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
    /* Token-Ring server definition. Example. */
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
                      CLIENT=(SNA01,AA),
                      SES&SNA=(AA,01,001,TKR)
    

    Virtual file support definitions

    The virtual file support requires one PAR&VFIL keyword.

    Keyword
    Description

    PAR&VFIL
    Is a required keyword to define the virtual file support parameters, when this support is specified in a SERVER keyword.

    You can specify up to 4 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    3. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only.

      The parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)
    4. Virtual drive.

      The parameter is required. This parameter specifies the virtual drive assigned to the virtual file support in the workstation.

      The parameter value ranges from C to Z.

    Virtual file support example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* Virtual File Support server definition. Example. */
                      SERVER=(VFILE),
                      PAR&VFIL=(AA,016,TKR,V)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Virtual File Support server definition. Example. */
                      SERVER=(VFILE),
                      PAR&VFIL=(AA,017,TKR,V)
    

    Virtual volume support definitions

    The virtual volume support requires one PAR&VVOL keyword.

    Keyword
    Description

    PAR&VVOL
    Is a required keyword to define the virtual volume support parameters, when this support is specified in a SERVER keyword.

    You can specify up to 27 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required, unless the workstation is directly attached to the 4700 system via DCADLC, and is the same workstation where the virtual volume support installed. The parameter value is a string of up to 2 alphanumeric characters.

    2. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    3. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only.

      The parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)
    4. Public virtual volume 1 selection.

      The parameter is optional. The parameter value can be Y, to select PUBLIC1 virtual volume, or N, tonot to select it. The default is N.

    5. through 27.

      Public virtual volume n selection (n = 2, 3, ... , 24).

      These parameters are optional. The parameter value can be Y, to select PUBLICn virtual volume, or N, to not select it. The default is N.

      At least one public virtual volume (n = 1, 2, ... ,24) must be selected.

    Virtual volume support example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* Virtual Volume Support server definition. Example. */
                      SERVER=(RDVVOLS),
                      PAR&VVOL=(AA,013,TKR,Y,Y,Y,N)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* Virtual Volume Support server definition. Example. */
                      SERVER=(RDVVOLS),
                      PAR&VVOL=(AA,014,TKR,Y,Y,Y,N)
    

    X.25 data link control definitions


    ehcmdos

    The X25DLC server, which supports the IBM PC X.25 Communications Adapter, requires one PAR&X25D keyword.

    The X25DLC2 server, which supports the IBM X.25 Interface Coprocessor/2, requires one PAR&X252 keyword. To use the IBM X.25 Interface Coprocessor/2, it is required to run the customization program provided with the IBM X.25 Interface Coprocessor/2 support program. For information, refer to the User's Guide and the Programmer's Reference manuals of that product.

    To use the X.25 support through the native X.25 server, it is necessary to specify one SES&NSVC keyword for each switched virtual circuit used by the client workstation. See Native X.25 server definitions.

    To use the X25DLC support through the SNA server, it is necessary to specify one SES&SPVC keyword for each permanent circuit, and one SES&SSVC keyword for each switched circuit, managed by the SNA server. See SNA server definitions.

    Keyword
    Description

    PAR&X25D
    Is a required keyword to define the X25DLC server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 16 parameters:

    1. Number of buffers.

      The parameter is optional. The parameter value ranges from 20 to 2000 (1 buffer = 144 bytes in memory, 128 bytes of data). The default is 20.

    2. Telephone number selection.

      The parameter is optional. The parameter value can be Y, to include your telephone number in the packet call, or N, not to include it. The default is Y.

      Number of virtual circuits and calls

      Parameters 3, 4, 5, and 6 specify, respectively, the number of:

      • Permanent virtual circuits
      • Incoming virtual calls
      • Both-way virtual calls
      • Outgoing virtual calls

      The sum of the permanent virtual circuits, incoming virtual calls, both-way virtual calls, and outgoing virtual calls, must be between 1 and 20. Note that you cannot assign 0 to the four parameters, but at least one of them must be assigned a non-zero value.

    3. Number of permanent virtual circuits.

      The parameter is optional. The parameter value ranges from 0 to 20.

    4. Number of incoming virtual calls.

      The parameter is optional. The parameter value ranges from 0 to 20.

    5. Number of both-way virtual calls.

      The parameter is optional. The parameter value ranges from 0 to 20.

    6. Number of outgoing virtual calls.

      The parameter is optional. The parameter value ranges from 0 to 20.

      Logical channel identification

      Parameters 7, 8, and 9 specify, respectively, the logical channel identification for:

      • First incoming virtual call
      • First both-way virtual call
      • First outgoing virtual call

      They are assigned in ascending order with the lowest being permanent virtual circuits:

      • Permanent virtual circuits
      • First incoming virtual call
      • First both-way virtual call
      • First outgoing virtual call

      The circuit IDs are assigned consecutively, starting with the logical channel ID specified for the first circuit of each type. Therefore, if you had three permanent virtual circuits, the logical channel ID of the first incoming virtual call must be at least 4. Logical channel IDs cannot overlap. The maximum number of circuits is 20.

      Note:
      Several circuit validations are performed on the data you provide:
      • The number of permanent virtual circuits must be less than the logical channel ID of any incoming, both-way, or outgoing virtual calls.
      • The maximum logical channel ID of incoming, both-way, and outgoing virtual calls cannot exceed 4095.
      • The logical channel ID of the first incoming, both-way, or outgoing virtual calls must be left blank when the respective number of incoming, both-way, and outgoing virtual circuits is zero.
    7. Logical channel identification for the first incoming virtual call.

      If the number of incoming virtual calls is different from zero, the parameter is required. The parameter value ranges from 1 to 4095.

    8. Logical channel identification for the first both-way virtual call.

      If the number of both-way virtual calls is different from zero, the parameter is required. The parameter value ranges from 1 to 4095.

    9. Logical channel identification for the first outgoing virtual call.

      If the number of outgoing virtual calls is different from zero, the parameter is required. The parameter value ranges from 1 to 4095.

    10. Level 2 window size.

      This parameter specifies the maximum number of messages that the workstation can send to the network before receiving an answer at frame level.

      The parameter is optional. The parameter value ranges from 1 to 7. The default is 7.

    11. Level 2 retransmission limit.

      This parameter specifies the number of frame retransmission attempts after an error occurs.

      The parameter is optional. The parameter value ranges from 1 to 20. The default is 3.

    12. Level 2 retransmission time-out.

      This parameter specifies the amount of time, in hundredths of seconds, the system waits for an answer before retrying the transmission.

      The parameter is optional. The parameter value ranges from 100 to 500. The default is 150.

    13. Interrupt number.

      This parameter specifies the interrupt number selected on the X.25 communications adapter card when it was installed in the workstation.

      The parameter is optional. The parameter value ranges from 2 to 4. The default is 3.

    14. Your country identification.

      The parameter is required. The parameter value is a number of three digits. Valid values for your country can be obtained from the telecommunications company.

    15. Your country subcode.

      The parameter is required. The parameter value ranges from 0 to 9. Valid values for your country can be obtained from the telecommunications company.

    16. Your subscriber number.

      The parameter is required. The parameter value is a number of up to 11 digits.

    PAR&X252
    Is a required keyword to define the X25DLC2 server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 8 parameters:

    1. Number of buffers.

      The parameter is optional. The parameter value ranges from 20 to 2000 (1 buffer = 144 bytes in memory, 128 bytes of data). The default is 20.

    2. Telephone number selection.

      The parameter is optional. The parameter value can be Y, to include your telephone number in the packet call, or N, not to include it. The default is Y.

    3. Memory pool size.

      This parameter specifies the amount of memory, in KB, reserved for the IBM X.25 Co-Processor Support program.

      The parameter is optional. The parameter value ranges from 7 to 99.

      The recommended value is: 6KB + (n ÷. 2)KB, where n is the number of virtual circuits. If you specify a value that is too low, unpredictable errors can occur. The default is 7.

    4. Adapter number.

      The parameter is optional. The parameter value ranges from 0 to 7. The default is 0.

      IBM X.25 and other IBM Realtime Interface Co-Processor adapters are numbered sequentially, starting with 0, according to the physical slots into which they are plugged in the workstation. Empty slots and slots used by other adapters are not counted.

    5. Profile name.

      This parameter specifies a profile created with the customization program provided with the X.25 Co-Processor Support program.

      If only one X25DLC2 server profile is defined, the parameter is optional. The parameter value is a string of up to 8 alphanumeric characters.

    6. Your country identification.

      The parameter is optional. The parameter value is a number of three digits. Valid values for your country can be obtained from the telecommunications company. The default is 000.

    7. Your country subcode.

      The parameter is optional. The parameter value ranges from 0 to 9. Valid values for your country can be obtained from the telecommunications company. The default is 0.

    8. Your subscriber address.

      The parameter is required. The parameter value is a number of up to 11 digits.

    X.25 data link control examples

    /* Following is Example 1, which corresponds to keyword  */
    /* specifications for the X25DLC server.                 */
     
             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(X25NAT##),
                      CLIENT=(X25NAT01,AA),
                      SES&NSVC=(AA,01,OUTG,INXB,111111111),
    /* Definition using the IBM PC X.25 Communications Adapter. */
                      SERVER=(X25DLC),
                      PAR&X25D=(20,Y,1,2,4,4,2,4,8,7,3,150,3,214,1,
                      231020107)
    
    /* Following is Example 2, which corresponds to keyword  */
    /* specifications for the X25DLC server.                 */
     
             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(X25NAT##),
                      CLIENT=(X25NAT01,AA),
                      SES&NSVC=(AA,01,OUTG,INXB,111111111),
    /* Definition using the IBM X.25 Interface Coprocessor/2. */
                      SERVER=(X25DLC2),
                      PAR&X252=(20,Y,7,3,PROFILE,214,1,231020107)
    

    3270 emulator definitions




    ehcodw

    The 3270 emulator requires one PAR&3270 keyword, and as many SES&3270 keywords as 3270 emulated sessions are to be defined in the workstation.

    To define several 3270 emulators in the same workstation with the same parameter values, only one PAR&3270 keyword is required.

    Keyword
    Description

    PAR&3270
    Is a required keyword to define the 3270 emulator parameters, when the emulator is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. 3270 emulator high level language application programming interface (HLLAPI) selection.

      The parameter value can be Y, to use HLLAPI, or N, not to use HLLAPI. The default is N.

    2. Cryptographic support selection.

      The parameter does not apply to DBCS mode. It is optional. The parameter value can be Y, to use the cryptographic support, or N, not to use it. The default is N.

    Note:
    When working with LANDP for OS/2, or LANDP for Windows workstations, the 3270 emulator can be used only in the appropriate VDM. When working in DBCS mode, the 3270 emulator cannot be used in a VDM, and thus it cannot run on a LANDP for OS/2, or LANDP for Windows workstation.

    SES&3270
    Is a required keyword to define a 3270 emulator session, when the emulator is specified in a SERVER keyword. One keyword is required for each 3270 emulated session defined.

    You can specify up to 13 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. 3270 emulated session number.

      The parameter is required. The parameter value ranges from 1 to 5, and must be unique for the workstation where the 3270 emulator will be installed. The value must match the 3270 emulator suffix, which identifies the session to be used (x value in EMU3270x servername).

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    5. Display color attributes.

      This parameter identifies the color attributes table used for the workstation display.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the color attributes table. It must match the value assigned in the EXTEN keyword in a DISPLATT vector with TYPE = 3270. Specify ATR to use the default table.

    6. Display translation table.

      This parameter identifies the table that is used to translate from host computer EBCDIC to personal computer system ASCII, when receiving from the host computer.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a XLATETBL vector with TYPE = EA3270. Specify DIS to use the default table.

      In DBCS mode, this parameter applies only to single-byte characters (SBCS). DBCS characters are translated by the DBTR server.

    7. Keyboard translation table.

      This parameter identifies the translation table used for the workstation keyboard. The parameter value is a string of three alphanumeric characters, which is the identifier of the translation table. It must match the value assigned in the EXTEN keyword in a KBD3270 vector. Specify KBD to use the default table.

      There must also be an XLATETBL vector of type AE3270 and a KBD3270X vector with keyword EXTEN.

    8. Host application session identification.

      This parameter identifies the session that is used for the application program in the host computer. The parameter is optional. If specified, it overrides the value assigned in the E3270HKx keyword in the DEFAULTS vector. The parameter value is a string of up to 8 alphanumeric characters.

    9. Alternate screen height.

      This parameter specifies the height (number of rows) of the 3270 alternate screen to be emulated. The value can be in the range 24 through 49. This should not include the operator information area line at the bottom of the screen. The default is 24.

    10. Alternate screen width.

      This parameter specifies the width (number of columns) of the 3270 alternate screen to be emulated. The value can be 80 or 132. The default is 80. For LANDP for Windows workstations, only 80 is supported.

    11. Blinking.

      This parameter indicates whether blinking text is supported. The parameter value can be Y (use blinking) or N (no blinking). The default is N.

    12. Print screen.

      This parameter indicates whether the 3270 emulator should handle the Print Screen key. The parameter value can be Y or N. The default is Y.

    13. Host buffer size.

      This parameter specifies the buffer size to be used for communication with the host computer. The parameter value can be in the range 2048 through 4096. The default is 2048. The parameter value specified must match the RU size detailed in the bind session.

    3270 emulator example

             LWSCONF NAME=AA,
                     TYPE=DOS,
                     SERVER=(SNA##,,N),
                     PAR&SNA=(APPL,SRV),
                     SERVER=(TRDLC),
                     PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* 3270 emulator server definition. Example. */
                     SERVER=(EMU32701),
                     PAR&3270=(N,N),
                     SES&3270=(AA,1,011,TKR,ATR,DIS,KBD,,27,132,Y,N,4096)
     
             LWSCONF NAME=BB,
                     TYPE=DOS,
    /* 3270 emulator server definition. Example. */
                     SERVER=(EMU32701),
                     PAR&3270=(N,N),
                     SES&3270=(AA,1,012,TKR,ATR,DIS,KBD,,,,,,)
    

    3287 printer emulator definitions




    ehcodw

    The 3287 printer emulator requires one PAR&3287 keyword, and as many SES&3287 keywords as 3287 printer emulated sessions are to be defined in the workstation.

    When working in DBCS mode, the information related to IBM 4201 Proprinter applies to IBM 5575 Printer or IBM 5577 Printer; the information related to IBM 4712 Transaction Printer, IBM 4722 Document Printer, IBM 4009 Universal Banking Printer, IBM 4772 Universal Financial Printer, or IBM 9068-D01 Multi-Purpose Passbook Printer applies to IBM 4748 Document Printer.

    Note:
    When working with LANDP for OS/2, or LANDP for Windows, workstations, the 3287 emulator can be used only in an OS/2 or Windows VDM. When working in DBCS mode, the 3287 emulator cannot be used in an VDM, and thus it cannot run on LANDP for OS/2, or LANDP for Windows, workstations.

    Keyword
    Description

    PAR&3287
    Is a required keyword to define the 3287 printer emulator parameters, when the emulator is specified in a SERVER keyword.

    You can specify up to 5 parameters:

    1. Printer selection.

      This parameter specifies the printer to be used for output.

      The parameter is optional. The parameter value can be:

      1
      IBM 4201 Proprinter, or equivalent device
      2
      IBM 4712 Transaction Printer, IBM 4722 Document Printer, IBM 4009 Universal Banking Printer, or IBM 4772 Universal Financial Printer
      3
      IBM 4019, 4029, or 4039 Laser Printer, in HP/PCL mode.

      The default is 1.

    2. Printer character string for the 3287 printer emulator.

      The parameter value is a string of three alphanumeric characters, which is the identifier of the EBCDIC to ASCII translation table. It must match the value assigned in the EXTEN keyword in a XLATETBL vector with TYPE = EA3287.

      In DBCS mode the parameter does not apply. It is optional. The default is PRT.

    3. Printer 3287 attributes table.

      The parameter value is the extension of the file containing the printer 3287 attributes table. It must match the value assigned in the EXTEN keyword in the P3287ATT vector.

      It is optional. The default is TAB.

    4. Time interval of polling.

      This parameter specifies the amount of time, in seconds, the 3287 printer emulator waits before checking for a file to be printed.

      The time interval you specify is used only when the 3287 printer emulator is idle. However, when there is no file to be printed, a short interval deteriorates performance.

      The parameter is optional. The parameter value ranges from 1 to 60. The default is 15.

    5. Number of printers supported.

      The parameter is optional. The parameter value ranges from 1 to 3. Specify:

      • 1 to use LPT1 only
      • 2 to use LPT1 and LPT2
      • 3 to use LPT1, LPT2, and LPT3

      The default is the number of parallel ports available on the workstation.

    SES&3287
    Is a required keyword to define a 3287 printer emulator session, when the emulator is specified in a SERVER keyword. One keyword is required for each 3287 printer emulated session defined.

    You can specify up to 9 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. 3287 printer emulated session number.

      The parameter is required. The parameter value ranges from 1 to 5, and must be unique for the workstation where the 3287 printer emulator will be installed.

    3. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    4. DLC type used by the workstation providing SNA services.

      The parameter applies only when the SNA services are provided from a DOS workstation. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    5. Printer identification.

      The parameter is optional. The parameter value can be:

      1
      LPT1
      2
      LPT2
      3
      LPT3

      The default is 1.

    6. Characters density.

      This parameter specifies the default characters density, in characters per inch (CPI), for the 3287 printer emulator. The density can be modified at run-time using the CM command of the operator interface, or the local resource manager server.

      The parameter is optional. The parameter value can be:

      10
      Normal
      12
      Medium
      17
      Condensed

      The default is 17.

      When working with IBM 5575 Printer or IBM 5577 Printer, condensed density means 15 CPI.

    7. Page length.

      This parameter must match the length, in inches, of the paper page to be used, and the switch settings in the printer attached to the workstation.

      The parameter is optional. The parameter value can be 11 or 12.

      The default is 11.

    8. Form feed before every listing selection.

      The parameter is optional. The parameter value can be Y, to perform a form feed before every listing, or N, not to perform it. The default is N.

    9. Host application session identification.

      This parameter identifies the session that is used for the application program in the host computer.

      The parameter is optional. If specified, it overrides the value assigned in the E3287SIx keyword in the DEFAULTS vector. The parameter value is a string of up to 8 alphanumeric characters.

    3287 printer emulator example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* 3287 printer emulator server definition. Example. */
                      SERVER=(EMU3287),
                      PAR&3287=(1,PRT,TAB),
                      SES&3287=(AA,1,017,TKR,1,17,11,N)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* 3287 printer emulator server definition. Example. */
                      SERVER=(EMU3287),
                      PAR&3287=(1,PRT,TAB),
                      SES&3287=(AA,1,018,TKR,1,17,11,N)
    

    Financial printer server definitions




    ehcodwl

    When the financial printer server is loaded in a DOS, OS/2, Windows, or Linux workstation, it requires one PAR&47X2 keyword for the workstation that provides services.

    No matter the operating system in the server workstation, the server requires as many SES&47X2 keywords as printer server sessions are to be defined in the client workstation.

    Keyword
    Description

    PAR&47X2
    Is a required keyword to define the financial printer server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 17 parameters:

    1. Parallel port usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      N
      Not used

      The default is N.

    2. Port 1 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    3. Baud rate for port 1.

      This parameter specifies the number of bits per second the printer device driver sends data to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 1. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    4. Printer model for port 1.

      The parameter is optional. The parameter value can be:

      4009
      4009 printer
      4712
      4712 or 9069 printer
      4722
      4722 printer
      4772
      4772 or 9068 printer
      9069
      9069 printer

      The default is 4722.

    5. REMS selection for port 1.

      The parameter applies only when using port 1. It is optional. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    6. Port 2 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    7. Baud rate for port 2.

      This parameter specifies the number of bits per second the printer device driver sends data to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 2. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    8. Printer model for port 2.

      The parameter is optional. The parameter value can be:

      4009
      4009 printer
      4712
      4712 or 9069 printer
      4722
      4722 printer
      4772
      4772 or 9068 printer
      9069
      9069 printer

      The default is 4722.

    9. REMS selection for port 2.

      The parameter applies only when using port 2. It is optional. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    10. Port 3 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    11. Baud rate for port 3.

      This parameter specifies the number of bits per second the printer device driver sends data to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 3. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    12. Printer model for port 3.

      The parameter is optional. The parameter value can be:

      4009
      4009 printer
      4712
      4712 or 9069 printer
      4722
      4722 printer
      4772
      4772 or 9068 printer
      9069
      9069 printer

      The default is 4722.

    13. REMS selection for port 3.

      The parameter applies only when using port 3. It is optional. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    14. Port 4 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    15. Baud rate for port 4.

      This parameter specifies the number of bits per second the 4712 or 4722 printer device driver sends data to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 4. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    16. Printer model for port 4.

      The parameter is optional. The parameter value can be:

      4009
      4009 printer
      4712
      4712 or 9069 printer
      4722
      4722 printer
      4772
      4772 or 9068 printer
      9069
      9069 printer

      The default is 4722.

    17. REMS selection for port 4.

      The parameter applies only when using port 4. It is optional. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    SES&47X2
    Is a required keyword to define a financial printer server session, when the server is specified in a CLIENT keyword. One keyword is required for each printer server session defined.

    You can specify up to 6 parameters:

    1. Name of the workstation providing printer services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Session identification.

      This value is used by a server or application to identify the printer session.

      The parameter is required. The parameter value is a string of two alphanumeric characters. For each workstation, it must be unique for this service, and must match the ## value of the financial printer server in the CLIENT keyword.

    3. Port identification.

      The parameter is required. The parameter value can be:

      0
      Parallel port
      1
      Port 1
      2
      Port 2
      3
      Port 3
      4
      Port 4

      The value must match the port usage in the PAR&47X2 keyword for the server workstation.

    4. Port usage.

      The parameter is required. The parameter value can be:

      A
      Shared A
      B
      Shared B
      C
      Common

      The value must match the port usage in the PAR&47X2 keyword for the server workstation, provided it runs DOS, OS/2, or Windows. If the parallel port is used, only value C can be specified.

    5. Length of data to be printed.

      This parameter specifies the maximum number of KB to be printed at a time.

      The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

      The value to be used for each printer is the maximum value specified for all the sessions defined for that printer.

    6. Device name.

      This parameter specifies where the device is attached.

      The parameter is required for Linux workstations. If the financial printer services are provided from a DOS, OS/2, or Windows workstation, the parameter does not apply.

      If a TTY device is specified, the parameter value can be the following, within quotes:

        \dev\tty\string
      

      where string is a string of up to 18 characters, without blanks.

    Financial printer server example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
    /* 4712/22 printer server definition. Example. */
                      SERVER=(PR47X2##),
                      PAR&47X2=(N,C,9600,4722,N,C,9600,4722,Y)
     
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
    /* 4712/22 printer client definition. Example. */
                      CLIENT=(PR47X2JO,AA),
                      SES&47X2=(AA,JO,1,C)
    

    IBM 4721 self-service document printer


    ehcmdos

    The 4721 printer requires one PAR&SP21 keyword to define the printer server parameters, and one PAR&PT21 keyword to define the printer integrator parameters.

    Keyword
    Description

    PAR&SP21
    Is a required keyword to define the IBM 4721 Self-Service Document Printer server parameters, when the server is specified in a SERVER keyword.

    You can specify two parameters:

    1. Number of 4721 printers.

      This parameter specifies how many 4721 printers are managed by the server. The parameter value ranges from 1 to 3. The default is 1.

    2. 4721 printer ID.

      This parameter specifies the first two characters of the 4721 terminal address that is used for the connection between the 4721 printer server and the served 4721 printers.

      The parameter is optional. The parameter value must be unique in the network, for each 4721 printer server and the served 4721 printers. This enables you to configure several LANDP workgroups in the same network where every workstation with the 4721 printer server has the same ID.

      The parameter value is a string of two alphanumeric characters. The default is the name of the workstation (workstation ID) where the 4721 printer server is installed.

      The customization program creates an ASCII run-time file, named DEVSP47.TAB, which contains the information.

      Note:
      The parameter is supported by 4721 Server V. 2.00 or higher.

    PAR&PT21
    Is a required keyword to define the 4721 printer integrator parameters, when the server is specified in a SERVER keyword.

    You can specify up to 8 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. 4721 printer number.

      This parameter identifies the 4721 printer to be used.

      The parameter is required. The parameter value ranges from 1 to 3, and must take into account the value assigned in the PAR&SP21 keyword.

    3. SNA LU pool ID or LU number for session 1.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

      If you do not wish to use the session, omit the parameter.

    4. DLC type used by the workstation providing SNA services for session 1.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with more than one X.25DLC, to specify the particular X.25DLC used, the parameter value ranges from 1 to 999 and must match the virtual circuit definition defined for the SNA server in the SES&SPVC or SES&SSVC keyword.

    5. SNA LU pool ID or LU number for session 2.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

      If you do not wish to use the session, omit the parameter.

    6. DLC type used by the workstation providing SNA services for session 2.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with more than one X.25DLC, to specify the particular X.25DLC used, the parameter value ranges from 1 to 999 and must match the virtual circuit definition defined for the SNA server in the SES&SPVC or SES&SSVC keyword.

    7. SNA LU pool ID or LU number for session 3.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

      If you do not wish to use the session, omit the parameter.

    8. DLC type used by the workstation providing SNA services for session 3.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with more than one X.25DLC, to specify the particular X.25DLC used, the parameter value ranges from 1 to 999 and must match the virtual circuit definition defined for the SNA server in the SES&SPVC or SES&SSVC keyword.

    IBM 4721 printer example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,N),
                      PAR&SNA=(APPL,SRV),
                      SERVER=(TRDLC),
                      PAR&TKR=(48,04,04,00999999,00111111,017,00000),
    /* 4721 self-Service Document printer server definition. Example. */
                      SERVER=(SP4721##),
                      PAR&SP21=(1),
                      CLIENT=(SP4721##,AA),
                      SERVER=(PT4721),
                      PAR&PT21=(AA,1,005,TKR)
    

    IBM 4731, 4738, 4739 personal banking machines




    ehc_xx00

    The IBM 4731, 4738, 4739 Personal Banking Machine (PBM) requires one PAR&4731 keyword to define the PBM server.

    Keyword
    Description

    PAR&4731
    Is a required keyword to define the IBM 4731, 4738, 4739 PBM server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 6 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is optional. It is required, if SNA services will be used.

      The parameter value is a string of up to 2 alphanumeric characters.

    2. Configuration path.

      This parameter specifies the directory where the IBM 4731, 4738, 4739 PBM files are located in the production workstation at run-time.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    3. SNA LU pool ID or LU number for operational session.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

      If you do not wish to use the session, omit the parameter.

    4. DLC type used by the workstation providing SNA services for operational session.

      The parameter applies only to DOS workstations. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    5. SNA LU pool ID or LU number for utility session.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

      If you not wish to use the session, omit this parameter.

    6. DLC type used by the workstation providing SNA services for utility session.

      The parameter applies only when the SNA services are provided from a DOS workstation. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    IBM 4731, 4738, 4739 PBM example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,Y),
                      PAR&SNA=(ANY,SRV),
                      SERVER=(SDLC,,N),
                      PAR&SDLC=(8,C1,Y,N,N,03D,12345,CRTS),
    /* 4731, 4738, 4739 Personal Banking Machine server definition. Example. */
                      SERVER=(SS#####,,N),
                      PAR&4731=(AA,C:\PROD\FBSS\WORK\,002,SDL,001,SDL)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* 4731, 4738, 4739 Personal Banking Machine client definition. Example. */
                      CLIENT=(SS#####,AA)
    

    IBM 4733 teller assist unit




    ehc_xx00

    The IBM 4733 Teller Assist Unit requires one PAR&4733 keyword.

    Keyword
    Description

    PAR&4733
    Is a required keyword to define the IBM 4733 Teller Assist Unit server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 2 parameters:

    1. Line speed.

      The parameter is required. The parameter value can be:

      • 1200
      • 2400
      • 4800
      • 9600

      The default is 9600.

    2. Port.

      The parameter is optional. The parameter value ranges from 1 to 3. The default is 1.

    IBM 4733 teller assist unit example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
    /* 4733 Teller Assist Unit server definition. Example. */
                      SERVER=(DTAU4733),
                      PAR&4733=(9600,2)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* 4733 Teller Assist Unit client definition. Example. */
                      CLIENT=(DTAU4733,AA)
    

    IBM 4737 self-service transaction station




    ehc_xx00

    The IBM 4737 Self-Service Transaction Station requires one PAR&4737 keyword, and one PAR&PBMS keyword to define the PBM support.

    Keyword
    Description

    PAR&4737
    Is a required keyword to define the IBM 4737 Self-Service Transaction Station server parameters, when the server is specified in a SERVER keyword.

    You can specify one parameter:

    1. Configuration path.

      This parameter specifies the directory where the IBM 4737 files are located in the production workstation at run-time.

      The parameter is required. The parameter value is a string of up to 30 alphanumeric characters. The format must be:

        D:\[directory1\[directory2\[directory3\]]]
      

      A maximum of three levels is permitted for the path.

    PAR&PBMS
    Is a required keyword to define the PBM server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 3 parameters:

    1. Name of the workstation providing SNA services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. SNA LU pool ID or LU number.

      When SNA services are provided by the SNA server from a DOS workstation without LU pooling, use this parameter to specify the LU number. The parameter value must be in the range 1 through 254, and must be unique for the data link control (DLC) or virtual circuit.

      When SNA services are provided by the SNA server with LU pooling, use this parameter to the specify the ID of the LU pool. The parameter value must be two characters, the first being alphabetic and the second alphanumeric.

      When SNA services are provided by the TCP/IP server, or by a non-DOS SNA server without LU pooling, omit this parameter.

    3. DLC type.

      The parameter applies only if the SNA services are provided by a DOS workstation. In this case, it is required except for workstations that have one DLC only, which is not X.25.

      For workstations with DLC other than X.25, to specify the type of DLC used, the parameter value can be:

      SDL
      Synchronous Data Link Control (SDLC)
      TKR
      Token-ring
      DCA
      Device Cluster Attachment (DCA)

      For workstations with DLC being X.25, the parameter value is the number you have assigned as the virtual circuit definition identification in a SES&SPVC keyword or SES&SSVC keyword.

    IBM 4737 station example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
                      SERVER=(SNA##,,Y),
                      PAR&SNA=(ANY,SRV),
                      SERVER=(SDLC,,N),
                      PAR&SDLC=(8,C1,Y,N,N,,,CRTS),
    /* 4737 Self-Service Transaction Station server definition.
       Example. */
                      SERVER=(SS######,,N),
                      PAR&4737=C:\4737PBM\,
                      SERVER=(PBMS,,N),
                      PAR&PBMS=(AA,002,SDL),
                      CLIENT=(SS######,AA)
     
             LWSCONF  NAME=BB,
                      TYPE=DOS,
    /* 4737 Self-Service Transaction Station client definition.
       Example. */
                      CLIENT=(SS######,AA)
    

    IBM 4748 printer server definitions




    ehcodw

    The 4748 printer server requires one PAR&4748 keyword, and as many SES&4748 keywords as printer server sessions are to be defined in the client workstation.

    Under Windows, the 4748 printer server does not support the 4748 printer itself, but supports a 9055-01 or 9068-D01 printer when its ID byte is set to 1E(hexadecimal).

    Keyword
    Description

    PAR&4748
    Is a required keyword to define the printer server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 12 parameters:

    1. Port 1 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    2. Baud rate for port 1.

      This parameter specifies the number of bits per second the printer device driver sends to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 1. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    3. Printer model for port 1.

      The parameter is optional. The parameter value can be:

      4748
      4748 printer (not supported by LANDP for Windows)
      9055
      9055 printer in native mode (ID=1E hex) or 4748 emulation mode (ID=1D (hex)). 4748 emulation is not supported under Windows. 9068 printer configured as a 9055-D01 (ID=1E hex))

      The default is 4748.

    4. REMS selection for port 1.

      The parameter is optional, and applies only when the printer for port 1 is 9055. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    5. Port 2 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      S
      Shared (A/B) usage
      N
      Not used

      The default is N.

    6. Baud rate for port 2.

      This parameter specifies the number of bits per second the printer device driver sends to the port when it receives data to be printed.

      Select a lower baud rate, if necessary, based on the cable length and the working environment.

      The parameter applies only when using port 2. It is optional. The parameter value can be:

      150
      300
      600
      1200
      2400
      4800
      9600

      The default is 9600.

    7. Printer model for port 2.

      The parameter is optional. The parameter value can be:

      4748
      4748 printer (not supported by LANDP for Windows)
      9055
      9055 printer in native mode (ID=1E (hex)) or 4748 emulation mode (ID=1D (hex)). 4748 emulation is not supported under Windows. 9068 printer configured as a 9055-D01 (ID=1E hex))

      The default is 4748.

    8. REMS selection for port 2.

      The parameter is optional, and applies only when the printer for port 2 is 9055. The parameter value can be Y, to specify that REMS is installed, or N, to specify that REMS is not installed. The default is N.

    9. Driver file name (COM.SYS or COMDMA.SYS).

      This parameter specifies the printer device driver.

      The parameter applies only to OS/2 workstations. It is optional. The parameter format is xxxxxxxx.yyy. The default is COMDMA.SYS.

    10. Alert setting.

      This parameter specifies whether alerts are required. It is optional. The parameter value can be Y, to specify that alerts are required, or N, to specify that alerts are not required. The default is N.

    11. Code conversion.

      This parameter specifies whether code conversion is supported. It is optional. The parameter value can be:

      Y
      Code conversion required
      N
      Code conversion not required

      The default is Y.

    12. UDC file name.

      This parameter specifies the UDC file name. It is optional. The parameter format is xxxxxxxx.yyy. The default is PR4748.UDC.

    SES&4748
    Is a required keyword to define a printer server session, when the server is specified in a CLIENT keyword. One keyword is required for each printer server session defined.

    You can specify up to 5 parameters:

    1. Name of the workstation providing printer services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Session identification.

      This value is used by a server or application to identify the printer session.

      The parameter is required. The parameter value is a string of two alphanumeric characters. For each workstation, it must be unique for this service.

    3. Port identification.

      The parameter is required. The parameter value can be:

      1
      Port 1
      2
      Port 2

      The value must match the port usage in the PAR&4748 keyword for the server workstation.

    4. Port usage.

      The parameter is required. The parameter value can be:

      A
      Shared A
      B
      Shared B
      C
      Common

      The value must match the port usage in the PAR&4748 keyword for the server workstation.

    5. Length of data to be printed.

      This parameter specifies the maximum number of KB to be printed at a time.

      The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

      The value to be used for each printer is the maximum value specified for all the sessions defined for that printer.

    4748 printer server example

             LWSCONF  NAME=AA,
                      TYPE=DOS,
    /* 4748 printer server definition. Example. */
                      SERVER=(PR4748##,,Y),
                      PAR&4748=(C,9600)
     
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
    /* 4748 printer client definition. Example. */
                      CLIENT=(PR474801,AA),
                      SES&4748=(AA,01,1,C)
    

    IBM 4770 printer server definitions


    ehcmos2

    The 4770 printer server requires one PAR&4770 keyword, and as many SES&4770 keywords as printer server sessions are to be defined in the client workstation.

    Keyword
    Description

    PAR&4770
    Is a required keyword to define the 4770 printer server parameters, when the server is specified in a SERVER keyword.

    You can specify up to 7 parameters:

    1. Parallel port usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      N
      Not used

      The default is N.

    2. Port 1 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      N
      Not used

      The default is N.

    3. Baud rate for port 1.

      This parameter specifies the number of bits per second the 4770 printer device driver sends data to the port when it receives data to be printed.

      The parameter applies only when using port 1. It is optional. The parameter value can be:

      1200
      9600

      The default is 9600.

    4. Port 2 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      N
      Not used

      The default is N.

    5. Baud rate for port 2.

      This parameter specifies the number of bits per second the 4770 printer device driver sends data to the port when it receives data to be printed.

      The parameter applies only when using port 2. It is optional. The parameter value can be:

      1200
      9600

      The default is 9600.

    6. Port 3 usage.

      The parameter is optional. The parameter value can be:

      C
      Common usage
      N
      Not used

      The default is N.

    7. Baud rate for port 3.

      This parameter specifies the number of bits per second the 4770 printer device driver sends data to the port when it receives data to be printed.

      The parameter applies only when using port 3. It is optional. The parameter value can be:

      1200
      9600

      The default is 9600.

    SES&4770
    Is a required keyword to define a 4770 printer server session, when the server is specified in a CLIENT keyword. One keyword is required for each printer server session defined.

    You can specify up to 4 parameters:

    1. Name of the workstation providing printer services.

      The parameter is required. The parameter value is a string of up to 2 alphanumeric characters.

    2. Session identification.

      This value is used by a server or application to identify the printer session.

      The parameter is required. The parameter value is a string of two alphanumeric characters. For each workstation, it has to be unique for this service and must match the ## value of the 4770 printer server in the CLIENT keyword.

    3. Port identification.

      The parameter is required. The parameter value can be:

      0
      Parallel port
      1
      Port 1
      2
      Port 2
      3
      Port 3

      The value must match the port usage in the PAR&4770 keyword for the server workstation.

    4. Length of data to be printed.

      This parameter specifies the maximum number of KB to be printed at a time.

      The parameter is optional. The parameter value ranges from 1 to 4. The default is 1.

      The value to be used for each printer is the maximum value specified for all the sessions defined for that printer.

    4770 printer server example

             LWSCONF  NAME=AA,
                      TYPE=OS/2,
    /* 4770 printer server definition. Example. */
                      SERVER=(PR4770##),
                      PAR&4770=(N,C,9600)
     
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
    /* 4770 printer client definition. Example. */
                      CLIENT=(PR477001,AA),
                      SES&4770=(AA,01,1)
    

    Editing model configuration data

    Before editing model configuration data, identify your requirements:

    The customization process provides two alternative procedures to prepare and process model specification files.

    To edit model configuration data using EDITSPC:

    The EDITSPC procedure is provided to edit .SPC files.

    Write the model configuration vectors on that file:

    The following sections explain the vectors, their keywords, and the parameters corresponding to the keywords.

    When you generate the MODELS.SPC file through the generation procedure, using the customization data stored in the internal repository, the order in which the vectors appear in the file may be different from the order in which you wrote them.


    Model configuration vectors - one by one

    Information about each particular vector, including an example, follows.

    LANMODEL vector

    Contains workgroup information, and must be placed in the MODELS.SPC file.

    A quick reference


    Vector position None. It can be followed by up to 250 LWSCONF vectors.
    List of keywords

    MODNAME

    DEFAULTS, LANADAPT, LANGUAGE, SUFFIX, XPORT, TCPPORT, ADAPTNUM, NETBUFF, WSNAMES, NWSIDDUP, PARLIP

    Vector relates to LWSCONF (NAME keyword), LANCONF (MODEL keyword), DEFAULTS
    Vector format LANMODEL MODNAME=xxxxxxxx,
    [DEFAULTS=xxxxxxxx,]
    [LANADAPT=x,]
    [LANGUAGE=xxx,]
    [SUFFIX=x,]
    [XPORT=x,]
    [TCPPORT=xxxxx,]
    [ADAPTNUM=xxx,]
    [NETBUFF=xx,]
    [NWSIDDUP=x,]
    [PARLIP=x,]
    WSNAMES=(   )

    The keywords in the first line in the list identify the workgroup model configuration.

    Other keywords define the workgroup model configuration. For information on these keywords, refer to LANCONF vector.

    Keyword
    Description

    MODNAME
    Is a required keyword to specify the name of the workgroup model configuration.

    The parameter value is a model name of up to 8 alphanumeric characters. The value is assigned in the MODEL keyword in the LANCONF vector to refer to the workgroup model configuration.

    WSNAMES
    Is a required keyword to specify the names of the workstations in the workgroup model configuration. This keyword can specify up to 250 parameters, which is the maximum number of workstations in a workgroup supported by the LANDP family.

    Each parameter is the name of a workstation in the workgroup model configuration. The parameter value is a string of up to 2 alphanumeric characters. The value is assigned in the NAME keyword in the LWSCONF vector that contains information about the workstation.

    Each workstation specified in the WSNAMES keyword requires one LWSCONF vector to define that particular workstation in the workgroup model configuration. For information on this vector, refer to LWSCONF vector.

    LANMODEL vector example

             LANMODEL MODNAME=MODEL01,
                      WSNAMES=(AA,BB,CC),
                      LANGUAGE=001
     
             LWSCONF  NAME=AA,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      SERVER=(EHCSQL01),
                      PAR&SQL=(CONFIGUR,5,4,10,Y,15)
             LWSCONF  NAME=BB,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      CLIENT=(EHCSQL01,AA)
             LWSCONF  NAME=CC,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      CLIENT=(EHCSQL01,AA)
    

    WSMODEL vector

    Contains information about a workstation model configuration.

    A quick reference


    Vector position None
    List of keywords

    MODNAME

    TYPE, SYSLVL, PRODLVL, SOFTPACK, FRAME, RPLOAD, POOLSIZE, XPORT, PARLIP, PARLIPEX, LANDPDCE, ADAPTNUM, NETBUFF, DBCSXLAT, PARWIN, SBC, SERVER, CLIENT

    PARxxxxx, SESxxxxx

    Vector relates to SVRMODEL vector
    Vector format WSMODEL MODNAME=xxxxxxx,
    [TYPE=(   ),]
    [SYSLVL=x,]
    [PRODLVL=xxx,]
    [SOFTPACK=xxxxxxxx,]
    [FRAME=xxxx,]
    [RPLOAD=x,]
    [POOLSIZE=xxx,]
    [XPORT=x,]
    [PARLIP=(   ),]
    [PARLIPEX=(   ),]
    [LANDPDCE=x,]
    [ADAPTNUM=x,]
    [NETBUFF=xx,]
    [DBCSXLAT=x,]
    [PARWIN=xx,]
    [SBC=(   ),]
    [SERVER=(   ),]
    [CLIENT=(   ),]
    [PARxxxxx=(   ),]
    [SESxxxxx=(   )]

    The MODNAME keyword identifies the workstation model configuration.

    The keywords in the second line in the list define the workstation model configuration. The keywords in the third line define the servers related to that workstation. For information on all these keywords, refer to LWSCONF vector.

    Keyword
    Description

    MODNAME
    Is a required keyword to specify the name of the workstation model configuration.

    The parameter value can be any model name, of up to 8 alphanumeric characters.

    WSMODEL vector example

             WSMODEL  MODNAME=MODEL02,
                      TYPE=OS/2,
                      PRODLVL=L60,
                      SERVER=(PR47X2##,MODEL03),
                      CLIENT=(EHCSQL01,AA),
                      CLIENT=(SNA02,AA),
                      SES&SNA=(AA,02,019,001)
     
    

    SVRMODEL vector

    Contains information about a server model configuration.

    A quick reference


    Vector position None
    List of keywords

    MODNAME

    SVRNAME, EXPMEM, SERVPARM

    PARxxxxx, SESxxxxx

    Vector relates to None
    Vector format SVRMODEL MODNAME=xxxxxxx,
    SVRNAME=xxxxxxxx,
    [EXPMEM=x,]
    [SERVPARM=(   ),]
    [PARxxxxx=(   ),]
    [SESxxxxx=(   )]

    The MODNAME keyword identifies the server model configuration. The SVRNAME and the EXPMEM keywords identifies the server.

    The other keywords define the server model configuration. For information on those keywords, refer to LWSCONF vector.

    Keyword
    Description

    MODNAME
    Is a required keyword to specify the name of the server model configuration.

    The parameter value can be any model name, of up to 8 alphanumeric characters.

    SVRNAME
    Is a required keyword to specify the server name. The parameter value is a string of up to 8 alphanumeric characters.

    Refer to the table in Vectors - a quick reference for the names corresponding to the functional areas (string in parenthesis).

    The following servers require that the server suffix (##) is substituted by the corresponding value to completely identify the server:

    EHCMQ##
    EHCODB##
    EHCSQL##
    ELECJO##
    MSRE47##
    PINP47##
    PR47X2##
    PR4770##
    SHFILE##

    The following servers require a suffix to identify the session to be used:

    BIWPx
    BPPx
    EMU3270x
    LDA7x

    Note that BIWP and LDA 7 program need the suffix only when they are installed in a DOS workstation.

    If the following servers are to be run in either an OS/2 or a Windows VDM, the server names to be specified are:

    BIWP
    VBIWPx
    LDA7
    VLDA7x
    BPP
    VBPPx (Windows only)

    where x is the suffix to identify the session.

    EXPMEM
    Is an optional keyword to specify the expanded memory selection. The parameter applies only to DOS workstations.

    The parameter value can be:

    Y
    The server is loaded in expanded memory
    N
    The server is loaded in conventional memory

    The default is N.

    SERVPARM
    Is an optional keyword to specify a string that will be added to the loading statement of the server.

    The parameter value is a string of up to 40 characters, enclosed between quotes.

    SVRMODEL vector example

             SVRMODEL MODNAME=MODEL03,
                      SVRNAME=PR47X2##,
                      PAR&47X2=(N,C,9600,4722,,C,9600,4722)
     
    

    Appendix E. Using TCP/IP for internal communication

    Note for DOS users

    For DOS users, the statements in this appendix about TCP/IP apply equally to PC/TCP.




    ehcodwl

    You can configure a LANDP workgroup to use TCP/IP as its internal communication protocol. This means that LANDP workstations can be connected to a TCP/IP network and use TCP/IP to support the LANDP client/server mechanism.

    The low-level communication protocols used by the TCP/IP implementation in each environment (token-ring, Ethernet, X.25, and so on) are transparent to LANDP and exclusively controlled by TCP/IP.

    LANDP uses standard TCP/IP functions and facilities. This requires a properly implemented TCP/IP network. For details on installing and configuring a TCP/IP network, refer to the appropriate TCP/IP support product manuals.

    Because LANDP internal communication is transparent to clients and servers, no special considerations apply when developing applications or user servers.


    LANDP Internet Protocol (LIP)

    LANDP uses the standard TCP/IP user datagram protocol (UDP). LANDP adds extensions to this protocol to ensure reliable communication. The resulting protocol (and the LANDP server that implements it) is referred to as the LANDP Internet Protocol (LIP).

    The following sections describe the LIP, and provide configuration information.

    LIP workstation ID definition

    LIP refers to each workstation in the workgroup by its LIP name. The LIP name of a workstation consists of the prefix 'LIP-' followed by the workstation id and optionally followed by the workgroup name if SUFFIX=Y is specified in the LANCONF configuration vector.

    For example: the LIP name of workstation 'S1' in workgroup 'BRANCH3' would be 'LIP-S1BRANCH3' if SUFFIX=Y were specified and 'LIP-S1' otherwise.

    The LIP names are used as TCP/IP host names or host alias names for the workstations.

    Within a LANDP workgroup the workstations that need to communicate with any particular workstation are called its related workstations. These are the workstations to which it provides services, or from which it receives services.

    LIP uses TCP/IP to resolve the LIP name of every related workstation into an IP address. This requires the LIP names and corresponding IP addresses to be defined to a TCP/IP names server or in a local HOSTS file, but see Unresolved workstation IDs.

    A sample of a HOSTS file follows:

      214.1.1.51   basement     LIP-AAWHAREHS
      214.1.1.55   bossdesk     LIP-BBWHAREHS
      214.1.1.67   firstfloor   LIP-CCWHAREHS
    

    This sample corresponds to a LANDP workgroup with the following characteristics:

    Note:
    If the HOSTS file or the NAMES server is changed, you have to load the LIP again.

    TCP/IP verification

    Before attempting to use LANDP for the first time, you should verify TCP/IP communications and definitions with the PING TCP/IP program. On each workstation, after TCP/IP has been started, issue the PING command with each related workstation ID.

    For example, on a workstation AA belonging to a LANDP workgroup with the name WHAREHS, and related to LANDP workstations with the IDs BB and CC, you must issue:

      PING LIP-AAWHAREHS
      PING LIP-BBWHAREHS
      PING LIP-CCWHAREHS
    

    PING should report successful contact with every workstation. If it does not, either the network or the TCP/IP definitions are not ready.

    For detailed information on the PING program, refer to the TCP/IP manuals. See Appendix J, Bibliography.

    You can also perform this verification at production time when two workstations are unable to contact each other.

    Unresolved workstation IDs

    Unresolved workstation IDs can occur when not all workstations in the workgroup are in existence, or when DHCP (Dynamic Host Configuration Protocol) is being used to dynamically assign IP addresses.

    In normal operation if any LIP name cannot be resolved then LANDP loading terminates. However when LIP address checking is turned off (with the PARLIP keyword or the /J parameter of EHCLIP) then unresolved LIP names are logged but LANDP loading continues.

    Turning off LIP address checking is useful when not all workstations in the workgroup are in existence, or when DHCP (Dynamic Host Configuration Protocol) is being used to dynamically assign IP addresses. When LIP names cannot be resolved there will not, initially, be any attempt at communication with the workstations with unresolved LIP names. However, if any of these workstations make contact then communications will resume.

    DHCP (Dynamic Host Configuration Protocol)

    In an environment where DHCP is being used there are some alternative configurations to choose from:

    Port number

    The LIP uses one UDP port for communication in each workstation. The port number must be the same for all the workstations in a LANDP workgroup. If the default port number conflicts with other application requirements it can be changed during customization or at loading time.

    Workstation identification

    The LIP establishes and maintains a session with each related LANDP workstation in the workgroup as defined at customization.

    When the session is established, workstations identify themselves to each other to verify the LANDP configuration. If a mismatch is detected in the workstation identification or the corresponding INET addresses, the session is not established and an error message is logged.

    Data interchange

    Data is exchanged by sending and receiving datagrams. Datagrams are acknowledged by the destination workstation. Datagrams that are not acknowledged are retransmitted until they are acknowledged or until the LIP detects that contact is lost. If this happens, the session is reset, an attention message is logged, and the procedure to re-establish contact is started.

    Both ends of a session can send data simultaneously at any time.

    Depending on the message size, messages exchanged during a session are sent in one or more datagrams. The LIP stores information about each datagram in a retransmission table that is used if the datagram has to be retransmitted.

    In LANDP for DOS, the size of this table is defined at customization or with a LIP loading parameter. If there is no space left in the retransmission table, the datagram cannot be sent and the process has to be retried later.

    Message segmentation

    The default datagram length used by the LIP is 1472 bytes on DOS and 4272 bytes on other operating systems. The maximum datagram lengths are 32711 and 32767 respectively. To support messages longer than the datagram length, a segmentation mechanism divides them into segments and sends each segment as a datagram. The segments are reassembled at the receiving end. This process consumes time and resources. Therefore, the overall performance can be affected.

    Session partner availability

    The LIP can detect whether a session partner is available during the periods of time when there is no traffic over the network. The LIP sends short availability probe datagrams at regular intervals to the related workstations. If these datagrams are not acknowledged, the LIP starts the session reset and re-establishment procedures.

    You can disable this feature with a LIP parameter. However, this is not recommended in environments where clients can lock server resources. If a client locks a resource and then becomes unavailable, the resources would remain locked since the server would not be able to detect the lost session.

    Communication errors

    LANDP provides trace tools to diagnose errors and track problems. These tools use trace servers to log information about internal and external errors, and provide statistics.

    For more information about these tools, see LANDP Problem Determination.


    Appendix F. Host communication definitions

    This appendix contains information for a possible host setup that you will need when working with LANDP. You must modify these examples for your own host system.


    ACF/NCP (Read by VTAM)

    Three examples are provided that correspond to LANDP SNA/SDLC, SNA/X.25, and SNA/TRDLC configurations.

    SNA/SDLC

    The access method configuration must match the LANDP SNA/SDLC configuration set up during customization. Following is an example for ACF/VTAM(R).

    Note:
    This is only an example; you must tailor it to your environment and requirements.
     WPCGR20  GROUP LNCTL=SDLC,
                   DIAL=NO,
                   TYPE=NCP,
                   ANS=CONTINUE,
                   DATRATE=LOW,
                   DISCNT=NO,
                   DUPLEX=FULL,
                   IRETRY=NO,
                   ISTATUS=INACTIVE,
                   MAXDATA=265,
                   MAXOUT=2,
                   NEWSYNC=NO,
                   NRZI=NO,
                   PASSLIM=254,
                   PUTYPE=2,
                   PUDR=NO,
                   REPLYTO=2.0,
                   RETRIES=(3,15,40),
                   SERVLIM=10,
                   SPDSEL=NO,
                   TEXTTO=1.0
     
    WL1PC    LINE ADDRESS=001,
                  SPEED=9600,
                  CLOCKNG=EXT
     
    WSRV1    SERVICE ORDER=(WP1AA,WP1AC)
     
    WP1AA    PU ADDR=AA
     
    
     FU1AA01  LU LOCADDR=01,
                MODETAB=TABPCLU,
                SSCPFM=FSS,
                DLOGMOD=ENTRYF,
                PACING=0,
                VPACING=0
     
    FU1AA41  LU LOCADDR=41,
                MODETAB=TABPCLU,
                SSCPFM=FSS,
                LOGAPPL=CICS2,
                DLOGMOD=ENTRYP,
                PACING=1,
                VPACING=0
     
    FU1AA37  LU LOCADDR=37,
                MODETAB=TABPCLU,
                SSCPFM=FSS,
                DLOGMOD=ENTRYF,
                PACING=0,
                VPACING=0
     
    FU1AA81  LU LOCADDR=81,
                MODETAB=TABPCLU,
                SSCPFM=USSSCS,
                USSTAB=ROBTAB,
                DLOGMOD=ENTRYZ,
                PACING=0,
                VPACING=0
     
    WP1AC    PU ADDR=AC,
                MAXOUT=7,
                PACING=7,
                PASSLIM=7,
                VPACING=7
     
    FU1AC01  LU LOCADDR=01,
                MODETAB=MODCRYP,
                DLOGMOD=TABDSX11,
                SSCPFM=USSSCS
     
    

    SNA/X.25

    The access method configuration must match the LANDP SNA/X.25 configuration setup during customization. Following is an example for ACF/VTAM.

    Note:
    This is only an example; you must tailor it to your environment and requirements.
     SWPCX25  VBUILD TYPE=SWNET,
                   MAXGRP=10,
                   MAXNO=50
     
    SPF01    PU    ADDR=AA,
                   IDBLK=017,
                   IDNUM=80001,
                   ISTATUS=ACTIVE,
                   DISCNT=(YES,F),
                   MAXDATA=265,
                   MAXPATH=8,
                   PUTYPE=2,
                   SSCPFM=USSSCS,
                   VPACING=2
     
             PATH  DIALNO=C3231020108,PID=1,
                   GRPNM=XF1SNET
     
    SUF0101  LU    LOCADDR=01,
                   MODETAB=TABPCLU,
                   SSCPFM=FSS,
                   DLOGMOD=ENTRYF,
                   PACING=0,
                   VPACING=0
     
    SUF0141  LU    LOCADDR=41,
                   MODETAB=TABPCLU,
                   SSCPFM=FSS,
                   LOGAPPL=CICS2,
                   DLOGMOD=ENTRYP,
                   PACING=1,
                   VPACING=0
     
    SUF0137  LU    LOCADDR=37,
                   MODETAB=TABPCLU,
                   SSCPFM=FSS,
                   DLOGMOD=ENTRYK,
                   ENCR=REQD,
                   PACING=0,
                   VPACING=0
     
    SUF0181  LU    LOCADDR=81,
                   MODETAB=TABPCLU,
                   SSCPFM=USSSCS,
                   USSTAB=ROBTAB,
                   DLOGMOD=ENTRYZ,
                   PACING=0,
                   VPACING=0
     
    

    SNA/TRDLC

    The access method configuration must match the LANDP SNA/TRDLC configuration set up during customization. Following is an example for ACF/VTAM.

    Note:
    This is only an example; you must tailor it to your environment and requirements.
    SWPCTOKE VBUILD TYPE=SWNET,
                   MAXGRP=2,
                   MAXNO=25
     
    SPT11    PU    ADDR=1,
                   IDBLK=05D,
                   IDNUM=11111,
                   PUTYPE=2,
                   MODETAB=TABPCLU,
                   MAXPATH=2
     
    SDT1120  PATH  DIALNO=0104400011111111,
                   GRPNM=GTL120
     
    SDT1145  PATH  DIALNO=0104400011111111,
                   GRPNM=GTL145
     
    SUT111   LU    LOCADDR=1,
                   USSTAB=ROBTAB,
                   DLOGMOD=ENTRYF
     
    SUT1137  LU    LOCADDR=37,
                   USSTAB=ROBTAB,
                   DLOGMOD=ENTRYF
     
    SUT1235  LU    LOCADDR=35,
                   USSTAB=ROBTAB,
                   MODETAB=MODCRYP,
                   DLOGMOD=TABDSX11
     
    SUT1500  LU    LOCADDR=0,
                   DLOGMOD=FBSSMODE,
                   SPAN=(450),
                   RESSCB=2
     
    SUT1590  LU    LOCADDR=90,
                   DLOGMOD=FBSSMODE,
                   SPAN=(450)
     
    SUT1141  LU    LOCADDR=41,
                   USSTAB=ROBTAB,
                   DLOGMOD=ENTRYP
     
    SUT1181  LU    LOCADDR=81,
                   USSTAB=ROBTAB,
                   DLOGMOD=ENTRYZ
    

    SNA over TCP/IP dependent LUs

    When using the TCP/IP wide area communications server the dependent LU names must have a common alphanumeric prefix and a numeric suffix with a constant difference between the suffix and the LOCADDR. For example:

         IYCKT300 LU LOCADDR=2
         IYCKT301 LU LOCADDR=3
         IYCKT327 LU LOCADDR=29
         IYCKT481 LU LOCADDR=183
    

    VTAM MODETAB

    Following is an example of VTAM MODETAB for the previous definitions.

    Note:
    This is only an example; you must tailor it to your environment and requirements.
     MODFBSS MODETAB
     
    

    MODEENT for LU type 0

     ENTRYF   MODEENT LOGMODE=ENTRYF,
                     FMPROF=X'04',
                     TSPROF=X'04',
                     PRIPROT=X'B1',
                     SECPROT=X'B1',
                     COMPROT=X'7080',
                     RUSIZES=X'8787'
    
    Note:
    As an alternative, the logmode EMU3790 in the default MVS VTAM mode table can be used.

    MODEENT for LU type 1 (IBM LANDP 3287 printer emulator)

     ENTRYP   MODEENT LOGMODE=ENTRYP,
                     TSPROF=X'03',
                     FMPROF=X'03',
                     PRIPROT=X'B1',
                     SECPROT=X'B0',
                     COMPROT=X'3080',
                     PSERVIC=X'010000F90000000000000000',
                     RUSIZES=X'8585',
                     PSNDPAC=X'01',
                     SRCVPAC=X'01'
    

    MODEENT for LU type 2 (DBCS)

    LDPDBCS  MODEENT LOGMODE=LDPDBCS,
                     TSPROF=X'03',
                     FMPROF=X'03',
                     PRIPROT=X'B1',
                     SECPROT=X'B0',
                     COMPROT=X'3080',
                     PSERVIC=X'028000000000000000000300',
                     RUSIZES=X'8585'
    
    Note:
    This LOGMODE corresponds to the CICS-supplied typeterm DFHLU2 in DFHTYPE.

    MODEENT for LU type 2 (IBM LANDP 3270 emulator)

     ENTRYZ   MODEENT LOGMODE=ENTRYZ,
                     TSPROF=X'03',
                     FMPROF=X'03',
                     PRIPROT=X'B1',
                     SECPROT=X'90',
                     COMPROT=X'3080',
                     PSERVIC=X'028000000000185000007E00',
                     RUSIZES=X'87C7'
    
    Note:
    Nonqueryable LU_2s are also now supported.

    The LANDP V5 emulator rejects the bind image if any of the following is true:

    It is recommended that you set on the queryable flag in the VTAM MODEENT LOGMODE statement. This provides greater flexibility and allows the use of the extended color and highlighting support.

    MODEENT for RCMS

    ENTDSX11 MODEENT LOGMODE=ENTDSX11,
                     FMPROF=X'03',
                     TSPROF=X'04',
                     PRIPROT=X'B0',
                     SECPROT=X'A0',
                     COMPROT=X'4000',
                     RUSIZES=X'8585'
    

    MODEENT for LU type 6.2

    This is an example for dependent LU:

    SNASVCMG MODEENT LOGMODE=SNASVCMG,
                     TYPE=0,
                     FMPROF=X'13',
                     TSPROF=X'07',
                     PRIPROT=X'B0',
                     SECPROT=X'B0',
                     COMPROT=X'D0B1',
                     SSNDPAC=X'00',
                     SRCVPAC=X'00',
                     RUSIZES=X'8585',
                     PSNDPAC=X'00',
                     PSERVIC=X'060200000000000000000300'
     
    

    This is an example for peer-to-peer LU:

    FBSSMODE MODEENT LOGMODE=FBSSMODE,
                     TYPE=0,
                     FMPROF=X'13',
                     TSPROF=X'07',
                     PRIPROT=X'B0',
                     SECPROT=X'B0',
                     COMPROT=X'D0B1',
                     SSNDPAC=X'00',
                     SRCVPAC=X'00',
                     RUSIZES=X'F7F7',
                     PSNDPAC=X'00',
                     PSERVIC=X'060200000000000000002C00'
     
    

    CICS definition examples

    Note:
    These are only examples; you must tailor them to your environment and requirements.

    Definition for LU_0


    ENTRYF     MODEENT LOGMODE=ENTRTF,
               FMPROF=X'04',
               TSPROF=X'04',
               PRIPROT=X'B1',
               SECPROT=X'B0',
               COMPROT=X'7080',
               RUSIZES='8787'
     
    TYPETERM = ALU0M2
    TERM     = L711
    
    Note:
    If the logmode EMU3790 in the MVS VTAM default mode table is used, the IBM-supplied TYPETERM DFHLU2C2 in DFHTYPE can be used.

    Definition for LU_1


    TYPETERM(LDPSCSP)      GROUP(LANDP)    DESCRIPTION()
    CICS/ESA(R)  RDO OFF-LINE UTILITY PROGRAM
                           RESOURCE-TYPE
                                           DEVICE(SCSPRINT)        TERMMODEL()               SESSIONTYPE()
                                           LDCLIST()               SHIPPABLE(NO)
                           MAPPING-PROPERTIES
                                           PAGESIZE(24,80)         ALTPAGE(0,0)              ALTSUFFIX()
                                           FMHPARM(NO)             OBOPERID(NO)
                           PAGING-PROPERTIES
                                           AUTOPAGE(YES)
                           DEVICE-PROPERTIES
                                           DEFSCREEN(0,0)          ALTSCREEN(   ,   )        APLKYBD(NO)
                                           APLTEXT(NO)             AUDIBLEALARM(NO)          COLOR(NO)
                                           COPY(NO)                DUALCASEKYBD(NO)          EXTENDEDDS(NO)
                                           HILIGHT(NO)             KATAKANA(NO)              LIGHTPEN(NO)
                                           MSRCONTROL(NO)          OBFORMAT(NO)              PARTITIONS(NO)
                                           PRINTADAPTER(NO)        PROGSYMBOLS(NO)           VALIDATION(NO)
                                           FORMFEED(NO)            HORIZFORM(NO)             VERTICALFORM(NO)
                                           TEXTKYBD(NO)            TEXTPRINT(NO)             QUERY(NO)
                                           OUTLINE(NO)             SOSI(NO)                  BACKTRANS(NO)
                                           CGCSGID(0,0)
                           SESSION-PROPERTIES
                                           ASCII(NO)               SENDSIZE(256)             RECEIVESIZE(256)
                                           BRACKET(YES)            LOGMODE()
                           DIAGNOSTIC-DISPLAY
                                           ERRLASTLINE(NO)         ERRINTENSIFY(NO)          ERRCOLOR(NO)
                                           ERRHILIGHT(NO)
                           OPERATIONAL-PROPERTIES
                                           AUTOCONNECT(NO)         ATI(YES)                  TTI(YES)
                                           CREATESESS(NO)          RELREQ(YES)               DISCREQ(YES)
                                           NEPCLASS(0)             SIGNOFF(YES)              XRFSIGNOFF(NOFORCE)
                           MESSAGE-RECEIVING-PROPERTIES
                                           ROUTEDMSGS(ALL)         LOGONMSG(NO)
                           APPLICATION-FEATURES
                                           BUILDCHAIN(NO)          USERAREALEN(40)           IOAREALEN(512,0)
                                           UCTRAN(NO)
                           RECOVERY
     
                                           RECOVOPTION(SYSDEFAULT)
                                           RECOVNOTIFY(NONE)
    

    Definition for forwarding


    TYPETERM(A360001F)     GROUP(TCTHURS)  DESCRIPTION()
    CICS/ESA   RDO OFF-LINE UTILITY PROGRAM
                           RESOURCE-TYPE
                                           DEVICE(3600)            TERMMODEL()               SESSIONTYPE()
                                           LDCLIST()               SHIPPABLE(NO)
                           MAPPING-PROPERTIES
                                           PAGESIZE(1,40)          ALTPAGE(0,0)              ALTSUFFIX()
                                           FMHPARM(NO)             OBOPERID(NO)
                           PAGING-PROPERTIES
                                           AUTOPAGE(YES)
                           DEVICE-PROPERTIES
                                           DEFSCREEN(0,0)          ALTSCREEN(   ,   )        APLKYBD(NO)
                                           APLTEXT(NO)             AUDIBLEALARM(NO)          COLOR(NO)
                                           COPY(NO)                DUALCASEKYBD(NO)          EXTENDEDDS(NO)
                                           HILIGHT(NO)             KATAKANA(NO)              LIGHTPEN(NO)
                                           MSRCONTROL(NO)          OBFORMAT(NO)              PARTITIONS(NO)
                                           PRINTADAPTER(NO)        PROGSYMBOLS(NO)           VALIDATION(NO)
                                           FORMFEED(YES)           HORIZFORM(NO)             VERTICALFORM(NO)
                                           TEXTKYBD(NO)            TEXTPRINT(NO)             QUERY(NO)
                                           OUTLINE(NO)             SOSI(NO)                  BACKTRANS(NO)
                                           CGCSGID(0,0)
                           SESSION-PROPERTIES
                                           ASCII(NO)               SENDSIZE(30270)           RECEIVESIZE(30720)
                                           BRACKET(YES)            LOGMODE(0)
                           DIAGNOSTIC-DISPLAY
                                           ERRLASTLINE(NO)         ERRINTENSIFY(NO)          ERRCOLOR(NO)
                                           ERRHILIGHT(NO)
                           OPERATIONAL-PROPERTIES
                                           AUTOCONNECT(NO)         ATI(YES)                  TTI(YES)
                                           CREATESESS(YES)         RELREQ(YES)               DISCREQ(YES)
                                           NEPCLASS(0)             SIGNOFF(YES)              XRFSIGNOFF(NOFORCE)
                           MESSAGE-RECEIVING-PROPERTIES
                                           ROUTEDMSGS(ALL)         LOGONMSG(NO)
                           APPLICATION-FEATURES
                                           BUILDCHAIN(YES)         USERAREALEN(40)           IOAREALEN(1024,32767)
                                           UCTRAN(NO)
                           RECOVERY
     
                                           RECOVOPTION(SYSDEFAULT)
                                           RECOVNOTIFY(NONE)
    

    Definition for LU_2

    The CICS-supplied TYPETERM definition DFHLU2C2 in group DFHTYPE corresponds to the VTAM logmode ENTRYZ shown.

    For an LU_2 with extended data streams, TYPETERM DFHLU2 in group DFHTYPE is suitable.


    IMS/VS terminal statement examples

    Note:
    This is only an example; you must tailor it to your environment and requirements.

    Definition for LU_0

            TYPE     UNITYPE=SLUTYPEP
     
           TERMINAL NAME=DCDSZU00,
                    OUTBUF=1024,
                    OPTIONS=(TRANRESP, PAGDEL, ACK, NOBID)
     
    

    Definition for LU_1

            TYPE     UNITYPE=SLUTYPE1
     
           TERMINAL NAME=DCDPZU02
                    COMPT1=(PRINTER1,MFS=SCS1),
                    OPTIONS=(OPNDST, SHARE, RELRQ),
                    OUTBUF=256
     
    

    Definition for LU_2

            TYPE     UNITYPE=SLUTYPE2
     
           TERMINAL NAME=LUFBS2,
                    TYPE=3270-A02,
                    SIZE=(24,80),
     
    

    IBM AS/400 connectivity using SNA LU_2 protocol

    Communication between an AS/400 system and a LANDP workstation can use SNA LU_2 protocols. The following parameters must be defined in the AS/400 computer:

    Line
    This AS/400 definition must have the same communications parameters as specified in LANDP customization.

    Communication Controller or Workstation Control Unit

    Display Station
    The Display Station supported by LANDP is equivalent to an IBM 3277, Model 0.

    The Local Address must be the same as the LU defined for the emulator session during LANDP customization.

    Remarks:

    IBM AS/400 connectivity using SNA LU_0 protocol

    The following parameters must be defined in the AS/400 system for communications between AS/400 system and LANDP workstations using SNA LU_0 protocol:

    Line
    This AS/400 definition must have the same communication parameters as specified in LANDP customization.

    Communication Controller
    The Controllers supported are:

    The Station Address must be the same as the one defined in FBSS Customization for SNA Communication.

    Note:
    This Communication Controller definition is available with OS/400* Release 1.2 and up.

    Communication Device
    The Communication Devices supported are:

    The Local Address must be the same as the LU defined in LANDP customization for the LU_0 Session.

    There is no need to configure the LANDP controller as a 3174 because AS/400 also supports attachment of 3270 devices to 4700 controllers.


    Appendix G. LANDP using Server Based Computing

    WorkSpace On-Demand (WSoD) and Windows Terminal Server (WTS) are known generically as Server Based Computing (SBC) products. This appendix describes how workstations within a LANDP workgroup can run within an SBC environment.


    WorkSpace On-Demand




    ehc_0x00

    WorkSpace On-Demand (WSoD), a component of OS/2 Warp Server for e-Business, provides server-managed client support. The following describes how LANDP can be integrated into the WSoD client environment.

    WorkSpace On-Demand Road Map gives a detailed walkthrough of how to install an application onto a WSoD server. Figure 25 (based on page 59 of WorkSpace On-Demand Handbook (Release 2)) shows how an application like LANDP is integrated into the WSoD directory structure for remote IPL.

    Figure 25. Integrating LANDP into WorkSpace On-Demand directory structure

    EHCGR966

    The application (LANDP) directory structure is as follows:

    Note:
    There is a set of files (for B and C) for each WSoD client that is also a LANDP workstation.

    To aid the implementation of LANDP in a workgroup comprising Server Based Computing systems, LANDP Customization generates the lists of files for the above SBC directories. Using GETTING, the sets of files can be suitably distributed. For more information, look at the descriptions of the SBC keyword of LWSCONF at ***, and of GETTING /S at ***.

    Distributing files

    Following customization, the LANDP files distributed by GETTING are machine-specific. They are for a specific workstation, although they include many files that might be shared across other workstations. There are no user-specific files. The following is an analysis of how the LANDP files might be distributed into the WSoD directory structure.

    The following LANDP files can be shared across multiple machines, and are read-only (that is, suitable for inclusion in directory A):

    All EXE files
    All DLL files
    All HLP files
    All MSG files
    All COM files
    All SYS files
    Device drivers
    SERVERS.LST
    3270 translate tables (AE3270.* DIS3270.* EA3270.* FK3270.*)
    RCMS translate tables (AERCMS.* EARCMS.*)
    All PAN files

    All other files should be placed into a machine-unique directory. The following files might be machine-unique (read/write or read/only). Included are files that are targeted to a specific machine and that may be modified by selected servers. The following are suitable for inclusion in directory C:

    AUTOFBSS.BAT
    AUTOFBSS.CMD
    Other command files (for example, CREADB.CMD, RCK.CMD, RST.CMD)
    *.CFG
    Shared file server files (*.DBD, *.PCB, *.SEQ)
    SNA.BID

    There are many other miscellaneous files that can be distributed to each workstation dependent upon the servers selected, and that convey machine-configured information specific to a workstation.

    These should similarly be placed into a machine-unique directory.

    CONFIG.SYS updates

    The CONFIG.ADD file includes modifications to CONFIG.SYS that are required for a given WSoD client (for example to include support for additional device drivers). This is identical to the process for a non-WSoD workstation. CONFIG.SYS is usually in RPL\MACHINES\client_name\CONFIG.SYS. Typical statements that could be added include:

    LIBPATH=Z:\LANDP
    DPATH=Z:\LANDP
    DEVICE=Z:\LANDP\EHCVDMVD.SYS
    DEVICE=Z:\LANDP\4772PDD.SYS /D1 /C11 /B19600
    SET EHC_WSID=id (where id is the workstation identifier)
    

    File index table (FIT) updates

    This implementation is a machine-specific application. It does not follow the user around and always stays with that machine.

    The following entries need to be added to the machine's file index table (FIT file). The FIT file entries are dependent upon which LANDP servers are assigned to the WSoD client. The following is an example of the relevant LANDP section of a FIT file used for a WSoD client on which Shared-File server and System Manager will run.

    One possible suggestion is to add these entries to the machine classes that LANDP will be running on. This can be done either by modifying the machine FIT file \IBMLAN\RPL\FITS\DFBB20xx.FIT (where xx is the country code) before creating those machines, or by modifying the individual machine FIT files.

    LANDP Support
    Z:\LANDP                 LANDP
    Z:\LANDP\*.CFG               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.LOG               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.BAT               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.DAT               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.DBD               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.PCB               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\*.SEQ               \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\EHCLOG*.DAT         \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\EHCTRC*.BAT         \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\FBSS#*              \\rplservername\WRKFILES\client_name\LANDP
    Z:\LANDP\AUTOFBSS.CMD        \\rplservername\WRKFILES\client_name\LANDP\AUTOFBSS.CMD
    

    Multiple workgroup support

    If you wish to have more than one LANDP workgroup in a single WSOD server machine, one option is to define an additional instance of LANDP. For example, if two workgroups have different LANCONF LANGUAGE values, two sets of FIT file entries (as above) could be defined:

    ;LANDP Support (English)
    Z:\LANDPENG                 LANDPENG
    Z:\LANDPENG\*.CFG            \\rplservername\WRKFILES\client_name\LANDPENG
     ...
    

    ;LANDPESP Support (Spanish)
    Z:\LANDPESP                 LANDPESP
    Z:\LANDPESP\*.CFG            \\rplservername\WRKFILES\client_name\LANDPESP
     ...
    

    LANDP customization considerations

    The assigned drive location on the WSoD server on which the client system and application files reside defaults to Z:. This is the client user's boot drive. The rest of LANDP would have to be on the same drive and configured that way. For example, the target drive for location of the files used by RCMS server (PAR&RCMS parameters 5 and 6) and System Manager server (PAR&SMGR parameters 5, 6, 7, 8) for the production workstation would need to conform to this default, Z:. (These files are subsequently copied to their target directories by EHCVAL).

    For example:

            /* RCMS */
                  SERVER=RCMS,
                  PAR&RCMS=(AB,,,,Z:\LANDP\,Z:\LANDP\,,,),
            /* System Manager */
                  SERVER=(SMGR,,N),
                  PAR&SMGR=(AB,,Z:\LANDP\,SMGRPRF1,Z:\LANDP\,
                                  Z:\LANDP\,Z:\LANDP\,Z:\LANDP\,Z,USER1)
    

    Generally, LANDP facilities run on a WSoD client as they do on an OS/2 workstation. Servers that have been tested include Shared_File server, Financial Printer server with the financial printer attached to the WSoD client, System Manager and System Manager Operator, and 3270 emulator running in a VDM.

    Careful attention needs to be given to planning the use of Shared File (SF) server, specifically when using XLR or Replicator support. The underlying purpose of XLR or Replicator support is to provide immediate database recovery from a backup server in case of machine or system failure on the workstation on which SF server resides. Clearly it is inappropriate to have both the SF server and its backup residing on the same WSoD server.

    To support the LANDP Java Manager in a WSoD environment, the environment variable EHC_WSID must be defined with the workstation ID and should be included in the machine-unique CONFIG.SYS file.

    Run Time

    By default, WSoD does not allow anything to be written to a disk on a WSoD client workstation (it may be a media-less workstation). Any I/O requests are read/written to the disk on the WSoD server, for example, shared-file access or any attempt to write trace or logging information.

    References


    Windows Terminal Server




    ehcmwin

    Microsoft Windows Terminal Server (WTS) is a multi-user environment that provides either an addition to the Windows NT 4.0 Terminal Server Edition, or a service in the Windows 2000 Server family. WTS consists of two main parts, the terminal server and the terminal (or client). WTS allows more than one user to use the same server machine at the same time. Note that on Windows XP, Remote Desktop Connection is supported, but Fast User Switching is not supported by LANDP.

    The following describes how LANDP can be integrated into the WTS multi-user environment.

    Distributing files

    In the WTS environment, the installation and customization of LANDP can be done in the same way as usual for LANDP for Windows. There is no need to use the program wizard that is supplied with WTS to install and remove applications.

    However, when distributing a workgroup, care must be taken to ensure that the LANDP files are segregated correctly.

    One benefit of WTS is that only one version of an application program needs to be present on the server machine. These applications must be kept in a read-only directory. However, because LANDP files are distributed on a machine-specific basis, some changes to the normal distribution process are required.

    Normally, after LANDP customization, the GETTING utility is used to distribute the files for a given workstation to the same directory destination. In a WTS environment, shared read-only files should be placed in a workstation-specific directory.

    The following describes how the LANDP files might be distributed in a WTS environment.

    The following LANDP files can be shared across multiple machines, and are suitable for inclusion in the read-only directory:

    All EXE files
    All DLL files
    All HLP files
    All MSG files
    All COM files
    All SYS files
    Device drivers
    SERVERS.LST
    3270 translate tables (AE3270.* DIS3270.* EA3270.* FK3270.*)
    RCMS translate tables (AERCMS.* EARCMS.*)
    All PAN files

    All other files should be placed into a machine-unique read-write directory. The following files might be machine-unique (read/write or read/only). The list includes files that are targeted to a specific machine and that can be modified by selected servers.

    AUTOFBSS.BAT
    Other command files (for example, CREADB.BAT, RCK.BAT, RST.BAT)
    *.CFG
    Shared file server files (*.DBD, *.PCB, *.SEQ)
    SNA.BID

    There are many other miscellaneous files that can be distributed to each workstation, and that contain information specific to that workstation.

    These should also be placed into a machine-unique read-write directory.

    LANDP customization considerations

    LANDP customization creates configurations for the LANDP servers. In some cases, these configurations contain file names and file paths. These file attributes must be chosen carefully when LANDP is to run in a WTS environment. In a normal Windows environment, a LANDP workstation does not share its disk with another LANDP workstation, because each workstation is on a separate machine. However, under WTS, all LANDP workstations are on the same machine. Therefore, it is vital that these separate workstations are not allowed to interfere with each other.

    For example, the SHFLDBD vector contains two keywords: DBDPATH and DBFLNAME. These keywords describe the name and path of the shared file. If two Shared File Servers exist within the same workgroup and therefore are going to run on the same server machine, these keywords must not conflict. Each shared file server profile must have have its own unique file name and path.

    Client-attached devices

    Devices that are attached to the client machine can be used by applications that run within that client's session. WTS provides the ability to access client-attached devices by mapping them through the LPT or COM ports. WTS only maps devices that have been installed using the printer wizard install utility provided by the operating system. It does not allow the mapping of client drives, although network drives can be mapped.

    The common LANDP devices are magnetic stripe readers (MSRs), PIN pads, and printers. You might not be able to install these using the Windows printer wizard.

    There are third-party software solutions (for example, Citrix MetaFrame) that extend the functionality of client-attached device mapping.

    Some LANDP servers require the port number to which the device is attached. In the WTS environment, LANDP uses the port number that is defined on the terminal server, not the client. For example, if an MSRE is attached to the client's COM 1 port and mapped to the terminal server's COM 4 port, the /C: parameter for MSRE47## needs to be 4, not 1.

    LANDP can access the local machine's disk when mapped through either MetaFrame or the 'net use' command. MetaFrame defines the drive-mapping convention that will be used for each client session, and when using the local drives mapped in the client sessions, no authorization is needed. However, the 'net use' method requires authorization before accessing a network drive. If client drives are to be used, the corrected path names must be supplied in your LANDP Customization data.

    Run time

    When running LANDP in a WTS environment, it is important to make sure that each server does not interfere with other servers. This can usually be done through careful planning at the customization stage. However, in some cases, action is required at run time.


    Shared File Server

    The Shared File Server has two types of local files, the log file and the locks file, which are unique to that instance of the Shared File Server. By default, these files are placed in the root directory of the C drive. In the WTS environment, if two or more Shared File Servers exist within the same workgroup, these local files will conflict.

    LANDP provides a mechanism to enable users to select their own paths for these files. This mechanism should be used within the WTS environment, so that each Shared File Server has its own instances of the log and locks files. To use the mechanism, set the environment variables LOGPATH, LOGPATH2, and LOCKSPATH in the AUTOFBSS.BAT file for each Shared File Server within the workgroup.

    Java manager

    When running LANDP Java applications in a WTS environment, the variable EHC_WSID must be defined. EHC_WSID should be set to be the ID of the LANDP workstation, and must be available to the process that is running the LANDP Java application and to the LANDP Java Manager.

    If the LANDP Java manager is started using the AUTOFBSS.BAT file, add the SET EHC_WSID statement to the AUTOFBSS.BAT file. Otherwise, set the EHC_WSID variable from the command-line prompt before starting the LANDP Java Manager. Because LANDP Java applications are not started by AUTOFBSS, EHC_WSID should be set at the command line prompt before the Java application is started.

    Because Windows NT Services can only have one instance invoked, each LANDP workstation should be loaded in application mode. To do this, use the parameter /N when invoking the LOADER utility program. In addition, use the /W parameter to specify a unique directory path for this Shared File Server. If no /W parameter is specified, the current working directory is used.

    For example:

    LOADER /N: /W:C:\LANDP\SPV.EXE /01
    

    You should also add the read-only directory name to the 'path' statement. This tells Windows NT where the LANDP read-only files are, and also enables the user to invoke LANDP.

    An example

    The following describes a simple workgroup configuration for a WTS environment. Figure 26 shows a simple LANDP workgroup in a normal Windows NT environment.

    Figure 26. A Simple LANDP Workgroup

    EHCGR967

    Figure 27. A Simple LANDP Workgroup in a WTS Environment

    EHCGR968

    Under the WTS environment the associated COMMON.SPC and LANCONF.SPC files are described below.

    COMMON.SPC (extract):

       SHFLDBD     SHFLPRF=SEF01234,
                   DBDNAME=F1DBD,
                   COLLKEYS=N,
                   RECLEN=62,
                   DBDPATH=D:\client1\SFSDATA,
                   DBDFLNAME=F1,
                   KEY01=(F1P,P,N,5,0)
       SHFLPCB     PCBNAME=PCBF1,
                   KEYFIELD=F1P
     
       SHFLDBD     SHFLPRF=PERDATA,
                   DBDNAME=PERDATA,
                   COLLKEYS=N,
                   RECLEN=100,
                   DBDPATH=D:\client2\SFSDATA,
                   DBDFLNAME=F1,
                   KEY01=(PERNO,P,N,5,0)
       SHFLPCB     PCBNAME=PERSNO,
                   KEYFIELD=PERNO
    
    Note:
    The DBDPATH definitions have been highlighted because, in a WTS environment, the LANDP Shared File profiles must have uniquely defined file and path names. In the example shown, the DBD file name is the same in both Shared File profiles, but the DBD paths are different. Note that LANDP does not check for this uniqueness during customization.

    LANCONF.SPC (extract):

       LWSCONF     NAME=01,
                   TYPE=NT,
                   SERVER=(SHFILE01),
                   PAR&SHFL=(SEF01234,3,8,Y,0,,,,0,),
                   CLIENT=(SHFILE01,01),
                   CLIENT=(MSRE4702,02)
     
       LWSCONF     NAME=02,
                   TYPE=NT,
                   SERVER=(SHFILE02),
                   PAR&SHFL=(PERDATA,3,8,Y,0,,,,0,),
                   SERVER=(EHCODB2),
                   PAR&ODB=(DBNAME,4,14,10,),
                   SERVER=(MSRE4702),
                   PAR&MSRE=(4777,1),
                   CLIENT=(SHFILE01,01),
                   CLIENT=(MSRE4702,02),
                   CLIENT=(SHFILE02,02),
                   CLIENT=(EHCODB02,01) 
    

    The LANCONF vector definitions are exactly the same as for a normal Windows environment.

    The following shows how the files that have been created by customization should be distributed if no LANDP servers are to be run as Windows services:

    E:\LANDP is the shared read-only directory that contains all the read-only files ( for example, EXE files, DLL files, HLP files, MSG files).

    E:\CLIENT1\01\contains the files that are specific to workstation 01 ( for example, SEF01234.*, AUTOFBSS.BAT, *.cfg).

    E:\CLIENT2\02\contains the files that are specific to workstation 02 ( for example, PERDATA.*, AUTOFBSS.BAT, *.cfg).

    Use the following statement to update the PATH variable to include the shared read-only file directory:

    SET PATH=E:\LANDP;%PATH%

    Before running LANDP, you must also change the AUTOFBSS.BAT files to set the correct environment variables to avoid conflicts between the two shared-file servers.

    Add the following statements to the AUTOFBSS.BAT file in the directory containing read-write file for workstation 01:

    SET LOGPATH=E:\CLIENT1\01

    SET LOCKSPATH=E:\CLIENT1

    Add the following statements to the AUTOFBSS.BAT file in the directory containing read-write file for workstation 02:

    SET LOGPATH=E:\CLIENT2\02

    SET LOCKSPATH=E:\CLIENT2


    Appendix H. Notices

    This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this information in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

    IBM may have patents or pending patent applications covering subject matter described in this information. The furnishing of this information does not give you any license to these patents. You can send license inquiries, in writing, to:

    IBM Director of Licensing
    IBM Corporation
    North Castle Drive
    Armonk, NY 10504-1785
    USA

    For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

    IBM World Trade Asia Corporation
    Licensing
    2-31 Roppongi 3-chome, Minato-ku
    Tokyo 106, Japan

    The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS " WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore this statement may not apply to you.

    This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the information. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this information at any time without notice.

    Any references in this information to non-IBM documentation or non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those documents or Web sites. The materials for those documents or Web sites are not part of the materials for this IBM product and use of those documents or Web sites is at your own risk.

    Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

    IBM United Kingdom Laboratories,
    Mail Point 151,
    Hursley Park,
    Winchester,
    Hampshire,
    England
    SO21 2JN.

    Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

    The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Programming License Agreement, or any equivalent agreement between us.


    Trademarks and service marks

    The following terms are trademarks of the IBM Corporation in the United States or other countries, or both:

    Table 14. Trademarks and service marks

    ACF/VTAM

    AnyNet

    Application System/400

    AS/400

    AT

    BookManager

    C/2

    CICS

    COBOL/2

    Common User Access

    CUA

    DB2 Universal Database

    Distributed Database Connection Services/2

    Distributed Relational Database Architecture

    DRDA

    IBM

    IBMLink

    IMS/ESA


    LAN Distance

    LANDP

    Macro Assembler/2

    Micro Channel

    MQSeries

    Operating System/2

    OS/2

    OS/390

    RETAIN

    S/390

    ThinkPad

    VisualAge

    VisualGen

    VM/ESA

    VTAM

    WIN-OS/2

    Workplace Shell

    WebSphere


    Lotus is a registered trademark of Lotus Development Corporation in the United States and other countries.

    Tivoli and NetView are registered trademarks of Tivoli Systems Inc. in the United States and other countries. In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.

    Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc in the United States and other countries.

    Microsoft, Windows, Windows NT, Windows 2000, and the Windows logo, are registered trademarks of Microsoft Corporation.

    UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.

    Intel is a registered trademark of Intel.

    PC/TCP and NetManage are registered trademarks of NetManage Inc.

    Red Hat is a registered trademark of Red Hat, Inc.

    SuSE and its logo are registered trademarks of SuSE AG.

    Caldera Systems, the C-logo, and OpenLinux are either registered trademarks or trademarks of Caldera Systems, Inc.

    TurboLinux is a registered trademark of TurboLinux, Inc.

    Other company, product, and service names may be trademarks or service marks of others.


    Appendix I. Glossary

    This glossary includes abbreviations, terms, and definitions used in the IBM LANDP Licensed Programs Family publications. It does not include all terms previously established for IBM networks, programs, operating systems, or other IBM products.

    If you do not find the term you are looking for, refer to the IBM Dictionary of Computing.

    This glossary includes terms and definitions from the following sources:

    Definitions that are specific to IBM products are so labeled, for example, "In LANDP," or "In SNA."

    A

    abend
    Abnormal end of task.

    Abnormal end of task
    Termination of a task before its completion because of an error condition that cannot be resolved by recovery facilities while the task is executing.

    abstract class
    A class that provides common information for subclasses, and that therefore cannot be instantiated. Abstract classes provide at least one abstract method.

    abstract method
    A method with a signature, but no implementation. You provide the implementation of the method in the subclass of the abstract class that contains the abstract method.

    account
    In the AIX operating system, the log-in directory and other information that gives a user access to the system.

    ACF
    Advanced Communications Function

    ACF/NCP
    Advanced Communications Function for the Network Control Program.

    activate logical unit request (ACTLU)
    A request, sent by the host to the LANDP SNA server, to establish a logical session.

    activate physical unit request (ACTPU)
    A request, sent by the host to the LANDP SNA server, to establish a physical session.

    active
    In an XLR environment, the server (and by implication, the workstation) that handles client requests and sends logging data to the backup.

    ACTLU
    Activate logical unit request.

    ACTPU
    Activate physical unit request.

    adapter
    A part that electrically or physically connects a device to a computer or to another device. A printed circuit board that modifies the system unit to allow it to operate in a particular way.

    address
    The unique code assigned to each device or workstation connected to a network. A standard Internet address is a 32-bit address field. This field can be broken into two parts. The first part contains the network address; the second part contains the host number.

    Advanced Communications Function (ACF)
    A group of IBM licensed programs, principally VTAM programs, TCAM, NCP, and SSP, that use the concepts of Systems Network Architecture (SNA), including distribution of function and resource sharing. See also Network Control Program (NCP).

    Advanced Communications Function for the Network Control Program (ACF/NCP)
    An IBM program product that provides communication controller support for single-domain, multiple-domain, and interconnected network capability. See also Advanced Communications Function (ACF) and Network Control Program (NCP).

    advanced program-to-program communication (APPC)
    The general facility characterizing the LU 6.2 architecture and its various implementations in products.

    AID
    Attention identifier.

    AIX (Advanced Interactive Executive)
    IBM's licensed version of the UNIX operating system.

    alert
    A message sent to a management services focal point in a network to identify a problem or an impending problem. In the NetView program, a high-priority event that warrants immediate attention. A database record is generated for certain event types that are defined by user-constructed filters.

    alert condition
    A problem or impending problem for which information is collected and possibly forwarded for problem determination, diagnosis, or resolution.

    alert description
    Information in an alert table that defines the contents of a Systems Network Architecture (SNA) alert for a particular message ID.

    alert focal point
    The system in a network that receives and processes (logs, displays, and optionally forwards) alerts. An alert focal point is a subset of a problem management focal point.

    alert ID number
    A value created from specific fields in the alert using a cyclic redundancy check. A focal point uses this value to refer to a particular alert, for example, to filter out duplicate alerts.

    alert type
    A value in an alert that indicates the problem being reported.

    American National Standards Institute (ANSI)
    An organization consisting of producers, consumers, and general interest groups, that establishes the procedures by which accredited organizations create and maintain voluntary industry standards in the United States. (A)

    ANSI
    American National Standards Institute.

    APAR
    Authorized program analysis report.

    API
    Application program interface.

    APPC
    Advanced program-to-program communication.

    applet
    A Java program designed to run within a Web browser. Contrast with application.

    application
    In LANDP, a program using IBM LANDP for DOS, IBM LANDP for OS/2, IBM LANDP for Windows, IBM LANDP for Linux, IBM FBSS/2, IBM PC/Integrator, or IBM PC Integrator/2, tailored to the needs of the workstation user. The use to which an information processing system is put; for example, a payroll application, an airline reservation application, a network application. A collection of software components used to perform specific types of user-oriented work on a computer. In Java programming, a self-contained, stand-alone Java program that includes a static main method. It does not require an applet viewer. Contrast with applet.

    application program
    A program that is specific to the solution of an application problem. Synonymous with application software. (T) A program written for or by a user that applies to the user's work, such as a program that does inventory control or payroll. A program used to connect and communicate with stations in a network, enabling users to perform application-oriented activities.

    application program interface (API)
    In LANDP, the common interface by which server functions are requested. Requests are expressed by issuing a call to the supervisor. A functional interface supplied by the operating system or by a separately orderable licensed program that allows an application program written in a high-level language to use specific data or functions of the operating system or the licensed program. The interface through which an application program interacts with an access method.

    application software
    Software that is specific to the solution of an application problem. (T) Synonymous with application program. Software coded by or for an end user that performs a service or relates to the user's work. Software products such as games, spreadsheets, and word processing programs designed for use on a personal computer.

    argument
    An independent variable. (I) (A) Any value of an independent variable; for example, a search key; a number identifying the location of an item in a table. (I) (A) A parameter passed between a calling program and a called program.

    arrival sequence
    An order in which records are retrieved that is based on the order in which records are stored in a physical file.

    AS/400(R)
    IBM Application System/400(R).

    ASCII (American National Standard Code for Information Interchange)
    The standard code, using a coded character set consisting of 7-bit coded characters (8-bits including parity check), used for information interchange among data processing systems, data communication systems, and associated equipment. The ASCII set consists of control characters and graphic characters. (A)
    Note:
    IBM has defined an extension to ASCII code (characters 128-255).

    ASCIIZ format
    A string of ASCII characters ending with a null character (X'00').

    ASYNC
    Asynchronous.

    asynchronous (ASYNC)
    Pertaining to two or more processes that do not depend upon the occurrence of specific events such as common timing signals. (T) Without regular time relationship; unexpected or unpredictable with respect to the execution of program instructions.

    attention identifier (AID)
    A code in the inbound 3270 data stream that identifies the source or type of data that follow. A character in a data stream indicating that the user has pressed a key, such as the Enter key, that requests an action by the system.

    authorization
    In computer security, the right granted to a user to communicate with or make use of a computer system. (T) An access right. The process of granting a user either complete or restricted access to an object, resource, or function.

    authorized program analysis report (APAR)
    A report of a problem caused by a suspected defect in a current unaltered release of a program.

    B

    back-out
    To restore a file to a previous condition by removing changes in the inverse chronological order from which the changes were originally made.

    backup
    In an XLR environment, the server (and, by implication, the workstation) that accepts logging data from the active and maintains a mirror set of databases (at a transaction level).

    BASIC
    Beginner's all-purpose symbolic instruction code. A procedural algebraic language originally designed for ease of learning with a small instruction repertoire. (A) A high-level programming language with a small number of statements and a simple syntax that is designed to be easily learned and used and that is widely used for interactive applications on microcomputers.

    Basic Input/Output System (BIOS)
    Code that controls basic hardware operations, such as interactions with diskette drives, hard disk drives, and the keyboard. See also NetBIOS.

    BAT, bat
    A DOS batch file extension (.BAT). A batch file that contains a series of commands to be processed sequentially.

    BB
    Begin bracket.

    begin bracket (BB)
    An SNA bracket protocol term issued by the LANDP SNA server when bracket protocol is requested in the bind session. Contrast with end bracket.

    BID
    In SNA, a request to start a bracket.

    bind
    To associate a variable with an absolute address, identifier, or virtual address, or with a symbolic address or label in a program.

    BIND
    In SNA, a request to start a session between two logical units. Contrast with UNBIND.

    binding
    In programming, an association between a variable and a value for that variable that holds within a defined scope. The scope may be that of a rule, a function call, or a procedure invocation. (T) In the AIX operating system, a temporary association between a client and both an object and a server that exports an interface to the object. A binding is meaningful only to the program that sets it and is represented by a bound handle.

    BIOS
    Basic Input/Output System.

    block
    The smallest complete unit of data that can be transmitted between units in a communication network. The maximum size of a block depends on the characteristics of the sending or receiving unit. A group of contiguous characters recorded as a unit. See also connectivity programming request block, program control block.

    browser
    An Internet-based tool that lets users browse web sites.

    buffer
    A routine or storage used to compensate for a difference in rate of flow of data, or time of occurrence of events, when transferring data from one device to another. (A) A portion of storage used to hold input or output data temporarily.

    C

    C language
    A language used to develop software applications in compact, efficient code that can be run on different types of computers with minimal change.

    call
    In LANDP, the invocation of one of the LANDP API routines, RMTREQ, GETRPLY and RMTAREQ (client calls) and GETREQ, RMTRPLY, and SRVINIT (server calls). A LANDP client uses the RMTREQ call to request a LANDP function. Calls use the connectivity programming request block (CPRB) to pass and receive information. The syntax of a call varies with the programming language. The following examples are for COBOL and C respectively
    CALL "RMTREQ" USING BY REFERENCE EHC-CPRB
                    BY VALUE     EHC-RESERVED
     
    retcode = GETREQ(&mycprb, EHC_RESERVED);
    

    CCITT
    Comité Consultatif International Télégraphique et Téléphonique. The International Telegraph and Telephone Consultative Committee.

    CD
    Compact disc.

    CD-ROM
    Compact disc-read-only memory.

    CICS(R)
    Customer Information Control System.

    CID
    Configuration, Installation, and Distribution. An IBM standard methodology for installing and distributing products under DOS, OS/2, and Windows 3.1.

    ciphertext
    In computer security, text produced by encryption. Synonym for enciphered data.

    cleartext
    Nonencrypted data. Synonym for plaintext.

    class
    An encapsulated collection of data and methods to operate on data. A class can be instantiated to produce an object that is an instance of the class.

    CLASSPATH
    In your deployment environment, the environment variable keyword that specifies the directories in which to look for class and record files.

    client
    A functional unit that receives shared services from a server. (T) A user. See also client/server, client workstation, server, and user.

    client workstation
    In IBM LANDP for DOS, IBM LANDP for OS/2, IBM LANDP for Linux, IBM LANDP for Windows, IBM FBSS/2, IBM PC/Integrator, and IBM PC Integrator/2, a workstation in a LAN that uses a service. See also client, client/server, server, and user.

    client/server
    In communications, the model of interaction in distributed data processing in which a program at one site sends a request to a program at another site and awaits a response. The requesting program is called a client; the answering program is called a server. See also client, client workstation, server, and user.

    CLIST, clist
    Command list.

    close
    A LANDP family function used to release a server. To end the processing of a file. A data manipulation function that ends the connection between a file and a program. Contrast with open.

    COBOL
    Common business-oriented language. A high-level programming language, based on English, that is used primarily for business applications.

    code page
    An assignment of graphic characters and control function meanings to all code points; for example, assignment of characters and meanings to 256 code points for an 8-bit code, assignment of characters and meanings to 128 code points for a 7-bit code.

    collating sequence
    A specified arrangement used in sequencing. (I) (A)

    COM, com
    A DOS file with the file extension .COM.

    command
    Loosely, a mathematical or logic operator. (A) A request from a terminal for performance of an operation or processing of a program. A character string from a source external to a system that represents a request for system action.

    command list (CLIST, clist)
    A list of commands and statements designed to perform a specific function for the user.

    Common User Access(TM) architecture
    Guidelines for the dialog between a human and a workstation or terminal. One of the three SAA architectural areas.

    communication configuration
    In LANDP, the process of selecting and describing to the LANDP programs the particular arrangement of communication functions about a particular user.

    communication controller
    A device that directs the transmission of data over the data links of a network; its operation may be controlled by a program executed in a processor to which the controller is connected or it may be controlled by a program executed within the device. (T) A type of communication control unit whose operations are controlled by one or more programs stored and executed in the unit. It manages the details of line control and the routing of data through a network.

    communication server
    A server that communicates with a remote computer for various workstations in a local area network.

    Communications Server
    An IBM licensed program that supports the development and use of OS/2 applications involving two or more connected systems or workstations. IBM SecureWay Communications Server for OS/2 Warp provides multiple concurrent connectivities using different protocols for IBM 3270 and 5250 emulation sessions, printer sessions, and file transfers. It supports a range of application programming interfaces (API), which may be called concurrently and are designed for a variety of applications. IBM SecureWay Communications Server for OS/2 Warp includes the necessary interfaces for network management.

    compact disc (CD)
    A disc, usually 4.75 inches in diameter, from which data is read optically by means of a laser. A disc with information stored in the form of pits along a spiral track. The information is decoded by a compact-disc player and interpreted as digital audio data, which most computers can process.

    compact disc-read-only memory (CD-ROM)
    A 4.75-inch optical memory storage medium, capable of storing about 550 megabytes of data. The standards for CD-ROM storage are known as the "Yellow Book."

    compaction
    Any method for encoding data to reduce the storage it requires. In SNA, the transformation of data by packing two characters in a byte so as to take advantage of the fact that only a subset of the allowable 256 characters is used; the most frequently sent characters are compacted. See also compression and encode.

    compression
    The process of eliminating gaps, empty fields, redundancies, and unnecessary data to shorten the length of records or blocks. In SNA, the replacement of a string of up to 64 repeated characters by an encoded control byte to reduce the length of the data stream sent to the LU-LU session partner. The encoded control byte is followed by the character that was repeated (unless that character is the prime compression character). Contrast with decompression.

    config.sys
    A file created during the customization process that holds the details about the system configuration. The CONFIG.SYS file is used during system operation.

    configuration
    The manner in which the hardware and software of an information processing system are organized and interconnected. (T) The physical and logical arrangement of devices and programs that make up a data processing system. The devices and programs that make up a system, subsystem, or network.

    connection
    An association established between functional units for conveying information. The path between two protocol modules that provide reliable stream delivery service. On the Internet, a connection extends from a TCP module on one machine to a TCP module on the other.

    connectivity
    The capability to attach a variety of functional units without modifying them.

    connectivity programming request block (CPRB)
    The control block used for communication between a server and a client. This control block contains the information that is exchanged between clients and servers, and the information required for routing the requests and replies.

    constructor
    A method called to set up a new instance of a class.

    control program
    A computer program designed to schedule and supervise the execution of programs of a computer system. (I) (A)

    coprocessor
    A supplementary processor that performs operations in conjunction with another processor. In personal computers, a microprocessor on an expansion board that extends the address range of the processor in the system unit or adds specialized instructions to handle a particular category of operations; for example, an I/O coprocessor, math coprocessor, or networking coprocessor.

    corrective service diskette
    A diskette provided by IBM to registered service coordinators for resolving user-identified problems with previously installed software. This diskette includes program updates designed to resolve problems.

    CPRB
    Connectivity programming request block.

    CRC
    The cyclic redundancy check character. (A)

    critical error handler
    A routine that the operating system calls automatically if an error occurs in an operating system function call. There is a standard error handler or the user can provide one for special functions.

    CRV
    Cryptography verification request.

    cryptography
    The transformation of data to conceal its meaning. In computer security, the principles, means, and methods for encrypting plaintext and decrypting ciphertext.

    cryptography key
    A parameter that determines cryptographic transformations between plaintext and ciphertext.

    cryptography verification (CRV) request
    A request unit sent by the primary logical unit (PLU) to the secondary logical unit (SLU) as part of cryptographic session establishment, to allow the SLU to verify that the PLU is using the correct session cryptography key and initialization vector (IV).

    CTS
    Clear to Send.

    CUA(TM) architecture
    Common User Access(TM) architecture.

    cursor
    A movable, visible mark used to show a position of interest on a display surface. (A) In SAA Common User Access architecture, a visual cue that shows a user where keyboard input will appear on the screen.

    Customer Information Control System (CICS(R))
    An IBM licensed program that allows transactions entered at remote terminals to be processed concurrently by user-written application programs. It includes facilities for building, using, and maintaining databases.

    Customer Information Control System for Virtual Storage (CICS/VS)
    An IBM licensed program used in a communications network.

    customization
    The process of designing a data processing installation or network to meet the requirements of particular users.

    customization workstation
    A workstation on which LANDP is installed, and which is used to customize a LANDP workgroup.

    cyclic redundancy check character (CRC)
    A character used in a modified cyclic code for error detection and correction. (A)

    D

    DASD
    Direct access storage device.

    data circuit-terminating equipment (DCE)
    In a data station, the equipment that provides the signal conversion and coding between the data terminal equipment (DTE) and the line. (I)

    Notes:

    1. The DCE may be separate equipment or a part of the DTE or an integral part of the DTE or of the intermediate equipment.

    2. A DCE may perform other functions that are usually performed at the network end of the line.

    Data Encryption Standard (DES)
    In computer security, the National Institute of Standards and Technology (NIST) Data Encryption Standard, adopted by the U.S. government as Federal Information Processing Standard (FIPS) Publication 46, which allows only hardware implementations of the data encryption algorithm.

    data flow control (DFC)
    In SNA, a request/response unit (RU) category used for requests and responses exchanged between the data flow control layer in one half-session and the data flow control layer in the session partner. Half duplex, flip-flop is the only LANDP-supported data flow control for both send and receive.

    data link control (DLC)
    In SNA, the layer that consists of the link stations that schedule data transfer over a link between two nodes and perform error control for the link. Examples of data link control are SDLC for serial-by-bit link connection and data link control for the System/370(TM) channel. See also Systems Network Architecture (SNA). In SNA, a set of rules used by two nodes on a data link to accomplish an orderly exchange of information.

    data set
    The major unit of data storage and retrieval, consisting of a collection of data in one of several prescribed arrangements and described by control information to which the system has access. Sometimes called a file.

    data terminal equipment (DTE)
    The part of a data station that serves as a data source, data sink, or both. (I) (A)

    database description (DBD)
    In LANDP, the shared-file server descriptor. In IMS/VS, the collection of macro-parameter statements that describes an IMS/VS database. These statements describe the hierarchical structure, IMS/VS organization, device type, segment length, sequence fields, and alternate search fields. The statements are assembled to produce database description blocks.

    datagram
    The basic unit of information that is passed across the Internet. It consists of one or more data packets.

    DBCS
    Double-byte character set.

    DBD
    Database description.

    DBM
    Database manager.

    DCA
    Direct communication adapter.

    DCE
    Data circuit-terminating equipment. Distributed Computing Environment.

    DDE
    Dynamic data exchange.

    DDT
    Diagnostic and debugging tool.

    decipher
    To convert enciphered data in order to restore the original data. (T) In computer security, to convert ciphertext into plaintext by means of a cipher system. To convert enciphered data into clear data. Synonymous with decrypt. Contrast with encipher.

    decompression
    A function that expands data to the length that preceded data compression. Contrast with compression.

    decrypt
    In computer security, to decipher or decode. Synonymous with decipher. (T)

    default
    A value, attribute or option that is assumed when none is explicitly specified.

    delimiter
    A character used to show the beginning and end of a character string. (T) A character that groups or separates words or values in a line of

    deprecation
    An obsolete component that may be deleted from a future release of a product.

    DES
    Data Encryption Standard.

    development workstation
    A workstation which is part of a LANDP workgroup, and which is customized via a customization workstation.

    device driver
    In Advanced DOS, a file that contains the code needed to attach and use a device.

    DFC
    Data flow control.

    DIN
    Deutsches Institut für Normung.

    direct access
    The capability to obtain data from a storage device, or to enter data into a storage device, in a sequence independent from their relative position, by means of addresses indicating the physical position of the data. (T) Contract with sequential access.

    direct access storage device (DASD)
    A device where access time is effectively independent of the location of the data.

    directory
    A table of identifiers and references to the corresponding items of data. (I) (A) A type of file containing the names and controlling information for other files or other directories. An index that is used by a control program to locate one or more blocks of data that are stored in separate areas of a data set in direct access storage. A listing of the files stored on a diskette.

    directory service (DS)
    An application service element that translates the symbolic names used by application processes into the complete network addresses used in an OSI environment. (T)

    disk
    A round, flat data medium that is rotated to read or write data. (T) Loosely, a magnetic disk unit.

    disk operating system
    An operating system for computer systems that use disks and diskettes for auxiliary storage of programs and data.

    diskette
    A thin, flexible magnetic disk and a semi-rigid protective jacket, where the disk is permanently enclosed. Contrast with hard disk.

    Distributed Computing Environment (DCE)
    The Open Software Foundation (OSF) specification (or a product derived from this specification) that assists in networking. DCE provides such functions as authentication, directory service (DS), and remote procedure call (RPC).

    distributed system
    A data processing system where processing, storage, and control functions, and also input and output operations, are distributed among remote locations.

    distribution diskette
    A diskette on which IBM sends programs and documentation to a customer.

    DLC
    Data link control.

    DLL
    Dynamic link library.

    DMA
    Direct memory access.

    domain
    The part of a computer network where the data processing resources are under common control. (T) In a database, all the possible values of an attribute or a data element. In SNA, a system services control point (SSCP) and the physical units (PUs), logical units (LUs), links, link stations, and all associated resources that the SSCP could control with activation requests and deactivation requests.

    DOS
    Disk Operating System.

    double-byte character set (DBCS)
    A set of characters in which each character is represented by 2 bytes. Languages such as Japanese, Chinese, and Korean, which contain more symbols than can be represented by 256 code points, require double-byte character sets. Because each character requires 2 bytes, the typing, display, and printing of DBCS characters requires hardware and programs that support DBCS. Contrast with single-byte character set (SBCS).

    DS
    Directory service.

    DSR
    Data Set Ready.

    DTE
    Data terminal equipment. (A)

    DTE/DCE interface
    The physical interface and link access procedures between a data terminal equipment (DTE) and a data circuit-terminating equipment (DCE).

    dynamic data exchange (DDE)
    The exchange of data between programs or between a program and a data-file object. Any change made to information in one program or session is applied to the identical data created by the other program.

    dynamic link library (DLL)
    A file containing executable code and data bound to a program at load time or run time, rather than during linking. The code and data in a dynamic link library can be shared by several applications simultaneously.

    E

    EB
    End bracket.

    EBCDIC
    Extended binary-coded decimal interchange code.

    EGA
    Enhanced graphics adapter.

    EID
    End-of-message (EOM) identification.

    EMM
    Expanded memory manager.

    emulation
    The use of a data processing system to imitate another data processing system, so that the imitating system accepts the same data, executes the same programs, and achieves the same results as the imitated system. Emulation is usually achieved with hardware or firmware. (T)

    encipher
    To scramble data or to convert data to a secret code that masks the meaning of the data to any unauthorized recipient. Synonymous with encrypt. (T) In computer security, to convert plaintext into an unintelligible form by means of a cipher system. Synonymous with cipher. Contrast with decipher. See also encode.

    enciphered data
    Data whose meaning is concealed from unauthorized users or observers. Synonymous with encode.

    encode
    To convert data by the use of a code in such a manner that reconversion to the original form is possible. (T) In computer security, to convert plaintext into an unintelligible form by means of a code system. See also plaintext.

    encrypt
    In computer security, to encode or encipher. Synonym for encipher. (T)

    end bracket (EB)
    An SNA bracket protocol term used when the bind session specifies the end bracket call. If specified in the bind session, the personal computer may send both begin bracket and end bracket calls (not-response mode protocol). Contrast with begin bracket.

    end-of-message (EOM)
    The character or sequence of characters that shows the end of a message or record.

    enhanced graphics adapter (EGA)
    An adapter, such as the IBM Enhanced Graphics Adapter, that provides high-resolution graphics, allowing the use of a color display for text processing and also graphics applications.

    environment
    A named collection of logical and physical resources used to support the performance of a function.

    EOM
    End-of-message.

    erase
    To remove data from a data medium. Erasing is usually accomplished by overwriting the data or deleting the references. (T)

    error log
    A data set or file in a product or system where error information is stored for later access. A record of machine checks, device errors, and volume statistical data.

    error message
    An indication that an error has been detected. (A)

    ERRORLEVEL
    A parameter of the IF command used by batch files. It is used in testing for failure of recently loaded programs.

    event
    An occurrence or happening. An occurrence of significance to a task; for example, the completion of an asynchronous operation, such as an input/output operation. A data link control command and response passed between adjacent nodes that allows the two nodes to exchange identification and other information necessary for operation over the data link. In the NetView program, a record indicating irregularities of operation in physical elements of a network.

    exception
    An object that has caused some new condition, such as an error. In Java, throwing an error means passing that object to an interested party. A signal indicates what condition has occurred. Catching the condition means receiving the sent object. Handling this exception means dealing with the problem after receiving the object (though it might mean doing nothing, which is bad programming practice).

    exchange identification (XID)
    The ID that is exchanged with the remote physical unit when an attachment is first established.

    EXE, exe
    An executable file with the file extension .EXE.

    extended ASCII
    A set of ASCII codes that uses the eighth (most significant) bit to define 127 additional codes. Standard ASCII uses 7 bits and defines 128 codes.

    extended binary-coded decimal interchange code (EBCDIC)
    A coded character set of 256 8-bit characters.

    external logging replicator (XLR)
    Shared-file mode of operation in which fault-tolerant data replication is achieved by logging database updates to an external server.

    F

    facility
    An operational capability, or the means for providing such a capability. (T) A service provided by an operating system for a particular purpose; for example, the checkpoint/restart facility.

    FBSI
    Financial Branch Systems Integrator.

    FBSS (DOS)
    IBM Financial Branch Systems Service (DOS). The predecessor to LANDP.

    FBSS/2
    Financial Branch Systems Service/2.

    FCB
    File control block.

    FIC
    First-in-chain.

    file
    A named set of records stored or processed as a unit. (T) A collection of information treated as a unit. A collection of data that is stored and retrieved by an assigned name.

    file control block (FCB)
    A record that contains all of the information about a file, such as its structure, length, and name.

    file index table (FIT)
    A table used by WorkSpace On-Demand to redirect file access requests from a client workstation's boot drive to the appropriate location on the boot server.

    file server
    A high-capacity disk storage device or a computer that each computer on a network can use to access and retrieve files that can be shared among the attached computers.

    file transfer
    In remote communications, the transfer of one or more files from one system to another over a communications link.

    first-in-chain (FIC)
    A request unit (RU) whose request header (RH) begin chain indicator is on and whose RH end chain indicator is off.

    FIT
    file index table

    fixed disk
    Synonym for hard disk.

    flag
    A variable indicating that a certain condition holds. (T) Any of various types of indicators used for identification; for example, a word mark. (A) A character that signals the occurrence of some condition, such as the end of a word. (A)

    FMH
    Function management header.

    format identification (FID) field
    In SNA, a field in each transmission header (TH) that shows the format of the transmission header; that is, the presence or absence of certain fields.

    forward recovery
    The process of reconstructing a file from a particular point by restoring a saved version of the file and then applying changes to that file in the same order in which they were originally made.

    function
    In IBM LANDP for DOS, IBM LANDP for OS/2, IBM LANDP for Windows NT, IBM FBSS (DOS), IBM FBSS/2, IBM PC/Integrator, and IBM PC Integrator/2 a function is the specification of an activity to be performed by a server. In computer programming, synonym for procedure.

    function management header (FMH)
    A special record or part of a record that contains control information for the data that follow. In SNA, one or more headers optionally present in the leading request units (RUs) of an RU chain that allow a half-session in an LU-LU session to: (a) select a destination as session partner and control way where end-user data it sends are handled at the destination, (b) change destination or characteristics of data during session, and (c) send between session partners status or user information about destination; for example, whether it is a program or device.

    G

    gateway
    In LANDP, the workstation that connects the LANDP workgroup to a host computer with the necessary LANDP software and the respective physical attachment. A functional unit that interconnects two computer networks with different network architectures. A gateway connects networks or systems of different architectures. A bridge interconnects networks or systems with the same or similar architectures. (T) A network that connects hosts. Contrast with router.

    generic alert
    A product-independent method of encoding alert data by means of both (a) code points indexing short units of stored text and (b) textual data.

    H

    hard disk
    A rigid magnetic disk such as the internal disks used in the system units of IBM personal computers and in external hard disk drives. Synonym for fixed disk. Contrast with diskette.

    HDLC
    High-level data link control.

    hexadecimal
    Describing a numbering system with base of sixteen; valid numbers use the digits 0 through 9 and characters A through F, where A represents 10 and F represents 15.

    high-level data link control (HDLC)
    In data communication, the use of a specified series of bits to control data links under the International Standards for HDLC: ISO 3309 Frame Structure and ISO 4335 Elements of Procedures.

    host, host computer, host processor, or host system
    The primary or controlling computer in a multiple computer installation. A computer used to prepare programs for use on another computer or on another data processing system; for example, a computer used to compile, link edit, and test programs to be used on another system.

    hot-key
    The key combination used to change from one session to another on the workstation.

    Hypertext Transfer Protocol (HTTP)
    The Internet protocol, based on TCP/IP, that is used to fetch hypertext objects from remote hosts.

    I

    I/O
    Input/output.

    IBM Operating System/2(R) (OS/2)
    Pertaining to the IBM licensed program that can be used as the operating system for personal computers. The OS/2 licensed program can perform multiple tasks at the same time.

    ICV
    Initial chaining value.

    ID
    Identifier. Identification.

    identification
    In computer security, the process that allows a system to recognize an entity with personal, equipment, or organizational characteristics or codes.

    identifier
    One or more characters used to identify or name a data element or possibly to show certain properties of that data element. (A)

    IEEE
    Institute of Electrical and Electronics Engineers.

    IMS/VS
    Information Management System/Virtual Storage.

    indexed access
    Pertaining to the organization and accessing of the records of a storage structure through a separate index to the locations of the stored records. (A)

    indexed sequential access
    Pertaining to the organization and accessing of records through an index of the keys that are stored in arbitrarily partitioned sequential files. (A)

    initial chaining value (ICV)
    An 8-byte pseudo-random number used to verify that both ends of a session with cryptography have the same session cryptography key. The initial chaining value is also used as input to Data Encryption Standard (DES) algorithm to encipher or decipher data in a session with cryptography.

    initial program load (IPL)
    The initialization procedure that causes an operating system to begin operation. The process by which a configuration image is loaded into storage at the beginning of a work day or after a system malfunction. The process of loading system programs and preparing a system to run jobs.

    initialization
    The operations required for setting a device to a starting state, before the use of a data medium, or before implementation of a process. (T) Preparation of a system, device, or program for operation.

    initiate self
    An SNA command issued by the LANDP SNA server to initiate a host application. The SNA command is issued in response to the receipt of an Open command from the personal computer.

    INITSELF
    Initiate self.

    input/output (I/O)
    Describing a device whose parts can perform an input process and an output process at the same time. (I) Describing a functional unit or channel involved in an input process, output process, or both, concurrently or not, and to the data involved in such a process.

    Instruction Pointer (IP)
    In System 38, a pointer that provides addressability for a machine interface instruction in a program.

    interface
    A shared boundary between two functional units, defined by functional characteristics, signal characteristics, or other characteristics, as appropriate. The concept includes the specification of the connection of two devices having different functions. (T)

    International Organization for Standardization (ISO)
    An organization of national standards bodies from various countries established to promote development of standards to simplify international exchange of goods and services, and develop cooperation in intellectual, scientific, technological, and economic activity.

    Internet Protocol (IP)
    A protocol used to route data from its source to its destination in an Internet environment.

    interoperability
    The capability to communicate, execute programs, or transfer data among various functional units in a way that requires the user to have little or no knowledge of the unique characteristics of those units. (T) In SAA usage, the ability to link SAA and non-SAA environments and use the combination for distributed processing.

    IP
    Instruction Pointer. Internet Protocol.

    IPL
    Initial program load.

    ISAM
    Indexed sequential access method.

    ISO
    International Organization for Standardization.

    J

    Jar file format
    Java Archive, a platform-independent file format that aggregates many files into one. Multiple Java applets and their requisite components (.class files, images, sounds, and other resource files) can be bundled in a JAR file and subsequently downloaded to a browser in a single HTTP transaction.

    Java
    An object-oriented programming language for portable, interpretive code that supports interaction among remote objects. Java was specified and developed by Sun Microsystems, Incorporated. The Java environment consists of the JavaOS, the Virtual Machines for various platforms, the object-oriented Java programming language, and several class libraries.

    Java Development Kit (JDK)
    A set of Java technologies made available to licensed developers by Sun Microsystems. Each release of JDK consists of the Java compiler, Java virtual machine, Java class libraries, Java applet viewer, Java debugger, and other tools.

    JavaDoc
    Sun Microsystems tool for generating HTML documentation of classes by extracting comments from the Java source code files.

    Java eXtensions for Financial Services (J/XFS)
    J/XFS is a proposed standard, developed jointly by IBM, Siemens Nixdorf, NCR, DeLaRue and Sun Microsystems, for a standardised interface to all common financial devices that can be used by applications and applets within the Java programming language. The J/XFS standard defines APIs for accessing financial devices, and a control mechanism that enables any number of applications to access these devices. The following LANDP servers are supported through the J/XFS API:

    Java Remote Method Invocation (RMI)
    Method invocation between peers, or between client and server, when applications at both ends of the invocation are written in Java. Java RMI is included in JDK 1.1, or later.

    Java Runtime Environment (JRE)
    A subset of the Java Development Kit (JDK) that contains the core executables and files that constitute the standard Java platform. The JRE includes the Java Virtual Machine, core classes and supporting files.

    Java Virtual Machine
    A software implementation of a central processing unit (CPU) that runs compiled Java code (applets and applications).

    journal
    A chronological record of changes made in a set of data; the record may be used to reconstruct a previous version of the set. (T) A special-purpose data set that provides an audit trail of operator and system actions, or as a means of recovering superseded data.

    JRE
    Java Runtime Environment.

    JVM
    Java Virtual Machine.

    J/XFS
    Java/eXtensions for Financial Services.

    K

    KB
    Kilobyte; 1024 bytes.

    key
    An identifier within a set of data elements. (T) One or more characters used to identify the record and establish the order of the record within an indexed file.

    keystroke
    Actuation of a key on a keyboard to perform or release a machine function. (T)

    keyword
    A name or symbol that identifies a parameter or an ordered set of parameters.

    L

    LAN
    Local area network.

    LAN configuration
    The process by which the details about the structure of the LAN for a particular user are provided to the LANDP family programs. This includes details about the workstations forming the LAN, the services provided by each workstation, and the workstations that receive the services.

    LAN trace
    A LANDP family trace facility that informs about the LANDP-related LAN and displays the status of the local area network.

    LAN Distributed Platform
    The former name for the LANDP family of products.

    last-in-chain (LIC)
    A request unit (RU) whose request header (RH) end chain indicator is on and whose RH begin chain indicator is off.

    LDA
    Logical device address.

    LED
    Light-emitting diode.

    LIC
    Last-in-chain.

    light-emitting diode (LED)
    A semiconductor chip that gives off visible or infrared light when operated.

    link connection
    In SNA, the physical equipment providing two-way communication between one link station and one or more other link stations; for example, a telecommunication line and data circuit-terminating equipment (DCE).

    LIP
    LAN Internet Protocol.

    LLAP
    Logical link access path.

    loader
    A routine, commonly a computer program, that reads data into main storage. (A)

    local area network (LAN)
    A computer network located on a user's premises within a limited geographical area. Communication within a local area network is not subject to external regulations; however, communication across the LAN boundary may be subject to some form of regulation. (T)

    local host
    In the Internet, the computer to which a user's terminal is directly connected without using the Internet.

    logging
    The recording of data about specific events.

    logical device address (LDA)
    A number used to represent a terminal or terminal component within a workstation. See also physical device address.

    logical link access path (LLAP)
    In a multi-system environment, the path between any two systems. One or more logical link paths must be defined for each logical link.

    logical unit (LU)
    In SNA, a port through which an end user accesses the SNA network to communicate with another end user and through which the end user accesses the functions provided by the system services control points (SSCPs). An LU can support at least two sessions, one with an SSCP and one with another LU, and may be capable of supporting many sessions with other logical units. A type of network addressable unit that allows end users to communicate with each other and gain access to network resources.

    longitudinal parity check
    A parity check of a row of binary digits that are members of a set forming a matrix; for example, a parity check of the bits of a track in a block on a magnetic stripe. (T)

    longitudinal redundancy check (LRC)
    Synonym for longitudinal parity check.

    LRC
    Longitudinal redundancy check.

    LU
    Logical unit.

    LU--LU session type 0
    In SNA, a type of session between two LU--LU half-sessions using SNA-defined protocols for transmission control and data flow control, but using end-user or product-defined protocols to augment or replace FMD services protocols.

    LU--LU session type 1
    In SNA, a type of session between an application program and single- or multiple-device data processing terminals in an interactive, batch data transfer, or distributed processing environment.

    LU--LU session type 2
    In SNA, a type of session between an application program and a single display terminal in an interactive environment, using the SNA 3270 data stream.

    LUSTAT
    An SNA command used to send logical unit status information.

    M

    MAC
    Message authentication code.

    mapper
    A device, such as a piece of code, which performs a mapping function.

    mapping
    A list, usually in a profile, that establishes a correspondence between items in two groups; for example, a keyboard mapping can establish what character is displayed when a certain key is pressed. In a database, the establishing of correspondences between a given logical structure and a given physical structure. (T)

    MB
    Megabyte; 1 048 576 bytes.

    memory
    All of the addressable storage space in a processing unit and other internal storages that is used to execute instructions. (T)

    message
    An assembly of characters and sometimes control codes that is transferred as an entity from an originator to one or more recipients. A message consists of two parts: envelope and content. (T) A communication sent from a person or program to another person or program. A unit of data sent over a telecommunication line. One or more message segments transmitted among terminals, application programs, and systems. In SAA Common User Access architecture, information not requested by a user but displayed by an application in response to an unexpected event, or when something undesirable could occur.

    message authentication code (MAC)
    In computer security, a value, part of, or accompanying a message, used to determine that the contents, origin, author, or other attributes of all or part of the message are as they appear to be. In cryptography: (a) a number or value derived by processing data with an authentication algorithm, (b) the cryptographic result of block cipher operations on text or data using a cipher block chain (CBC) mode of operation, (c) a digital signature code.

    method
    A fragment of Java code within a class that can be invoked and passed a set of parameters to perform a specific task.

    MIC
    Middle-in-chain.

    MICR
    Magnetic ink character recognition.

    microcode
    One or more microinstructions. A code, representing the instructions of an instruction set, that is done in a part of storage that is not program-addressable. To design, write, and also to test one or more microinstructions.

    middle-in-chain (MIC)
    A request unit (RU) whose request header (RH) begin chain indicator and RH end chain indicator are both off.

    mnemonic
    A symbol chosen to help the user remember the significance of the symbol.

    mode
    A method of operation.

    mode switching
    Operator switching between a concurrently running personal computer application and 3270 emulation or other internal application.

    MSR, MSR/E
    Magnetic stripe reader; Magnetic stripe reader/encoder.

    multi-tasking
    A mode of operation that provides for concurrent performance, or interleaved execution of two or more tasks. (I) (A)

    N

    name server
    The server that stores resource records about hosts. In the AIX operating system, a host that provides name resolution for a network. Name servers translate symbolic names assigned to networks and hosts into the Internet addresses used by machines. In TCP/IP, synonym for domain name server.

    NAU
    Network addressable unit.

    NCP
    Network Control Program.

    NDIS
    Network Driver Interface Specification

    NetBIOS
    Network Basic Input/Output System. A standard interface to networks, IBM personal computers (PCs), and compatible PCs, that is used on LANs to provide message, print-server, and file-server functions. Application programs that use NetBIOS do not need to handle the details of LAN data link control (DLC) protocols. See also BIOS.

    NetView program
    An IBM licensed program used to monitor and manage a network and to diagnose network problems.

    network
    An arrangement of nodes and connecting branches. (T) A configuration of data processing devices and software connected for information interchange.

    network addressable unit (NAU)
    In SNA, a logical unit, a physical unit, or a system services control point. The NAU is the origin or the destination of information transmitted by the path control network. See also logical unit, physical unit, system services control point (SSCP).

    Network Control Program (NCP)
    An IBM licensed program that provides communication controller support for single-domain, multiple-domain, and interconnected network capability. See also Advanced Communications Function (ACF).

    network management vector transport (NMVT)
    A management services request/response unit (RU) that flows over an active session between physical unit management services and control point management services (SSCP-PU session).

    network resource
    In ACF/VTAM(R), a network component such as a local network control program, an SDLC data link, or a peripheral node.

    network services procedure error (NSPE)
    A request unit that is sent by a system services control point (SSCP) to a logical unit (LU) when a procedure requested by that LU has failed.

    NLS
    National language support.

    NMVT
    Network management vector transport.

    node
    In a network, a point at which one or more functional units connect channels or data circuits. (I) In network topology, the point at an end of a branch. (T)

    NPSI
    X.25 NCP Packet Switching Interface.

    NSPE
    Network services procedure error.

    O

    object
    The principal building block of object-oriented programs. Objects are software programming modules. Each object is a programming unit consisting of related data and methods.

    object-oriented programming (OOP)
    A programming approach based on the concepts of data abstraction and inheritance. Unlike procedural programming techniques, object-oriented programming concentrates on the data objects that constitute the problem and how they are manipulated, not on how something is accomplished.

    ODBC
    Open Database Connectivity is a standardized set of API function calls that can be used to access data stored in both relational and non-relational DBMSs.

    OIA
    Operator information area.

    OIC
    Only-in-chain.

    only-in-chain (OIC)
    A request unit (RU) for which the request header (RH) begin chain indicator and RH end chain indicator are both on.

    OOP
    object-oriented programming

    open
    The function that connects a file to a program for processing. Contrast with close.

    open system
    A system with specified standards, and that therefore can be readily connected to other systems that comply with the same standards.

    operating system
    Software that controls the execution of programs and that may provide services such as resource allocation, scheduling, input/output control, and data management. Although operating systems are predominantly software, partial hardware implementations are possible. (T)

    operator information area (OIA)
    In the 3270 Information Display System, the area near the bottom of the display area where terminal or system status information is displayed.

    option
    A specification in a statement that may be used to influence the processing of the statement.

    OS/2 operating system
    IBM Operating System/2.

    P

    pacing
    A technique by which a receiving station controls the rate of transmission of a sending station to prevent overrun.

    package
    A program element that contains classes and interfaces.

    packet
    A sequence of binary digits, including data and control signals, that is transmitted and switched as a composite entity.

    panel
    A formatted display of information that appears on a display screen.

    parallel port
    On a personal computer system, a port used to attach devices such as dot matrix printers and input/output units; it transmits data one byte at a time. See also serial port.

    parameter
    A variable that is given a constant value for a specified application and that may denote the application. (I) (A) An item in a menu for which the user specifies a value or for which the system provides a value when the menu is interpreted. Data passed between programs or procedures.

    Pascal
    A high-level, general purpose programming language, related to ALGOL. Programs written in Pascal are block structured, consisting of independent routines. They can run on different computers with little or no modification.

    path
    In a personal computer system, the logical relationship between directories.

    PBM
    Personal banking machine.

    PC
    Personal computer.

    PC-ID
    Workstation identifier.

    PCB
    Program control block.

    PC/TCP
    FTP Software's implementation of TCP/IP for systems running DOS and Windows. Now called PC/TCP Network Software version 5.0 and available from NetManage Inc..

    PDA
    Physical device address.

    PDP
    Problem determination procedure.

    personal computer system
    IBM Personal System/2 and also the various IBM Personal Computer system units, unless otherwise described.

    Personal Identification Number (PIN) pad
    A pad with twelve keys in a specific arrangement that display alphabetic and numeric characters that may be entered onto a financial transaction terminal. (T) (A)

    physical device address (PDA)
    An address or set of addresses that identifies a particular device.

    physical unit (PU)
    In SNA, the component that manages and monitors the resources, such as attached links and adjacent link stations, associated with a node, as requested by an SSCP via an SSCP-PU session. An SSCP starts a session with the physical unit to indirectly manage, through the PU, resources of the node such as attached links. This term applies to type 2.0, type 4, and type 5 nodes only.

    PIN
    Personal identification number.

    plaintext
    Nonencrypted data. Synonymous with cleartext. Synonym for clear data.

    PLU
    Primary logical unit.

    PM
    Presentation Manager(R) (in OS/2).

    pointing device port
    The IBM PS/2 port that allows attachment of various devices including pointing devices.

    port
    An access point for data entry or exit. A connector on a device to which cables for other devices such as display stations and printers are attached. A specific communications end point within a host. A port is identified by a port number.

    Post Telephone and Telegraph Administration (PTT)
    An organization, usually a government department, that provides communication common carrier services in countries other than the USA and Canada. Examples of PTTs are the Bundespost in Germany, and the Nippon Telephone and Telegraph Public Corporation in Japan.

    PPC
    Program to program communications.

    Presentation Manager
    A component of OS/2 that provides a complete graphics-based user interface, with pull-down windows, action bars, and layered menus.

    primary logical unit (PLU)
    In SNA, the logical unit (LU) that contains the primary half-session for a particular LU--LU session. Contrast with secondary logical unit (SLU). See also logical unit (LU).

    problem determination procedure (PDP)
    A prescribed sequence of steps taken to identify the source of a problem.

    process
    A unique, finite course of events defined by its purpose or by its effect, achieved under defined conditions. Any operation or combination of operations on data. A function being performed or waiting to be performed. A program in operation.

    processor
    In a computer, a functional unit that interprets and executes instructions. A processor consists of at least an instruction control unit and an arithmetic and logic unit. (T) The functional unit that interprets and processes instructions.

    profile
    In computer security, a description of the characteristics of an entity to which access is controlled. Data that describes the significant characteristics of a user, a group of users, or one or more computer resources.

    program
    A sequence of instructions suitable for processing by a computer. Processing may include the use of an assembler, a compiler, an interpreter, or a translator to prepare the program for execution, and also to execute it. (I)

    program control block (PCB)
    LANDP family shared-file server pointer related to a specific DBD.

    Program temporary fix (PTF)
    A temporary solution or bypass of a problem diagnosed by IBM as resulting from a defect in a current unaltered release of the program.

    protocol
    In SNA, the meanings of and the sequencing rules for requests and responses used for managing the network, transferring data, and synchronizing the states of network components.

    PS/2
    Personal System/2.

    PTF
    Program temporary fix.

    PTT
    Post Telephone and Telegraph Administration.

    PU
    Physical unit.

    Q

    QLLC
    Qualified logical link control.

    qualified logical link control (QLLC)
    An X.25 protocol that allows the transfer of data link control information between two adjoining systems network architecture (SNA) nodes that are connected through an X.25 packet-switching data network. The QLLC provides the qualifier "Q" bit in X.25 data packets to identify packets that carry logical link protocol information.

    query
    A request for information from a file relying on specific conditions. In the AS/400 system, the query management object that is used to define queries against relational data.

    quiescing
    The process of bringing a device or a system to a stop by rejection of new requests for work. (A)

    R

    RAM
    Random access memory. (A)

    random access memory (RAM)
    A storage device where data can be written and read.

    RC
    Return code.

    RCMS
    Remote change management services.

    RDBMS
    Relational database management system. A generic name for any relational database system such as DB2.

    re-synchronization
    Restarting the transmission of a function at the point where it was interrupted.

    read-only memory (ROM)
    A storage device where data, under normal conditions, can only be read. (T) See also read-only storage (ROS).

    read-only storage (ROS)
    A storage device whose contents cannot be modified, except by a particular user, or when operating under particular conditions. See also read-only memory (ROM).

    record
    In programming languages, an aggregate that consists of data objects, possibly with different attributes, that usually have identifiers attached to them. In some programming languages, records are called structures. (I) A set of data treated as a unit. (T) A set of one or more related data items grouped for processing.

    remote attachment
    A method of connecting two devices over a telecommunication line.

    remote initial program load (remote IPL)
    A feature that permits a computer to receive its initial program from another computer, rather than from its own internal disk or diskette storage.

    remote method invocation
    A specific instance of the more general term RPC (remote procedure call). Remote method invocation (RMI) allows objects to be distributed over a network, that is, a Java program running on one computer can call the methods of an object running on another computer. RMI and java.net are the only 100% pure Java APIs for controlling Java objects in remote systems.

    remote procedure call (RPC)
    A facility that a client uses to request the execution of a procedure call from a server. This facility includes a library of procedures and an external data representation.

    REMS
    Reader/encoder magnetic stripe.

    request/response header (RH)
    In systems network architecture (SNA), control information preceding a request/response unit (RU) that specifies the type of RU and contains control information associated with the RU.

    request/response unit (RU)
    In systems network architecture (SNA), a generic term for a request unit or a response unit.

    resource
    Any of the data processing system elements needed to perform required operations, including storage, input/output units, one or more processing units, data, files, and programs. (T) See also network resource.

    retry
    To resend data a prescribed number of times or until the data is received correctly.

    return code (RC)
    A code used to influence the execution of succeeding instructions. (A) A value returned to a program to indicate the results of an operation requested by that program.

    RH
    Request/response header.

    roll back
    To remove changes that were made to database files under commitment control since the last commitment boundary.

    RMI
    Remote Method Invocation.

    rollback
    A programmed return to a prior checkpoint. (A) The process of restoring data changed by an application program or user to the state of its last commitment boundary. In SQL, the process of restoring data changed by an application program or user to the state of its last commit point.

    ROM
    Read-only memory. (A)

    ROS
    Read-only storage.

    router
    A computer that determines the path of network traffic flow. The path selection is made from several paths based on information obtained from specific protocols, algorithms that attempt to identify the shortest or best path, and other criteria such as metrics or protocol-specific destination addresses. An attaching device that connects two LAN segments, which use similar or different architectures, at the reference model network layer. Contrast with bridge, gateway. In OSI terminology, a function that determines a path by which an entity can be reached.

    RPC
    Remote procedure call.

    RTR
    Ready to Receive.

    RU
    Request/response unit.

    S

    SAM
    Service availability manager.

    SAP
    Service access point.

    SBC
    Server Based Computing.

    SBCS
    Single-byte character set.

    scan code
    A code generated by a keyboard.

    SCS
    Systems network architecture character string.

    SDLC
    Synchronous data link control.

    secondary logical unit (SLU)
    In systems network architecture (SNA), the logical unit (LU) that contains the secondary half-session for a particular LU-LU session. Contrast with primary logical unit (PLU). See also logical unit (LU).

    SEQ
    Sequential file.

    sequential access
    The capability to enter data into a storage device or a data medium in the same sequence as the data is ordered, or to obtain data in the same order as it has been entered. (T) An access method in which records are read from, written to, or removed from a file based on the logical order of the records in the file. Contrast with direct access.

    serial port
    On personal computer systems, a port used to attach devices such as display devices, letter-quality printers, modems, plotters, and pointing devices such as light pens and mice; it transmits data one bit at a time. See also parallel port.

    serialization
    Turning an object into a stream and back again.

    server
    A functional unit that provides shared services to workstations over a network; for example, a file server, a print server, a mail server. (T) In LANDP, a functional area that provides functions to LANDP workstations in a LANDP workgroup. The computer that hosts the Web page that contains an applet. The .class files that make up the applet, and the HTML files that reference the applet reside on the server. When someone on the Internet connects to a web page that contains an applet, the server delivers the .class files over the Internet to the client that made the request. The server is also known as the originating host. See also client, client workstation, and user. In LANDP, a function provided by a server.

    server based computing (SBC)
    This is a generic term that is used to describe network computer systems such as WorkSpace on Demand and Windows Terminal Server.

    service access point (SAP)
    A logical point made available by a token-ring adapter where information can be received and transmitted.

    service availability manager (SAM)
    Facility used by the shared-file server to provide fault-tolerant data access in an XLR environment.

    servlet
    Server-side program that executes on and adds function to a Web server. Java servlets allow for the creation of complicated, high-performance, cross-platform Web applications. They are highly extensible and flexible, making it easy to expand from client or single-server applications to multi-tier applications.

    session
    In systems network architecture (SNA), a logical connection between two network addressable units (NAU) that can be started, tailored to provide various protocols, and deactivated, as requested. The time during which programs or devices can communicate with each other.

    single-byte character set (SBCS)
    A character set in which each character is represented by a one-byte code. Contrast with double-byte character set (DBCS).

    SLU
    Secondary logical unit.

    SNA
    Systems network architecture.

    SNUF
    Systems network architecture up-line facility.

    socket
    An endpoint for communication between processes or applications. A pair consisting of TCP port and IP address.

    SOM
    Start-of-message code.

    SPC, spc
    Specification file.

    specification file (SPC, spc)
    In LANDP, a file with the file extension .SPC. This file can be edited. It contains information for customization purposes.

    SQL
    Structured query language.

    SSCP
    System services control point.

    start-of-message code (SOM)
    A character or group of characters transmitted by the polled terminal and indicating to other stations on the line that what follows are addresses of stations to receive the answering message.

    storage
    A functional unit into which data can be placed, where it can be retained, and from which it can be retrieved. (T)

    stream
    A continuous sequence of data elements being transmitted, or intended for transmission, in character or binary-digit form, using a defined format.

    structured query language (SQL)
    An established set of statements used to manage information stored in a database. By using these statements, users can add, delete, or update information in a table, request information through a query, and display the results in a report.

    subdirectory
    A directory contained within another directory in a file system hierarchy.

    synchronous
    About two or more processes that depend on the occurrence of a specific event such as common signal timing. Occurring with a regular or predictable time relationship. See also asynchronous.

    synchronous data link control (SDLC)
    A discipline conforming to subsets of the Advanced Data Communication Control Procedures (ADCCP) of the American National Standards Institute (ANSI) and High-level Data Link Control (HDLC) of the International Organization for Standardization, for managing synchronous, code-transparent, serial-by-bit information transfer over a link connection. Transmission exchanges may be duplex or half-duplex over switched or not-switched links. The configuration of the link connection may be point-to-point, multi-point, or loop. (I)

    system diskette
    The diskette, either real or virtual, that contains your control program. In personal computer systems, the diskette on which you have the operating system.

    system distribution manager
    A system that contains the files and programs required for product installation, and initiates or manages the installation process.

    system services control point (SSCP)
    In systems network architecture (SNA), the focal point within an SNA network for managing the configuration, coordinating network operator and problem determination requests, and providing directory support and other session services for end users of the network.

    systems network architecture (SNA)
    The description of the logical structure, formats, protocols, and operational sequences for transmitting information units through and controlling the configuration and operation of networks.

    systems network architecture character string (SCS)
    In systems network architecture (SNA), a character string composed of EBCDIC controls, optionally intermixed with end-user data, that is carried within a request/response unit (RU).

    systems network architecture network (SNA network)
    In systems network architecture (SNA), the part of an application program network that conforms to the formats and protocols of SNA. It allows reliable transfer of data among end users and provides protocols for controlling the resources of various network configurations. The SNA network consists of network addressable units (NAU), boundary function components, and the path control network.

    systems network architecture up-line facility (SNUF)
    The communications support that allows an AS/400 system to communicate with CICS/VS and IMS/VS application programs on a host computer.

    T

    takeover
    In an XLR environment, the process by which a backup server assumes the role of the (failed) active. This involves backing out incomplete transactions, rebuilding indexes, and informing SAM of the new active workstation.

    TCP/IP
    Transmission Control Protocol/Internet Protocol.

    terminal status line
    Synonym for operator information area (OIA).

    TH
    Transmission header.

    thin client
    A client workstation that loads its operating system environment and applications across a network from a server. The degree of local processing power in a thin client can vary considerably depending on the implementation of the thin client concept.

    The term thin client usually refers to a system that runs on a resource-constrained machine or that runs on a small operating system. This clients do not require local system administration, and they execute Java applications delivered over the network.

    Time Sharing Option (TSO)
    An operating system option; for the System/370 system, the option provides interactive time sharing from remote terminals.

    token-ring network
    A ring network that allows unidirectional data transmission between data stations by a token passing procedure, so that the transmitted data returns to the transmitting station. (T) A network that uses a ring topology, where tokens are passed in a circuit from node to node. A node that is ready to send can capture the token and insert data for transmission.

    trace
    A record of the execution of a computer program. It exhibits the sequences in which the instructions were executed. (A) The process of recording the sequence in which the statements in a program are executed and, optionally, the values of the program variables used in the statements. To record a series of events as they occur. For data links, a record of the frames and bytes transmitted or received.

    trace file
    A file that contains a record of events that occur in a system.

    trace function
    A function used for problem determination.

    trace log
    A file in which trace events are recorded.

    trace program
    A computer program that performs a check on another computer program by exhibiting the sequence in which the instructions are executed and, usually, the results of executing the instructions. (I) (A)

    trace routine
    A routine that provides an historical record of specified events in the execution of a computer program. (A)

    transaction
    An exchange between a workstation and another device that accomplishes a particular action or result.

    translation
    Conversion of a code or codes to another code or codes according to a set of specifications.

    transmission
    The sending of data from one place for reception elsewhere. (A)

    Notes:

    1. Transmission implies only the sending of data; the data may or may not be received.

    2. The term transmit is used to describe the sending of data in telecommunication operations. The terms move and transfer are used to describe movement of data in data processing operations.

    transmission control (TC) layer
    The layer within a half-session or session connector that synchronizes and paces session-level data traffic, checks session sequence numbers of requests, and enciphers and deciphers end-user data.

    Transmission Control Protocol (TCP)
    A communications protocol used in the Internet and in any network that follows the US Department of Defense standards for inter-network protocol. TCP provides a reliable host-to-host protocol between hosts in packet-switched communications networks and in interconnected systems of such networks. It assumes that the Internet protocol is the underlying protocol.

    Transmission Control Protocol/Internet Protocol (TCP/IP)
    A set of communication protocols that support peer-to-peer connectivity functions for both local and wide area networks.

    transmission header (TH)
    In systems network architecture (SNA), control information, optionally followed by a basic information unit (BIU) or a BIU segment, that is created and used by path control to route message units and to control their flow within the network.

    transmission services (TS) profile
    In systems network architecture (SNA), a specification in a session activation request (and, optionally in the responses) of transmission control (TC) protocols, such as session-level pacing and the usage of session-level requests, to be supported by a particular session. Each defined TS profile is identified by a number.

    trap
    An unprogrammed conditional jump to a specified address that is automatically activated by hardware. A recording is made of the location from which the jump occurred.

    TRDLC
    Token-ring data link control.

    TS
    Transmission services.

    TSO
    Time Sharing Option.

    U

    UDP
    User Datagram Protocol.

    UNBIND
    In systems network architecture (SNA), a request to deactivate a session between two logical units (LU). Contrast with BIND.

    user
    A function that uses the services provided by a server. A host can be a user and a server at the same time. Any person or any thing that may issue or receive commands and messages to or from the information processing system. (T) Any person who requires the services of a computing system. See also client, client/server, client workstation, and server.

    User Datagram Protocol (UDP)
    In TCP/IP, a packet-level protocol built directly on the Internet protocol layer. UDP is used for application-to-application programs between TCP/IP host systems.

    user profile
    In computer security, a description of a user that includes such information as user identification (ID), user name, password, access authority, and other attributes obtained at log-on.

    user-written server
    In LANDP, a server not supplied with a LANDP program, but developed by the customer.

    utility program
    A computer program which supports computer processes; for example, a sort program. (T) A program designed to perform an everyday task such as copying data from one storage device to another. (A)

    V

    validation
    The checking of data for correctness, or compliance with applicable standards, rules, and conventions. (A)

    VDM
    Virtual DOS machine.

    vector
    A set of keyword=parameter statements that define configuration items. These items can correspond to both model and real configurations.

    verify
    To determine whether a transcription of data or other operation has been accomplished accurately. (A)

    VFS
    Virtual file system.

    virtual DOS machine (VDM)
    A functional simulation of a machine running under DOS.

    virtual file system (VFS)
    A remote file system that has been mounted so that it is accessible to the local user.

    virtual machine (VM)
    A virtual data processing system that seems to be at the exclusive disposal of a particular user, but whose functions are accomplished by sharing the resources of a real data processing system. (T)

    Virtual Telecommunications Access Method (VTAM)
    A set of programs that maintain control of the communication between terminals and application programs running under Disk Operating System/Virtual Storage (DOS/VS), OS/VS1, and OS/VS2 operating systems.

    VisualGen(R)
    A high-level object-oriented programming language.

    VM/CMS
    Virtual machine/conversational monitor system.

    VTAM
    Virtual Telecommunications Access Method.

    W

    WAN
    Wide area network.

    wide area network (WAN)
    A network that provides communication services to a geographical area larger than that served by a local area network.

    WebSphere(TM)
    A comprehensive solution to build, deploy, and manage e-business Web sites. WebSphere is the cornerstone of IBM's overall Web strategy The Websphere product line provides companies with an open, standards-based, Web server deployment platform, together with Web site development and management and management tools to help accelerate the process of moving to e-business.

    window
    A division of a screen where one of several programs being run concurrently can display information.

    workgroup
    In LANDP, the logical connection of LANDP for DOS, LANDP for OS/2, LANDP for Windows NT, and LANDP for AIX workstations through the LANDP client/server mechanism, which is available with each LANDP program.

    Workspace On-Demand
    A set of management utilities that enables OS/2 Warp Server to remotely load a thin client operating system, known as Workspace On-Demand client, into a client workstation across a LAN. The client workstation component of Workspace On-Demand, which is loaded into a client workstation from a server machine running OS/2 Warp Server and Workspace On-Demand Server.

    Workspace On-Demand Server
    A server, running OS/2 Warp Server and Workspace On-Demand, that is used to boot client workstations.

    workstation
    A functional unit at which a user works. In LANDP, personal computer system in a local area network (LAN).

    wrapper
    A language binding.

    X

    X.25
    A CCITT recommendation that defines the physical level (physical layer), link level (data link layer), and packet level (network layer) of the open systems inter-connection (OSI) reference model. An X.25 network is an interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) operating in the packet mode, and connected to public data networks by dedicated circuits. X.25 networks use the connection-mode network service.

    X.25 NCP Packet Switching Interface
    An IBM-licensed program that allows systems network architecture (SNA) users to communicate over packet switched data networks that have interfaces complying with Recommendation X.25 (Geneva 1980) of the International Telegraph and Telephone Consultative Committee (CCITT). It allows SNA programs to communicate with SNA equipment or with non-SNA equipment over such networks.

    XID
    Exchange identification.

    XLR
    External logging replicator.

    XOR
    Logical operation exclusive-or.

    Numerics

    4700 Processor
    IBM Finance Communication System 4701 Controller Model 3 and IBM 4702 Branch Automation Processor, unless otherwise described.

    Appendix J. Bibliography

    This bibliography includes publications cited in this book and other publications on related topics. Where a shortened title is used in the text, the short title is listed after the full title.

    This bibliography also includes books which might now be obsolete.


    IBM LANDP Family

    IBM LANDP Family: Introduction and Planning, GC34-6043. Short title: LANDP Introduction and Planning.

    IBM LANDP Family: Installation and Customization, GC34-6044.Short title: LANDP Installation and Customization.

    IBM LANDP Family:Programming Guide, SC34-6048.Short title: LANDP Programming Guide.

    IBM LANDP Family: Programming Reference, SC34-6045. Short title: LANDP Programming Reference.

    IBM LANDP Family: Servers and System Management, SC34-6046. Short title: LANDP Servers and System Management.

    IBM LANDP Family: Problem Determination, GC34-6047. Short title: LANDP Problem Determination.


    IBM Financial Branch System Services Licensed Programs

    IBM FBSS Licensed Programs Family General Information. GC19-5172.

    IBM FBSS Licensed Programs Family Installation and Customization. SC19-5173.

    IBM FBSS Licensed Programs Family Program Description. SC19-5176.

    IBM FBSS Licensed Programs Family Version 2 Programmer's Reference. GA19-5450.

    IBM FBSS Licensed Programs Family Version 2 Application Programming. SC19-5174.


    IBM Financial Branch System Integrator Licensed Programs

    Financial Branch System Integrator and Financial Branch System Integrator/2 General Information. GC19-5187.

    Financial Branch System Integrator Programmer's Reference Manual. GA19-5452.

    Financial Branch System Integrator/2 Programmer's Reference Manual. SC19-5188.


    IBM Transaction Security System

    IBM Transaction Security System: General Information Manual and Planning Guide. GA34-2137.

    IBM Transaction Security System: Programming Guide and Reference. SC31-2934.


    Banking Self-Service

    IBM 4721 Self-Service Document Printer Programmer's Reference. GA19-5342.

    IBM 4731/38/39 Personal Banking Machines P-Models Software Customization and Programming Reference. GA19-5462.

    IBM 4733 Teller Assist Unit Programmer's Reference. GA19-5425.

    IBM 4737 Self-Service Transaction Station Programmer's Reference. GA19-5408.

    IBM Financial Application Development Toolkit Version 2 Program Description and Operation. SB11-8461.


    IBM workstations

    PC DOS 7 Technical Update. GG24-4459.

    PC DOS 7 User Guide. S83G-9260.

    PC DOS 7 Command Reference. S83G-9309.

    PC DOS 7 Keyboard and Code Pages. S83G-9310.

    IBM TCP/IP Version 2.1.1 for DOS: Installation and Administration. SC31-7047.

    IBM TCP/IP Version 2.1.1 for DOS: User's Guide. SC31-7045.

    IBM TCP/IP Version 2.1.1 for DOS: Programmer's Reference. SC31-7046.

    OS/2 Warp Version 4 Up and Running!. S84H-3098.

    OS/2 Warp Server for e-Business. SG24-5393.

    OS/2 Warp, PM Programming Reference Vol I. G25H-7190.

    OS/2 Warp PM Programming Reference Vol II. G25H-7191.

    OS/2 2.0 Application Design Guide. S10G-6260.

    OS/2 2.0 Virtual Device Driver Reference. S10G-6310.

    DB2/2 Guide. S62G-3663.

    OS/2 LAN Server Network Administration Reference Volume 1: Planning, Installation and Configuration. S10H-9680.

    OS/2 LAN Server Network Administrator Reference Volume 2: Performance Tuning. S10H-9681.

    OS/2 LAN Server Network Administrator Reference Volume 3: Network Administrator Tasks. S10H-9682.

    IBM Systems Application Architecture Common Programming Interface Dialog Reference. SC26-4356.

    IBM Systems Application Architecture Common Programming Interface Presentation Reference. SC26-4359.

    IBM OS/2 Programming Tools and Information V1.3 Programming Guide. S91F-9259.

    TCP/IP for OS/2 Warp Programming Reference, SC31-8407.

    IBM Network SignON Coordinator/2 Getting Started. S96F-8629.


    IBM Local Area Network

    IBM Token-Ring Network: Introduction and Planning Guide. GA27-3677.

    IBM Token-Ring Network: Problem Determination Guide. SX27-3710.

    Local Area Network: Administrator's Guide. GA27-3748.

    IBM PC Network: Technical Reference.

    IBM Personal Computer LAN Support Program.

    IBM Personal Computer Baseband and Broadband.

    IBM Cabling System Planning and Installation Guide. GA27-3361.

    Using the IBM Cabling System with Communication Products. GA27-3620.

    IBM Token-Ring Network Architecture Reference. SC30-3374.

    IBM Local Area Network Technical Reference. SC30-3587.

    IBM Local Area Network Support Program User's Guide. SC21-8288.


    IBM 3270

    IBM 3270 Personal Computer Control Program Programming Guide. SC23-0165.

    IBM 3270 Information Display System Character Set Reference. GA27-2837.

    IBM PC 3270 Emulation Program, Entry Level V2.0 Programmer's Guide. S91F-8583.

    IBM 3270 PC High Level Language API Programming Reference. SC23-2473.

    Personal Communications Version 4.3 Emulator Programming, SC31-8478.


    Wide Area Communications

    SNA Primary Custom Feature Description. GC31-2509.

    Advanced Function for Communications: System Summary. GA27-3099.

    System Network Architecture (SNA) Technical Overview. GC30-3073.

    System Network Architecture (SNA) Format and Protocol Reference Manual. SC30-3112.

    System Network Architecture (SNA) Formats. GA27-3136.

    System Network Architecture (SNA) Format and Protocol Reference Manual: Management Services. SC30-3346.

    System Network Architecture (SNA) Sessions between Logical Units. GC20-1868.

    CCITT X.25 Recommendations, Interface between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks. Vol. VIII. Fascicle VIII.5. This document is useful when writing X.25 applications.

    RT PC X.25 Communication Support User's Guide. SC33-0630.

    X.25 Interface for Attaching SNA Nodes to Packet-Switched Data Network General Information Manual. GA27-3345.

    RT PC X.25 Communications Support Programmer's Reference. SC33-0631.

    IBM Cryptographic Subsystem Concepts and Facilities. GC22-9063.

    IBM X.25 Co-Processor Support Program User's Guide. X07F-8915.

    IBM X.25 Co-Processor Support Program Programmer's Reference. X07F-8916.

    IBM X.25 Interface Co-Processor/2 Technical Reference. S16F-1879.

    SNA Advanced Peer-to-Peer Networking Dependent LU Requester Architecture Reference. SV40-1010.

    Multiprotocol Transport Networking (MPTN) Architecture: Formats. GC31-7074.

    Multiprotocol Transport Networking (MPTN) Architecture: Technical Overview. GC31-7073.

    Telnet Protocol Specification, STD 8, RFC 854, USC/Information Sciences Institute. J. Postel and J. Reynolds .

    To view this book, use the keyword RFC 854 with an internet search engine.

    Printed copies of RFCs are available for a fee from:
    SRI International, Room EJ291
    333 Ravenswood Avenue
    Menlo Park, CA 94025
    (415) 859-3695
    (415) 859-6387
    FAX (415) 859-6028


    IBM NetView

    NetView Distribution Manager: General Information V1.6. GH19-6792.

    NetView Distribution Manager: Planning. SH19-6589.

    NetView Distribution Manager Release 6: Installation and Customization. SH19-6794.

    NetView Distribution Manager: Operation. SH19-6592.

    NetView Distribution Manager: User's Guide V1.6. SH19-6795.

    NetView Distribution Manager: Diagnosis R5. LY19-6374.

    NetView Distribution Manager: Messages and Codes V1.6. SH19-6798.


    IBM Financial I/O Devices

    IBM 4009 Operator's manual. GA19-5650.

    IBM 4009 Service manual/Parts catalogue. SY19-6392.

    IBM 4009 Quick Reference Card. GX11-6316.

    IBM 4009 Customer Setup. GA19-5651.

    IBM 4009 Safety Instructions. GA19-5651.

    IBM 4009 Product and Programming Description (PPD) DOS. SH19-4015.

    IBM 4009 Product and Programming Description (PPD) OS/2. SH19-4038.

    IBM 4700 Finance Communication System Summary. GC31-2016.

    IBM 4700 Financial I/O Planning Guide. GC31-3762.

    IBM 4700 Financial I/O Devices Programming Guide. GC31-3770.

    IBM 4700 Financial I/O Devices Programming Guide for OS/2. GC31-2661.

    IBM 4700 Finance Communication System, Controller Programming Library, Volume 5, Cryptographic Programming. GC31-2070.

    IBM 4700 Financial I/O Devices Operating Guide. SC31-3763.

    IBM 4712 Transaction Printer Models 1, 2, and 3 Reference Card. SC31-3765.

    IBM 4722 Document Printer Model 3 Programming Addendum. GC31-2928.

    IBM 4722 Document Printer Models 1, 2, and 3 Reference Card. SC31-3767.

    IBM 4748 Document Printer Programming Guide. SA34-2090.

    IBM 4748 Document Printer Operating Guide. SA34-2068.

    IBM 4748 Document Printer Service Guide. SA34-2091.

    IBM 4770 Ink Jet Transaction Printer Product Profile. G571-0276.

    IBM 4772 Universal Financial Printer Model 1 Programming Guide. SA34-2199.

    IBM 4772 Universal Financial Printer Model 1 and 2 Installation and Operating Guide. GA34-2192.

    IBM 4772 Universal Financial Printer Model 1 and 2 Reference Card. GX31-2077.

    IBM 4772 Universal Financial Printer Model 1 and 2 Service Guide. SA34-2193.

    IBM 4777 Magnetic Stripe Unit Installation and Operating Guide. GA34-2189.

    IBM 4777 Magnetic Stripe Unit: Programming Guide for OS/2. SA34-2194.

    IBM 4777 Magnetic Stripe Unit: Programming Guide for DOS. SA34-2195.

    IBM 4778 PIN-Pad Magnetic Stripe Reader Installation and Operating Guide. GA34-2190.

    IBM 4778 PIN-Pad Magnetic Stripe Reader: Programming Guide for OS/2. SA34-2196.

    IBM 4778 PIN-Pad Magnetic Stripe Reader: Programming Guide for DOS. SA34-2197.

    IBM 4777 Magnetic Stripe Unit and 4778 PIN-Pad Magnetic Stripe Reader AIX Programming Guide. SA34-2358.

    IBM 9055-001 Document Printer: Planning and Programming Guide. SA18-7496.

    IBM 9055-002 Document Printer: Planning and Programming Guide. SA18-7489.

    IBM 9068-A01/A03 Multi-Purpose Passbook Printer Operating Guide. GA18-7719.

    IBM 9068-A01/A03 Multi-Purpose Passbook Printer Planning and Programming Guide. GA18-7721.

    IBM 9068 Multi-Purpose Passbook Printer Model D01 Planning and Programming Guide. SA18-7505.

    IBM 9068 Multi-Purpose Passbook Printer Model S01 Planning and Programming Guide. SA18-7506.

    IBM 9068-S01 Multi-Purpose Passbook Printer Operating Guide. SA18-7507.

    IBM 9069 Printer Planning and Programming Guide, SA18-7525.

    IBM 9069 Operating Guide, SA18-7524.


    Encryption and Decryption

    IBM Cryptographic Subsystem Concepts and Facilities. GC22-9063.

    IBM 4700 Finance Communication System, Controller Programming Library, Volume 5, Cryptographic Programming. GC31-2070.

    IBM Transaction Security System Workstation Security Services: Installation and Operating Guide. SA34-2141.

    IBM Transaction Security System Concepts and Programming Guide: Volume 1, Access Controls and DES Cryptography. GC31-3937.


    IBM VisualAge C++

    Product web site:

    http://www.ibm.com/software/ad/vacpp/
    

    IBM VisualAge Generator

    Product web site:

    http://www.ibm.com/software/ad/visgen/
    

    IBM Redbook:

    VisualAge Generator Version 3.1 System Development Guide, SG24-4230-02


    IBM VisualAge Smalltalk

    Product web site:

    http://www.ibm.com/software/ad/smalltalk/
    

    IBM Redbooks:

    VisualAge for Smalltalk Handbook - Volume 1: Fundamentals, SG24-4828-00

    VisualAge for Smalltalk Handbook - Volume 2: Features, SG24-2219-00


    Java

    IBM Java web site:

    http://www.ibm.com/software/java/
    

    IBM VisualAge for Java product web site:

    http://www.ibm.com/software/ad/vajava/
    

    IBM developerworks web site:

    http://www.ibm.com/software/developer/java/
    

    IBM VisualAge Developers Domain web site:

    http://www.ibm.com/software/vadd/
    

    IBM Redbooks:

    Programming with VisualAge for Java Version 2, SG24-5624

    Application Development with VisualAge for Java Enterprise, SG24-5081


    IBM Personal Communications

    Personal Communications AS/400 and 3270 for OS/2 Up and Running, SC31-8258.

    Personal Communications AS/400 and 3270 for Windows NT Up and Running, GC31-8314.

    Personal Communications/3270 Programmer's Guide for DOS (Entry Level), S20H-1774.

    Personal Communications/3270 Programmer's Guide for OS/2, S85G-8681.

    Personal Communications/3270 Reference Guide for OS/2, S85G-8721.

    Personal Communications Version 4.3 for Windows 98 and Windows NT Reference, Volumes 1 and 2 , SC31-8682, SC31-8680.

    Personal Communications Windows NT Quick Beginnings, GC31-8679.


    IBM Communications Server

    IBM Communications Server for OS/2 Warp Quick Beginnings, GC31-8189.

    IBM Communications Server for Windows NT Quick Beginnings, GC31-8424.

    eIBM Network Communications Server for OS/2 Guide to AnyNet, GC31-8193, GC31-8320


    WorkSpace On-Demand

    WorkSpace On-Demand Road Map Release 2.0, SG24-5117

    WorkSpace On-Demand Handbook Release 2.0, SG24-5117

    WorkSpace On-Demand Handbook (Release 1), SG24-2028

    WorkSpace On-Demand Early Customer Experiences, SG24-5107

    IBM Up and Running! OS/2 Warp Server, S25H-8004

    WorkSpace On-Demand Administrator's Guide.,, on the web at www.ibm.com/software/network/workspace/library


    MQSeries

    MQSeries for Windows NT and Windows 2000 Quick Beginnings, GC34-5389

    MQSeries for OS/Warp Quick Beginnings, GC33-1868

    MQSeries Planning Guide, GC33-1349

    MQSeries Intercommunication, SC33-1872

    MQSeries Clients, GC33-1632

    MQSeries System Administration, SC33-1873

    MQSeries Command Reference, SC33-1369

    MQSeries Programmable System Management, SC33-1482

    MQSeries Messages, GC33-1876

    MQSeries Application Programming Guide, SC33-0807

    MQSeries Application Programming Reference, SC33-1673

    MQSeries Using C++, SC33-1877



    Appendix . Index

    Special Characters
    Numerics
    A B C D E F G H I J K L M N O P Q R S T U V W X Y
    Special Characters Numerics A B C D E F G H I J K L M N O P Q R S T U V W X Y

    Appendix K. Sending your comments to IBM

    If you especially like or dislike anything about this book, please use one of the methods listed below to send your comments to IBM(R).

    Feel free to comment on what you regard as specific errors or omissions, and on the accuracy, organization, subject matter, or completeness of this book.

    Please limit your comments to the information in this book and the way in which the information is presented.

    To make comments about the functions of IBM products or systems, talk to your IBM representative or to your IBM authorized remarketer.

    When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in any way it believes appropriate, without incurring any obligation to you.

    You can send your comments to IBM in any of the following ways:

    Whichever method you use, ensure that you include:

     


    Footnotes:

    1
    X.25 is a CCITT standard for packet switching networks.

    2
    This information is available in multiple languages. Contact your IBM representative for ordering information.