Unisys. Enterprise Application Developer. Installation and Configuration Guide. Release 3.3. Copyright 2003 Unisys Corporation. All rights reserved.

Transcription

1 Enterprise Application Developer Installation and Configuration Guide Unisys Copyright 2003 Unisys Corporation. All rights reserved. Release 3.3 March

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to Government End Users: The software and accompanying documentation are delivered and licensed as commercial computer software and commercial computer software documentation as those terms are used in 48 C.F.R and 48 C.F.R through , as applicable. The Government shall receive only those rights provided in the standard commercial software license, or where applicable, the restricted and limited rights provisions of the contract FAR or DFARS (or equivalent agency) clause. Correspondence regarding this publication should be forwarded to Unisys Corporation by addressing remarks to Product Information, Australian Centre for Unisys Software, Locked Bag 3111, Rhodes, NSW 2138, Australia. Comments about documentation can also be sent through to [email protected]. All terms which may be mentioned in this document that are known to be trademarks or service marks have been appropriately capitalized. Unisys Corporation cannot attest to the accuracy of this information. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Unisys, LINC, INFOConnect, ClearPath, and PowerClient are registered trademarks, and Griffin is a trademark of Unisys Corporation. EPSON is a registered trademark of Seiko Epson Corporation. IBM, AIX and RS/6000 are registered trademarks of International Business Machines Corporation. JADE is a trademark of Aoraki Corporation Limited. Micro Focus and Net Express are registered trademarks of Merant International Limited. Microsoft, Windows, Visual Basic, and Internet Explorer are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. ORACLE and SQL*Plus are registered trademarks of Oracle Corporation. SPARC is a registered trademark of SPARC International, Inc. Products bearing SPARC trademarks are based on an architecture developed by Sun Microsystems, Inc. SQL Server is a trademark of Sybase, Inc. or its subsidiaries Sun, Java and Solaris are registered trademarks of Sun Microsystems, Inc. in the United States and other countries. UNIX is a registered trademark in the U.S. and other countries, licensed exclusively through X/Open Company, Ltd. UnixWare is a registered trademark of The Santa Cruz Operation, Inc.

3 Contents Section 1. Introduction About This Guide Purpose Audience Section 2. Developer Overview About Developer Designing and Developing Systems Testing Systems Developer Software Developer Modules Required Software Configuration Windows 2000 Compatibility Problem Reporting Section 3. Developer Installation Selecting the User Mode Single User Mode Multiuser Mode Hardware Requirements Stand-alone Workstations Multi-user Environment For Developer Repository For Developer Test Database Software Requirements Enterprise Application Environment Software Essential Enterprise Application Environment Software Optional Enterprise Application Environment Software Preparing Your Network for Developer Transport Protocols Disk Locations Number of Network Locks Access Rights to Drives, Directories, and Files Installing Developer Software Setting Access Rights Unisys Installation Interface Developer Using the Administrator Option Preventing IC Incompatibilities with Runtime for Windows Installation Options after an Administrator Installation Typical Installation iii

4 Contents Custom Installation Network Installation Permission Problems Installing the Developer Server Installing Developer on a Client Workstation Locating the Developer Test Database Installing the Developer Repository Installing Developer with Windows Terminal Services What are Terminal Services? Recommended Configuration Requirements for a Terminal Services Installation Installation Procedure Known Issues with Developer with Windows Terminal Services Verifying Your Installation Summary Section 4. Migrating from an Earlier Release of Developer Migrating Your Developer Repository Extract and load Get from Version Control Bank Automatic upgrade Migrating Your Developer Security Database Migrating Your Version Control Bank Meeting the Hardware Requirements For Builder For Developer Version Control Summary Section 5. Developer Configuration Understanding Configuration Parameters Optimizing Memory Usage Initialization Files Setting the TEMP Environmental Variable Facts about the Working Directory Setting up a Single User Configuration Developer Test Database Configuring a Single User Installation Setting up a Multiuser Configuration Locating the Developer Test Database When the Repository is on the Developer Server When the Repository is on the LAN File Server Configuring a Multiuser Environment Developer Shortcut Properties Setting up Multiple Repositories Switching Between Single User and Multiuser Modes Summary Appendix A. Related Product Information... A 1 iv

5 Section 1 Introduction About This Guide Purpose This document is a guide for installing and configuring Enterprise Application Developer in standalone or network environments. Audience This document is primarily for those who install Developer, either on a single workstation or on a network. It is also useful for system administrators and new users of Developer

6 Introduction

7 Section 2 Developer Overview This section provides an overview of the Enterprise Application Developer software. The topics that are covered are: About Developer Developer Software Problem Reporting About Developer Developer is an Enterprise Application development environment for Windows workstations, independent of host systems. Developer integrates into a single environment the facilities to design, develop, and unit-test systems, in either single user or multiuser environments. Designing and Developing Systems The graphical capabilities of Developer enable you to create high-level graphical models of your business systems. You can then expand your design by adding screen and report layouts using Painter, and turning Business Rules into logic using the Developer Logic Editor. If you are reverse-engineering a host Specification, Developer enables you to recover and analyze the design of the system with the Design Audit facility. By using Developer's Function Point Analysis, you can estimate your system complexity and cost. See your Unisys Enterprise Application Developer User Guide for details of these design and development features. Testing Systems You can unit-test your system using Developer Test, which includes a logic debugging component. Developer Test can also be used to evaluate your evolving system, enabling you to incorporate changes during the development phase of building an application. See your Unisys Enterprise Application Developer User Guide for details of these testing features

8 Developer Overview Developer Software Developer Modules Developer can be installed standalone on a workstation, or as a network installation with shared components. All installation types are detailed in this document. When you are installing Developer, it appears as the following software modules: Developer Module Developer Test Developer Security Developer Version Control Builder Graphical Interface Workbench Utilities Developer Repository Developer Server Version Control Server Description Enables you to design, develop and analyze Enterprise Application systems. Functionality includes a logic editor, logic validation, and a screen painter. All development data is stored in the Developer Repository. Interprets: The implementation according to the target host selected for the Business Segment The definition of the Business Segment held in the Developer Repository Controls access to operations and objects in the Developer Repository accessed by Developer and Developer Test. It does not affect security on host systems. Provides integrated support for versioning objects from within Developer. Note: Developer Version Control is sold separately. Enables you to generate and deploy a Runtime system for a Windows, UNIX, OS2200, or MCP based target host directly from your Developer environment. Moves graphical mode screens between Developer and Graphical Interface Workbench. To use this, Graphical Interface Workbench must be running on the same workstation as Developer. Holds definitions of Business Segments; handles multiple users with locking, recovery, and synchronization; is maintained by Developer; is interpreted by Developer Test; and provides the interface to host Builder. Controls all interactions with the repository in a multiple-user Developer environment. Installs the Unisys Universal Repository (UREP), the underlying repository for the Version Control Server, which supports the Version Control bank(s). Note: You need an installation key to install Developer Version Control. All application files can be stored and run from a shared directory

9 Developer Overview Required Software Configuration The software configuration required for Developer client workstations, the Developer Server, and the network file server (if used) is detailed in the table below. Required Item Windows 2000 TCP/IP transport protocol File transfer utility such as FTP, INFOConnect utilities or FileExpress Comments Usually Windows Server is used for Developer Server, however Windows 2000 Professional can also be used, providing the workstation meets the minimum requirements for Developer Server. The only limitation is that Developer Server cannot be registered as a Windows Service due to the dependence on the computer browser running on the workstation. See also the section below regarding Windows 2000 Compatibility. Mandatory if using a multiuser repository, optional for single user. Note that NetBIOS is not supported by Developer. Required for transferring files to and from host systems. Note: For Builder, you must use FTP as the file transfer mechanism. Builder uses FTP to automatically transfer source files from the Developer workstation (where they were generated) to the target host (where they will be compiled and deployed). Windows 2000 Compatibility Developer software is qualified on the following Windows operating systems: Windows 2000 Professional (Service Pack 1) for single users Windows 2000 Server Windows 2000 Advanced Server Windows 2000 Datacenter Server Please note the following requirements: Runtime for Windows Operating Systems and Builder Server for Windows Operating Systems require Windows 2000 Server when using the SQL Server database. Terminal Server requires Windows 2000 Server Problem Reporting Because Developer relies on the underlying operating system and network software, details of the environment are vital to the resolution of problems. When reporting problems, please ensure the following information is supplied: The operating system and version number used on the Developer workstations and the Developer Server, for example, Windows 2000 Professional

10 Developer Overview All networking software and versions, the network server software and level, and the workstation / Developer Server client software and version. Where the repository is located and how the Developer workstation or Developer Server accesses the repository. Where the Developer Test database is located and how the Developer workstations access the database. The following configuration files: JADE.INI LINC.INI Error and log files

11 Section 3 Developer Installation This section describes how to install Developer. The topics that are covered are: Selecting the User Mode Hardware Requirements Software Requirements Preparing Your Network for Developer Installing Developer Software Installation Options after an Administrator Installation Installing the Developer Server Installing Developer on a Client Workstation Locating the Developer Test Database Installing the Developer Repository Installing Developer with Windows Terminal Services Verifying Your Installation Selecting the User Mode Single User Mode In single user mode of Developer, each user has sole access to a Developer Repository stored on that user's local hard disk or on a shared drive. Developer with a single user Repository is the simplest configuration to install and manage. You may wish to use this mode when you first start using Developer. After your users are more familiar with how Developer interacts with the Repository, you may consider switching to multiuser mode. For details on switching to multiuser mode see Switching Between Single User and Multiuser Modes on page Multiuser Mode In multiuser mode of Developer, the Repository is shared between a group of users. The Repository can be located on the Developer Server or on a network file server

