COMPARISON BETWEEN CMVC 2.3 AND TEAMCONNECTION 2 Document Number TR 29.2253 Angel Rivera, Lee Perlov and Sam Ruby CMVC/TeamConnection Development IBM Software Solutions Research Triangle Park, North Carolina Copyright (C) 1997 IBM. All rights reserved. ii CMVC and TeamConnection ABSTRACT This technical report compares the functions of Configuration Management and Version Control (CMVC) and its successor product, TeamConnection. The objective is to provide to the CMVC user the relevant information about what is the same, what is different and what is new between CMVC and TeamConnection. ITIRC KEYWORDS o CMVC o TeamConnection ABSTRACT iii FIRST REVISION, MAY 1997 o Added the following sections: 1.2, "The Big Differences" on page 2, 3.8, "New UNIX GUI" on page 30, and 4.6.2.2, "Space used by family daemons" on page 40. o Updated the following section: 4.6.2.1, "Space used by data- base" on page 40 o Added references to other TeamConnection technical reports. This document has now been reviewed and updated by the TeamConnection lead architect, Sam Ruby. As such, his name has been added to the author's list. ABSTRACT v vi CMVC and TeamConnection ABOUT THE AUTHORS ANGEL RIVERA Mr. Rivera is an Advisory Software Engineer and team lead for CMVC development. He joined IBM in 1989 and since then has worked since then in the development and support of library systems. Mr. Rivera has an M.S. in Electrical Engineering from The Univer- sity of Texas at Austin, and a B.S. in Electronic Systems Engi- neering from the Instituto Tecnologico y de Estudios Superiores de Monterrey, Mexico. LEE R. PERLOV Mr. Perlov is a Staff Software Engineer in the TeamConnection/CMVC development group. He started working for IBM in 1985 in Gaithersburg, Md, in the Federal Systems Division on various projects for the United States intelligence community. He moved to RTP to work on library development and support, in 1992. Mr. Perlov received a B.S. degree in Accounting from the Univer- sity of Florida in 1983. He also completed two years of graduate work in the Department of Computer Science at the University of Florida. SAMUEL RUBY Mr. Ruby is a Senior Software Engineer and the lead architect of TeamConnection. He was previously lead architect of the mainframe library product, SCLM. His turn-ons include Diet Coke in the can and Dilbert. ABOUT THE AUTHORS vii viii CMVC and TeamConnection CONTENTS ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . III ITIRC KEYWORDS . . . . . . . . . . . . . . . . . . . . . iii ABOUT THE AUTHORS . . . . . . . . . . . . . . . . . . . . . VII Angel Rivera . . . . . . . . . . . . . . . . . . . . . . vii Lee R. Perlov . . . . . . . . . . . . . . . . . . . . . . vii Samuel Ruby . . . . . . . . . . . . . . . . . . . . . . . vii FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . XI 1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Compatibility . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Migration from CMVC to TeamConnection . . . . . . . 2 1.2 The Big Differences . . . . . . . . . . . . . . . . . 2 2.0 COMPARISON OF COMMON FUNCTIONS . . . . . . . . . . . . . 5 2.1 Command names . . . . . . . . . . . . . . . . . . . . 5 2.2 Configuration management . . . . . . . . . . . . . . . 6 2.2.1 Components and component hierarchy . . . . . . . . 6 2.2.2 Access to components . . . . . . . . . . . . . . . 6 2.2.3 Notification mechanism . . . . . . . . . . . . . . 7 2.2.4 Customized processes for components . . . . . . . . 8 2.3 Release management . . . . . . . . . . . . . . . . . . 8 2.3.1 Releases . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Approval List . . . . . . . . . . . . . . . . . . 10 2.3.3 Environment List . . . . . . . . . . . . . . . . 10 2.3.4 Customized processes for releases . . . . . . . . 10 2.4 Change Control . . . . . . . . . . . . . . . . . . . 11 2.4.1 Overview . . . . . . . . . . . . . . . . . . . . 11 2.4.2 Defects . . . . . . . . . . . . . . . . . . . . . 12 2.4.3 Features . . . . . . . . . . . . . . . . . . . . 12 2.5 Version Control . . . . . . . . . . . . . . . . . . 12 2.5.2 Files (CMVC) or Parts (TeamConnection) . . . . . 13 2.5.3 Tracks (CMVC) or Workareas (TeamConnection) . . . 14 2.5.4 Levels (CMVC) or Drivers (TeamConnection) . . . . 15 2.6 Users and authentication of users . . . . . . . . . 15 2.6.1 Differences . . . . . . . . . . . . . . . . . . . 15 2.7 Architectural Issues . . . . . . . . . . . . . . . . 16 2.7.1 Client/Server Design . . . . . . . . . . . . . . 16 2.7.2 Customization aspects . . . . . . . . . . . . . . 16 2.7.3 Integration with other products . . . . . . . . . 17 2.7.4 Query facility . . . . . . . . . . . . . . . . . 17 2.7.5 Migration utilities . . . . . . . . . . . . . . . 18 2.7.6 Year 2000 Compliance . . . . . . . . . . . . . . 18 2.8 Supported platforms and databases . . . . . . . . . 19 2.8.1 Family server . . . . . . . . . . . . . . . . . . 19 2.8.2 Clients . . . . . . . . . . . . . . . . . . . . . 19 2.8.3 Databases . . . . . . . . . . . . . . . . . . . . 20 2.8.4 License handling . . . . . . . . . . . . . . . . 20 Contents ix 2.9 Family administration . . . . . . . . . . . . . . . 20 2.9.1 Structure of a family account . . . . . . . . . . 21 2.9.2 Suggestions . . . . . . . . . . . . . . . . . . . 22 2.9.3 Family administration tools . . . . . . . . . . . 22 3.0 NEW USER FUNCTIONS OF TEAMCONNECTION . . . . . . . . . 23 3.1 Sequential/Concurrent development . . . . . . . . . 23 3.2 Automatic pruning of releases . . . . . . . . . . . 23 3.3 Versioning . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 Versioning in CMVC . . . . . . . . . . . . . . . 24 3.3.2 Versioning in TeamConnection . . . . . . . . . . 25 3.3.3 Finding different versions of TeamConnection objects . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4 Parts are more than just Files . . . . . . . . . . . 26 3.4.1 File/Part links . . . . . . . . . . . . . . . . . 26 3.4.2 Changing the type of a file (text <-> binary) . . 27 3.5 Workareas are more than renamed Tracks . . . . . . . 27 3.5.1 Multiple workareas per defect or feature . . . . 28 3.5.2 Workarea performance . . . . . . . . . . . . . . 28 3.5.3 teamc workarea -undo . . . . . . . . . . . . . . 28 3.6 Driver has more options than Level . . . . . . . . . 28 3.6.1 teamc driver -freeze . . . . . . . . . . . . . . 29 3.6.2 teamc driver -restrict . . . . . . . . . . . . . 29 3.7 Updated Intel GUI . . . . . . . . . . . . . . . . . 29 3.8 New UNIX GUI . . . . . . . . . . . . . . . . . . . . 30 3.9 Authentication by means of login . . . . . . . . . . 31 3.10 Planning for teamc release/driver -extract actions 31 3.11 Build support . . . . . . . . . . . . . . . . . . . 32 3.12 Packaging support . . . . . . . . . . . . . . . . . 33 3.13 Object Repository and Information Model . . . . . . 33 4.0 CHANGES THAT IMPACT SYSTEM ADMINISTRATORS . . . . . . 35 4.1 TCADMIN - System Administrator's GUI . . . . . . . . 35 4.1.1 Other administrator tools . . . . . . . . . . . . 35 4.2 User exits . . . . . . . . . . . . . . . . . . . . . 36 4.3 License handling . . . . . . . . . . . . . . . . . . 36 4.3.1 License handling in CMVC . . . . . . . . . . . . 36 4.3.2 License handling in TeamConnection . . . . . . . 37 4.4 Backup and Recovery . . . . . . . . . . . . . . . . 37 4.5 What processes are started . . . . . . . . . . . . . 37 4.5.1 What processes are started in CMVC . . . . . . . 37 4.5.2 What processes are started in TeamConnection . . 38 4.6 Use of disk space and memory . . . . . . . . . . . . 39 4.6.1 Directory /tmp . . . . . . . . . . . . . . . . . 39 4.6.2 Disk space for the family account . . . . . . . . 40 4.6.3 Use of AFS and NFS . . . . . . . . . . . . . . . 41 4.7 Memory usage . . . . . . . . . . . . . . . . . . . . 41 4.8 Family daemons and security/integration issues . . . 41 4.8.1 Process privileges . . . . . . . . . . . . . . . 42 4.8.2 Access to data in the family account . . . . . . 42 4.8.3 System integration issues . . . . . . . . . . . . 42 4.8.4 Other issues . . . . . . . . . . . . . . . . . . 43 APPENDIX A. BIBLIOGRAPHY . . . . . . . . . . . . . . . . . 45 x CMVC and TeamConnection A.1 CMVC 2.3 . . . . . . . . . . . . . . . . . . . . . . 45 A.2 TeamConnection 2 . . . . . . . . . . . . . . . . . . 45 A.3 TeamConnection 1, useful to TeamConnection 2 users . 45 A.4 Related Technical Reports . . . . . . . . . . . . . 45 APPENDIX B. COPYRIGHTS, TRADEMARKS AND SERVICE MARKS . . . 47 FIGURES 1. CMVC terms that have different name/function in TeamConnection . . . . . . . . . . . . . . . . . . . . . 5 2. CMVC family directory structure . . . . . . . . . . . 21 3. TeamConnection family directory structure . . . . . . 21 4. Changes from CMVC to TeamConnection . . . . . . . . . 22 5. CMVC daemon process hierarchy . . . . . . . . . . . . 38 6. TeamConnection daemon process hierarchy . . . . . . . 39 Contents xi xii CMVC and TeamConnection 1.0 INTRODUCTION The purpose of this technical report (TR) is to compare and con- trast the product Configuration Management and Version Control (CMVC) Version 2.3 with its successor TeamConnection Version 2.0. The focus will be on enhanced capabilities in TeamConnection derived from the addition of an object-oriented methodology and object repository. This TR is designed to provide enough information for current CMVC users to quickly become productive TeamConnection users. It is assumed that readers are familiar with the basic functions of CMVC. The organization of this TR is as follows: o Comparison of functions common to both products o New functions affecting general TeamConnection users o New functions and differences impacting family administrators This technical report is not a replacement for the documentation of these products; therefore, the functions will be explained briefly in this TR. For more details, refer to the appropriate documentation listed in the bibliography, Appendix A, "Bibli- ography" on page 45. The best way to find out how the client functions really work, is to run/review the following samples: o In CMVC, /usr/lpp/cmvc/samples/README.demo2 and demo2.tar. o In TeamConnection, /usr/teamc/samples/univunix. The univunix utility runs the TeamConnection commands in univunix.cmds which you can modify. 1.1 COMPATIBILITY TeamConnection is the successor product to CMVC. TeamConnection has evolved and been extended to support object-oriented develop- ment. Both products have a lot in common; however, because of changes in TeamConnection these products are not compatible with each other. That is, you cannot use a CMVC client with a TeamConnection server or a TeamConnection client with a CMVC server. A migration facility is provided with TeamConnection to move your CMVC family to TeamConnection. There are no utilities to migrate a TeamConnection family to CMVC. Introduction 1 1.1.1 Migration from CMVC to TeamConnection ____________________________________________ The technical report "How to do migration tasks with CMVC", TR 29.2232, describes (in Chapter 6 "Preparing to migrate to TeamConnection") how to prepare a CMVC family to be migrated to TeamConnection. Follow the instructions in the TeamConnection Administrator's Guide (Chapter 16 "Migrating to TeamConnection version 2") to perform the actual migration from a CMVC family to TeamConnection. 1.2 THE BIG DIFFERENCES The main differences between CMVC and TeamConnection that CMVC users will experience when migrating to TeamConnection are shown below. There is more detail in the sections 2.0, "Comparison of common functions" on page 5 and 3.0, "New user functions of TeamConnection" on page 23. o The names of several objects have changed. For example, tracks are now workareas and levels are now drivers. For more details see 2.1, "Command names" on page 5. o Workareas are much more important than tracks and behave dif- ferently. For more details see 3.5, "Workareas are more than renamed Tracks" on page 27 - A workarea needs to be specified in all teamc part -checkin and -checkout commands. Even if you are just using TeamConnection to store parts in a single release without any defects or features, you need to create a workarea and periodically integrate and commit your changes. - You will periodically be required to refresh your workarea before you perform actions like integrating the workarea, or checking parts in or out. For example, if you try to check out a file that another user has updated in a different workarea, but has not being committed, you will need to refresh from that workarea. o The versioning scheme is different. Version identifiers are now related to the workarea, and are not global. Further- more, workareas, drivers and releases are versioned. For more details see 3.3, "Versioning" on page 24 2 CMVC and TeamConnection o When performing queries, like filling in a filter window, you are often querying within a context instead of using the entire family. Therfore, you need to specify that context by entering a release, a driver or a workarea. If you do not provide enough context you will get an error or not be able to press the OK button. For more details see 2.7.4, "Query facility" on page 17. Introduction 3 4 CMVC and TeamConnection 2.0 COMPARISON OF COMMON FUNCTIONS 2.1 COMMAND NAMES When comparing TeamConnection and CMVC, the most obvious change is the naming of the client commands. All TeamConnection com- mands now begin with "teamc", for example, "teamc report". Most of the CMVC and TeamConnection commands are the same. However, the table below lists commands that have changed names: +---------------------------------------------------------------+ | Figure 1. CMVC terms that have different name/function in | | TeamConnection | +------------+------------+-------------------------------------+ | CMVC | TEAMCONNECT|OCOMMENT | +------------+------------+-------------------------------------+ | File | Part | To better describe the range in | | | | granularity of the objects that can | | | | be managed. | +------------+------------+-------------------------------------+ | Level | Driver | To conform with common industry | | | | terms | +------------+------------+-------------------------------------+ | LevelMember| DriverMembe| To conform with the change for | | | | Level | +------------+------------+-------------------------------------+ | Track | Workarea | To conform with the functionality | | | | change in workarea. | +------------+------------+-------------------------------------+ | cmvcd | teamcd | To reflect the name of the product | +------------+------------+-------------------------------------+ | cmvc | teamcgui | To reflect the name of the product | +------------+------------+-------------------------------------+ | stopCMVC | stopteamc | To reflect the name of the product | +------------+------------+-------------------------------------+ NOTES: 1. The actions in the Authority table reflect the corresponding names, such as FileView in CMVC and PartView in TeamConnection. 2. In Windows and OS/2, where commands are limited to 8 charac- ters some of the CMVC names have been abbreviated. 3. Some versions of the OS/2 client contain compatibility com- mands (for example, Report.exe). These will be removed at a later date. Comparison of common functions 5 2.2 CONFIGURATION MANAGEMENT Both CMVC and TeamConnection provide support for the process of identifying, organizing, managing and controlling software modules. This is accomplished by components and a component hierarchy. 2.2.1 Components and component hierarchy _________________________________________ A component hierarchy allows software modules to be grouped for organization purposes and to control the access of users to those software modules. For example, an application can create compo- nents to separately manage access to server code, client code and documentation. A component can have zero, one or more child components, as well as one or more parents. The top component of the hierarchy, "root", has no parent; consequently, all the rest of the active components are descendants of the "root" component. However, deleted components also do not have parents. The access list and the notification lists are inherited from the parent component to its descendants. 2.2.2 Access to components ___________________________ An access list associated with a component specifies an authori- zation level for each user, which determines the action that the user can perform on that component and its descendants. For example, a user with a "general" access has the CompView authority that allows the user to view the description of the specified component (or its descendants) but does not have the PartAdd authority that is needed to create a software module. The above authorities can be restricted in a specific component. However, child components do not inherit these restrictions. There are certain actions that all users are able to perform, regardless of their access list. These actions are called "base authorities", such as opening a defect and adding remarks to it. There are other actions that each user has implicit authority for, such as modifying the properties for the user object in CMVC or in TeamConnection. 6 CMVC and TeamConnection The users who have "superuser" authority are allowed to perform any action that is legal, given the current process configura- tions and the state of the TeamConnection object being manipu- lated. For example, a superuser can cancel any defect that is not already associated with a workarea. 2.2.2.1 Differences o Some actions from the CMVC authority.ld have been renamed in the TeamConnection authorit.ld file; which is loaded into the database as the Authority table. For example, the FileView action has been renamed to PartView o Furthermore, some new actions have been added to TeamConnection to reflect the new functions. 2.2.3 Notification mechanism _____________________________ A notification mechanism sends mail to team members as software modules change and as other actions are taken with objects in the product. There are some explicit notifications that the user may want to receive and this is accomplished by registering to a notification list in a given component. For example, if a user wants to be notified when a new release is created in that component, then the user can add the "developer" notification list. There is no support for finer granularity of events, such as the notification for all changes for one particular defect. The actual notification is performed by means of the Notification Daemon (notifyd). This daemon runs a script which can be custom- ized, for example, to use a mechanism other than sendmail. 2.2.3.1 Differences o Some actions from the CMVC interest.ld have been renamed in the TeamConnection interest.ld file; this file is loaded into the database to populate the Interest table. For example, the FileView action has been renamed to PartView. o Furthermore, some new actions have been added to TeamConnection to reflect the new functions. Comparison of common functions 7 2.2.4 Customized processes for components __________________________________________ The components are the objects from which defects and features (see 2.4.2, "Defects" on page 12 and 2.4.3, "Features" on page 12) are opened and manipulated. The process to handle the defects and features is customizable by component; that is, one component can have one process, and another component can have another process. The process for a component could include the following subproc- esses: o Design-Size-Review (DSR) o Verify subprocess Depending on the subprocesses, it is possible to have the fol- lowing records: o sizing records to identify the sizing activities during design o verification records to accept or reject the defect/feature. 2.3 RELEASE MANAGEMENT Both CMVC and TeamConnection provide support performing a logical organization of objects that are related to an application. This is accomplished by releases. 2.3.1 Releases _______________ A release provides a logical view of objects that must be extracted, built, tested and distributed together. Furthermore, a release can be linked to another release. Both CMVC and TeamConnection provide support for handling serial development; that is, only one user at a time can have a lock on a file. The release may have an approval list and environment list. 8 CMVC and TeamConnection 2.3.1.1 Differences TeamConnection has added the following functionality to releases: o Concurrent development. A release can be created to allow concurrent development, that is, more than one developer at a time can update a part. For more details see 3.1, "Sequential/Concurrent development" on page 23. o Collision records. When using concurrent development, if two or more users are updating the same part, then a collision record is created upon the first checkin of that part (that is, the first one in wins, the second gets a collision record). The workarea receiving the collision record needs to resolve the differ- ences prior to integration. We suggest using the TCMERGE tool, available on Windows and OS/2. For more details see 3.1, "Sequential/Concurrent development" on page 23. o TCMERGE: Graphical tool to merge different versions of a part. To help the handling of collision records, TeamConnection provides a GUI utility called TCMERGE that shows the differ- ences between two parts and allows the user to manually merge the parts into one part. Currently, this tool is not available in UNIX. o Versioning releases. In TeamConnection the releases can be versioned in the same manner as other versionable objects in TeamConnection. For more details see 3.3, "Versioning" on page 24. o Building and packaging releases. By using the new build and packaging functions in TeamConnection, the releases can be built and packaged from within TeamConnection, without the need to extract the release and invoke the make utilities to build the code. For more details see 3.11, "Build support" on page 32. o Pruning. Comparison of common functions 9 A release can be automatically pruned under certain condi- tions. For more details see 3.2, "Automatic pruning of releases" on page 23. 2.3.2 Approval List ____________________ The approval list contains the users who can approve the changes to be made in a release. 2.3.3 Environment List _______________________ The environment list contains the platforms or environments that need to be tested when the changes are incorporated into the release. 2.3.4 Customized processes for releases ________________________________________ The process to handle the releases is customizable, that is, one release can have one process, and another release can have another process. The process for a release could include the following subproc- esses: PROCESS PURPOSE TRACK Require defects or features to be associated with all tracks (CMVC) or workareas (TeamConnection). In other words, you need a reason to make a change. APPROVAL Require approval for each track/workarea before changes can be made to the track/workarea. This is usually used to limit development activity as you approach delivery of the release. FIX Used to identify components where files/parts are changed. Completing a fix record is a useful mechanism for developers to indicate that their track/workarea is ready to be integrated. 10 CMVC and TeamConnection LEVEL (CMVC) OR DRIVER (TEAMCONNECTION) Levels/Drivers are used to incrementally integrate and commit a set of changes in a release. This makes incremental development and the delivery of beta drivers easy to manage and recreate. TEST Used as a verification method for someone other than the originator of a defect or feature. Useful when a test group or some other users need to evaluate a change prior to the originator taking final action. Depending on the subprocesses being used, the following records may be used: o approval records which are used by those users that are in the approval list. o fix records which are used by those users who are responsible for the components where the changes will be incorporated. o test records which are used by those users who need to test the changes in the specified environments. 2.3.4.1 Differences The CMVC Level subprocess is called Driver in TeamConnection. 2.4 CHANGE CONTROL 2.4.1 Overview _______________ Both CMVC and TeamConnection keep track of any file changes you make and the reasons you make them. After changes are made, you integrate the changes and build the application. NOTE: It is not necessary to make a change prior to integrating tracks (CMVC) or workareas (TeamConnection). An empty track/workarea can be promoted for documentation or record keeping purposes. Both products ensure that the change process is followed and that the changes are authorized. The change control process is configurable and your team can decide how strict the change control should be, from loose to very tight. You can also adjust the level of control as you move through a development cycle. Comparison of common functions 11 Defects and features are used to identify the requirements for the file changes. There is an audit trail associated with each defect and feature. The history information includes who opened it, who accepted it, a description of the problem or suggestion, etc. The defects and features can be "aged" in order keep track of how long the defect or feature has been active. 2.4.1.1 Differences TeamConnection also adds a timestamp to each entry in the audit log for more complete tracking of family activity. 2.4.2 Defects ______________ A defect is opened (but not created) to report a problem. The process to handle the defect depends on the process config- uration for the component where the defect was opened. See 2.2.1, "Components and component hierarchy" on page 6. 2.4.3 Features _______________ A feature is opened (but not created) to request a design change to a future function. The process to handle the feature depends on the process config- uration for the component where the feature was opened. See 2.2.1, "Components and component hierarchy" on page 6. 2.5 VERSION CONTROL Both CMVC and TeamConnection provide support for the process of tracking the relationships among the versions of the various software modules that form an application. Version control with configuration management enables you to build your product using stable levels of code, even if the code is constantly changing. 12 CMVC and TeamConnection Version control allows you to view the different snapshots of a file over time: as the file was created, as it was one month ago, as it is today. The file changes need to be done in the context of a release. These changes are done by means of CMVC Tracks or TeamConnection Workareas, which in turn are integrated into a CMVC Level or a TeamConnection Driver. These integrated changes will eventually be committed by following the release process. 2.5.1.1 Differences The implementation of versioning has been completely replaced in TeamConnection. For more details see 3.3, "Versioning" on page 24. 2.5.2 Files (CMVC) or Parts (TeamConnection) _____________________________________________ The software modules for your application are stored in files in CMVC (and parts in TeamConnection). Files are then created and modified to address defects and features. These files are asso- ciated with a component for the authorization of who can do what, and with a release for the actions of extraction, subsequent build and packaging. The files are versioned and both products handle the versioning of text (such as a file that contains source code in C) and binary files (such as an executable file). Both CMVC and TeamConnection provide expandable keywords that can be embedded in the files. This information identifies the context of the build (for example, which release the file came from), and when the files are extracted, these expanded keywords provide useful information to developers trying to determine where a source file or executable came from. 2.5.2.1 Differences o TeamConnection parts are more than CMVC files. The granularity was expanded to include fine-grained objects that are not extracted as files, such as VisualAge Generator objects. Further, TeamConnection parts have attributes that are used during build and packaging. For more details see 3.3, "Versioning" on page 24 and 3.4, "Parts are more than just Files" on page 26. Comparison of common functions 13 o In CMVC, there are 2 sets of expandable keywords, one if the family is configured to use SCCS (the most widely used type) and another if the family uses PVCS. TeamConnection provides a new and more flexible syntax for providing the same keyword capabilities as SCCS. o The TeamConnection Part command does not have a -destroy action. Parts can still be deleted from a release, but not physically removed. o The TeamConnection Part command adds actions to support the building of parts. o The TeamConnection Part object uses in the lastUpdate attri- bute the date and time from the file system of the file that is being checked in. Thus, during the extraction, the file will have the same date and time that the file had during the most recent check-in. In contrast, in CMVC, the lastUpdate attribute changed for ANY action that affected either the contents or the attributes of the file, and this date and time was used during the extraction. 2.5.3 Tracks (CMVC) or Workareas (TeamConnection) __________________________________________________ In CMVC, depending on the process of the release, if the track subprocess is activated, then you need to specify a CMVC Track that will identify the file changes with a defect/feature and a release. For more details see 3.5, "Workareas are more than renamed Tracks" on page 27. You may specify that a given Track/Workarea needs to be inte- grated with another one, and thus, they will become corequisites. 2.5.3.1 Differences TeamConnection workareas are more powerful and useful than CMVC tracks due to the TeamConnection's object-oriented design. o Workareas in TeamConnection are the context by which you view a release (a logical view). As such, you must specify always a workarea. o Further, you may open multiple workareas for a defect or feature in one release. For more details, see 3.5, "Workareas are more than renamed Tracks" on page 27. o TeamConnection add the concept of a prerequisite so that two workareas do not need to change the same part in order to 14 CMVC and TeamConnection establish a relationship that will insure they are integrated to the same driver. 2.5.4 Levels (CMVC) or Drivers (TeamConnection) ________________________________________________ In CMVC, depending on the process of the release, if the CMVC Level subprocess is activated, then you need to integrate the CMVC Track into a CMVC Level by means of a CMVC LevelMember. Similarly, in TeamConnection, depending on the process of the release, if the TeamConnection Driver subprocess is activated, then you need to integrate the TeamConnection Workarea into a TeamConnection Driver by means of a TeamConnection DriverMember. 2.5.4.1 Differences TeamConnection Drivers are also more powerful and useful than CMVC Levels. See 3.6, "Driver has more options than Level" on page 28 for more details. 2.6 USERS AND AUTHENTICATION OF USERS Each user has a unique ID in CMVC or TeamConnection. Be default, it is used in combination with a hostname and a system login to control access to the family. In OS/2 and in Windows 3.1, because there is no system login, a variable is used instead; in CMVC the variable is USER and in TeamConnection the variable is TC_USER. 2.6.1 Differences __________________ The functionality of the user is the same, but the authentication of users has been expanded in TeamConnection to use passwords and to require users to login into TeamConnection, and this makes optional the use of the hostname and system login as part of the authentication. For more details, see 3.9, "Authentication by means of login" on page 31. Comparison of common functions 15 2.7 ARCHITECTURAL ISSUES 2.7.1 Client/Server Design ___________________________ Both CMVC and TeamConnection have a client/server architecture, in that the GUI and client communicate across a TCP/IP socket to a family server. The socket is identified by "FamilyName@FamilyHost@SocketNumber". The client consists of a command line interface and a graphical user interface (GUI). The GUI constructs and issues line com- mands. The line commands issued are stored in a log file (the location is set in the GUI's settings pages). 2.7.1.1 Differences In TeamConnection, instead of having one executable file for each line command, such as with the CMVC "Report" command, a single executable teamc, contains all functions for specific command such as "teamc report". This approach allows to have the same name for UNIX and OS/2 commands. For example, in CMVC, the UNIX command "LevelMember" had to be renamed in OS/2 as "levelMem". TeamConnection adds a second client/server interface, the Object Repository. This allows C++ programs to access data in the family server through an object-oriented application programming interface. See 3.13, "Object Repository and Information Model" on page 33 for more details. 2.7.2 Customization aspects ____________________________ The family can be customized in the following aspects: o Configuration types (config.ld) The family administrator can add more new types for items that have multiple-choice values. o Configurable fields It is possible to add extra fields to the following objects: - Defects - Features - Users 16 CMVC and TeamConnection - Files (CMVC) or Parts (TeamConnection) For the family administrator there are several small changes. See 2.9, "Family administration" on page 20 for more details. o User exits (only on the server side) Both products allow you to extend their functionality to a certain degree by allowing the family server to invoke utili- ties developed by the family administrator when certain actions/conditions occur. For more details, see 4.2, "User exits" on page 36. 2.7.3 Integration with other products ______________________________________ In CMVC and TeamConnection it is possible for other applications to use the command line interface to interact with the product. 2.7.3.1 Differences o In CMVC, a UNIX client GUI is provided that is integrated with the product Softbench. TeamConnection is not integrated to Softbench, but will integrate to other similar "framework applications" in the future. o In TeamConnection, API's are provided for other tools to invoke TeamConnection command line capabilities from a func- tion library, and to access TeamConnection data through an Object Repository (see 3.13, "Object Repository and Informa- tion Model" on page 33 Applications such as VisualAge Gener- ator use both API's integrate to TeamConnection. 2.7.4 Query facility _____________________ Both CMVC and TeamConnection allow queries to the database that are based on SQL. Comparison of common functions 17 2.7.4.1 Differences o CMVC simply passes thru the SQL queries to the database man- agement system (DBMS) of the relational database and the DBMS responds to the queries. o TeamConnection provides an SQL translation facility on top of an object-oriented database. Users should not see any dif- ferences in capabilities. o The TeamConnection report command now checks access lists and returns only the rows of data that a user is authorized to see. o CMVC and TeamConnection have basically the same common tables and views, with the exception of the new functions for TeamConnection (such as ParserView) and the renaming of some functions (such as Levels to Drivers). o The TeamConnection teamc report command offers two new options: - -testClient verifies the configuration of the client without contacting the server. - -userExitInfo provides information on user exit to super- users. 2.7.5 Migration utilities __________________________ CMVC and TeamConnection provide utilities to migrate to the most current versions of each product. Further, TeamConnection pro- vides a utility to migrate from CMVC to TeamConnection 2.0. CMVC provides utilities to migrate from SCCS to CMVC. 2.7.6 Year 2000 Compliance ___________________________ CMVC uses 2 digits to store the information about the year. Although CMVC does not parse or use this information directly, when the user requests sorting by date (the actual sorting is done by the database) it might be possible that the year 2000 might not be sorted properly. TeamConnection uses 4 digits to store the information about the year. Thus, TeamConnection is fully compliant with the Year 2000 requirement. 18 CMVC and TeamConnection 2.8 SUPPORTED PLATFORMS AND DATABASES 2.8.1 Family server ____________________ Both products support family servers in the following platforms: o AIX Version 4 o HP-UX Version 10 NOTE: The port to Solaris is being done at the time this TR is being prepared. TeamConnection adds the following server platforms: o OS/2 Warp o Windows NT CMVC supports the following "older" server platforms. This support will not be added to TeamConnection: o AIX Version 3 o HP-UX Version 9 o SunOS 4.1.3 2.8.2 Clients ______________ Both products support clients (GUI and line commands) in the fol- lowing platforms: o AIX Version 4 o HP-UX Version 10 o OS/2 Warp o Windows 3.1 (GUI only) o Windows 95 and Windows NT NOTES: 1. The port to Solaris is being done at the time this TR is being prepared. 2. The Windows 32 bit support in CMVC is beta only. CMVC supports the following "older" client platforms. This support might be added to TeamConnection at a later date (depending upon demand): o AIX Version 3 o HP-UX Version 9 o SunOS 4.1.3 Comparison of common functions 19 2.8.3 Databases ________________ CMVC supports the following relational databases: o DB/2 Version 1 and 2 o Oracle Version 7.x (excluding 7.3 and later) o Informix Version 5 and 7 o Sybase Version 4.9 and 10 TeamConnection supports only the following object-oriented data- base: o ObjectStore (bundled with TeamConnection and not distributed separately). 2.8.4 License handling _______________________ CMVC uses NetLS to enforce that the maximum number of concurrent users complies with the number of licenses that the customer acquired. For more details, see 4.3.1, "License handling in CMVC" on page 36. TeamConnection, on the other hand, uses a utility named tclicmon (TeamConnection License Monitor) to monitor the audit.log of the family to see if the maximum number of concurrent users is within the bounds. 2.9 FAMILY ADMINISTRATION CMVC and TeamConnection use a family to contain the objects and files associated with a project or a set of projects. For each family there is a database that is dedicated only to that family. In UNIX, a system account is created for a family. In Intel, a directory is used for a family. 20 CMVC and TeamConnection 2.9.1 Structure of a family account ____________________________________ CMVC stores the file changes in a directory structure from the family file system and stores the information about the objects of the family inside the relational database. In contrast, TeamConnection stores both the part changes and the information about the objects of the family inside the same data- base. As a result all updates happen within a single database transaction to improve data integrity. The directory structure for CMVC and TeamConnection are similar; They are shown in Figure 2 and in Figure 3; the comments describe the differences: authority.ld * config.ld * cfgcomproc.ld * cfgrelproc.ld * config.ld * interest.ld * audit/log * Separate directory for audit log files configField/ maps/ * The driver information is stored in the database in TeamConnection queue/messages * Separated addressing information and text vc/ * The file data is stored in the database in TeamConnection Figure 2. CMVC family directory structure authorit.ld * comproc.ld * config.ld * interest.ld * relproc.ld * audit.log * Audit directory removed cfgField/ * queue/ * Messages stored in one file in one directory Figure 3. TeamConnection family directory structure Comparison of common functions 21 NOTES: 1. The items marked with * indicate items that are needed to create a family. 2. The file names in configField (CMVC) differ from the ones in cfgField (TeamConnection). The differences in the family directory structure between CMVC and TeamConnection are shown in Figure 4. CMVC TeamConnection -------------- -------------- authority.ld authorit.ld cfgcomproc.ld comproc.ld cfgrelproc.ld relproc.ld configField/ cfgField/ queue/messages queue/ maps REMOVED vc REMOVED Figure 4. Changes from CMVC to TeamConnection 2.9.2 Suggestions __________________ In CMVC, it is strongly recommended (and is somewhat enforced by the tools) to have one family in a single system account. In TeamConnection, it is also strongly recommended to have one family in a single system account; however, it is possible to handle several families in one system account. 2.9.3 Family administration tools __________________________________ In TeamConnection, a GUI tool called TCADMIN is the utility that is used to create and to maintain a family. Most other tools have changed names. For more details see 4.1, "TCADMIN - System Administrator's GUI" on page 35. The format for the views of the configurable fields was changed from CMVC to TeamConnection. 22 CMVC and TeamConnection 3.0 NEW USER FUNCTIONS OF TEAMCONNECTION This chapter elaborates on new TeamConnection functions of interest to general users. 3.1 SEQUENTIAL/CONCURRENT DEVELOPMENT CMVC provides only the mode of sequential development, in which a file can be locked only to one user at a time. TeamConnection also provides this mode of sequential development, but it offers a mode of concurrent development in which a part can be locked by more than one user at a time, and then when the different versions of the parts are checked-in, there will be collision records that the users would have to resolve to ensure that one user is not deleting the code added by another user. This concurrent mode is available only per release and it is specified only at the time a release is created. A release that is created with sequential mode cannot be changed later on to concurrent development. 3.2 AUTOMATIC PRUNING OF RELEASES In CMVC, every checkin of a file created a new version number. This leads to saving versions of files that were not useful in the long term. TeamConnection lets you control the versions you keep during your development process without limiting the number of times you check your files/parts into a workarea. By using release pruning and workarea freeze you can specify how many of the intermediate checkins you perform will be kept and how many can be discarded after you integrate and commit a workarea. You can prune a committed branch (workarea or driver) of a release by using the command "teamc release -prune". It is possible to specify that a release can be pruned automat- ically for committed branches (work areas or drivers); this is accomplished with the +autopruning flag in the command "teamc release -create" or "teamc release -modify". For more information about this topic and for a graphical expla- nation of the branches, consult the Versioning Model in Page 82, New user functions of TeamConnection 23 Chapter 2 "TeamConnection", in the manual "Introduction to the IBM Application Development Team Suite". 3.3 VERSIONING In CMVC, only files are versioned either by SCCS or PVCS. These utilities determine the version numbers based on the number of changes and take into account when links are broken between releases. The entire architecture of versioning in TeamConnection is new. TeamConnection versions most of the objects you use in develop- ment: parts, workareas, drivers and releases. The scope of a version is based on your release and workarea, so that the version of a part now has a meaningful context. Furthermore, in TeamConnection, the version control allows the users to provide control over which changes are available to everyone by processing the workareas; for more details, see 3.5, "Workareas are more than renamed Tracks" on page 27. 3.3.1 Versioning in CMVC _________________________ CMVC uses the UNIX utility SCCS as the underlying mechanism for the versioning of the files. The product PVCS can be purchased for use with CMVC on AIX 3.x platform. In SCCS, numbers begin with 1.1 and the second digit is incre- mented with each version checked in (for example, 1.2, 1.3, etc). When a release or file is linked and then a link is broken during a check-in, a branch occurs in the numbering. For example, if release_1 is linked to release_2 when file_a is version 1.3, both releases will point to version 1.3. If only release_2 checks in a new version of file_a, the link will be broken to release_1 and the new version number will be 1.3.1.1. The approach in PVCS is similar, but not identical. The important point is that the numbering scheme is global and managed by SCCS/PVCS. It does not show any practical relation- ship between changes and the workarea/release where the change occurred. Space is saved when storing files in CMVC in the following manner: o SCCS/text files are stored as forward deltas by SCCS. This saves space by comparing each file to the previous version 24 CMVC and TeamConnection and only saving the changes. The drawback is that it takes longer to extract the most current version (it must be con- structed from the previous changes). o SCCS/binary files are stored as backward deltas by CMVC. If the changes between the current and previous version are beyond a specified level they the whole current file is stored. Backward delta means that the most current version is a whole file and previous versions are stored as deltas. As a result it is faster to extract the current version but slower to extract old versions. SCCS has lots of limitations in the types of data it can store so lots of files that you would expect to be text are really stored as binary. o PVCS/all files are stored as forward deltas by PVCS. One drawback the separate processing for text and binary files in SCCS is that files cannot be changed on the fly from one type to another. If you want to change the type, then you must delete and destroy the file and then recreate it with the new type. 3.3.2 Versioning in TeamConnection ___________________________________ In TeamConnection, all parts are managed and versioned in the database. Here is what we do to them: o Text files are compressed and versioned using forward deltas. o Binary files are compressed and each version is stored whole. This allows you to change on the fly the type of the part, from text to binary and vice versa. 3.3.3 Finding different versions of TeamConnection objects ___________________________________________________________ The version control of TeamConnection maintains different ver- sions of the following objects: o Releases o Work areas (and driver members) o Drivers o Parts When you want to find and retrieve previous versions of these objects, it is helpful to know how TeamConnection creates and deletes previous versions of each object. New user functions of TeamConnection 25 o When you first create an object, the initial version name is the object name suffixed with ":1". When you create a new work area called "myWorkArea", for example, its version is "myWorkArea:1". Subsequent versions are identified in numer- ical order: myWorkArea:2, myWorkArea:3, myWorkArea:4, and so on. Versions of releases and drivers are identified similarly: myRelease:1, myRelease:2, myRelease:3; myDriver:1, myDriver:2, myDriver:3; and so on. o Unique versions of parts are identified by association with a specific version of a release, work area, or driver. Your family may have three different versions of a part called "myPart", one associated with release myRelease:2, one asso- ciated with work area myWorkArea:1, and one associated with work area myWorkArea:2. 3.4 PARTS ARE MORE THAN JUST FILES TeamConnection parts are more than just files. The most impor- tant changes are: o Parts can be more than just files (of type text and binary). Parts may also be type "none" indicating that they will not be extracted as files; this is used for object level inte- gration with other tools. o Parts include attributes defining their behavior during build and packaging. 3.4.1 File/Part links ______________________ From a user's point of view, parts are linked between releases and links can be broken in the same manner in CMVC and TeamConnection. However, there are two differences: o In TeamConnection Version numbers are not dictated by the when links are broken, rather, the numbering is based on the workarea and release. o In TeamConnection parts are copied into each release, regard- less of whether there is a link. So if a part is linked in two releases it still takes up twice the space as it would if it were in one release. 26 CMVC and TeamConnection 3.4.2 Changing the type of a file (text <-> binary) ____________________________________________________ in TeamConnection you can change the type of a file without the need to destroy the file and then to recreate it again. NOTES: 1. The "type" field in CMVC is called "fileType" in TeamConnection. 2. The main changes about the file type from CMVC File to TeamConnection Part are: File -type text --> Part -text File -type binary --> Part -binary new Part -type (for fine grain objects) 3.5 WORKAREAS ARE MORE THAN RENAMED TRACKS A workarea provides a logical view of a release that includes all of your changes and excludes the changes of all other workareas that have not been promoted. While a CMVC track is just a list of the changes for a given defect or feature within a release, a TeamConnection workarea lets you see the impact of a defect or feature without needing to compare the version numbers of every file that has uncommitted versions. In other words, a CMVC Track just contains file changes, but a TeamConnection Workarea is a view of the entire release. You cannot build a Track, but you can build a Workarea because it includes all the parts. In CMVC you could use a release process such as 'prototype' which would allow you to create and checkin files without the need to specify a track. By contrast, in TeamConnection, you always have to specify the information about the workarea in order to create and checkin parts. However, in release processes such as 'prototype' it is not necessary to name a workarea after a defect or feature, that is, you can use any name that may help you identify the workarea (it has to be unique). New user functions of TeamConnection 27 3.5.1 Multiple workareas per defect or feature _______________________________________________ A significant improvement in TeamConnection over CMVC is the ability to create more than one workarea for a defect or feature within a release. This allows you to break up the work you are doing into pieces, even to commit the work a piece at a time. You can include parts from other workareas, including currently committed drivers or releases. 3.5.2 Workarea performance ___________________________ For users of prototype releases it is important to periodically integrate a workarea into the release in order to maintain good performance. 3.5.3 teamc workarea -undo ___________________________ Workareas are versioned objects; as a result, you need to undo new versions of workareas in TeamConnection just like you do files in CMVC. If a workarea has been frozen or refreshed from another workarea (refreshing causes an implicit freeze), then teamc part -undo is not enough to remove all changes from the workarea (as File -undo could do for a CMVC track). After using Part -undo on any files that have been changed since the last freeze, use teamc workarea -undo to remove each freeze that occurred. The "teamc report -view versionView" command reports each freeze that occurred (that is, reports each version of the workarea). From the GUI WorkArea window, select Selected->Show->Versions. 3.6 DRIVER HAS MORE OPTIONS THAN LEVEL Because the CMVC map files have been replaced with state data in the database, drivers can now list all of the parts and their versions that are in a committed driver. One side effect of the change from Levels to Drivers is that it takes longer to integrate workareas into drivers. The "teamc driver" command has two new options that give you more flexibility. 28 CMVC and TeamConnection 3.6.1 teamc driver -freeze ___________________________ Because a driver is really a specialized workarea, you can save a snapshot of the driver's contents prior to committing. Depending on how you have set the pruning of the release, this allows you to either temporarily or permanently version the changes in a driver. This is particularly useful if you do not commit drivers frequently. 3.6.2 teamc driver -restrict _____________________________ Restrict is a state for drivers between integrate and commit. The purpose is to allow a release's build administrator to limit the ability of other users to change the contents of a driver while building and verifying the build. The typical use of restrict is in conjunction with some automated promotion and build process. For example, at 7 PM every night a process is started that adds all workareas in a release that are in integrate state, that is, all the fix records are completed, to the driver by creating driver members. After adding the workareas to the driver, a build is started. Without the restrict state the only way to prevent changes to a driver while build is running is to either change all users access (affecting the entire release) or to commit the driver (preventing further changes). By using restrict, the tool can commit the driver after a suc- cessful build or regression test. If the build or regression test fails, then notifications can be sent to the development team to make the necessary changes to complete the build and pass the regression test. At that point the build administrator can promote the changes, build, test and commit the driver without anyone else changing the driver contents. 3.7 UPDATED INTEL GUI The GUI for Intel operating systems has evolved significantly from the original CMVC GUI. Examples of new features in the TeamConnection GUI are: o The TeamConnection Part command adds an -edit action that performs checkout, opens an editor session, then checks the part back in after the editor session is closed. o Better context-sensitive menu options when selecting an entry in a dialog by pressing the right-mouse button. New user functions of TeamConnection 29 o More options on the Settings dialog, such as selecting whether the read-only attribute should be set. NOTE: This compares the TeamConnection V2 Intel GUI with the CMVC version 2.3.0.18 Intel GUI. 3.8 NEW UNIX GUI CMVC users of the OS/2 or Windows GUI are already familiar with the TeamConnection Intel GUI. The TeamConnection Unix GUI is now based on the Intel design; as a result of using the Intel design, the following has changed for Unix GUI users: o You now have a settngs page for changing the defaults for options. You should not need to edit the Teamcgui X-Windows resource file to change the teamcgui defaults. o The task list queries now support the use of environment var- iables. As a result, the default tasks do not need to be customized to be useful. o There is a significant increase in the use of icons that are associated with each TeamConnection object. For example, there is a generic icon for defect, another for component, etc; then when you are showing a list of defects you will see the same generic icon in the left hand side, one icon for each actual component. Each icon provides additional infor- mation on the state of the objects, such as a defect in working state has a different icon than a defect that was canceled. The GUI uses "containers" to show the components and drivers, and you can select a Tree-View which will show the icons with a plus or a minus sign. Then you can click on these signs to expand or contract a specific component. This provides an equivalent function to the CMVC Component Tree hierarchy. o A command window has been added. This allows you to use line commands without out opening a shell window. o After selecting an object (for example, a defect in the defect window), a right-mouse click provides a context sensi- tive menu of actions. o You an edit and invoke queries on each object window without opening the filter window, by using the footer in that window. 30 CMVC and TeamConnection 3.9 AUTHENTICATION BY MEANS OF LOGIN TeamConnection provides several authentication methods, one of which requires users to use the command called "tclogin". With this command the user uses the TeamConnection License Manager in the client and logs in once into a TeamConnection family using a valid password. If the user is authorized, then the family server and the login manager keep track of the login status and allows the user to issue other TeamConnection commands. The family administrator could setup the family to use the fol- lowing methods for authentication. o Only use host entries, which is the default: HOST_ONLY This is the only option in CMVC. o Only use the method of login with password: PASSWORD_ONLY o Either a login with password or a host entry, in that order: PASSWORD_OR_HOST o No authentication method at all: NONE This security feature affects the role of the "Host List" for reaching the doors of the family and for getting in. However, once the user passes the door and gets into the family, then the "Access List" provide the proper authorization to perform certain tasks in TeamConnection. This authentication feature does NOT affect the role of "Access List". While most companies have no reason to worry about someone recon- figuring their workstation/PC to have the same hostname as another machine on the network in order to acquire another user's privileges, it is sometimes a security issue. The authentication method of PASSWORD_ONLY in TeamConnection provides an option to use passwords instead of hostnames as a means of authentication. Because TeamConnection only sends encrypted passwords across the network, this is a vastly more secure form of authentication. This option makes it easier for users to access TeamConnection from mobile locations. 3.10 PLANNING FOR TEAMC RELEASE/DRIVER -EXTRACT ACTIONS TeamConnection V2 extracts all files directly to the client. It is no longer necessary to set the userid (uid) and the group-id (gid), or to worry about the ability to mount a client directory to the server. However, planning is still required whenever you want to manage an extract to a system or to another user other than the client invoking the extract. New user functions of TeamConnection 31 Our recommendation is to do an NFS mount or use any other tool at your disposal (for example, OS/2 NET USE) to place the target directory to the reach of the local host where the family daemon is running and then extract to the client as you normally would. The other popular option would be to issue an rexec to the target machine so that a client installed on that machine can run the extract. 3.11 BUILD SUPPORT The function that enables you to define the structure of your application and then to create it within TeamConnection from your input parts. You can build applications for platforms in addition to the one TeamConnection runs on; currently, you can use TeamConnection to build applications on AIX, HP-UX, OS/2, Windows NT, Windows 95, and MVS. However, because the build function is homogenous, you need to plan to build each platform individually. With TeamConnection's distributed build, managed components or releases can also be built for the enterprise client/server envi- ronment (that is, for the target platforms that may be different from the server platform used for development). With TeamConnection, a development team can set up the build structure once and be able to identify the build rules depending on the task at hand. The build rules are associated with the objects being built so there is no need to search for related build steps in a file used by a separate build tool. The soft- ware configuration management services rebuild only those objects that need to be rebuilt, based on criteria such as date changes. This minimizes the system resources required to accomplish each build reliably. The TeamConnection software configuration management services also determine which parts of a build need to be built in serial and which can be in parallel; it then can parcel out the work to the available machines. Building objects from different technologies, such as procedural and object-oriented languages, through a single rule-based build process reduces integration risks and complexity. 32 CMVC and TeamConnection 3.12 PACKAGING SUPPORT After you complete a build, you can run a specialized build to package and even distribute your product. Currently, TeamConnection supports a generic packaging tool called "gather" and the Netview/DM (Distribution Manager) facility that is now part of Tivoli. 3.13 OBJECT REPOSITORY AND INFORMATION MODEL TeamConnection integrates an object-based repository with soft- ware configuration management functions to provide a managed environment for data-related assets at all levels of business and application information. With TeamConnection, team members of different disciplines interact with the repository to work with information in a form that makes sense for their task. The repository provides a central point of controlling and translating information by allowing access to the data through the integration of tools. A repository provides multiple task-driven views of stored infor- mation, as well as, "inherited" services to all the objects that it manages. Tool integration with the TeamConnection repository provides the ability to decompose the processes of each disci- pline in a team, analyze them, and transform their managed data- objects into their conceptual, logical, and physical implementations, each with their respective views. Underlying all of the views (conceptual, logical, storage) are the object and class definitions required to support these views. This set of definitions represents the Information Model. The TeamConnection repository architecture includes a set of APIs and an open extendible information model so that tools can share data, store their unique data, and use the common software con- figuration management and repository services available in TeamConnection. This capability allows for an open repository that can be extended through TeamConnection services by both tool vendors and developers of in-house tools. Specifically, TeamConnection's information meta-meta model provides a common language for representing various tool-specific meta-models. A tool can reuse or extend TeamConnection classes to define a tool model reflecting attributes, relationships, and behaviors of the objects to be created and used. The information model and the functions for the tool builder are provided separately in the Tool Builder's Development Kit. New user functions of TeamConnection 33 34 CMVC and TeamConnection 4.0 CHANGES THAT IMPACT SYSTEM ADMINISTRATORS There are significant differences in the way CMVC and TeamConnection work and use system resources. The following sections address some of these differences. Much of this infor- mation is not fully documented in either the CMVC or TeamConnection administration manuals. 4.1 TCADMIN - SYSTEM ADMINISTRATOR'S GUI NOTE: The TCADMIN tool is not yet available in UNIX. While TeamConnection still allows you to create, configure and manage your families using commands, there is a new GUI, TCADMIN, that makes all of the configurable elements of a TeamConnection family obvious and easy to manage. Also, you can keep track of all of your families at once by and select which family to modify from the main dialog. For each family you can specify to start/stop the daemons and to change the following characteristics, which are presented as a notebook: o Family information o Initial superuser o Configurable fields o Component processes o Release processes o User exits o Security o Authority groups o Interest groups 4.1.1 Other administrator tools ________________________________ In CMVC, chfield actually interacts with the database and vali- dates the configurable field definition files in configField. In contrast, in TeamConnection, chfield does not interact with the database and relies only in the configurable field definition files in the cfgField directory. Changes that impact system administrators 35 4.2 USER EXITS The CMVC user exit paradigm is supported in TeamConnection. However, the parameters on almost all commands have changed. Further, the possible values for many of the commands have changed. For example, the file "type" in CMVC is either "text" or "binary" but in TeamConnection the values are "text", "binary" and "none". Even worse, in several commands, the values are passed as integers (that is, 0, 1, 2) instead of text strings. TeamConnection adds significant ease of use on top of the CMVC paradigm. You can cause a parameter file to be created that con- tains the values of specific parameters in a binary files. The sample program teamcenv.c allows you to extract the values from the files. TeamConnection adds a family administration GUI that supports the setting up of user exits; see 4.1, "TCADMIN - System Administra- tor's GUI" on page 35. The most significant limitations of TeamConnection user exits are that it does NOT support issuing ANY TeamConnection commands in a user exit. Also, there is NO way to directly access the database using SQL. For user exits that modify the contents of files as they are extracted, checked in, etc. there is one minor change. In CMVC, all text files were normalized to the UNIX standard (carriage- return, CR, between each line). In contrast, in TeamConnection, files are checked in "as is", then normalized by the client during extract or checkout. As a result, the temporary file on the server that is accessible by a user exit may contain CR/LF (Intel standard carriage-return/line-feed) or CR between lines. Further, tabs and/or spaces are altered on the client on the way out. 4.3 LICENSE HANDLING 4.3.1 License handling in CMVC _______________________________ In CMVC, the licenses for the UNIX clients are managed by the use of the product NetLS (also known as iForLS or iFor). This product enforces the number of concurrent users that can work with CMVC. However, NetLS could be difficult to install, to administer and to maintain, specially in complex networks. Further, an inefficiently running NetLS can add up to one minute to each CMVC command. Because of this, the use of NetLS is one of the major dissatisfactors for some CMVC customers. By the 36 CMVC and TeamConnection way, the licenses for the OS/2 and Windows clients do not use NetLS. 4.3.2 License handling in TeamConnection _________________________________________ TeamConnection chose a simpler approach for the licenses: the honor system. That is, the customers will use only the licenses for which they are entitled to. In order to help them with this task, TeamConnection provides a License Monitor utility that will scan the audit log of a family server and will report the highest number of concurrent users. The number of concurrent users is defined as the number of unique combinations of TeamConnection user id, system login, and host name that use the family server in a period of 15 minutes (this default value can be modified). 4.4 BACKUP AND RECOVERY ObjectStore provides a utility, osbackup, for backing up indi- vidual databases. You do not need to stop TeamConnection in order to run the backup, although it is recommended so that you can backup all databases (for each release) at one time, insuring that the backup is consistent for the entire family. There is more documentation on backup and recover in the TeamConnection Administrator's Guide. At the present time there is no facility for removing data from a TeamConnection family. It is anticipated in the future that it will be possible to break the links for a release that uses its own database (a new option when creating a release). 4.5 WHAT PROCESSES ARE STARTED 4.5.1 What processes are started in CMVC _________________________________________ CMVC has a fairly complex hierarchy of daemons, where a single daemon (called "the grand-parent") is started, followed by the number of daemons requested; for example, "cmvc testfam 3" would start 3 daemons. This second set of daemons are called "parents". After all of the parents have started, the grand- parent is terminated. Next, each parent starts a "child" daemon that listens for CMVC clients requesting that a CMVC command be processed. So, from Changes that impact system administrators 37 the example above, 1 grand-parent starts 3 parents which in turn start 1 child each producing 3 children, but when the grand- parent terminates, then there will be 6 processes left running. When a command is issue that needs to temporarily change to your user ID, like "Release -extract", a grand-child is spawned for the duration of the command (with your user ID as the owner). Grand children are also generated for all file operations, where changing to the family account is necessary before running SCCS commands. Also, when calling user exits it is necessary to spawn a grand- child running as the family account in order to prevent a user exit from getting access to root authority. All this was done so that CMVC could handle almost any sort of failure without reducing the number of daemons available to service your requests. The process hierarchy for CMVC daemons is shown in Figure 5. COMMAND: cmvcd testfam 3 HIERARCHY: grand-parent (dies after parents start) /|\ parent parent parent | | | child child child | grand-child (created for duration of commands like Release -extract, File -create and user exits) Figure 5. CMVC daemon process hierarchy 4.5.2 What processes are started in TeamConnection ___________________________________________________ TeamConnection has a much simpler architecture. A single parent spawns one child for each family daemon you request. Also, the parent will spawn a build agent and build processor daemons as requested in the startup command. The parent stays around to keep an eye on all of the children. 38 CMVC and TeamConnection Because the parent does not open the database, therefore it uses no database resources. TeamConnection is not a setuid process and does not need to change user IDs, thus, it only needs to spawn grand-children for such things as user exits. The process hierarchy for TeamConnection daemons is shown in Figure 6. COMMAND: teamcd -a buildsystem@2000 -p pool1 -e HP -s 3 -n testfam 3 HIERARCHY: parent (stays around to manage children) //|\\ parent parent parent build agent build processors | | | (possibly on (possibly on child child child a different a different | system) system) | grand-child (created for duration of a user exit) Figure 6. TeamConnection daemon process hierarchy NOTE: In order for processes in TeamConnection to start and stop properly, you should start all processes using the options on the teamcd command. This will ensure that stopteamc will find all processes and terminate them. 4.6 USE OF DISK SPACE AND MEMORY 4.6.1 Directory /tmp _____________________ CMVC requires that /tmp (or the directory pointed to by the TMP variable) must have free space equal to three times (3X) the largest file to be checked into the family. This is pretty vague, because you rarely know how big your largest file will be. TeamConnection uses /tmp on a per process basis. The use of /tmp by the database ObjectStore can be changed by setting the OS_CACHE_DIR variable in Unix and OS/2, and OS_TMPDIR for Windows installations. Changes that impact system administrators 39 The amount of space used by each process is determined by the value of OS_CACHE_SIZE (the default for OS_CACHE_SIZE is 8 Mb). For example, if you have 3 families, each running 2 daemons plus one build agent each and OS_CACHE_SIZE is set to 100 Mb, you will need 900 Mb free in /tmp: ((6 child daemons + 3 build agents) X OS_CACHE_SIZE of 100 Mb) = 900 Mb 4.6.2 Disk space for the family account ________________________________________ In CMVC, almost all of the disk space is allocated to the vc directory structure. This is where the files are stored. When a file system becomes too big, we recommend that you select a sub- directory (such as, $HOME/vc/0/2) and symbolically link that directory into another filesystem. This allows you to overcome any filesystem size limits. The next largest directory is where you store the database backup or export. 4.6.2.1 Space used by database In TeamConnection, all files and other data are stored in the database. In order to distribute the space consumed by a family, we recommend that you specify a separate database for each large release. Because ObjectStore allows you to physically distribute the data- bases for your releases across systems, you have greater flexi- bility with space allocation than you did with CMVC. There are directions for distributing in the TeamConnection Administrator's Guide 4.6.2.2 Space used by family daemons The TeamConnection temporary directory, tmp/tctmp, stores a tem- porary copy of each part of type tcpart that is checked in or out. The other files stored in the temporary directory tend to be small, so no significant space needs to be allocated. 40 CMVC and TeamConnection 4.6.3 Use of AFS and NFS _________________________ Network distributed file systems such as AFS (formerly known as Andrew File System) and NFS (Network File System) are commonly used for the home directories of users. Furthermore, DFS (Dis- tributed File System) is an industry standard component of DCE (Distributed Computing Environment) and a replacement for AFS and it is expected to become a popular new alternative. The CMVC development and support teams has always discouraged their use for the contents of family accounts or databases, because NFS can be unreliable and because AFS tokens can expire; therefore, we strongly recommend that the database and contents of family accounts must reside physically on the systems running the CMVC daemons. We do understand that customers have success- fully moved less frequently used files in the vc directory struc- ture to NFS mounted drives, but we hope that is limited to a last resort. TeamConnection databases do not work in AFS or DFS filesystems. However, as already indicated, ObjectStore supports distributing databases across systems and this configuration involves the use of NFS. 4.7 MEMORY USAGE In CMVC, most of the memory is used by the database processes; in TeamConnection, it is the same. While ObjectStore has different defaults for maximum values for each operating system (for example, in HP-UX is about 300 Mb per process, AIX is 1 Gb per process), this value is controlled by the OS_AS_SIZE variable. You only need to be concerned about OS_AS_SIZE if you get errors from transactions reporting "Address Space Full". 4.8 FAMILY DAEMONS AND SECURITY/INTEGRATION ISSUES Changes that impact system administrators 41 4.8.1 Process privileges _________________________ The CMVC daemon processes run with the setuid bit on and are owned by root. This allows CMVC to become a specific user (other than the family account) as needed, as well as running the mount command which is owned by root. TeamConnection does not need to use the mount command or change the user id, therefore the TeamConnection daemons do not use the setuid bit and are NOT root processes. The following CMVC security/integration issues are eliminated by this TeamConnection architecture: o There is no need for TeamConnection daemons to be owned by root, thus, eliminating the possibility of a user or system administrator "stealing" root. o The functionality of the CMVC Release/Level extract was changed in TeamConnection Release/Driver extract so that, NFS mounts are NOT needed in TeamConnection. Thus, this change eliminates the need for use of the mount command or to change to a user ID. Another benefit is the elimination of mount failures due to differences in TCP/IP of various operating systems. 4.8.2 Access to data in the family account ___________________________________________ In CMVC, it is necessary for all of the files and directories in the vc directory to have read access for group and other. Even though it is not possible to determine which file is which without access to the database, this is still a security issue. In TeamConnection, the files are stored in the database so that they are much more difficult to access. Further, you can now be more restrictive in the file and directory permissions you use for your family account. 4.8.3 System integration issues ________________________________ The TeamConnection daemon does not have to interact with SCCS. The greatest benefit is that all the work happens in a single database transaction, which improves data integrity. This also eliminates 2 environment variables, as well as a long list of miscellaneous restrictions on the format of "text" files, as well as a lengthy list of obscure SCCS error messages. 42 CMVC and TeamConnection 4.8.4 Other issues ___________________ The teamc report command now has access controls. It is no longer possible for a user without permissions via component access lists to see the data through the report command. Changes that impact system administrators 43 44 CMVC and TeamConnection APPENDIX A. BIBLIOGRAPHY A.1 CMVC 2.3 For more information on how to use CMVC, you can consult the fol- lowing manuals and publications: SC09-1596-01 IBM CMVC Client Installation and Configuration SC09-1597-01 IBM CMVC User's Reference SC09-1631-02 IBM CMVC Server Administration and Installation SC09-1633-00 IBM CMVC Concepts SC09-1635-01 IBM CMVC Commands Reference A.2 TEAMCONNECTION 2 For more information on how to use TeamConnection, you can consult the following manuals and publications: SC34-4551 TeamConnection, Administrator's Guide SC34-4552 Getting Started with the TeamConnection Clients SC34-4499 TeamConnection, User's Guide SC34-4501 TeamConnection, Commands Reference SC34-4500 TeamConnection, Quick Commands Reference A.3 TEAMCONNECTION 1, USEFUL TO TEAMCONNECTION 2 USERS A few publications that have not been updated for TeamConnection 2.0 are still useful. SG24-4648 Introduction to the IBM Application Development Team Suite 83H9677 Staying on Track with TeamConnection Processes (Poster) A.4 RELATED TECHNICAL REPORTS +--- ADD TC TRS HERE -------------------------------------------+ | | | TC TRs | | | +---------------------------------------------------------------+ Appendix A. Bibliography 45 46 CMVC and TeamConnection APPENDIX B. COPYRIGHTS, TRADEMARKS AND SERVICE MARKS The following terms used in this technical report, are trademarks or service marks of the indicated companies: +---------------------+-------------------------------------------+ | TRADEMARK, | COMPANY | | REGISTERED | | | TRADEMARK OR | | | SERVICE MARK | | +---------------------+-------------------------------------------+ | AIX, OS/2, IBM, MVS | IBM Corporation | | DB2/6000, DB2, CMVC | | | VisualAge, | | | TeamConnection, | | +---------------------+-------------------------------------------+ | NetView/DM, Tivoli | Tivoli Systems, a subsidiary of IBM | +---------------------+-------------------------------------------+ | ObjectStore | Object Design, Inc. | +---------------------+-------------------------------------------+ | UNIX, USL | UNIX System Laboratories, Inc. | +---------------------+-------------------------------------------+ | NetLS, Network | Gradient | | Licensing System, | | | iForLS, iFor | | +---------------------+-------------------------------------------+ | OSF, Motif, DFS, DCE| Open Software Foundation, Inc. | +---------------------+-------------------------------------------+ | PostScript | Adobe Systems Incorporated | +---------------------+-------------------------------------------+ | INFORMIX | Informix Inc. | +---------------------+-------------------------------------------+ | ORACLE | Oracle Corp. | +---------------------+-------------------------------------------+ | SYBASE | Sybase Inc. | +---------------------+-------------------------------------------+ | NFS, SunOS, Solaris | Sun Microsystems Inc. | +---------------------+-------------------------------------------+ | HP-UX, SoftBench | Hewlett-Packard Company | +---------------------+-------------------------------------------+ | Windows, Windows NT,| Microsoft Corporation | | Windows 95 | | +---------------------+-------------------------------------------+ | X Window System | Massachusetts Institute of Technology | +---------------------+-------------------------------------------+ | PVCS | InterSolv, Inc. | +---------------------+-------------------------------------------+ | AFS | Transarc Corp. | +---------------------+-------------------------------------------+ | Intel | Intel Corp. | +---------------------+-------------------------------------------+ Appendix B. Copyrights, Trademarks and Service marks 47 END OF DOCUMENT 48 CMVC and TeamConnection