12 Developer Installation Hardware Requirements Enterprise Application Developer can be installed either on stand-alone workstations or on a server, for use by multiple users. Requirements for each configuration option are described below. The hardware requirements for the Version Control Server are listed separately, as it is often located on a dedicated machine. If the Developer Server and Version Control Server software is on the same machine, the machine will need to be considerably larger than specified for either product. Note: The Developer Test database must be located where it can be accessed by all the workstations, preferably at each Developer workstation, although the LAN file server or the Developer Server may also be used. Stand-alone Workstations Developer is an I/O intensive application because all objects are stored in the Repository and updated constantly as each object changes. Windows is also I/O intensive when all applications cannot reside in memory. This means that disk transfer rates are a critical factor in workstation performance. Faster disk drives and increased RAM will provide performance benefits. These workstation recommendations apply to both the development and the testing environments (i.e. Developer and Developer Test). A Test only workstation will access the Test database more often than a client workstation used for development but the basic requirements remain unchanged. The following table shows the hardware requirements for a workstation in a single user environment when Developer (Server and Client) is installed, either on its own, or together with Builder (Client) or Version Control (Client). Hardware Developer Developer and Builder Developer and Version Control Client Processor Pentium II 200 MHz Pentium II 200 MHz 400 MHz RAM 128 MB 128 MB 128 MB Disk space* 500 MB 500 MB 500 MB Other SVGA monitor CD-ROM drive ISO 9660 format SVGA monitor CD-ROM drive ISO 9660 format Paging file 300 MB SVGA monitor CD-ROM drive ISO 9660 format Paging file 300 MB Network Speed 100 Mbps

13 Developer Installation * Additional disk space is required if the repository is stored on this machine. The required space will vary depending on the size and complexity of the system. Note: The only limitation that exists when the Developer Server software is installed on a workstation is that it cannot be registered as a service. This is due to the dependence on the Computer Browser running on the workstation. Multi-user Environment The hardware requirements for the Developer Server and workstations in a multi-user environment are described below. Developer Server Hardware Requirements The Developer Server should be the most powerful machine in a multi-user environment, as it controls all interactions with the Developer Repository. You should consider upgrading your Developer Server to a faster Pentium with more RAM than recommended, if: You will have a large number of users accessing the Repository. You intend to locate the Repository on the same machine as the Developer Server. You are developing a large system (for example 300 or more Ispecs) and you are using one multiuser Repository. The following table shows the hardware requirements for the Developer Server in a multiuser environment, where Developer (Server) is installed either on its own, or together with Builder (Client). Hardware Developer only Developer and Builder Processor Pentium II 300 MHz Pentium II 300 MHz RAM 128 MB 128 MB Disk space* 500 MB 500 MB Paging file Not required 300 MB Other SVGA monitor CD-ROM drive ISO 9660 format 10 MB LAN card SVGA monitor CD-ROM drive ISO 9660 format * Additional disk space is required if the Developer Repositories are on this machine. The required space will vary depending on the size and complexity of the system

14 Developer Installation Developer Workstation Hardware Requirements The following table lists the hardware requirements for the Developer workstation in a multi-user environment, where Developer (Client) is installed either on its own, or together with Builder (Client) or Version Control (Client). Note: If you want to install Developer, Builder client and Version Control client on the same workstation, use the requirements listed in the Developer and Version Control Client column of this table. Hardware Developer only Developer and Builder Developer and Version Control Client Processor Pentium II 200 MHz Pentium II 300 MHz Pentium II 400 MHz RAM 128 MB 128 MB 128 MB Disk space* 500 MB 500 MB 500 MB Paging file Not required 300 MB 300 MB Other SVGA monitor CD-ROM drive ISO 9660 format 10 MB LAN card SVGA monitor CD-ROM drive ISO 9660 format SVGA monitor CD-ROM drive ISO 9660 format * Additional disk space is required if the Developer Repositories are on this machine. The required space will vary depending on the size and complexity of the system. Note: If you use a modem for Internet access, performance in multi-user mode may be slow. If automatic dialling is enabled for your modem, automatic dialling will be initiated when any component of Developer is started in multi-user mode. This will severely impact the speed of access to the repository. You should modify your modem settings to disable automatic dialling. To do this, open the Control Panel and select Internet options. In the Connection options, ensure automatic dialling is not set. For Developer Repository The disk space required for the Repository depends on the size of the Specification being developed. This includes the number of Ispecs, Reports, lines of logic, and Global Logics. In general, a fully validated Repository will be between four to eight times the size of the original trimmed model file. ('Trimmed' means that trailing spaces on the LCIF file have been suppressed.) For small to medium size systems, 130MB should provide enough space to allow for growth. To estimate your disk usage requirements use the following guidelines: For small to medium sized systems (for example, less than 1000 objects objects include Ispecs, Profiles, Global Logics, and Reports; but not the Dictionary), multiply the number of objects by 100KB

15 Developer Installation For larger systems (for example, more than 1000 objects), use a multiplier of 200KB. Note: This will produce a rough estimate only. There is no method of accurately predicting the size of a Repository. For Developer Test Database Developer Test, which has its own database, requires enough disk space for all the Ispecs and Reports in your systems, as well as enough free space (for reorganizations) to accommodate a second copy of the largest dataset in your system. Software Requirements The following table lists the software requirements for Developer, Builder, and Version Control. Software Operating system Comms protocols and services File transfer utility Platform-specific software (required if Builder is installed) Requirement Windows 2000 operating systems: Windows 2000 Professional (Service Pack 1), for single users Windows 2000 Server Windows 2000 Advanced Server, for multi-users Windows 2000 DataCenter TCP/IP and Printing Services (mandatory if you use a multi-user Repository, and for a single-user setup if a LAN file server is used) RPC Services Internet Information Server (IIS) or Peer Web Services (PWS) FTP UNIX platforms support for standard UNIX character mode terminals ClearPath OS 2200 CMS R4A or Communications Platform ClearPath MCP Transaction Server Transaction Server Language Support Heritage Network Services, TCP, or OSI as a comms network protocol Other Internet Explorer 6.0 Optional Output Manager Release 5R1 or higher

16 Developer Installation Enterprise Application Environment Software Essential Enterprise Application Environment Software Due to the inter-relationships between the components of the Enterprise Application Environment, the Runtime Release 3.3 software for the target host platform is required to generate and deploy an Enterprise Application Environment system. Optional Enterprise Application Environment Software The following optional software is available for testing and viewing your Enterprise Application Environment systems. You can use these products to web-enable and provide remote access to a Runtime system: Component Enabler Release 3.3 Presentation Client Release 3.3 ASP Generator Release 3.3 ASP Generator Customization Kit Release 3.3 Visual Basic Generator Release 3.3 These products are provided on the Enterprise Application Client Tools Release 3.3 CD- ROM. Preparing Your Network for Developer Network traffic can be a significant factor in the overall performance of Developer with a multiuser Repository. Before installing Developer, you should tune your network to minimize traffic congestion. This will ensure that your network handles the interaction between Developer and the Repository to provide optimum performance. Transport Protocols In multiuser mode, workstations use a single Developer Repository managed by the Developer Server. Developer supports your selection of transport protocol provided the Developer Server and client workstations use the same TCP/IP protocol

17 Developer Installation For Windows Operating Systems The Windows software controls whether a file is actually closed on the server in order to optimize response time for repeated open and close operations performed by clients. However, this optimization can cause a problem mapping network disks to a server or workstation, affecting Developer Test database operation and causing file sharing violations. You must disable this optimization feature if you intend to use multiuser Developer Test. To do this, set the Registry parameter CachedOpenLimit to zero for the server and for all Windows clients, as follows: 1. Start Registry Editor (REGEDT32.EXE). 2. Find the following key: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanServer\Parameters 3. With \Parameters selected, do an Edit, Add Value, and then enter: Value Name: CachedOpenLimit Data Type: REG_DWORD The Data should be 0 (zero). 4. Exit the registry. 5. Shutdown and restart Windows. Caution You should only use the Registry Editor if you are an experienced system administrator. Incorrect use of the Registry Editor can cause serious problems. Disk Locations If the Developer Repository and Test databases are stored on a network disk, the underlying network software becomes a factor in the performance and integrity of the Repository or database. Number of Network Locks The network lock parameters control: The number of open files on each workstation The number of open files the network operating system can handle The number of record locks for each workstation The total number of record locks

18 Developer Installation The lock parameters prevent more than one user from updating the same data, thereby protecting the integrity of the data: File locking ensures that a file is correctly updated before another user can access it. Record locking prevents different users from gaining access to the same record in a shared file. Windows Operating Systems Under Windows operating systems, the number of locks is set dynamically. Novell LAN In a multiuser environment with the Developer Test database located on a Novell LAN, your network administrator sets the number of locks permitted by the network. When calculating the number of locks for non-integrity systems, only records being written require locks. For integrity systems your calculation must include both read and written records. You should set the maximum number of record locks high enough to cover the maximum number of records that might be locked by your largest Developer Test Report. The maximum number or record locks that you can set on a Novell LAN is 10,000. Note: If the Report is unable to lock the required number of records, the file server will hang or crash. Access Rights to Drives, Directories, and Files In a single user environment, you must give each user full read and write access rights to the drive and directory in which that user's Developer Repository is located. In a multiuser environment, the Developer Server requires full read and write access rights to the drive and directory in which the Developer Repository is located. The users do not require access to the Repository or Repository machine. All users must have read and write access rights to their nominated working directories. Access to Font Files All users must have read and execute access to the fonts that Developer uses. This is necessary in order to correctly display the fonts used in the Painter and the Logic Editor, and for creating Help screens. Developer uses these fonts: LINCDEFAULT, LINCDEFAULTNEW, and LINCDEFAULTNEWBOLD. These fonts are stored in the directory \WINNT\FONTS. LINC.INI The LINC.INI initialization file sets global parameters that govern the behavior of your Developer system

19 Developer Installation By default, during installation, the LINC.INI file is put into the working directory. You can install the LINC.INI file in any directory on any machine as long as Developer can reference it when starting up. You can choose whether your users share a single LINC.INI file or have individual LINC.INI files. Single LINC.INI file Individual LINC.INI files Using a single LINC.INI file will provide a uniform environment for all users for the following attributes: Developer Server name Painter settings Printer settings Developer Test test environment settings Language Colors for graphs, matrixes, text, and security Startup screen Parameters for locks Search settings Reports DEPCON Report settings Fonts When one user changes a LINC.INI parameter, the change affects all other users. The single LINC.INI file can specify the path to the Repository (REPOSPATH parameter) and all users point the command line of their Developer shortcuts to this LINC.INI file. Using individual LINC.INI files gives each user an opportunity to define individual attributes. Your users can use the LINC.INI file to point to the Repository or they can specify the path to the Repository on the command line of the Developer shortcuts. Installing Developer Software Setting Access Rights If the Developer installation process attempts to overwrite a system file and detects that you do not have Administrator access rights, an error message will be displayed and the installation process will exit. Windows operating system access rights are set by the User Manager program. This can be accessed by clicking the Start menu and going to Programs, and then Administrative Tools (Common). If you are unable to set Windows operating system access rights, see the System Administrator for your site. Note: If the Developer installation process finds system files that need updating, you will be prompted to reboot your machine before running Developer

20 Developer Installation Unisys Installation Interface When you insert the Developer CD-ROM into your CD-ROM drive and run the file setup.exe, the Unisys Installation Interface is displayed. This interface controls the installation process. The following options are available: Developer Select this option to access the Developer installation program. The following subsections provide more information about the Developer installation process. VC Server Select this option to access the Version Control Server installation program. For more details about Version Control Server installation, see your Unisys Enterprise Application Developer Version Control Guide. Documentation Select this option to view the Developer documentation. The Product Information Contents window is displayed. Select the document you require to open it. The documentation is in Portable Document Format (PDF), and you must have Adobe Acrobat Reader 3.0 or later to view it. If you do not have Acrobat Reader installed, selecting a document from the Contents window will automatically start the installation of Acrobat Reader 4.05 with Search. View Readme Select this option to view the CD Readme.txt file. Exit Select this option to exit the Installation Interface. Developer When you select the Developer option from the Installation Interface, the Developer installation process starts. After the welcome and license screens, the Setup screen is displayed with the following options: 1. Administrator 2. Custom 3. Developer Server 4. Typical See the following subsection On a Standalone Workstation for details on the Typical and Custom options. See Using the Administrator Option on page 3 11 and Installing the Developer Server on page 3 16 for details on the Administrator and Developer Server options

21 Developer Installation On a Standalone Workstation A Typical or Custom installation from a CD-ROM to a standalone workstation is unlikely in a typical Developer environment. In most cases you are far more likely to install Developer on individual workstations after you have performed an Administrator Installation from the CD-ROM. To install Developer on a workstation that is not part of a network (standalone): 1. From the Enterprise Application Developer Installation screen of the Developer installation, select one of the following options and click Next: Typical if you want to install Developer, Developer Test, and Developer Repository. Custom if you want to select the components for installation. See Custom Installation on page 3 14 for an explanation of the custom components. If you select Custom, the Select Component screen is displayed. Select the components you want to install and the default installation directory in the Destination Folder field. If you want to check the disk space on your other drives, select the Disk Space button. Click Next to continue. 2. The Installation Configuration screen is displayed with default paths for the Installation, Working, and Repository directories. 3. Enter new paths if you do not want to use the defaults and click Next. The Select Program Folder screen is displayed. 4. Accept the default program folder by clicking Next, or change the default and then click Next. 5. Check your settings when the confirmation screen appears. 6. Click Back to change settings, or Next to initiate the installation task. Using the Administrator Option If you have a group of users using Developer, as the first step, you should perform an Administrator installation from the CD-ROM. Basically, the Administrator installation loads the Developer software to the network. You can then install all Developer components from the network to individual workstations. The exception is the Version Control Server. This can only be installed from the CD-ROM. See the Unisys Enterprise Application Developer Version Control Guide for details. For an Administrator installation, you will need at least 72MB on the target network drive. Before you install To ensure users have access to the necessary files to install the Developer components on individual workstations, perform the following steps before you start an Administrator installation: 1. From the Control Panel, double-click System

22 Developer Installation 2. On the Advanced tab, click Environment variables. 3. Note the directory value of the TEMP user variable. 4. Open Windows Explorer and locate the directory. 5. Right-click the directory and select Properties. 6. On the Security tab, click Add. add Everyone to the Names list. 7. Select Everyone and click Add. 8. Click OK. 9. Ensure Allow inheritable permissions from parent to propagate to this object is checked. 10. Click OK. Administrator installation Follow the steps below to perform an Administrator Installation. 1. Ensure that you have write access to the network directory into which you are loading the Developer software. 2. Log into a workstation using your Network Administrator account. 3. From the Enterprise Application Developer Installation screen, select Administrator and click Next. The Installation Configuration screen is displayed. Only the Installation directory field is enabled. 4. Specify the drive and directory to which you want to load the software for subsequent installation. You can either type the full pathname or browse for it. The installation drive and directory must be visible to all the workstations on which you will subsequently install Developer. You may want to set read-only access to the directory for user accounts. 5. Review your selection settings when the confirmation screen appears. 6. Click Next to decompress the contents of the CD-ROM and load them to the installation directory. Preventing IC Incompatibilities with Runtime for Windows Runtime for Windows Environments of different IC or minor levels can coexist on the same machine. This may lead to incompatibilities between Runtime and Developer if the IC levels are not the same. Later releases of Developer may require a particular IC level to be compatible with Runtime for Windows

23 Developer Installation When you attempt to generate a System to the environment you have specified in the Generate System Dialog Box: If the server environment version is compatible with the client version, the generate is successful. If the server environment version is not compatible with the client version, an error message is displayed in the Builder Client window, and the generate will not be initiated. You will need to upgrade your Runtime environment to the appropriate IC level. Installation Options after an Administrator Installation After you have performed an Administrator installation from the Developer CD-ROM, you can install components of Developer software on individual workstations from the network directory. To install from the network directory use Explorer to locate the setup.exe in the installation directory and double-click. Four installation options are available: Custom Developer Server Network Typical Typical Installation Choose this option to install Developer, Developer Test, and the Developer Repository on each client workstation in a single user environment. See Installing Developer on a Client Workstation on page 3 17 for steps to follow for a Typical installation

24 Developer Installation Custom Installation Choose this option to select individual or additional components to install. Options that are not included in the Typical install are: Developer Security Typically you would only install the Security module on workstations used by people with administrative rights to the development project. Users without these rights cannot use this application. The Security module requires some library files that are only installed with Developer. If you select to install the Security module, Developer will automatically be checked and the option disabled, forcing Developer to be installed. Graphical Interface Workbench Utilities This option installs the utilities Graphical Interface Workbench to Developer and Developer to Graphical Interface Workbench. You can install these utilities if you have already installed a Developer Repository and Graphical Interface Workbench. Version Control Client You can install the Developer Version Control Client if you have the appropriate license, the Version Control Server installed, and meet the hardware / software requirements. Builder You can install the Builder Client if you have met the hardware / software requirements. Developer Test Remote Server Select this option to install the Enterprise Application Remote Access server with Developer Test. When combined with Component Enabler, the Remote Access server in conjunction with Developer Test creates a complete development and testing environment. See your Unisys Enterprise Application Developer User Guide for details. Online Documentation This option installs all the Developer documentation, in Portable Document Format (PDF). You must have Adobe Acrobat Reader to view the documentation. If you do not have Acrobat Reader, the Acrobat Reader installation process will begin at the end of the Developer install. See Installing Developer on a Client Workstation on page 3 17 for steps to follow for a Custom installation. Network Installation When you choose the network option, Developer executables are not installed on your local hard drive. The network option creates shortcuts to Developer components already installed on network drive during the Administrator installation. The shortcuts are placed into the startup program folder

25 Developer Installation You may also use the network option to: Install a new Developer Repository in a directory that you specify during the process. Create a new working directory and LINC.INI file with settings specified for the network installation. Note: A Network installation will save you local hard disk space but you will notice performance degradation. The steps for performing a network install are: 1. From the Enterprise Application Developer Installation screen of the Administrator Install, select Network and click Next. The Select Component screen is displayed. 2. Select the components you want to install and the default installation directory in the Destination Folder field. If you want to check the disk space on your other drives, select the Disk Space button. Click Next to continue. If you have selected to install the Developer Version Control Client, the Enter Licensing Information screen is displayed. Enter the required license information and click Next. The Installation Configuration screen is displayed with default paths for Working and Repository directories. Because the Installation directory already exists on the network drive, the Installation directory field for Developer software is disabled. 3. Enter new paths if you do not want to use the defaults and click Next. The Select Program Folder screen is displayed. 4. Accept the default program folder by clicking Next, or change the default and then click Next. 5. Check your settings when the confirmation screen appears, and click Next. The installation process is initiated. Shortcuts to the selected components will be placed in the program folder. Permission Problems If permission problems are encountered when trying to install Developer from an Administrator installation, perform the following: 1. Select all the files in the Administrator installation directory. Do not select the subfolders. 2. Right-click and select Properties. 3. Click the Security tab. A message is displayed, which states that the permissions cannot be displayed because several files have different settings. 4. Click Yes to reset the permissions on all files. The security permissions for all files are set to Everyone

26 Developer Installation Installing the Developer Server To install the Developer Server: 1. Boot the workstation to the Windows operating system and log on. You should use the Administrator account to perform the installation. 2. Using Explorer, locate setup.exe: If you are performing the Server installation after an Administrator installation, all the required files, including the setup.exe, are located in the Installation directory on the network drive. If you are installing from CD-ROM, insert the CD-ROM into your CD-ROM drive, and locate the setup.exe on the CD-ROM. 3. Double-click setup.exe. If you are running setup.exe from the CD-ROM, select the Developer option from the Unisys Installation Interface. After the Welcome and license screens, the Enterprise Application Developer Installation screen is displayed. 4. Select Developer Server and click Next. The Installation Configuration screen is displayed. 5. Specify the drive and the Installation directory for the Developer software and the Developer Repository. You can either type the full pathname or browse for it. When choosing the installation directory, consider the following: Place the Developer software on a local drive. Performance will be degraded if you install to a network drive. You must specify the Installation directory. The Repository directory specifies the location of the repository files. If a Repository does not exist, you will be asked to create one. You must specify a Repository directory. 6. Specify the machine name for the Developer Server. For a local Developer Monitor to identify the server, the server machine name must be given. This updates the ServerNode parameter in the JadeClient section of JADE.INI. After installation, you may want to change the name used in the title bar of the Developer Server to something more meaningful. To do this, change the NodeName parameter in the JadeServer section of JADE.INI. 7. When you have selected your installation directory and Server machine name, click Next. The Select Program Folder screen appears. 8. Click Next. The program folder defaults to Developer Server. 9. Check your settings when the confirmation screen appears. 10. Click Next to proceed with the installation or Back to change settings

27 Developer Installation Installing Developer on a Client Workstation Developer workstation installation applies to both single and multiuser mode. Depending on which Developer components you install, you will need at least 73MB of hard disk space on the client workstation drive. If you intend running Developer in multiuser mode: You should have a dedicated Developer Server workstation. You should install the Developer Server before installing Developer on the client workstations. You should install the Developer Repository before installing Developer on the client workstations. During the installation of Developer on the client workstation, you will be required to enter the names and locations of the Developer Server and Repository. If you have not already installed the Server and Repository before the installing Developer, you can edit each individual LINC.INI file on each workstation after you have installed Developer. It is, however, easier and more reliable to specify these details during the installation process. The steps to install Developer on a client workstation are: 1. Log on to the workstation. (Use a userid that has write access to the local drive.) 2. Use Explorer to locate setup.exe. If you are installing after an Administrator installation, all the required files, including the setup.exe, are located in the Installation directory on the network drive. If you are installing from CD-ROM, insert the CD-ROM into the CD-ROM drive on the workstation and locate the setup.exe on the CD-ROM. 3. Double-click setup.exe. If you are running setup.exe from the CD-ROM, select the Developer option from the Unisys Installation Interface. After the Welcome and license screens, the Enterprise Application Developer Installation screen is displayed. 4. Choose the appropriate installation type by selecting either Typical or Custom and click Next. If you have already installed the Developer Server and the Repository, select the Custom button. On the list of Components displayed, de-select Developer Repository as you have already installed it. Note: Typical and Custom are the only valid options when installing Developer on a client workstation. If you chose Custom install and selected Developer Version Control Client for installation, then the Enter Licensing information dialog box is displayed. Enter the required license key in the relevant field

28 Developer Installation 5. Click Next. If you selected the Version Control Client as part of the Custom Install, the Version Control Server Information dialog box appears. Enter the name of the machine where the Version Control Server is located. Enter the Version Control Bank name. The Version Control Bank name is case sensitive and must be identical to the Version Control Bank name created on the server by the Version Control System Administrator. 6. Click Next. The Installation Configuration screen is displayed with default paths for Installation, Working, and Repository directories. For the Installation directory, accept the default directory or specify the directory where you want the Developer executables to be located. For the Working directory, accept the default directory or specify the directory where you want the LINC.INI initialization file to be located. For a multiuser installation, to set up a separate LINC.INI file for each client workstation, specify a local directory on that workstation. To set up one LINC.INI file for use by all client workstations, specify a network directory that can be seen by all client workstations. If a LINC.INI file already exists in the specified directory, you will be asked if you want to update it. Select Yes if you want to reset your LINC.INI parameter settings. For the Repository directory, accept the default directory or specify the directory where you want the Repository located. For a multiuser installation, install the Repository once on a shared drive visible to the Developer Server. For a single user installation, install individual Repositories locally on each workstation. Note: This field is used to update the ReposPath parameter in the LINC.INI file, as well as specifying the location to install a new Repository. When performing a Custom installation without a Repository, this field may or may not be filled in. If the field is not filled in, a warning message will be displayed, no Repository will be installed and no ReposPath parameter will be defined in the LINC.INI file. Choose single or multiuser installation. If you choose multiuser, you can provide the name of the Developer Server now or edit the LINC.INI file later. For single user installation, the Developer Server is a background task on the local machine. Click Next. The Select Program Folder screen is displayed. 7. Check your settings when the confirmation screen appears. 8. Click Back to change settings, or Next to complete the installation

29 Developer Installation Locating the Developer Test Database Since a Developer Test database is not created until you are unit testing in Developer Test, the location of the database is not part of the installation process. You do, however, have to plan for its location when installing Developer. You must create a separate database for each Business Segment. The default location for each Test database is in a subdirectory under the working directory named after the Business Segment. The location can also be specified in the Business Segment options within Developer. The drive letter you specify refers to the drive on the Developer client machines, not on the Server. You can locate a shared Developer Test database on any shared drive. If you specify a location other than the default for a shared Developer Test database, all client workstations must map to where the Test database resides using a letter other than the one used on the workstation where the Test database resides. For example, if the shared Developer Test database resides on drive D on the Server, all client workstations might map to the Server's D drive as drive E. The options for locating the Developer Test database are shown in the following table. Mode Local Drive Shared Drive Multiuser mode This is the recommended option. Implies a separate database for each user to use for unit testing. Implies a single database accessed by several users to test one or more modules. Single user mode Yes Yes Installing the Developer Repository The Developer Repository is installed as part of a Typical installation of Developer on a client workstation. There may, however, be instances when you only need to install a new Developer Repository without re-installing any other components of Developer. To install a Developer Repository: 1. Log on to any Developer client workstation. 2. Use Explorer to locate setup.exe. If you are performing a Network installation, all the required files, including the setup.exe, are located in the Installation directory on the network drive. If you are installing from the CD-ROM, insert the CD-ROM into your CD-ROM drive and locate the setup.exe on the CD-ROM. 3. Double-click setup.exe. If you are running setup.exe from the CD-ROM, select the Developer option from the Unisys Installation Interface. After the Welcome and license screens, the Enterprise Application Developer Installation screen is displayed

30 Developer Installation 4. Select Custom and click Next. This displays the Select Components screen. 5. Select only the Developer Repository. (Ensure all other items are deselected). The Installation Configuration screen is displayed with a default path in the Repository directory field. The Installation directory and Working directory fields are disabled. 6. Accept the default path for the Repository or specify the required location. You can either type the full pathname or browse for it. Note: You should specify a new directory because installation will not overwrite an existing directory. For a multiuser system, you should not attempt to locate the Repository on a machine that will run Developer. If you do, there is a chance that the local user will start in single user mode and lock the rest of the team out of the Repository. The local user will also experience a degradation in performance. 7. Click Next. The Select Program Folder screen is displayed. 8. Check your settings when the confirmation screen appears. 9. Click Back to change settings, or Finish to proceed with the installation. Note: The workstation LINC.INI files are not automatically updated. If the workstation software is already installed, you need to edit each LINC.INI to specify the new repository path. Installing Developer with Windows Terminal Services This subsection contains instructions on how to install and configure Developer with Microsoft Windows 2000 Server Terminal Services. What are Terminal Services? Terminal Services allow a single server to be used for multiple users, with each user having a separate virtual environment on the Terminal Server. All processing is performed by the Terminal Services server. Users access the server using a client containing only the minimum software necessary to boot the device, establish a connection to the server, and present the user interface. This type of client is sometimes called a Thin Client. Windows 2000 Server provides integrated support for a Thin Client environment in the form of Windows 2000 Terminal Services

31 Developer Installation Recommended Configuration Configure a Terminal Services server installation on a Windows network so that all users who log in to the network and use a Terminal Services client session are able to use required Developer components, such as Developer and Developer Test. To achieve this configure Developer in multiuser mode, with the Developer Server being a different networked machine. In this recommended configuration: Users log in to the Local Area Network (LAN) using a Windows Terminal Services client session and start Developer. Dial-in connections, as well as direct connections, may be used. Developer clients (in multiuser mode) connect to the Developer Server, Security module, Version Control Server (if required), and Repository on the network. The Developer Security Administrator can work from either the Server machine or from another machine on the network. Note: In this configuration it is assumed that the Security module is installed on a separate machine on the network. However, in practice this is not necessary and it can be installed on the Developer Server machine. Requirements for a Terminal Services Installation Before installing and configuring Terminal Services, ensure you have the following: A Microsoft Windows network using TCP/IP as described in Setting up a Multiuser Configuration on page 5 5. A network directory (usually a location on the file server), from which a Developer client installation can be performed. A machine with Microsoft Windows Server, connected to the network, on which the Developer Server, Version Control Server (if required) and Repository are to be installed. This will be referred to as the Server machine. A machine with Microsoft Windows, connected to the network, on which the Developer Security module is to be installed. This will be referred to as the Security machine. A machine with Microsoft Windows Terminal Services installed and connected to the network. This will be referred to as the Terminal Services server. A Root Drive for each user on the network, which will be mapped to the user s home directory on the network. For example, each user has drive letter H: as the root drive mapped to a directory on the Developer Server machine. It will be represented by the %ROOTDRIVE% environment variable on the Terminal Services server. The Application Compatibility Scripts, Lda23a.cmd, Lda23aUsr.cmd, and ULda23a.cmd. These are installed as part of an Administration installation

32 Developer Installation Installation Procedure For the purposes of this example installation it is assumed that: Each user s Root Drive (%ROOTDRIVE% variable) is mapped to drive letter H:. The %SYSTEMROOT% environment variable on the Terminal Services server is set to C:\Wtsrv. Required user accounts have been created on the Terminal Services server. Setting Access Rights In order to install Developer on a Windows Terminal Services server, you need to have Administrator access rights to the Terminal Services server. This is required because some Windows system files may be overwritten during installation, and only users with Administration access rights have permission to overwrite system files. If the Developer installation process attempts to overwrite a system file and detects that you do not have Administrator access rights, an error message will be displayed and the installation process will exit. Windows operating system access rights are set by the User Manager program. This can be accessed by clicking the Start menu and going to Programs, and then Administrative Tools (Common). If you are unable to set Windows operating system access rights, see the System Administrator for your site. Note: If the Developer installation process finds system files that need updating, you will be prompted to reboot your machine before running Developer. Installing Terminal Services 1. When installing Windows 2000 Server on your Terminal Services server machine, you must install the following components: Terminal Services Terminal Services Licensing 2. After selecting these components, the Terminal Services Setup screen displays a choice of Terminal Services modes. Select Application Server mode. This mode is recommended for Developer, because it means that client machines can only install programs using the Terminal Services server (using Add/Remove Programs in the Windows Control Panel). Note: To use Application Server mode, you must install a Terminal Services licensing server in your domain within 90 days. See your Windows documentation for details. 3. Once the Terminal Services mode has been selected, set the default permissions for application compatibility. Two options are available: Permissions compatible with Windows 2000 users This option is more secure, but may not be able to run legacy applications such as Windows NT 4.0 and earlier

33 Developer Installation Permissions compatible with Terminal Server 4.0 users This option is compatible with most legacy applications, but offers reduced security since all clients have full access to the Windows registry and file system locations. This is the default option. Developer installation will not be affected by this option, so you should select an option based on the number of other legacy programs you are running, and the level of security required. 4. When you have selected your default permissions, continue with the standard Windows 2000 Server installation. Creating Client Install Disks Once Terminal Services is installed on the server machine, create installation disks for the client machines. To create the disks: 1. Log in to the Terminal Services server. 2. Select Start, then Programs, Administrative Tools, Terminal Services Client Creator. 3. In the Create Installation Disk(s) dialog box, select Terminal Services for 32-bit x86 windows. Click OK to finish creating the disks. Use the created disks to install the Terminal Services Client on your client machines. Administrator and Developer Server Machine Installation Ensure you have Windows Administrator privileges for the machine you are installing to, then install the following components: Component Comments On the Terminal Services server Administrator installation of Developer to a directory. See Using the Administrator Option on page On the Developer Server Machine Developer Server Version Control Server (if required) Repository See Installing the Developer Server on page See your Unisys Enterprise Application Developer Version Control Guide. See Installing the Developer Repository on page On the Security Machine Developer (required for security) See Installing Developer on a Client Workstation on page Developer Security See Custom Installation on page

34 Developer Installation Note: After installing the Security module, you should set up the necessary access rights for the users who will be using Developer. See your Unisys Enterprise Application Developer Administration Guide for details. Developer with Terminal Services Installation and Configuration To install Developer on the Terminal Services server and configure it for client use: 1. Log in to the Terminal Services server, then select Add/Remove Programs from the Windows Control Panel. 2. Click Install, then locate and open the Developer installation program (setup.exe) from the directory to which the Administrator installation was copied. 3. In the wizard dialog select the All users begin with common application settings option and click Next to start the Developer installation. 4. Select the Custom Installation Type and click Next. 5. In the Select Components dialog box select only those components users need for a multiuser installation (for example, Developer and Developer Test). When complete, click Next. If required, the Version Control Client and Builder can be installed later. Note: De-select Repository as this has been installed as part of the Server machine installation. 6. Enter the following data in the Installation Configuration dialog box: In the Installation Directory field, enter the location on the Terminal Services server where Developer is to be installed. The default is C:\Program Files\Enterprise Application Developer. In the Working Directory field, enter the path to the user s Root Drive, for example, H:\Program Files\Enterprise Application Developer\Work. In the Repository Directory field, specify the path to the Repository relative to the Developer Server machine (that is, the same value entered when you installed the Developer Server). See Setting up a Multiuser Configuration on page 5 5 for more details. 7. Select the Multi user mode radio button and specify the Developer Server machine name. Click Next to continue. 8. Answer Yes to The Installation directory does not exist. Do you want the directory to be created? and Yes to The Working directory does not exist. Do you want the directory to be created? Answer No to Creating the Repository. 9. When the installation process is complete, click OK. 10. Return to the Add/Remove Program dialog box and choose Next, then Finish. 11. Restart the Terminal Services server. The Terminal Services installation process is now complete

35 Developer Installation Uninstalling Developer with Terminal Services To uninstall Developer, select Programs from the Start menu, then navigate to the Developer 3.3 program folder and select Uninstall. Known Issues with Developer with Windows Terminal Services Some issues may arise with auditing, change management and Version Control operations, because on a Terminal Services server installation, the machine name logged by Developer will be the same for each user. To obtain usable audit information, it is recommended that Security is turned on so that both the user-id and machine name are logged. Each user can have multiple Terminal Server client sessions running, but should use a different username to log on to the Terminal Services server to use Developer. The Terminal Services server machine is generally not recommended for Primary or Backup Domain Controller. A single user Developer Repository is not supported within a Terminal Services server installation. Verifying Your Installation To ensure your installation is correct, load the Sample Model that is included with the Developer software, and validate it. If you are installing in multiuser mode, you should first perform the configuration functions described in Developer Configuration on page 5 1 to initialize the Developer Server before verifying your installation. To load the Sample Model: 1. Start Developer and select Load from the File menu. The Model Load dialog box is displayed. 2. Specify the Developer directory in which the Sample.mdl file resides. 3. Click the Open button. The Model Load Options window opens. 4. Check the Load in Exclusive Mode check box to lock the Repository while loading the object. This helps speed up the load. 5. Check the Validate After Load check box. 6. Key in a New Name for the Sample Model, if you wish. 7. Leave the Load Change Information check box unchecked. 8. Click the OK button. If Developer is correctly installed, the sample will load and validate without error. To create a test database for the Sample Model in Developer Test: 1. Start Developer Test and from the File menu select the Create New database option from Database Utilities

36 Developer Installation 2. Select the Sample System from the Select a System dialog box and click OK. 3. Check the Status bar for the Database Creation Completed message. 4. From the File menu, select Open Session. The Select a System dialog box is displayed. 5. Select Sample System and click OK. The opening screen from the Sample System is displayed. Check that each user can log onto the Developer Server and access the Repository. If you are running in multiuser mode, only one user needs to perform the load for the Sample Model to be visible to everyone. Summary After reading this section, you can: Ensure that your environment meets the necessary software and hardware requirements for installing Developer. Understand all Developer installation options. Follow the processes to install modules of Developer. Verify that you have installed Developer successfully

37 Section 4 Migrating from an Earlier Release of Developer This section describes the process of migrating your existing Developer installation to Release 3.3. It is assumed that you are migrating from a release no earlier than LDAIII 2.2. Topics covered are: Migrating Your Developer Repository Migrating Your Developer Security Database Migrating Your Version Control Bank Meeting the Hardware Requirements Migrating Your Developer Repository The database schema of the Developer Repository has changed and your existing Developer Repository needs to be migrated to this release. If you are migrating from a release earlier than LINC Development 2.4, you should contact your Unisys Support Administrator prior to commencing the migration process. There are several options available for migrating your Developer Repository: Extract and load Get from Version Control Bank Automatic upgrade Extract and load This option is suitable for migrating your Developer Repository from any previous release. The procedure involves: 1. Performing a full extract of your system from the existing Developer Repository. 2. Installing this Developer release

38 Migrating from an Earlier Release of Developer 3. Loading your extracted system into the newly created Developer Repository and validating it. See your Unisys Enterprise Application Developer Administration Guide for details of the extract and load procedure. Get from Version Control Bank If you have an existing Version Control Bank, this option is also suitable for migrating your Developer Repository from any previous release. The procedure involves: 1. Migrating your existing Version Control Bank to this Developer release. 2. Installing this Developer release. 3. Performing a Get Latest from the migrated Version Control Bank to the newly created Developer Repository. See your Unisys Enterprise Application Developer Version Control Guide for details of migrating your Version Control Bank and performing a Get Latest operation. Automatic upgrade This option may be available for migrating your Developer Repository from an earlier level of the Developer release to the current IC level. Refer to the Readme.htm file accompanying your IC installation for details. Migrating Your Developer Security Database The following steps are not required if you migrated your repository with the Automatic Upgrade facility. They apply only if you migrated with an Extract and Load. Perform an extract of your security data from the Developer Security module. Install Developer Security. Load the security data into the Developer Release 3.2 Security module. See your Unisys Enterprise Application Developer Administration Guide for details of performing an extract and load of security data

39 Migrating from an Earlier Release of Developer Migrating Your Version Control Bank If you have an existing Version Control Bank, it needs to be migrated to this release. Note: Although Version Control Banks are UREP repositories, the process of migrating a Version Control Bank is not the same as migrating your Developer Repository. See Migrating the Version Control Bank in your Unisys Enterprise Application Version Control Guide for details. Meeting the Hardware Requirements You should ensure that each machine in your Developer environment meets the hardware configuration requirements as specified in Hardware Requirements on page 3 2. To optimize the response times to your users, provide the recommended values, not the minimum ones. If you are migrating from a release earlier than 2.3, you need to be aware that an empty Developer Repository requires more disk space than an empty Repository from an earlier release. Prior to LINC Development Release 2.3, an empty Repository required 1.28MB. Now an empty Repository requires 9.2MB. For Builder If this is the first time that you are planning to use Builder to directly generate runtime systems to a target host, you will require additional disk space to store generate history information. Some additional disk space may be required to store system data. If the Model you are migrating is from a release earlier than 2.3 and it does not contain Generate Set data, there may be a slight increase in the size of the Developer Repository. Because Generate Sets have been fully supported in Developer since Release 2.3, the load process will require you to define a System Name: If it detects that the Model file being migrated to is from a release earlier than 2.3 and contains Generate Set data If it detects that the Model file was created by host LINC/Enterprise Application Environment and contains Generate Set data In releases prior to 2.3, Generate Set data was stored in the Developer Repository and you did not have access to it from the Developer environment

40 Migrating from an Earlier Release of Developer For Developer Version Control If this is the first time that you are planning to use Developer Version Control, you will require additional disk space. As a minimum, the Version Control Server requires a Pentium 200 with 128MB of RAM and a 200MB pagefile. Each connection to the Version Control Server takes 10MB. The UREP software requires a minimum of 300MB. The minimum requirement for the Version Control Bank is 440MB. When the OSMOS database is created, it preallocates the hard disk space required. As you add objects to the Bank, the preallocated space is used up, but more space is allocated automatically when it is required; that is, the database grows itself. Developer Version Control 3.1 and later features a Configuration Wizard to calculate the disk space required for the Version Control Bank based on your estimates of the number of objects it will contain. For planning purposes, you can run the Wizard, enter various figures to see the results of its calculations, then defer creating the configuration files until later. See your Unisys Enterprise Application Developer Version Control Guide for details of the Configuration Wizard. Summary To ensure successful migration: Extract your existing Developer Repository and security details, or use the Automatic Repository Upgrade facility. Install the software according to the recommendations in Developer Installation on page 3 1. Configure the software according to the recommendations in Developer Configuration on page 5 1. Reload the Developer Repository and security details, and validate each Business Segment. Reorganize the Developer Test database

41 Section 5 Developer Configuration This section describes how to configure the Developer Server and client workstations once Developer software has been installed. Configurations for single user and multiuser mode are illustrated by example. Topics covered are: Understanding Configuration Parameters Setting up a Single User Configuration Setting up a Multiuser Configuration Switching Between Single User and Multiuser Modes Understanding Configuration Parameters This section covers only those configuration parameters that are crucial to starting up and running Developer. For details of all configuration parameters, see the Developer Online Help. Specifically, see the on line help file Configuration (INI) Files which includes a full description of the parameters included in these ini files. The help file can be accessed from the link in the opening topic of Developer - Help. Optimizing Memory Usage When you retrieve objects from the Developer Repository for the first time, they are copied to the cache. On subsequent retrievals from the Repository, the cache is checked first to see if a disk access is necessary. This automatic system usage of memory minimizes disk access, speeding up the operations. To optimize memory usage, you should set the cache size limit as high as possible given the extended memory available. However, you should be careful not to set the limit too high as this can cause the system to page excessively to disk. You can use the ObjectCacheSizeLimit parameter located in the [PersistentDb] section of the JADE.INI file, to modify the size of the cache. The default value of this parameter is 2MB

42 Developer Configuration Initialization Files Developer uses three initialization (.INI) files to define the operation of the development environment. The following table provides an overview of the.ini files. More information on these files is covered under descriptions of specific tasks in this section and in Developer Online Help. File LINC.INI JADE.INI LINCDB.INI Description This file contains development environment parameters such as Repository location, Developer Server name when running in multiuser mode, Painter and printer settings. The installation process locates this file, which defines the Developer Server and Repository parameters, in the Repository directory. This file may also be created when Developer is run in multiuser mode for the first time. You can adjust JADE.INI parameters to tune Developer performance. This file identifies where the Developer Test Database files were last created or reorganized. During a reorganization of the Database, the location defined in the LINCDB.INI file is compared with the setting in the Repository. If the locations are different, the Database files will be moved to the Repository location as specified in the Run Time Options dialog box, which is accessed in Developer from the Business Segment Options dialog box. If you have moved your Developer Test Database you must adjust the settings in this file as described in Locating the Developer Test Database on page 5 7. Setting the TEMP Environmental Variable During a Developer Test session, temporary screen definition files are created (.FRM files). By default, these are placed in the working directory specified by the Developer Test shortcut. However, if you have set the environmental variable TEMP for your machine, they will be placed in the directory indicated by that variable. Note: You can remove these files to save disk space but do not delete them during a Developer Test session. Unisys recommends that you set the environmental variable TEMP for each Developer client. This helps prevent conflict where multiple developers have the same working directory, and it enhances performance when the directory pointed to by the TEMP variable is located on the local hard drive. In the Windows operating system, define the environmental variable TEMP as follows: 1. Start/Settings/Control Panel. 2. Double-click the System icon. 3. Click the Environment tab on the dialog box. 4. Click the Path parameter. 5. Update the parameter in the edit field as follows: SET TEMP=drive:\directory name

43 Developer Configuration Facts about the Working Directory The working directory is the default directory into which Developer places, and searches for, items such as intermediate files created at startup and deleted at closedown, bitmap files, data files (for example extract data from Developer Test Reports) and LCIF files. When you do a cut-and-paste in Developer the system writes temporary data to the working directory. Error files in Developer are not written to the working directory. They are written to the Repository directory. The default location for the working directory is set at the time of Developer installation. For a standard installation this is C:\Program Files\Enterprise Application Developer\Work. The working directory is a separate directory from both the directory in which the Developer application (executable files) is stored, and the directory in which the Repository is stored. A separate working directory makes it easier to identify the files stored there, rather than having to differentiate temporary or intermediate files from other files in either the Repository or application directories. By default, the Developer Test database is stored in a subdirectory under the working directory. Therefore, if you have a shared Developer Test database, it must be visible to all workstations. This means that the working directory mappings should be the same for all client workstations. For example, the working directory could be Q:\WORK for all workstations. The Developer Server does not need access to the working directory. Setting up a Single User Configuration A single user configuration of Developer means that one user has sole access to a Developer Repository stored on a local hard disk or on a shared drive. The Developer application (executable files) may be installed either on a shared network drive or locally on each client workstation. In the example illustrated below: The Developer Repository is installed locally on the client workstation. The Developer executable files are installed locally on the client workstation. TCP/IP is optional. Note: If the Repository is located remotely, then TCP/IP is required

44 Developer Configuration Local Repository on client workstation Developer client workstation.exe files in application directory Example Configuration: Single User Mode Developer with a single user Repository is the simplest configuration to install and manage. You may wish to use this mode to get started with Developer. Then, as you gain expertise, you may decide to switch to multiuser mode development. When you access a Repository in single user mode, a temporary file called $exclusi.ve$ is created in the Repository directory to prevent other users from accessing your Repository. The $exclusi.ve$ file sets the access mode for that session. When you end the session, this file is automatically deleted. Note: If Developer terminates abnormally, Windows may not release the $exclusi.ve$ file. In this case you must delete this file manually before you can restart Developer. Developer Test Database You create a Developer Test Database when you first run a Developer Test session. You must create a separate database for each Business Segment. By default, the Developer Test Database, in a single user Repository environment, resides in a subdirectory under the working directory, and is named after the system. For example: C:\Program Files\Enterprise Application Developer\WORK\TEST1 Note: For Windows Server 2012 and Windows 8, if you install Developer in a drive apart from the C: drive, double quotes appear twice next to the Developer Test Database and you fail to start the Developer Test Database. For example: ""D:\EAE Programs\WORK"" Before installing EAE Developer, you can perform the following steps to avoid the double quotes appearing twice next to the Developer Test Database. 1. Run the command prompt as an Administrator

45 Developer Configuration 2. Run the following command: fsutil 8dot3name set <volume> 0 For example: fsutil 8dot3name set d: 0 The location of the Database can also be specified in Developer by setting the Test Options from the Business Segment Options dialog box. Configuring a Single User Installation 1. Set the environmental variable TEMP for Developer Test forms creation. For example: TEMP=C:\TEMP For details on setting the TEMP environmental variable, see Setting the TEMP Environmental Variable on page Check Repository access. Ensure that each client workstation has read-write access to the Repository and the working directory. Shared application files, however, should be read-only. 3. Install the LINC.INI file. If the Developer executable files are shared, copy LINC.INI to the working directory of each workstation and then delete LINC.INI from the shared directory. Setting up a Multiuser Configuration A multiuser configuration of Developer means that a group of developers have shared access to a Developer Repository. To run Developer in multiuser mode, you must have the Developer Server running on a dedicated workstation. The Developer Repository may be located either on the Developer Server or the LAN file server. Both scenarios are illustrated in this section. Locating the Developer Test Database You create a Developer Test Database when you first run a Developer Test session. You must create a separate database for each Business Segment. By default each Business Segment Database is located in a subdirectory under the working directory, named after the system, for example: C:\Program Files\Enterprise Application Developer\WORK\TEST1 C:\Program Files\Enterprise Application Developer\WORK\TEST2 The location of the Database can also be specified in the Test Options dialog box accessed in Developer from the Business Segment Options dialog box

46 Developer Configuration The implications of the Developer Test Database location in multiuser mode depend on the particular configuration. There are three possible configuration scenarios: 1. Each developer in a group has a separate, local Developer Test Database. All developers in the group have access to the same Developer Repository. 2. All developers in a group have access to the same Developer Test Database. Each developer in the group has a separate, local Developer Repository. 3. All developers in a group have access to the same Developer Test Database. All developers have access to the same Developer Repository. In all three cases, entries in the LINCDB.INI file and the current Repository settings must match before Developer Test can locate and access the Database. Entries in the LINCDB.INI file identify where the Developer Test Database files were created last. These file locations are compared to the current settings in the Repository. In a normal Developer Test session, any discrepancy will result either in Developer Test closing or, if you have the necessary privileges, Developer Test will ask whether or not a logical reorganization should be continued. Depending on how the Repository is opened, the LINCDB.INI file will be located in either the Repository directory or the Developer Test Database directory. When the Repository is opened in single user mode, the LINCDB.INI file is written to the Repository directory. When the Repository is opened in multiuser mode the LINCDB.INI file is written to the Developer Test Database directory. In the three configuration scenarios cited above, scenarios 1 and 3 are examples of a Repository being opened in multiuser mode, so in both of these cases the LINCDB.INI file will be located in the Developer Test Database directory. Case 2 is an example of a Repository being opened in single user mode, so the LINCDB.INI file will be located in the Developer Repository. In cases where each developer in a group has: A local Developer Test Database (configuration scenario 1) OR A local Developer Repository (configuration scenario 2) AND Developer is installed on a network drive THEN The working directory of LINCRUN.EXE and LINCDEV.EXE should be set to an existing local path for each developer. If each developer requires a separate LINC.INI file, you should copy the LINC.INI file from the Developer application directory to the local path. If a group of developers are sharing the LINC.INI file, you should set the -i option for LINCRUN.EXE and LINCDEV.EXE to the directory where the LINC.INI file is located

47 Developer Configuration Relocating the Developer Test Database If you need to move your Developer Test Database from one location to another, you must remember to update the LINCDB.INI file so that it reflects the new location of the Developer Test Database. For example, if you need to move your Developer Test Database from C:\SAMPLE to F:\SHARED\SAMPLE, you must follow the steps set out below to accomplish the database move successfully: 1. Move all the Developer Test Database files from C:\SAMPLE to the new location at F:\SHARED\SAMPLE. 2. Update the database paths in the Repository with the new location. 3. Update the LINCDB.INI file with the new location. If you attempt to run Developer Test without updating the LINCDB.INI file first, you will incur the following problem: 1. Developer Test will compare the C:\SAMPLE settings in the LINCDB.INI file against the F:\SHARED\SAMPLE Repository settings and will find a discrepancy. 2. Depending on your user privileges, Developer Test will either close or tell you that a reorganization is necessary because it did not find the files in the place it last created them as shown by the LINCDB.INI file. 3. If you reorganize without updating the LINCDB.INI first, the reorganization utility would find no data in C:\SAMPLE. It would, therefore, create zero length files in F:\SHARED\SAMPLE by overwriting the files you moved to that location. Developer Test hubbing to Business Integrator Steps required for setting up Developer Test hubbing to Business Integrator. Configuration: Developer and Business Integrator located on the same machine. 1. Install Developer GCA and then Developer IC Install Business Integrator IC 3080 and then Business Integrator IC 3140 (please do not install the version BI GCA) 3. Use computer management and stop DEVTEST hub socket service. Set the Service to manual start. 4. Make sure that _EXT_COMP hubsocket service is started. Please note that only one hubsocket socket is allowed to start on one machine as they all configured to run on port Hence this sample configuration will use _EXT_COMP hubsocket as the running service. 5. Open Developer ntlinc.cfg file, it is located in <Developer_Install_directory>\Config

48 Developer Configuration 6. Edit Developer ntlinc,cfg (LINCIIDIR, LINCII_ENV) to match Business Integrator ntlinc.cfg located in <business_integrator_install_directory>\config\ For example: LINCIIDIR=C:\PROGRA~1\UNISYS\ENTERP~1.3 LINCII_ENV=_EXT_COMP HUB_PORT=6001 This will allow Developer Test to use _EXT_COMP hub socket instead of DEVTEST hub socket. 7. Load your model into Developer. 8. Open Developer Test, click on File > Manage External Systems. 9. Add an external system - For more details, see Developer documentation or Developer online help. For Example: External name: HUBSOURCE Environment name: _EXT_COMP Business Segment: HUBSOURCE Enable: True Default: True 10. You can create new database for the system 11. Open session. When the Repository is on the Developer Server In the example illustrated below: 1. The Developer Server is required. You can install it anywhere accessible to the client workstations. 2. The Developer Repository is installed on the Developer Server workstation. 3. The Developer executable files are installed on the LAN file server. 4. Development executables are installed on the LAN file server. The LAN file server can be located anywhere accessible to the client workstations. Note: The LAN file server is optional and if one is not available, the executables can be installed on each client workstation. 5. TCP/IP must be installed on each client workstation and the Developer Server. 6. TCP/IP is not required on the LAN file server

49 Developer Configuration LAN file server TCP/IP machine TCP/IP machine Developer client workstation Developer server workstation with local Repository Developer.EXE files in application directory TCP/IP machine TCP/IP machine Developer client workstation Developer client workstation Multiuser configuration with Repository on Developer Server When the Repository is on the LAN File Server In the example illustrated below: 1. The Developer Server is required. You can install it anywhere accessible to the client workstations. 2. The LAN file server is required. It can be located anywhere accessible to the client workstations. 3. The Developer Repository is installed on the LAN file server. 4. The Developer executable files are installed on a different LAN file server from the Repository. 5. TCP/IP is required on the client workstations and the Developer Server. 6. TCP/IP is not required on the LAN file servers

50 Developer Configuration TCP/IP machine Developer client workstation Repository TCP/IP machine Developer client workstation TCP/IP machine LAN file server Developer client workstation TCP/IP machine LAN file server Developer server workstation Developer.EXE files in application directory Multiuser configuration with Repository on the LAN file server Configuring a Multiuser Environment The configuration steps described below are applicable to both multiuser configuration examples illustrated earlier in this section: 1. Set the Startup Parameters. 2. Configure the Developer Repository. 3. Configure the Developer Server. 4. Configure the client workstations. Setting the Startup Parameters 1. Decide how you will use the LINC.INI file. That is, one LINC.INI file to be shared by all users or a separate LINC.INI file for each user. Consider the following scenerios: Allow a single LINC.INI file for all users to ensure a uniform development environment including colors and fonts used in the Developer application windows. The single LINC.INI file can specify the path to the Repository (REPOSPATH parameter) and all developers point the command-line of their Developer shortcuts to this LINC.INI file. Allow individual LINC.INI files and point to the Repository either from each LINC.INI file or from the command-line of the Developer shortcuts

51 Developer Configuration 2. Decide where to locate the LINC.INI file and how to point to it. Default locations in which Developer looks for the LINC.INI file are the working directory (in the shortcut properties) and the application directory. You can override both of these with a location defined by the /I command-line argument in the application properties. Copy the file from the shared application directory into either: The working directory specified in the shortcut properties for Developer and Developer Test The directory specified by the command-line argument in the shortcut properties for Developer and Developer Test You can then either delete the copy of the LINC.INI file from the shared application directory or leave it as a master copy. 3. Decide whether you will point to the repository using LINC.INI or using the shortcuts: LINC.INI Set the Repospath parameter to point to the Repository directory on the Developer Server, and set the MultiUser parameter in the LINC.INI file to Y. Shortcuts Edit all the shortcut properties to include the /R parameter to point to the Repository directory on the file server. For examples, see Developer Shortcut Properties later in this section. 4. Define the working directory in the properties of each of the shortcuts. It is recommended that, for multiuser mode, you leave the working directory separate from both the Developer application directory and the Repository directory, to give each user the ability to customize settings. The workstation must have read-write access to the working directory. The location of individual Developer Test Databases in a multiuser environment has implications for the naming of the working directory. For details, see Facts about the Working Directory on page 5 3. Configuring the Developer Repository 1. Check Repository installation. Check that the Repository has been installed correctly on the file server. Your Repository directory (by default \Enterprise Application Developer\Rep) should contain repository data files. Repository data files have a.dat extension. 2. Establish access rights to directories and files. Ensure that the Developer Server has full read-write access to the drive and directory where the Repository is located. If the Developer application (executable files) also resides on this or another server, check to ensure that all executable files are flagged as read-only. If you have decided to use a single LINC.INI file for all users, ensure that all the client workstations have read-write access to the LINC.INI file

52 Developer Configuration 3. Check the JADE.INI file settings. This file, which is located in the Repository directory, should have its parameters set to optimize performance. On installation, default settings are assumed by the system. Configuring the Developer Server Note: The Developer Server does not require a hardware security key. To configure the Developer Server: 1. Check Developer Server software installation. Ensure that Developer Server software has been installed on the Developer Server workstation and that Server workstation can be accessed by all the client workstations via TCP/IP. Check that shortcuts were created for the Developer Server, Monitor, and Repository Utilities during the installation process. 2. Establish access rights to directories and files. If the Repository is on a LAN file server, ensure that the Developer Server has login and read-write access to the LAN file server where the Repository is located. If the Repository is on the Developer Server, ensure that read-write access rights are available to the drive and directory where the Repository is located. The Repository files must be flagged as read-write. This is to ensure that intermediate files can be created during initialization and deleted at closedown. 3. Check JADE.INI file for NodeName and other parameter settings. The JADE.INI file is located by the Developer Server, Developer Monitor, and Repository Utility programs in the following order: Directory specified by the path parameter Working directory / Start In directory Windows directory A path parameter must be given for the Developer Server and Developer Monitor programs to start. If a path parameter is not given for the Repository Utility program, and a JADE.INI file is not found, a new JADE.INI file will be created and placed in the Windows directory. To ensure that your Developer Server is correctly configured, you should check and, if necessary, correct the following JADE.INI settings: The [JadeServer] section of the JADE.INI file contains a NodeName parameter. This node name is displayed in the title bar of the server window and does not have to be the same as the Windows machine name. The [JadeClient] section of the JADE.INI file contains a ServerNode parameter. The monitor program uses this server name to determine with which Developer Server it should communicate

53 Developer Configuration The [JadeClient] section of the LINC.INI file contains a ServerNode parameter. This server name is the name of the Windows machine on which the Developer Server is running. The parameter settings in the JADE.INI file should be set to optimize performance. On installation, default settings are assumed by the system. Running Developer Server as a Windows Service The Developer Server controls multiuser interaction with a Developer Repository. You can configure your Developer Server to run as a Windows Service. When the Server is configured as a Service, the Developer Server program becomes simply an interface for configuring the Service, and can be opened and closed without affecting users currently connected to the Repository. Note: Services can also be configured via the Control Panel. To configure the Developer Server to run as a Windows Service: 1. Start the Developer Server from the shortcut. 2. Select the Service option from the Options menu in the Developer Server window. This displays the Service Configuration dialog box. 3. Check the Run Server as Service check box to register your Developer Server as a Service. 4. Click the OK button. A Service named after the NodeName parameter in the [JadeServer] section of your JADE.INI initialization file is registered in the Windows registry in automatic startup mode. The RunAsService parameter in the [JadeServer] section of your JADE.INI initialization file is set to true. At this stage the Developer Server is only registered in the Windows registry as a Service. The Developer Server window must be closed to start the Service. 5. Select the Exit command from the File menu to close the Developer Server window. Next time you start the Developer Server (or reboot the machine), it will be run as an interface to configure the Service. Alternatively, once the Service is registered, you can configure it by double-clicking on the Services icon in the Control Panel and selecting the appropriate Developer Server. To run multiple Developer Servers as Services on the same machine, each Developer Server must have a unique TCP/IP port number, as well as a unique NodeName parameter in the [JadeServer] section of the JADE.INI initialization file. Any Developer Servers running as Windows Services must first be stopped and unregistered before you can uninstall them. To stop and unregister the Developer Server Service: 1. Start the Developer Server from the shortcut. 2. Select Stop Service from the File menu. This stops the Developer Server Service, and disconnects any users that may be connected to the Developer Server

54 Developer Configuration 3. Select Service from the Options menu. This displays the Service Configuration dialog box. 4. Uncheck the Run Server as Service check box to unregister your Developer Server as a Service. 5. Click OK. The entry for the Developer Server in the Windows Services is removed and the associated keys are removed from the Windows registry. The Developer Server application can now be uninstalled safely. If the Developer Server is uninstalled without first unregistering the Service, the Windows registry keys need to be removed manually. Failure to remove them may cause problems with the Windows Services feature. To remove the Developer Server registry keys: 1. Start Registry Editor (REGEDT32.EXE). 2. Delete the following key folders: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NodeName Where NodeName is the name of your Developer Server running as a Service, as defined by the NodeName parameter in the [JadeServer] section of the JADE.INI initialization file. 3. Exit the registry. 4. Shutdown and restart Windows. Caution You should only use the Registry Editor if you are an experienced system administrator. Incorrect use of the Registry Editor can cause serious problems. For more information about Windows Services, see your Windows documentation. Configuring Developer Client Workstations To configure Developer client workstations: 1. Implement and configure your network software. 2. Establish access rights to directories and files. In a multiuser environment, the Developer Server requires read-write access rights to the drive and directory in which the Developer Repository is located. Client workstations do not require access to the Repository or Repository machine. Client workstations must have read-write access rights to their nominated working directories

55 Developer Configuration 3. Set the environmental variable TEMP for Developer Test forms creation. For example: TEMP=C:\TEMP For details on setting the TEMP environmental variable, see Setting the TEMP Environmental Variable on page Check the settings of the following parameters in the LINC.INI file: Multiuser in [repository] section For multiuser mode, this parameter should be set to Y. Repospath in [repository] section Set the Repospath parameter to point to the Repository directory on the Developer Server. The Developer Server reads this parameter in the [JadeClient] section of the client LINC.INI file, and interprets the driver mappings for the Developer Server machine and not the workstation machine. ServerNodeSpecifications in [JadeClient] section ServerNodeSpecifications defines the connection path to a remote Developer Server, using the ServerNode and TcpServerPort parameters. Enter these parameters in the following format: ServerNodeSpecifications=TcpIp,<ServerNode>,<TcpServerPort> Note that no white space is allowed between the ServerNodeSpecifications parameters. The TcpIp parameter specifies that the TCP/IP transport protocol is used. The ServerNode parameter specifies the machine name or IP address of the Developer Server to which the LINC.INI file refers. The TcpServerPort parameter specifies the port number that, together with the ServerNode parameter, identifies a Developer Server. The default value for this parameter is However, if you are running multiple Developer Servers on the same machine, you must ensure that this parameter corresponds to the appropriate value in the [JadeServer] of the Jade.ini file associated with the required Developer Server. TransientDbPath in [JadeClient] section This parameter is set by the Developer installation. Ensure that the specified directory exists. The parameter value is only used if client applications do not have read/write access to the Repository directory

56 Developer Configuration Developer Shortcut Properties You can use the command-line arguments detailed in the following table to point your Developer or Developer Test shortcuts to a particular Repository or LINC.INI file. The arguments are not case-sensitive. Command Line Argument Description Example No command line argument /I or -i LINC.INI directory path /R or -r repository path /I or -i LINC.INI directory path and /R or -r repository path In the absence of any parameters in the command line, LINCDEV.EXE looks for LINC.INI in the working directory.the working directory is read by LINCDEV.EXE as being on the developer workstation, not on the Developer Server. LINCDEV.EXE uses this directory path to locate the LINC.INI file. LINCDEV.EXE uses this directory path to locate the Repository. This path overrides the Repospath parameter in the LINC.INI file. LINCDEV.EXE uses these directory paths to locate the LINC.INI file and the Repository. The command line repository path overrides the Repospath parameter in the LINC.INI file. N/A Command line = C:\DEVELOPER\LINCDEV.EXE /I C:\DEVELOPER Command line = C:\Developer\LINCDEV.EXE /R C:\DEVELOPER\REPOS Command line = C:\Developer\LINCDEV.EXE /I C:\DEVELOPER /R C:\DEVELOPER\REPOS Setting up Multiple Repositories If you have decided to organize your project around multiple Repositories, your configuration will have multiple Developer Servers, each servicing a single Repository. If you install multiple Repositories by re-installing Developer and selecting Repositoryonly, remember that the LINC.INI file is not automatically updated. You must copy the file and edit it each time to specify the new Repository path. Note: Setting up your LINC.INI files and shortcuts is more complex when working with more than one Repository. The options, for a multiuser configuration with multiple Repositories, are described in the following table: Option Each Repository has its own LINC.INI file with the REPOSPATH parameter pointing at the required Repository. Set up Developer and Developer Test Shortcuts for Each Repository with The argument -i drive :\path of LINC.INI file added to the command line of the shortcut properties

57 Developer Configuration Option Each user has a separate LINC.INI file (usually located in the working directory) for each Repository, with the REPOSPATH parameter pointing at the required Repository. Each user has a single LINC.INI file that they use for all Repositories The total Developer environment has a single LINC.INI file for each Repository, used by all users of a given Repository. Set up Developer and Developer Test Shortcuts for Each Repository with The argument -i drive :\path of LINC.INI file added to the command line of the shortcut properties. The argument -r drive :\path of repository added to the command line of the shortcut properties. Both the arguments -i drive :\path of LINC.INI file and -r drive :\path of repository added to the command line of the shortcut properties. Switching Between Single User and Multiuser Modes You can switch between single user and multiuser modes using one of the following methods: 1. Use two LINC.INI files, one for single user mode and the other for multiuser mode. Each one must be in a different location and be referenced by different copies of the Developer shortcuts. 2. Use a single LINC.INI file but change the Multiuser parameter on a session-bysession basis. Developer cannot be used in single user mode if the Developer Server for the Repository is running. The Developer Server cannot be started if the Repository is open in single user mode. Caution To avoid locking out all other users in a multiuser environment, do not open the Developer Repository in single user mode. Summary After reading this section, you can: Set the basic Developer configuration parameters. Configure a single user Developer installation. Determine the correct location for your Developer Test Database location in multiuser mode

58 Developer Configuration Understand the available options for locating the Developer Repository in multiuser mode. Configure a multiuser Developer installation. Switch between single user and multiuser modes

59 Appendix A Related Product Information These documents are published by Unisys Corporation and are available on the Internet at Order hardcopy documents online through the Unisys Book Store at Unisys Enterprise Application Developer Administration Guide This document provides information on the administration of a Developer installation, including security, database utilities, and how to perform an extract and load of a Developer Business Model and Developer Systems. If you migrating from an earlier release of Developer, you should become familiar with the utilities described in this document. Unisys Enterprise Application Developer User Guide This document provides information on using Developer software to design, develop, and test Systems on workstations. Unisys Enterprise Application Developer Version Control Guide This document provides information on using Developer Version Control to manage the source of versionable objects from within Developer. Developer Version Control is licensed separately from the basic Developer components. If your site has not purchased Developer Version Control then you do not need this document. Unisys Enterprise Application Builder Guide This document provides information on using Developer Systems and Builder to define a System for generation directly to a target Enterprise Application host. Unisys Enterprise Application Programming Reference Manual This document provides reference material for the definition of a Specification A 1

60 Related Product Information A

61 Index A access rights required for users, 3 8 Administrator installation, 3 11 B Builder, disk space, 4 3 C cache size definition, 5 1 client workstation hardware requirements, 3 2 installation, 3 17 configuration, 5 1 initialization files, 5 2 multiuser mode, 5 5, 5 10 optimizing memory, 5 1 shortcuts, 5 16 single user mode, 5 3 TEMP environmental variable, 5 2 Windows NT Terminal Server, 3 21 Custom installation, 3 14 customer support, 2 3 D Developer client workstation installation, 3 17 installation, 3 1, 3 10 modules, 2 2 overview, 2 1 Repository installation, 3 19 server installation, 3 16 disk locations, 3 7 disk space for Builder, 4 3 for empty Repository, 4 3 for Version Control, 4 4 documentation, installing, 3 14 H hardware requirements, 3 2 client workstations, 3 2 Repository, 3 4 Test database, 3 5 I initialization files, 5 2 installation options, 3 13 Custom, 3 14 Developer Server, 3 16 Network, 3 14 Typical, 3 13 installation, verifying, 3 25 installing Developer, 3 10 documentation, 3 14 on a client workstation, 3 17 on standalone workstation, 3 11 Repository, 3 19 to network, 3 11 to workstation from network, 3 13 Windows NT Terminal Server, 3 20 J JADE.INI, 5 2 L LINCDB.INI definition of, 5 2 location of Test database, 5 7 LINC.INI changes to, Index 1

62 Index definition of, 5 2 location, 3 8 loading Sample Model, 3 25 locking, 3 7 M memory usage, 5 1 migrating Builder Repository, 4 1 multiple Repositories, 5 16 multiuser configuration, 5 5, 5 10 multiple Repositories, 5 16 multiuser mode definition, 3 1 switching to single user mode, 5 17 N network disk locations, 3 7 installation, 3 14 locks, 3 7 transport protocols, 3 6 P problem reporting, 2 3 protocols, 3 6 R reporting problems, 2 3 Repository disk space, 4 3 hardware requirements, 3 4 installation, 3 19 migrating, 4 1 multiple, 5 16 on Developer Server, 5 8 on LAN File Server, 5 9 required software, 2 3 requirements hardware, 3 2 software, 3 5 S Sample Model, loading, 3 25 selecting user mode, 3 1 server configuring as Windows Service, 5 13 installation, 3 16 shortcuts, 5 16 single user configuration, 5 3 single user mode definition, 3 1 switching to multiuser mode, 5 17 software installation, 3 10 required, 2 3 requirements, 3 5 standalone workstation installation, 3 11 support, reporting problems, 2 3 Systems designing and developing, 2 1 testing, 2 1 T technical support, 2 3 TEMP environmental variable, 5 2 Terminal Server Edition configuring, 3 21 installing, 3 20 Test database hardware requirements, 3 5 location, 3 19 location, multiuser mode, 5 5 location, single user mode, 5 4 on Novell LAN, 3 8 relocating, 5 7 Typical installation, 3 13 U user mode definition, 3 1 switching, 5 17 V verifying installation, 3 25 Index

63 Index Version Control, disk space, 4 4 W Windows NT Terminal Server, 3 20 working directory, Index 3

64 Index Index

65

66 Unisys * *