IBM VisualAge TeamConnection Enterprise Server IBM User’s Guide Version 3.
IBM VisualAge TeamConnection Enterprise Server IBM User’s Guide Version 3.
Fourth Edition (March 1998) Note Before using this document, read the general information under “Notices” on page xiii. This edition applies to Version 3.0 of the licensed program IBM TeamConnection and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. Order publications by phone or fax. The IBM Software Manufacturing Company takes publication orders between 8:30 a.m. and 7:00 p.m.
Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . xi Notices . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . xv About this book. . . . How this book is organized Conventions . . . . . Tell us what you think . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authority to perform tasks . . . . . . . . . Finding objects within TeamConnection . . . . . Finding parts . . . . . . . . . . . . . Using work areas . . . . . . . . . . . . Naming your work areas . . . . . . . . . Creating parts. . . . . . . . . . . . . . Naming your parts . . . . . . . . . . . Preparing to build your parts . . . . . . . . Working with parts . . . . . . . . . . . . Working in serial or concurrent development mode Working with common parts . . . . . . . . Getting parts from TeamConnection .
Approving the fix . . . . . . . . Checking out a part . . . . . . . Checking in the changes . . . . . Freezing the work area. . . . . Building the application . . . . Accepting fix records . . . . . . Integrating changed parts into a release Adding a driver member . . . . Reconciling the differences . . . Refreshing the driver . . . . . Building the driver . . . . . . Restricting the driver . . . . . Integrating the parts. . . . . . Completing the driver . . . . . Testing the built application . . .
The physical structure of the build function The build object model . . . . . . . Parent-child relationships in a build tree . Working with a build tree . . . . . . Putting the pieces together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 130 131 133 135 Chapter 11. Installing, starting, and stopping build servers Installing the build function . . . . . . . . . . . . Creating a build server on MVS . . . . . . . . . .
Creating the build tree for the application. . . . . Starting the build on the client . . . . . . . . Putting the build scripts to work . . . . . . . . Finishing the job and reporting the results to the user Monitoring the progress of a build . . . . . . . Running a build in spite of errors . . . . . . . Building all parts, regardless of build times . . . . Finding out which parts will be built . . . . . . Canceling a build . . . . . . . . . . . . More sample build trees . . . . . . . . . .
Setting up your project options . . . Using your TeamConnection Workframe Project actions . . . . . . . Part actions . . . . . . . . Using your project: a simple scenario . . . . project . . . . . . . . . Appendix E. Enabling a Workframe/NT project Setting up your project options: . . . . . . Using your TeamConnection WorkFrame project Project actions . . . . . . . . . . . Part actions . . . . . . . . . . . . viii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample build scripts. . Sample parsers . . . Sample package files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 . 306 . 306 Customer support . . . . . . . . . . . . . . . . . . . . . 307 Bibliography . . . . . . . . . . IBM VisualAge TeamConnection Enterprise TeamConnection technical reports . . . DB2 . . . . . . . . . . . . . Related publications . . . . . . . . . . . . Server library . .
x User’s Guide
Figures 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. A sample TeamConnection client/server network Sample of a component hierarchy . . . . . Parts, releases, and components. . . . . . Tasks window . . . . . . . . . . . . Components window . . . . . . . . . . Accept Defects window . . . . . . . . . Create Work Areas window . . . . . . . Check Out Parts window . . . . . . . .
47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. xii User’s Guide TeamConnection components on separate machines Create Builder window . . . . . . . . . . Modify Part Properties window . . . . . . . Modify Part Properties window . . . . . . . Create Builder window . . . . . . . . . . A JCL fragment for an MVS compile . . . . . A JCL fragment converted to a build script . . . Create Parser window . . . . . . . . . . Modify Part Properties window . . . . . . .
Notices References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used.
xiv User’s Guide
Trademarks The following terms are trademarks of International Business Machines Corporation in the United States and/or other countries: AIX® NetView® C/370™ OpenEdition® C Set ++® Operating System/2® DB2® OS/2® DB2 Universal Database® SOM® IBM® SOMobjects@tm; MVS™ TeamConnection™ MVS/ESA™ VisualAge® MVS/XA™ XGA ENVY is a registered trademark of Object Technology International, Inc. Lotus and Lotus Notes are registered trademarks and Domino is a trademark of Lotus Development Corporation.
Adobe, the Adobe logo, Acrobat, the Acrobat logo, Acrobat Reader, and PostScript are trademarks of Adobe Systems Incorporated. Other company, product, and service names may be trademarks or service marks of others.
About this book This book is part of the documentation library supporting the IBM TeamConnection licensed programs. It is a guide for client users. For additional information when performing TeamConnection tasks, refer to the Commands Reference when entering commands or online help when using the graphical user interface (GUI). Getting Started with the TeamConnection Clients contains basic information for the client user. This book is available in PDF format.
v Italics are used to indicate the first occurrence of a word or phrase that is defined in the glossary. They are also used for information that you must replace. v Bold is used to indicate items on the GUI. v Monospace font is used to indicate exactly how you type the information. v File names follow Intel conventions: mydir\myfile.txt. AIX, HP-UX, and Solaris users should render this file name mydir/myfile.txt.
Part 1. Introducing TeamConnection Chapter 1. An introduction to TeamConnection. TeamConnection definitions . . . . . . . . TeamConnection’s client/server architecture . . TeamConnection database . . . . . . . Interfaces . . . . . . . . . . . . . Families. . . . . . . . . . . . . . Users and host lists . . . . . . . . . . Parts. . . . . . . . . . . . . . . Components . . . . . . . . . . . . Releases . . . . . . . . . . . . . Work areas . . . . . . . . . . . . Drivers . . . . . . . . . . . . . .
2 User’s Guide
Chapter 1. An introduction to TeamConnection TeamConnection provides an environment and tools to make software development run smoothly, whether your development team is small or large. Using TeamConnection, you can communicate with and share data among team members to keep up with the many tasks in the development life cycle, from planning through maintenance.
Topic and description Page Developing products using TeamConnection: 16 v Getting familiar with the interfaces v The basics of using TeamConnection v More about defects and features v Following TeamConnection processes Using TeamConnection to build applications: 128 v Build concepts v Installing build agents and processors v Working with build scripts and builders v Working with parsers v Building an application Packaging applications: v Using the packaging function v Using the Gather utility v Usin
Figure 1. A sample TeamConnection client/server network TeamConnection family servers control all data within the TeamConnection environment.
You can use any interface to do your TeamConnection work, or you can switch among them. This book usually gives instructions for using both interfaces. For more information, see “Chapter 2. Getting familiar with the TeamConnection client interfaces” on page 17. Families A family represents a complete and self-contained collection of TeamConnection users and development data. Data within a family is completely isolated from data in all other families. One family cannot share data with another.
Check out To get a copy of a part so that you can make changes to it. Check in To put the changed part back into TeamConnection. Extract To get a copy of the part without making changes to the current version in TeamConnection. Edit To change a part from within TeamConnection using a specified editor. Build To construct an output part from parts that you have defined to TeamConnection as input to the output part.
v The users who have access to the component and the level of access each user has. This information makes up the component’s access list. v The users who are to be notified about changes to the component. This set of users is called the notification list. v The process by which the component handles defects and features. Releases An application is likely to contain parts from more than one component.
track of all of these changes, even when more than one user updates the same part at the same time. To make this possible, TeamConnection uses something called a work area. A work area is a logical temporary work space that enables you to isolate your work on the parts in a release from the official versions of the parts. You can check parts out to a work area, update them, and build them without affecting the official version of the parts in the release.
Defects and features A defect is a record of a problem to be fixed. A feature is a record of a request for a functional addition or enhancement. Both may be associated with a work area, and both follow the processes defined for the component and release that are associated with the work area. TeamConnection tracks both objects through their life cycles as developers change and commit parts.
the parts modified for the specified defect or feature in one release and records the status of the defect or feature. The work area moves through successive states during its life cycle. The TeamConnection actions that you can perform against a work area depend on its current state. You must use the track subprocess if you want to use any of the other release subprocesses.
v Tracks build times of inputs and outputs so that it builds only those parts that are out of date themselves or that have out of date dependents. You can also force a build regardless of the build times. v Enables you to spread the build over multiple machines running at the same time or into multiple processes running on a single machine, such as on MVS. For more information, see “Part 4. Using TeamConnection to build applications” on page 127 .
v Maintaining one or more families v Creating and updating configurable fields v Configuring release and component processes for a family v Creating and updating user exits v Monitoring the user activity of a family Build administrator This administrator is responsible for the following: v Setting up and maintaining build servers v Planning for builds v Creating builders and parsers v Starting and stopping build servers v Defining pools v Monitoring build performance v Creating driver members v Committing a
14 User’s Guide
Part 2. Developing a product using TeamConnection Chapter 2. Getting familiar with the TeamConnection client Using the GUI. . . . . . . . . . . . . . . . . Starting the GUI . . . . . . . . . . . . . . . Stopping the GUI . . . . . . . . . . . . . . Performing tasks with the GUI . . . . . . . . . . Using the Settings notebook . . . . . . . . . . . Online help information. . . . . . . . . . . . . Using the command line interface . . . . . . . . . . Using the TeamConnection web client . . . . . . . . .
Verifying and testing part updates . . . Extracting a part . . . . . . . . Checking out the part one more time . Checking the part back in . . . . . Freezing the work area. . . . . . . Refreshing the work area . . . . . . Building the application . . . . . . Integrating the work area . . . . . . Closing a defect . . . . . . . . . Working in concurrent development . . . Refreshing the work area from the driver . Integrating the work area . . . . . . Reconciling differences. . . . . . . . . . . . . . . . . .
Chapter 2. Getting familiar with the TeamConnection client interfaces TeamConnection provides several interfaces that you can use to access data: v A graphical user interface based on industry standards. v A command line interface that lets you type TeamConnection commands from a prompt or from within TeamConnection. v A web client, that you access through your web browser. You can use any of the interfaces to do all of your TeamConnection work, or you can switch back and forth between the them.
If you are using AIX, HP_UX, or Solaris and are about to use the GUI for the first time, you need to do the following tasks: 1. See Configure the environment variables in the .profile in the Getting Started with the TeamConnection Clients manual. 2. See Ensure that the TeamConnection client command is accessible in the Getting Started with the TeamConnection Clients manual. 3.
Initially, a set of default tasks appears in your Tasks window. As you become more familiar with TeamConnection and see what tasks you do most often, you can change, delete from, and add new tasks to this list. To learn how to do this, select How do I from the Help pull-down menu, and then select Update tasks on the Tasks window. From the Tasks window, you can either select actions from the menu bar or select a task.
Using the Settings notebook The TeamConnection GUI provides a Settings notebook in which you can set default values for your working environment. To open the Settings notebook, select Settings from the Windows pull-down menu. You can set the following values; for more information about them, refer to the online help. The notebook has five pages. Note: The environment variables you specify are relevant for the GUI only, not the command line.
v Destination directory On the Extract page: v Read-only v Expand keywords v Pool On the Pool page: Online help information Online help information is available from anywhere in the TeamConnection GUI. Use the online help when you need more information about a topic or task. TeamConnection offers two types of help: v General help This is help for a specific window.
The Quick Commands Reference is a booklet that lists the syntax of each TeamConnection command. You can also become familiar with the commands by looking at the contents of the log file where TeamConnection stores the commands that are issued as you use the GUI. This file is specified in the Log file field on the Setup page of the Settings notebook. The default name is teamc.
currently available, most other familiar TeamConnection functions are available through the Web client. If you want to disable the Web Client interface, you must set the environment variable TC_WWWDISABLED before starting the family. To begin using the TeamConnection web client you must point your web browser to the correct URL. The syntax of the URL is: http://host name of the server:port number of your family.
v For the ChangeView action, the following are available with the TeamConnection web client (but not the TeamConnection GUI): – ChangeView – workAreaState. v For the PartBuild action, the following are available with the TeamConnection web client (but not the TeamConnection GUI): – cancel – partType. v The PartChildInfoView action does not exist in the TeamConnection GUI. v For the PartDelete action, force is available for use with the TeamConnection web client (but not the TeamConnection GUI).
Chapter 3. The basics of using TeamConnection All users of TeamConnection perform a number of basic tasks, such as checking parts out of TeamConnection and then back in, and testing and verifying part changes. Before you start doing these tasks, you need to understand the basic concepts behind them; that is what this chapter explains. This chapter assumes that you have read “Chapter 1. An introduction to TeamConnection” on page 3 and are familiar with the different objects, such as components and releases.
Figure 5. Components window From a command prompt, you can issue the following command to view the component structure. teamc report -view -raw bCompView -where "name='root'" Authority to perform tasks As a TeamConnection user, you are automatically given the authority to perform some basic tasks.
Note: You can issue queries to generate reports of data from tables and views using the -view action flag. If you do not specify selection criteria, such as the fields and the search conditions you want to use, the report query selects all entries for the table or view indicated that the user has authority to access. This command does not show any objects in components that you are not authorized to access “Appendix I.
BuildView Use when you want to search for information related to building your application, such as viewing a build tree, or when you want to do build actions. PartFull Use when you want to search for parts across releases, components, or work areas. For example, you want a list of all the optics.c parts. Unlike the Parts Filter, you can specify one or more release or work area names. You can also use this filter to display only parts that have been changed in a work area. For example, you check out robot.
version of the work area. For example, you might be adding a major feature to the code, and you want to be able to return to something that works in case the application no longer builds. When you integrate a work area or commit a driver, the work area is frozen automatically. Naming your work areas When TeamConnection automatically creates a work area, the work area is given the same name as the defect or feature it was created for plus the initial version number, :1.
Use the online help facility if you need assistance when creating parts. Naming your parts If your organization has a naming convention, be sure to follow it when naming your parts. When the naming convention is not followed, everybody in your organization can have trouble locating parts. Part names created on the server are case-sensitive; they must be retrieved using the same case in which they were created. When you name TeamConnection parts, you can specify only the base name, such as hand.
Output The part will be a generated output from the same build that creates its parent part. In other words, both the parent part and this child part are outputs when the parent part is built. Dependent The part will be needed for the build operation of its parent to complete, but it will not be passed directly to the builder. An example of this is an include file. If you do not provide this information when you create the part, you can provide it later using the connect function.
Before getting parts from TeamConnection, you might want to find out if the development mode for the release is concurrent or serial. To determine the mode, view the information about the specific release. To do this, select View from the Selected pull-down menu on the Releases window. Working with common parts A common part is a part with identical content that is shared by two or more releases or two or more work areas.
Getting parts from TeamConnection Checking out a part implies that you intend to modify it; extracting a part merely gives you a copy of the part. Normally, when you extract a part, you do not plan to change the current version in TeamConnection. You must have the necessary authority to a component before you can check out or extract parts from that component. You need PartExtract authority to extract a part from TeamConnection; you need PartCheckOut authority to check a part out. See “Appendix I.
When you want to make changes to a part, you can do one of the following: v Check out one or more parts and edit the parts on your workstation. When you finish making changes to the parts, you check them back in. v Edit a part from within the TeamConnection GUI using a specified editor. When you exit the editor, the Check In Parts window appears and you can check the part back in to TeamConnection.
Finding different versions of TeamConnection objects TeamConnection version control maintains different versions of the following objects: v Releases v Work areas (and driver members) v Drivers v 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.
Versioning work areas TeamConnection creates new versions of work areas whenever you do the following: v Create a work area This is the initial version of a work area. When you create myWorkArea, for example, its version name is myWorkArea:1. v Refresh a work area Refreshing a work area updates it with any new versions of parts that have been integrated with the release. When a workarea is refreshed, two versions of the workarea are created.
Versioning drivers TeamConnection creates new versions of drivers whenever you do the following: v Create a driver When you create a new driver, TeamConnection makes two versions of it: myDriver:1, for example and myDriver:2. v Add a work area (driver member) to a driver If you add myWorkArea:1 to myDriver:2, for example, TeamConnection creates a new version of myDriver called myDriver:3. v Freeze a driver Freezing a driver is like taking a snapshot of the driver.
Versioning parts TeamConnection versions parts in association with other TeamConnection objects, such as work areas. If, for example, you create part1 in myWorkArea:1, the current version of part1 is myWorkArea:1. If part1 is in release myRelease:2 and work area myWorkArea:2, then you can view the version of the part for either the release or the work area. The version label for part1 in myRelease:2 is myRelease:2 and in myWorkArea:2 is myWorkArea:2.
Reviewing the design and resource estimates After the resolution has been designed and the resources have been identified, the proposal needs to be reviewed. If the review indicates that work should continue on the defect or feature, it is accepted. Resolving defects and implementing features Resolving one defect or implementing one feature in one release can involve one or more users changing many parts.
40 User’s Guide
Chapter 4. The states of TeamConnection objects The actions that you can perform on certain TeamConnection objects are controlled by two factors: v The process followed by the component and by the release v The current state of the object Certain TeamConnection objects follow certain states through their life cycle. An instance where an object might not follow all the possible states is when it moves through the states defined in the subprocesses of the component and the release.
resolution. The component you open a defect or feature against should be one that manages the parts affected by the enhancement or problem. Use the component descriptions and the structure of your family’s hierarchy to find the most appropriate component. If you open a defect or feature in an inappropriate component, the component owner can reassign it.
Review state Defects or features move to this state after they have been sized. In this state, the design text and sizing records are reviewed to determine the feasibility of the proposal. The owner can do one of the following: v Accept the defect or feature if all design and sizing records are acceptable. This moves the defect or feature to the working state. v Return the defect or feature to the originator if all design and sizing records are not acceptable.
defect/feature will only go to the verify state when all the workareas for the release specified move to complete state. Note: If you do not intend to fix that defect for the release specified, then you must move the defect to verify state manually by doing a defect -verify. This should be done by the originator of the defect. When a defect or feature is accepted, TeamConnection creates a verification record.
The states of work areas A work area is a storage area where you can work on the parts in a release without affecting the ″official″ versions of those parts. A work area can be associated with a specific defect or feature, but it does not have to be. These attributes can affect the state of a workarea: trackfixhold With the trackfixhold attribute and the fix subprocess, a workarea will remain in the fix state rather than moving to the integrate state when the final fix -complete command has been issued.
How fix records are handled varies according to the subprocesses in effect: Component subprocesses v dsrDefect or dsrFeature - TeamConnection creates fix records for features or defects when existing sizing records are accepted. Release subprocesses v fix - If a fix record does not already exist for the component, TeamConnection creates one when a part managed by that component is checked in to the database.
Restrict state Work areas can be moved to the restrict state only when the release includes the driver subprocess. The work area moves automatically to the restrict state when the driver to which it belongs is restricted. If a work area in this state is removed from the driver, it returns to the integrate state. Otherwise, the work area remains in the restrict state until the driver to which it belongs is committed.
is added to it as a driver member. If all work areas are removed from the driver, the driver automatically returns to the working state. Work areas can be added to drivers as driver members when the driver is in the working, integrate, or restrict state and the work area is in the fix state. Adding driver members to a driver in restrict state requires proper authority.
v Abstain if unable to assess the results Once all test records have been accepted or abstained, the states of other objects change as follows: v Work areas - Go to complete state. v Defects and features - Go to verify state if the component includes the verifyDefect or verifyFeature subprocess; otherwise they go to the closed state. v Verification records - Go to ready state and are sent to the defect or feature originators.
These records are handled by different people and enable you to monitor your development progress in different ways. The sequence of creating and handling verification and test records is as follows: 1. Verification records are created in the notReady state when a defect or feature is accepted. This indicates that someone on the development team has begun implementing the changes warranted by the defect or feature, but the changes are not yet ready to be verified.
Chapter 5. Working with no component or release processes To illustrate how to work with objects in a release that does not follow a tracking process or component processes, this chapter follows an example of a programming team that is developing the control systems for a robot. They are working in a family called robot. Instructions for performing the task are given for both the graphical user interface (GUI) and the command line interface (Command).
to make some modifications to the parts in this release. This fix will require the tasks noted in the following table: For information about this task, Go to this page.
Figure 6. Accept Defects window Command From a command line, he issues the following command: teamc defect -accept 310 -answer program_defect Result The defect goes to the working state. Creating a work area Because the component is not following a design, size, and review process, Alex needs to manually create a work area in which to modify and build his parts.
Note: 310 is the name of the defect that was opened for the problem, so this is how Alex wants to identify the work area. Figure 7. Create Work Areas window Command From a command line, he issues the following command: teamc workarea -create -name 310 -release robot_control Result TeamConnection creates a work area named 310 associated with release robot_control. The following parts are currently available in the latest view of release robot_control: brain.c brain.obj brain.exe arm.c arm.obj hand.c hand.
From the GUI, he: 1. Selects Parts → Check out from the Actions pull-down menu on the Tasks window. 2. Types the following: v optics.c in the Path names field v robot_control in the Release field v 310 in the Work area field 3. Selects OK. Figure 8. Check Out Parts window Command From a command line, he issues the following command: teamc part -checkout optics.c -release robot_control -workarea 310 Result A copy of the part optics.
He does not select the PartFull choice because he wants to limit his search to a particular release and work area. He uses PartFull when he wants to search for parts across releases, components, or work areas. 2. Types the following in the Parts Filter window: v robot_control in the Release field v 310 in the Work area field v % in the Base names field and selects like 3. Selects Save to Task List. Figure 9.
Figure 10. Edit Task List window 6. Double-clicks on the task entry he just created. The Parts window appears. Hereafter, to display the list of parts in his work area, he merely double-clicks on the task entry. 7. Places the mouse pointer over the part name optics.c and presses mouse button 2 to display the pop-up menu. 8. Selects Check out. The Check Out Parts window appears with the required fields pre-filled.
This command returns a list of all the parts that match the query. After Alex determines which part he wants to check out, he issues the following command: teamc part -checkout optics.c -release robot_control -workarea 310 Result A copy of the part optics.c is checked out from TeamConnection and placed in the appropriate directory. The part optics.c is locked. No other user can update the part until Alex integrates the work area with the release.
Figure 11. Check In Parts window Note: Alex follows these steps because he knows the exact name of the part that he is checking in. If he does not know the name, or if he is checking in many parts, he can instead do one of the following to display a list of parts: v Select the entry on his Tasks window that displays the list of parts. v Re-open the Parts window if it was previously minimized. v Add an entry to his Tasks window that lists all of his checked-out parts.
Thus, work area 310 contains the following parts: brain.c brain.obj brain.exe arm.c arm.obj hand.c hand.obj leg.c leg.obj foot.c foot.obj optics.c (modification 1) optics.obj Work area 310 continues to contain the unchanged parts from the requested release view, but now the work area is overlaid with changes local to the work area — optics.c in this case. Alex has his own copy of the application that he can modify without impacting other developers. Alex has checked in optics.
Figure 12. Build Parts window Command From a command line, he issues the following command: teamc part -build brain.exe -release robot_control -workarea 310 -pool normal Result TeamConnection determines the parts that are needed for the build from the set of all the part versions that are currently visible from work area 310. The following part versions are selected for build: brain.c brain.obj brain.exe arm.c arm.obj hand.c hand.obj leg.c leg.obj foot.c foot.obj optics.c (modification 1) optics.
Note: For a detailed build example, see “Chapter 15. Building an application: an example” on page 181. Extracting a part Next, Alex tests his modifications in the robot prototype in his office. He extracts the executable part from the work area 310. GUI From the GUI, he: 1. Selects Parts → Extract from the Actions pull-down menu on the Tasks window. 2. Types the following in the Extract Parts window, and then selects OK: v brain.
This action places a copy of the part brain.exe in the current directory. Checking out the part one more time Alex then downloads brain.exe to his robot, runs his test, and determines that the modification did not work: the robot slams into the wall. However, Alex thinks he knows what the problem is, so he needs optics.c for further modifications. First, he checks out the part. GUI From the GUI, he: 1.
Checking the part back in Alex makes his modification and checks the part in. GUI From the GUI, he: 1. Does one of the following to display the Check In Parts window: v Selects Parts → Check in from the Actions pull-down menu on the Tasks window. v Selects the entry on his Tasks window that displays all the parts he has checked out, and then selects the part. v Re-opens the Parts window if it was minimized, and then selects the part. 2.
Result Now the work area contains the following parts: brain.c leg.c brain.obj leg.obj brain.exe (contains modification 1) foot.c arm.c foot.obj arm.obj optics.c (modification 2) hand.c optics.obj (modification 1) hand.obj Because Alex did not specify that he wanted to save a copy of the work area by freezing it, optics.c (modification 1) was overwritten. Freezing the work area Alex builds the application again, extracts the executable part, and runs his test.
Command From a command line, he issues the following command: teamc workarea -freeze 310 -release robot_control Result The freeze command saves the work area 310. Thus, TeamConnection takes a snapshot of the work area, with all its parts and their visible versions, and saves it. Alex can come back to this stage of development in the work area if he wants. Note, however, that a freeze action does not make the changes visible to the other people working in the release, nor does it unlock the parts.
Figure 17. Refresh Work Areas window Command From a command line, he issues the following command: teamc workarea -refresh 310 -release robot_control Result This action updates work area 310 with any changes from the release, and it also freezes work area 310, if it is not already frozen. Now Alex’s work area contains the following versions of parts: brain.c (Jenny's modification) brain.obj (from Alex's build after refresh) brain.exe (contains modification 5) arm.c arm.obj hand.
Figure 18. Build Parts window Command From a command line, he issues the following command: teamc part -build brain.exe -release robot_control -workarea 310 -pool normal Result Fortunately, nothing breaks, so Alex is ready to integrate his changes with the release. Integrating the work area To integrate his changes with the release, Alex must integrate the work area he has been using with the release. This will make the work area visible to all the users in the release.
Figure 19. Integrate Work Areas window Command From a command line, he issues the following command: teamc workarea -integrate 310 -release robot_control Result TeamConnection first determines that Alex’s changes were built against the latest version of the release. Then TeamConnection makes Alex’s changes visible at the release level so that the other team members can see and use them. The following part versions are now visible from the release: brain.c (Jenny's modification) brain.
From the GUI, he: 1. Selects Defects → Verify from the Actions pull-down menu on the Tasks window. The Verify Defects window appears. 2. Types 310 in the Defects field. 3. Selects OK. Figure 20. Verify Defects window Command From a command line, he issues the following command: teamc defect -verify 310 -release robot_control Result Because the component does not include the verifyDefect subprocess in its process, the defect moves directly to the closed state.
The following tasks are required: For information about this task, Go to this page. Refreshing the work area from the driver 71 Integrating the work area 72 Resolving differences 73 Refreshing the work area from the driver If Alex and Jenny are working on optics.c at the same time, they must resolve their part differences at some point, because both want to make their changes visible to the release.
From a command line, she issues the following command: teamc workarea -refresh 415 -release robot_control Result This command refreshes her work area with the latest view of the release. Her work area now contains the following part versions: brain.c (Jenny's modification 3) brain.obj (Jenny's modification 3) brain.exe (has Jenny's brain.c modification 3 and optics.c modification 4) arm.c arm.obj hand.c (Joy's modification, Ken's modification) hand.obj (Joy's modification, Ken's modification) leg.c leg.
Figure 22. Integrate Work Areas window Command From a command line, she issues the following command: teamc workarea -integrate 415 -release robot_control Result Because Jenny is up-to-date with the latest view of the driver, her changes are integrated after TeamConnection preserves a copy of the previous version of the release. Reconciling differences Later, Alex is ready to integrate his modifications. Alex issues a refresh command from the driver, as Jenny did (see page 71 for instructions).
Alex can use either the GUI or the command line to reconcile the differences. Four steps are required from the command line: 1. Check out the latest uncommitted version. 2. Extract the latest committed version. 3. Run the merge program against the two parts. 4. Check in the resultant part. However, on the GUI the reconcile action automatically does the preceding steps for you, which can save you a considerable amount of work if several parts require reconciliation. GUI From the GUI, he: 1.
Figure 23. Reconcile Collision Record window Command From a command line, he does the following steps: v Issues a report command to determine which parts are in conflict: teamc report -view collisionView -workarea 310 This report tells him that optics.c is the part that collided and gives the alternate version ID of the part that caused the collision. Alex makes note of the alternate version ID, robot_control:2, because he needs to specify that in a later step. v Extracts a copy of optics.
If Alex decides not to merge the two parts, but instead wants to use his copy of optics.c, he uses the collision -reject command. Or, if he wants to use the copy of optics.c at the release level, he uses the collision -accept command. v Checks the resultant copy of optics.c into his work area and builds it against the rest of the system. v After he is satisfied with the reconciled changes, he lets TeamConnection know that the previously discovered conflict is reconciled.
Chapter 6. Working with component and release processes The previous chapter described how to work with parts when the release does not follow a tracking process. This chapter describes how to work with parts when a tracking process is followed and how to use component processes for features and defects. When tracking is part of the process, users must associate any changes to their parts with the defects or features active for the release. This association is made through a work area.
For information about this task, Go to this page.
Changing defect ownership Because Carol is the component owner, she is currently defined as the owner of defect 456. But the problem is in Alex’s code, so she wants him to own the defect. To reassign ownership, she does one of the following: GUI From the GUI, she: 1. Selects Defects → Modify → Owner from the Actions pull-down menu on the Tasks window. The Modify Defect Owner window appears. 2. Types 456 in the Defects field and types Alex’s user ID, alexm, in the New owner field. 3. Selects OK. Figure 24.
Accepting a defect When you accept a defect or feature, you accept the responsibility of resolving it. A defect or feature might require changes in more than one release. If the component includes the design, size, and review process, these releases were identified during the size state, and TeamConnection created a work area for each identified release. If the component does not include the design, size, and review process, you will need to create a work area manually.
Command From a command line, he issues the following command: teamc defect -accept 456 -answer program_defect Results Defect 456 moves to working state, and TeamConnection creates a work area called 456. The work area is associated with the release specified on the sizing record, which in this example is robot_control. When the work area is created, a fix record is also created based on the sizing record.
Figure 26. Accept Approval Records window Command From a command line, they both issue the following command for the approval record that they have: teamc approval -accept -workarea 456 -release robot_control Results After both Linda and Sam accept the approval records, TeamConnection moves the work area to the fix state. Checking out a part Now that the approval records have been accepted, Alex can check out the necessary parts. He decides that modifications are again required to the part optics.c.
Figure 27. Check Out Parts window Command From a command line, he issues the following command: teamc part -checkout optics.c -release robot_control -workarea 456 -relative d:\robot\src Results A copy of the part optics.c is checked out from TeamConnection and placed in the directory d:\robot\src. If the directory name is not specified in the command, TeamConnection uses the directory specified in the TC_RELATIVE environment variable.
Figure 28. Check In Parts window Note: Alex follows these steps because he knows the exact name of the part that he is checking in. If he does not know the name, or if he is checking in many parts, he can instead do one of the following to display a list of parts: v Select the entry on his Tasks window that displays the list of parts. v Re-open the Parts window if it was previously minimized. v Add an entry to his Tasks window that lists all of his checked-out parts.
arm.c arm.obj hand.c hand.obj foot.obj optics.c (Alex's modification 1) optics.obj Freezing the work area Alex now wants to save, or freeze, the working system. He does one of the following: GUI From the GUI, he: 1. Displays the Freeze Work Areas window in one of the following ways: v Selects Work areas → Freeze from the Actions pull-down menu on the Tasks window. v Selects Work areas from the Objects pull-down menu on the Tasks window.
Note, however, that a freeze action does not make the changes visible to the other people working in the release. This does not occur until the work area is integrated. Building the application Alex now builds the application to verify that the changes he has made have fixed the problem. He does one of the following: GUI From the GUI: Alex has a Parts window open with a list of all the parts that exist in work area 456. He highlights the part brain.exe and then does the following: 1.
Alex builds the application and tests the results. The modification seems to solve the problem. Note: For a detailed build example, see “Chapter 15. Building an application: an example” on page 181. Accepting fix records Alex is satisfied that the changes are complete and the part is ready to be integrated with other parts in the release. He does one of the following: GUI From the GUI, he: 1. Selects Records → Fix records → Complete from the Actions pull-down menu on the Tasks window. 2.
Integrating changed parts into a release The changes that Alex has made are now ready to be put into the next set of changes scheduled to be integrated with the release. This set of changes is known as a driver. A driver named 0105 currently exists, and several driver members have already been added to the driver. Therefore, the driver is in the integrate state. Adding a driver member Carol, the project lead, adds work area 456 as a driver member of driver 0105: GUI From the GUI, she: 1.
Carol previously created a driver member for driver 0105 that included changes to optics.c, so Carol is notified that collisions were detected. (Remember, the release is in concurrent development mode.) Carol deletes the driver member for work area 456. She then asks Alex to reconcile the collisions. Reconciling the differences Before Alex can reconcile the differences, he needs to do the following: 1. Return the work area to the fix state 2. Reactivate the fix record 3.
Work area 456 is in the fix state. After the fix record is reactivated, Alex will check out optics.c from this work area to reconcile the differences. Reactivating the fix record Currently, the fix record for work area 456 is in the complete state. Alex must reactivate the fix record to move it back to the active state so that he can make the necessary changes to optics.c. He does one of the following: GUI From the GUI, he: 1.
From the GUI, he: 1. Selects Work areas → Refresh from the Actions pull-down menu on the Tasks window. 2. Types the following in the Refresh Work Areas window and selects OK: v 456 in the Work areas field v robot_control in the Releases field v 0105 in the Source field Figure 35.
2. Types 0105 in the Drivers field and robot_control in the Release field. 3. Selects OK. Figure 36. Refresh Drivers window Command From a command line, she issues the following command: teamc driver -refresh 0105 -release robot_control Results This command refreshes driver 0105 with any committed updates to the release. Building the driver Carol builds the application using the parts current to driver 0105. She does one of the following: GUI From the GUI, she: 1.
Figure 37. Build Parts window Command From a command line, she issues the following command: teamc part -build brain.exe -release robot_control -workarea 0105 -pool normal Results Carol runs some simple regression tests to verify that the application built properly. She is satisfied with the results, and is ready for the next step — committing the driver changes to the release.
Figure 38. Restrict Drivers window Command From a command line, she issues the following command: teamc driver -restrict 0105 -release robot_control Results This command restricts driver 0105 so that only Carol is able to make changes to it. Carol is now ready to build the application. Integrating the parts Carol commits the changes in the driver to the release by doing one of the following: GUI From the GUI, she: 1. Selects Drivers → Commit from the Actions pull-down menu on the Tasks window. 2.
From a command line, she issues the following command: teamc driver -commit 0105 -release robot_control Results TeamConnection moves the part versions associated with driver 0105 into the release. Other members of the team can now view the changes. Committing a driver commits all work areas designated as driver members and all parts changed in reference to those work areas. Completing the driver The driver is ready for formal testing in the specified release’s environment list.
Testing the built application Annmarie is the tester for the MVS version of the robot application. When she receives notification that the test record is in the ready state, she tests the part changes that were made within the release by Alex and several of his team members. The tests complete successfully, so she accepts the test record by doing one of the following: GUI From the GUI, she: 1. Selects Records → Test records → Accept from the Actions pull-down menu on the Tasks window. 2.
Using a configured process The scenarios in this chapter and the preceding chapter illustrate one release with no process management enabled and another release with full process management enabled. However, administrators can define a release that requires users to work with some intermediate level of process management. That is, the administrator can remove some of the subprocesses from the full-tracking scenario. For example, the administrator might want to eliminate the driver subprocess.
arm.c arm.obj hand.c hand.obj foot obj optics.c (modification 12) optics.obj (from Alex's build 12) Next Alex must update the brain.c part to set the appropriate conditions for activating the new zoom capability. He does not yet want to integrate his changes to optics.c for the zoom lens with the release because they are of little value without his changes to brain.c. Also, he is not certain that he is completely done with optics.c until he completes the modifications to brain.c.
workAreaName releaseName predecessor hasSuccessor releaseVersion addDate freezeDate 1208 robot_control 1208:2 yes no 1995/01/14 11:13:25 1995/01/15 09:01:35 name workAreaName releaseName predecessor hasSuccessor releaseVersion addDate freezeDate 1208:4 1208 robot_control 1208:3 no no 1995/01/16 08:10:15 1995/01/16 10:05:11 So what does it all mean? v name is the name of the version in the work area. v workAreaName is the name of the work area that owns the version.
Note: If the -where clause were not specified, the report would return all of the parts visible from version 1208:2. The TeamConnection system returns the following report: baseName releaseName compName versionSID addDate lastUpdate pathName nuVersionSID nuAddDate nuDropDate nuPathName userLogin fmode optics.c robot_control robot_dev 1208:2 02/02/94 04/15/94 smarts\eyes\optics.c 1208:2 alexm 0640 Because optics.c is the only part modified in version 1208:2, Alex assumes it is the copy he wants.
Part 3. Using TeamConnection Notes Integrated Databases Chapter 7. Introduction to TeamConnection Getting started . . . . . . . . . . Prerequisites and dependencies . . . . Using TeamConnection with Lotus Notes . . Sources of user information . . . . . Database types . . . . . . . . . Forms and subforms . . . . . . . Views . . . . . . . . . . . . Reviews . . . . . . . . . . . Document archiving . . . . . . . . Integrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102 User’s Guide
Chapter 7. Introduction to TeamConnection Integrated Notes Databases The VisualAge TeamConnection Integrated Notes Database feature provides a documentation facility to support software development. A software development group can use this database to communicate with TeamConnection objects from within Lotus Notes documents. The TeamConnection Integrated Notes Database links the technical documents to the TeamConnection objects involved in software enhancement and maintenance.
Prerequisites and dependencies In preparation for setting up and administering the Lotus Notes Integration feature, ensure that the machine you are using to implement this feature (generically, the Notes server) is equipped as follows: v To use this function, the client machine requires Lotus Notes Release 4.5.3a or higher and a Version 3 TeamConnection client. There are no prerequisites or dependencies on the TeamConnection server. v The TeamConnection Web Client interface is also required.
The About document provides graphical previews for the Requirements, Development, and Test database types. These previews provide a graphical depiction of available documents and the document hierarchy for each database, along with the default setup values available to an administrator. The Using document provides detailed information that users will need to take advantage of Notes Integrated Database functionality.
the design. Documents existing in Notes can be associated with existing features and defects in TeamConnection. Test Case Management and Tracking The Test Case Management and Tracking database assists with test case management and tracking. In this database, test case definitions and their execution results are tracked. Defects can be opened for failing test cases to track their progress. Generic A Generic database is available for other purposes that you choose and also has access to TeamConnection.
Table 1. Integrated database forms by database type (continued) Form Use for this form Response to Response Document your response to another’s response to a requirements, design, test case, or basic document. Requirements Requirement Document and open a requirements document in the database. TeamConnection Feature Open a TeamConnection feature against a requirement document to track the implementation of the requirement. Development Design To open a design document in the database.
specific document title. By using buttons on the action bar, you can choose to view the children documents of a parent document or category, all active features, or all active defects. Views are available through the Navigator and the View menu. Table 2 provides a listing of all views currently available to database users. Table 2. Integrated database views View Documents accessed (purpose) All documents To list all of the documents stored in the database.
Table 2. Integrated database views (continued) View Documents accessed (purpose) Execution Records To list all of the execution records in the database. Hierarchy To list test case, execution records, and defects in a hierarchy. My Execution Records To list all of the execution records that you have created in the database. Testers To list the tester name(s) and a summary of their test case executions. Test Case To list all of the test cases in the database.
110 User’s Guide
Chapter 8. Creating and Maintaining Integrated Notes Databases This section and the one that follows (“Chapter 9.
Figure 42. Notes Integrated Database Creation and Staging The flow presented in the figure applies to all potential user databases available through the Notes Integrated Database feature. Initializing the original template and creating a database To help you with developing Notes applications, a database master template is included on the IBM VisualAge TeamConnection Enterprise Server installation CD-ROM.
3) The Server field should contain the Local value. You can supply the Title of your choice. 4) Rename the file in the File Name field to match the naming conventions of your organization. This copy of the template must keep the .nsf suffix. For example: development.nsf. 5) Select the folder icon button, which will open the Choose a folder window. Choose the directory on your local file system that will store the database.
Note Setup is a staging process that may require some planning. See “Chapter 9. Database Design Strategies and Advanced Customization” on page 121 for details on setup strategies and customization options. You will need to decide what type of database you need: Requirements, Design and Development, Test Case Management, Generic, or a User Defined database.
You should also add any users involved in the testing process to the access list for this database. The default Access of Author is recommended. i. When the database is working to your satisfaction (you can go back to the setup several times to make changes and refine it), you are ready to make it available to your user community. Be sure to delete any documents you created during local testing and evaluation.
Creating customized production databases Now that you have initialized the Integrated Notes Database feature and performed a preliminary setup of the database template for your organization, you can proceed to customize the initialized database. See “Using the Customization setup facility” on page 122 for additional details on the customization options. Note: A Customization Wizard is available from the Setup window action bar to assist you in customizing your database.
v Open Defects and/or Features. v Examine views. You should also add any users involved in the testing process to the access list for this database. The default Access and Role of Author is recommended. 4. When the database is working to your satisfaction (you can go back to the setup several times to make changes and refine it), you are ready to make it available for to your user community. Be sure to delete any documents you created during local testing and evaluation.
Performing reconciliation The Reconciliation facility synchronizes the data in the TeamConnection family and the Notes databases that use it. The reconciliation facility is an agent that should be run regularly. As a default, reconciliation is activated during Setup. It can be run on an established schedule that you set up, or manually when needed. We suggest that the reconciliation facility be set up to run after your regular TeamConnection build completes.
Database maintenance: refreshing design from a template In the course of using Notes Integrated databases, you may have occasion to refresh current databases with a template. As you receive code updates from IBM VisualAge TeamConnection Enterprise Server, it is likely that you will want your current databases to reflect the most current template. In the course of maintaining database consistency across your enterprise, you may want to refresh all active databases from a common template.
v Reopen documents. v Select Feature and Defect push buttons. v Open Defects and/or Features. v Examine views. 6. When you are satisfied that refreshing the local database copy was a successful operation, select the production (original) database from your workspace and repeat the refresh process, beginning with step 3. Important notice to administrators: Be sure that you select the right template. An inappropriate template may have a destructive impact on your database! 7.
Chapter 9. Database Design Strategies and Advanced Customization This section include some general strategies for setting up, testing, and tuning your Notes Integrated Database implementation. The primary administrative functions are described in “Chapter 8.
3. Assess and implement any access control/authorization schemes necessary at this level of implementation. 4. Open the newly initialized database. 5. Create test documents for testing. 6. Open features and defects if your database addresses these elements. 7. Determine whether existing (TeamConnection—supplied) documents, subdocuments, and forms can be mapped into your organization’s terminology, workflow, hierarchies, and state system. 8.
The Customization setup facility addresses the following areas of database manipulation: v Notes Database Customization v Modify TeamConnection Access v Reconciliation of Notes and TeamConnection Data In order to perform the Customization setup, you must set your role to Administrator in the Access Control List window. Notes Database Customization The following areas of customization are described in detail in the Setup help.
response documents for the base documents you defined in the Modify which documents your project will use section. This level of customization allows you to control how response documents can build upon a base document and other response documents. Modify the states for documents In the Modify the states for documents section, you can integrate the documents you defined in the Modify which documents your project will use section with a state system that best reflects your organization’s workflow process.
Activate Reconcile The Notes Integrated Database feature provides a reconciliation facility that synchronizes the data in the TeamConnection family and the Notes databases that use it. The reconciliation facility is an agent that should be run regularly. The reconciliation facility can be run on an established schedule that you set or manually when needed.
There are one or more subforms defined for all the Forms that allow user-defined subforms. This allows you to augment or replace the subform supplied by TeamConnection. The TeamConnection-supplied database teamc.nsf has all of the user subforms defined. All of them are empty. You should define your initial database by copying teamc.nsf so that you have all the subforms available (This process is described in “Initializing the original template and creating a database” on page 112.
Part 4. Using TeamConnection to build applications Chapter 10. Basic build concepts . . The physical structure of the build function The build object model . . . . . . . Parent-child relationships in a build tree . Working with a build tree . . . . . . Putting the pieces together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 129 130 131 133 135 Chapter 11.
Putting a parser to work . . . Removing a parser from a part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 . 179 Chapter 15. Building an application: an example . Starting the build servers . . . . . . . . . . Creating builders and parsers . . . . . . . . Creating the build tree for the application. . . . . Starting the build on the client . . . . . . . . Putting the build scripts to work . . . . . . . .
Chapter 10. Basic build concepts This chapter defines terms and briefly describes the TeamConnection pieces that work together in building an application. For more details, continue to the other chapters in this section. The TeamConnection build function has numerous features: v It builds applications for platforms in addition to those it runs on. Currently you can build applications using TeamConnection on the following platforms: AIX, HP-UX, Solaris, MVS, MVS/OE, OS/2, Windows NT, and Windows 95.
Build servers are started by a TeamConnection administrator. For more information, see “Chapter 11. Installing, starting, and stopping build servers” on page 137. The build object model Figure 44 on page 133 shows the TeamConnection objects and events that constitute the build function, as illustrated in a sample application named msgcat.exe. This build object model is a conceptual model of the build function.
Build script An object that a builder uses in transforming inputs to outputs; it is essentially a binding between TeamConnection and a transformation tool, such as a linker or compiler. In OS/2, Windows, UNIX, or MVS/OE environments, a build script is usually a command file, but it can be a string that calls the tool. In MVS, it is a file containing JCL-like instructions. Parser A tool that can read a source file and report back a list of dependencies of that source file.
Though parent-child relationships usually imply that the parent part generates the child part, in a TeamConnection build it is the opposite. Because TeamConnection places the build output at the top of the tree, it refers to the build output as the parent and to the build input as the child. To understand how build output is generated, it may be easier to start at the bottom of the build object model and work your way up. In Figure 44 on page 133, hello.h and bye.
Figure 44. Sample build object model for msgcat.exe Working with a build tree Software developers must provide the information by which TeamConnection determines the build events that make up a build request. An application’s build tree shows this information graphically. Chapter 10.
A build tree is a simplified version of the build object model, showing the dependencies that the parts in an application have on one another. If you change the relationship of one part to another, the build tree changes accordingly. Figure 45 shows a build tree for the hello application: Figure 45. The build tree for the hello application In this simple application, hello.c is compiled to create hello.obj, which in turn is linked to create hello.exe. The build tree shows that hello.
Figure 46. Two versions of a build tree Putting the pieces together The table that follows lists the tasks involved in preparing for building an application and in actually building it. Usually an administrator does the preparation steps, but anyone with the proper authority can do so. For more information about this task, Creating build startup files Go to this page. “Creating build startup files (for non-MVS environments)” on page 144 Chapter 10.
For more information about this task, Go to this page. Starting build servers “Chapter 11.
Chapter 11. Installing, starting, and stopping build servers This chapter explains how to install, start, and stop a build server. Installing the build function Before installing build servers, you should be familiar with the build concepts found in “Chapter 10. Basic build concepts” on page 129. For hardware requirements for the build server machines, refer to the requirements for your specific operating system in the Installation Guide.
The following are software requirements for the MVS build server: v TCP/IP Version 3.2 for MVS v OS/390 R3 LE To install the build server on MVS, you create MVS data sets and then upload the TeamConnection files to these data sets. Follow these steps: 1. On your TeamConnection server, install the MVS build server component, following the instructions in the Installation Guide. 2.
Note: The file fhbmsg.mvs is installed in the language subdirectory of the \nls\msg directory path in the TeamConnection installation directory, for example, \nls\msg\en_us for US English. The remaining MVS files are installed in the \mvs subdirectory. c. This optional step installs the sample build scripts on MVS. It must be done from a machine that has the TeamConnection client installed. Note: The details in this step are subject to change.
2. From the oe subdirectory where TeamConnection is installed, use ftp to upload the following files to MVS/OE, in binary. v rename teamcbld.oe to teamcbld (main executable) v rename fhccmnc.oe to fhccmnc (supporting DLL) v rename fhcrscli.oe to fhcrscli (supporting DLL) v teamcv3.cat (for required national language) 3. Using chmod in the OE shell, set the access flags for teamcbld, fhccmnc, and fhcrscli so that they are executable.
v -s sends log file messages to the screen.The build server generates a log file called teamcbld.log. Build server log messages can be routed to the screen using the -s parameter. v -n writes files: – writes the changed environment variables to a file called tcbldenv.lst instead of setting them in program’s environment. The format of the file is variable=value. – writes the list of input files to a file called tcbldin.lst. One file per line, format is pathName type.
– TC_BUILDMINWAIT - Minimum amount of time to wait (in seconds) between queries for new jobs. Default setting is 5, minimum setting is 3. – TC_BUILDMAXWAIT - Maximum amount of time to wait (in seconds) between queries for new jobs. Default setting is 15, maximum setting is 300. The teamcbld will check the family for work to do every TC_BUILDMINWAIT. If it is not busy it will slow down to the TC_BUILDMAXWAIT time.
v unit_name indicates the default unit type for dynamic data set allocations. VIO is the default. v login_password is required only when the family server authentication level requires a TeamConnection user password. v local_codepage indicates the code set that text data is converted to for the build. The default is IBM-1047. v remote_codepage indicates the code set for data stored in TeamConnection. The default is IBM-850. Notes: a.
v login_password is used only when the family server authentication level requires a TeamConnection user password. The user ID used by the build server is the MVS/OE user ID under which the build job is started. v local_codepage indicates the code set that text data is converted to for the build. The default is IBM-1047. v remote_codepage indicates the code set for data stored in TeamConnection. The default is IBM-850. Notes: 1.
You can store the build startup files wherever you like, provided that you give the full file path names for them in the -b parameters, or in the TC_BUILD_RSSBUILDS_FILE environment variable. Stopping the build servers To stop a build server, do one of the following: v Close the window in which the build server is running. v Press Ctrl+C when the build server window has focus. v Close the window in which the family server was started if the build server was started with the teamcd command.
146 User’s Guide
Chapter 12. Working with build scripts and builders A builder is an object that can transform one set of TeamConnection parts into another by invoking tools such as compilers and linkers. For example, one builder might transform a COBOL source file into an object file. Another might transform a set of object files into an executable file. Builders use build scripts to invoke the tools that actually transform TeamConnection parts.
Figure 48. Create Builder window To create a builder using the command line: From a command line, type the teamc builder -create command and press Enter.
To use the builder from a previous release, you can link to a part that uses it in that release. This action copies the builder to the new release. Otherwise, you must create the builder again in the new release. Script, File type, and Source file These fields work together to define the build script that the builder invokes to accomplish the transformation. (The File type field on the GUI corresponds to -text, -binary, and -none in the command.
starting, and stopping build servers” on page 137 for more information.) It is recommended that you follow a naming convention for this attribute, using values such as os2 and mvs. Comparison operator and RC value Together, these two attributes make up a Boolean expression that defines the criteria used to decide whether a specific build event was successfully accomplished, when evaluated against the value returned by the build script.
Passing parameters to a build script There are three places where parameters can be specified that affect the outcome of a build. As attributes of a builder Builder parameters are passed to the build script, after variable substitution is performed. Variables are substituted based upon the following syntax: $(variable_name) To pass parameters to your build script, specify them in the Parameters attribute of the builder. TeamConnection sets these variables before invoking the build script.
Note: There is a one-to-one relationship between each object in the TC_OUTPUT list and this list of types (TCPart, for example). TC_WORKAREA The name of the work area in which the build is being performed. You can define other variables. These can be set when you start the build by specifying a value for parameters in the part -build command (from the command line or through the GUI). These variables are set in the parameters string passed to the build script.
Writing a simple build script This kind of build script is written into the Script attribute of the builder. When you create or modify the builder, you specify in this attribute the name of the transformation tool to be invoked. For example, suppose you want to create a builder that compiles a C source file into a .exe file using IBM’s VisualAge C++ compiler.
debug = VALUE('DEBUG',,environ) if debug = 'YES' then do parms = parms || '/Ti+' end icc parms '/Fo'||output input exit result Windows NT and 95 build scripts must be able to return a value for a return code. Because *.bat command files provide little support for programming logic and cannot return a value, use a compiled executable for your build script. TeamConnection provides two sample Windows build scripts and their source files. These samples, fhbwcomp.exe and fhbwlink.
DEBUG parameters, and then runs the command file against a local copy of hello.c. If the test is successful, the script correctly builds hello.obj in the current directory, and DEBUG is interpreted correctly. Modifying the contents of a build script Sometimes you need to modify the contents of a build script. Remember that a build script is stored as part of the builder itself. Because builders are not versioned, you do not check them out as you would most TeamConnection parts.
Figure 49. Modify Part Properties window v From a command line, type the following and press Enter. teamc part -modify name -Builder name where the part name is the name of the output file to be created by this builder and the builder name is the name of the builder itself. The complete syntax for this command is described in the TeamConnection Commands Reference. You can also attach a builder to an output file when the part is created. After you attach a builder to a part, the builder is ready for action.
Figure 50. Modify Part Properties window v From a command line, type the following: teamc part -modify name -builder null -release name -family name Working with VisualAge C++ and Templates When using VisualAge C++ and templates, template-include objects are saved in a subdirectory of the current directory called TEMPINC, so that subsequent builds can use them.
158 User’s Guide
Chapter 13. Working with MVS build scripts and builders A builder is an object that can transform one set of TeamConnection parts into another by invoking tools such as compilers and linkers. For example, one builder might transform a COBOL source file into an object file. Another might transform a set of object files into an executable file. Builders use build scripts to invoke the tools that actually transform TeamConnection parts.
Figure 51. Create Builder window To create a builder using the command line: From an OS/2 command line, type the builder -create command and press Enter.
To use the builder from a previous release, you can link to a part that uses it in the previous release. This action copies the builder to the new release. Otherwise, you must create it again in the new release. Script, File type, and Source file These fields work together to define the build script that the builder invokes to accomplish the transformation. (The File type field on the GUI corresponds to -text, -binary, and -none in the command.
See “Synchronizing the build of unrelated parts” on page 196 for an example. Environment This is the name of the environment supported by the builder, such as MVS. The value that you specify here can be anything you like, but it must exactly match the environment value specified in the command used to start the build server. It is recommended that you follow a naming convention for this attribute, using values such as os2 and mvs.
handling the timing of MVS builds is to start the MVS build server only at night and ensure that the MVS builders do not have short timeout values. Writing an MVS build script The best starting point for an MVS build script is an existing JCL fragment that is used for transforming inputs into outputs. For example, suppose you want to create a builder that compiles a C source file into an OBJECT file using IBM’s C/370 compiler.
File name conversions for MVS TeamConnection file names are modified by the MVS build server according to the following rules: v The directory path of a file name is not used. All characters of a file name up to and including the rightmost slash (/ or \) are thrown away. v Lowercase characters are converted to uppercase characters. v The file extensions are stripped from the right, up to and including the leftmost period.
&TCBLDUSR On MVS, can be used in JCL scripts, which will be substituted with the userID before processing the script. &TCINPUT This variable is used for in-stream data. For each build input, the line where &TCINPUT appears is duplicated and the variable &TCINPUT substituted with the input name. &TCOUTPUT This variable is used for in-stream data. For each build output, the line where &TCOUTPUT appears is duplicated and the variable &TCOUTPUT substituted with the output name.
– Selecting Part → View → View build message from the Actions pull-down menu on the Tasks window Note: More than one ddname can specify TCOUT; the results are concatenated in the order of appearance.
v PARM='information', where information is the parameter string passed to the load module. v COND=(code,operator [,stepname]) – code is the value to test against the return code from a previous step – operator is the comparison to be made between the value for code and the return code – stepname is the step issuing the return code All other keyword parameters are ignored and not used.
This will always be allocated as a DUMMY DSN. All other keyword parameters are ignored and not used. Example of a build script for a C compile The following JCL can be submitted as a batch job to do the following: v Compile the source file member in the data set WELLSK.TEAMC.C v Produce an object file member in the data set WELLSK.TEAMC.OBJ v Produce a listing of the source file in the file member in the data set WELLSK.TEAMC.LISTING v List the compiler messages in the file member in the data set WELLSK.
The first step in converting the JCL fragment is to recognize the intent for each of the data sets and ddnames. For this C/370 compiler example, the SYSIN ddname needs to be associated with the source file, the SYSPUNCH ddname needs to be associated with the object file, and so on. In each of these cases, the build script must tell the TeamConnection build server where to put or pick up the parts before and after the execution of the specified program (PGM=EDCCOMP).
//COMPILE EXEC PGM=EDCCOMP, // PARM='LO,SSCOMM,NOSEQ,NOMAR,LIS,FL(I),SO,DECK,&TCPARM', // REGION=1536K //STEPLIB DD DSN=SYS1.EDC.SEDCCOMP,DISP=SHR // DD DSN=SYS1.EDC.SEDCLINK,DISP=SHR // DD DSN=SYS1.PLI.SIBMLINK,DISP=SHR //SYSMSGS DD DSN=SYS1.EDC.
//*-----------------------------------------------------//* PROGRAM: cobolcmp.
This syntax is a subset of the linkage editor INCLUDE card. If the card is an INCLUDE ddname(MEMBER) control statement, the object code is copied into a sequential data set associated with the SYSMOD ddname. Otherwise, the control card is embedded in the data set associated with the SYSMOD ddname. This data set can be returned as the output from this build script. //FHBTCLNK EXEC PGM=FHBTCLNK, // PARM='SIZE=(768K,192K),LIST,MAP,AMODE(31),RMODE(24),LET,XREF' //STEPLIB DD DSN=userid.teamc.
The output specified in INCLUDE OBJECT(OUTPUT) contains embedded control statements specified from the build script FHBTCLNK. The linkage editor recognizes these embedded statements and produces an executable load module from the output file. The NAME control statement cannot be embedded in the output data set. Chapter 13.
174 User’s Guide
Chapter 14. Working with parsers This chapter describes how to create a parser. It assumes that you have read “Chapter 10. Basic build concepts” on page 129. Consider the task of defining and maintaining a build tree. One of the more time-consuming, and error-prone, portions of this task is defining the dependencies that one TeamConnection part has on others. For example, if hello.c includes hello.h, you need to define hello.h as a dependency of hello.c in the build tree.
Figure 54. Create Parser window From a command line, type the parser -create command and press Enter. The complete command syntax looks like the following: teamc parser -create name -command name -release name -family name [-include paths] [-become user_name] [-verbose] No matter which way you create a parser, you must specify a number of attributes for it.
v A dependency in which the file is stored in the TeamConnection database. For example, hello.c includes hello.h, and both files are stored in the TeamConnection database. During a build, these dependencies must be extracted to a path accessible by the build server. Because a build extracts parts from TeamConnection, anyone requesting a build needs to have PartExtract authority to all parts involved in the build. v A dependency on a file that is not stored in the TeamConnection database.
3. Writes out the list of such files into the dependency list file For example, for a C source file, the program could report a list of all the files included by the source file (using #include statements). For a COBOL program, COPY statements would be the cue. TeamConnection ships a sample of a command file named fhbopars.cmd. It is written in REXX. Putting a parser to work For an application to use a parser, the parser must be attached to the TeamConnection parts that it will check for dependencies.
After you attach a parser to a part, it is ready for action. The next time the part is checked in, when a part is created, or when the parser is attached, the parser will invoke its command file, which will report back a list of dependencies. Using a parser does not keep you from defining dependencies manually by using the GUI or the part -connect command.
Figure 56.
Chapter 15. Building an application: an example This chapter uses an extended example to describe in more detail how each of the components of the build function work together. All commands used in this example are described in detail elsewhere in this publication. This example walks through the control flow for a sample application, explaining what happens at each step. These are the tasks involved in building our sample application, msgcat.
Figure 57. Sample build tree For more examples of build trees, see “More sample build trees” on page 195.
Figure 58. Sample build object model for msgcat.exe Starting the build servers The software development team in our example is building large applications using a family named testfam, so they set TC_FAMILY to testfam. They plan to spread the work across several build servers, taking advantage of TeamConnection’s ability to perform multiple build events simultaneously. Mark, the build administrator, has installed a number of build servers on the team’s machines, for building OS/2 and MVS applications.
mvspool For MVS builds pool1 For normal OS/2 builds pool2 For fast, high-priority OS/2 builds Each pool is formed as Mark starts build servers and assigns them to it. He starts the following build server (bldserv2): teamcbld -b bldserv2 -p pool1 -e os2 The parameters specify the following: -p The build server is assigned to the pool named pool1. -e The environment is os2. Use the teamcbld command to start the build server when the family server has already been started.
builder c_linker, and the parent of hello.obj and bye.obj. Because the file has no contents initially, he selects No source (or specifies -empty on the command line), to identify it as a place holder. Using the GUI, he can create this file by selecting Create from the Actions → Parts menu of the Tasks window, and completing the fields as shown in the following illustration: Figure 59.
2. Creates two place-holder parts for the output of compiling the .c files. These parts are the output of the compile step; c_compiler, the builder that manages that step, is attached to both of them. He indicates that they are input to their parent file, msgcat.exe. Using the GUI, he can create these files by selecting Create from the Actions → Parts menu of the Tasks window, and completing the fields as shown in the following illustration: Figure 60.
teamc part -create hello.obj bye.obj -builder c_compiler -binary -empty -release 9503 -workarea 223 -component comp1 -parent msgcat.exe -input teamc part -create hello.h bye.h -release 9503 -workarea 223 3. Attaches the parser c_parser to the .c files. Using the GUI, he can attach the parser to these files by selecting Modify → Properties from the Actions → Parts menu of the Tasks window, and completing the fields as shown in the following illustration: Figure 61.
Figure 62. Connect Parts window Using the command-line interface, he can connect these parts by issuing the following commands: teamc part -connect hello.c -parent hello.obj -input -release 9503 -workarea 223 teamc part -connect bye.c -parent bye.obj -input -release 9503 -workarea 223 The .h parts are not connected because he expects the parser on hello.c and bye.c to find the correct dependencies. 5. Now, Greg can see the build tree in the GUI.
Figure 63. The build tree display Starting the build on the client After much hard work on his source code, Greg is ready to start building his application. Using the GUI, he can start the build by selecting build from the Actions → Parts menu of the Tasks window, and completing the fields as shown in the following illustration: Chapter 15.
Figure 64. Build Parts window Using the command-line interface, he can start the build by issuing the following command: teamc part -build msgcat.exe -release 9503 -workarea 223 -pool pool1 -normal -detail msgcat.det This command specifies the following: Build target The name of the part at the top of the build tree, msgcat.exe, which is the final output of this build. TeamConnection uses the build target to determine the scope of the build.
Unconditional Builds only parts that are out-of-date but continues processing even if errors are returned. Note that outputs are not rebuilt for inputs that have failed. Report Gives a preview of what would be built if you invoked a build. The report identifies what steps would occur without any translations taking place. In our example, Greg specifies -normal, which is the default. In this mode, only the parts that are stale with respect to their inputs are rebuilt.
In our example, each of the build servers receives a compile event to perform. Each extracts the .c source files it needs from the TeamConnection database and the contents of the build script for the c_compiler builder. The build servers then run their build scripts. The results (the .obj files and the return code) are sent back to the build servers. After updating the TeamConnection database, the build servers re-enter the polling loop to see if any more build events await their attention.
Build of 'bye.obj' successfully completed at '15:35:22 1995-08-10'. Completed Jobs: 2 Remaining Jobs: 1 Build of 'msgcat.exe' started at '15:35:26 1995-08-10' via a build agent on the host 'OCTOFVT'. Build of 'msgcat.exe' successfully completed at '15:35:56 1995-08-10'. Completed Jobs: 3 Remaining Jobs: 0 Processing Completed for 'msgcat.exe'. To see the commands that TeamConnection issued during the build, you can look at the detail file specified in the part -build command.
Finding out which parts will be built Before running a build of a large application, you might want to find out exactly which parts will be built. If you specify that you want to run in report mode, TeamConnection determines what will be built in a normal build and produces a report showing the results. If Greg really wants to see which parts of msgcat.exe will be built before he runs the actual build, he can issue the following command: teamc part -build msgcat.
This command will stop all queued and in_progress builds. Any build events already performed for that build are not undone. For example, if Greg cancels the build of msgcat.exe when the compile steps have been completed, then the link step is not performed. However, the newly compiled hello.obj and bye.obj are left in the database, with their build times updated. More sample build trees The msgcat.exe example is just one possible build tree. Here are some others.
teamc part -build robot.dll -workarea 915 -release 9503 The output of this build would be both robot.dll and robot.map. Any parameters specified in the teamc part -build robot.dll command would also apply to the build of robot.map. Synchronizing the build of unrelated parts An entire application can require multiple separate builds. For example, in the robot application, there might be one build to create the .dll parts, another to create the .exe parts, and so on.
The -none flag identifies this as a part that will never have any contents. 3. Tim connects the other parts to the collector: teamc part -connect robot.dll robot.exe -parent robot.app -input -release 9503 When Tim builds robot.app, the result is a build of both robot.dll and robot.exe. Chapter 15.
198 User’s Guide
Part 5. Using TeamConnection to package products Chapter 16. Using TeamConnection to package a product . Setting up your build tree for packaging . . . . . . . . Setting up a build tree for the gather tool . . . . . . . . . . . . . . . . . . . . . . . . . . 201 . 202 . 202 Chapter 17. Using the Gather tool . . . . . Using the teamcpak command for the Gather tool . Command line flags . . . . . . . . . . Examples of the teamcpak gather command . Writing a package file for the Gather tool . . . .
200 User’s Guide
Chapter 16. Using TeamConnection to package a product After you have built an application to your satisfaction, it is time to distribute it to users. This chapter describes how you can use TeamConnection to help automate the packaging and distribution steps. TeamConnection provides the following: v Two electronic software distribution tools: – Gather, which moves an application’s parts into a single directory in preparation for distribution.
Setting up your build tree for packaging When TeamConnection builds an application, the application’s build tree identifies the parts to be built and the tools to use in building it. Similarly, when you use TeamConnection for packaging the application, the build tree can define the parts to be packaged and the tools to do it.
existing structure, with parts contained in directories according to their application component. A better structure might be to place all of the .dll files in one directory, all of the .exe files in another, and so on. To move the parts into this structure, the test team does a different kind of build, using the gather tool. To make this happen, Annmarie does the following: 1. She creates the top-level part for the new build tree.
Figure 68. Adding the gather step to the build tree The package file, robot.pkf, specifies the directories into which the robot files are gathered, with e:\robot as the target root directory. When Annmarie builds e:\robot, the .dll files are placed in e:\robot\dll; the .bin files are placed in e:\robot\bin. Instead of extracting the built application from TeamConnection, the test team can pull the application from e:\robot.
Chapter 17. Using the Gather tool The Gather tool automates the movement of software and data from one directory to another on the same machine to prepare a package for electronic distribution. It can copy or erase files; it can create or delete directories. This tool takes a list of input files and moves them into a directory structure as directed by a package specification file.
teamcpak [-i] [-o "String"] gather Input_file... Where -i Specifies that only one Input_file is specified in the command: an include file containing the list of input files. This parameter is optional. If you specify -i, it must precede the gather flag. -o " String" Specifies that the string listed in quotes be passed to the Gather tool. The opening quote must be followed by a blank. For a list of possible flags to be passed, see “Command line flags”. This parameter is optional.
-f Force deletion from the root: if this is used in combination with -t or -c and TARGETROOT is a root directory (for example, e:\, \, /). -t Ensure that the target tree is exactly the tree specified in the package file.
Examples of the teamcpak gather command The following are examples of the teamcpak gather command. teamcpak gather d:\demoapp demoapp.pkf teamcpak gather a.exe b.exe \help\*.hlp demoapp.pkf In the first example, an input source directory is specified. In the second example, a list of files is specified. In both cases, the files are to be copied into target directories as specified in the demoapp.pkf file. teamcpak -i -o " -t -m -x" gather myfiles.lst The file myfiles.
(DATA (PACKAGEFORMAT gather) (TARGETROOT Filename) (RULE (SOURCE Filename...) (TARGET Path) [(EXITPRIOR String... | EXITREPLACE String... | EXITPOST String...)] ) ) . . [(EXITPRIOR String...)] [(EXITPOST String...)] ) Keywords for a Gather package file DATA This keyword is required. It must be the first keyword in the package file, and it can be specified only once. All other keywords are nested within the DATA clause. PACKAGEFORMAT gather This keyword is required. It can be specified only once.
TARGET keyword. The files in the SOURCE directory are copied to the TARGET path. The target path is derived by concatenating the value of TARGETROOT with a backslash (\), followed by the value of the TARGET keyword specified in the RULE clause. A RULE clause can also contain one user exit clause: EXITPRIOR, EXITPOST, or EXITREPLACE. For a description of the exit keywords, go to page 212. The following example copies all *.exe, *.cmd, and *.hlp files to target directory f:\demoapp\bin. (DATA . .
The resulting source path is the concatenation of d:\demoapp with the SOURCE file specifications. Therefore, all of the .exe files in the directory d:\demoapp\bin are copied to the target directory e:\demoapp\bin. (DATA (TARGETROOT e:\demoapp) . . (RULE (SOURCE bin\*.exe) (TARGET bin) ) . . ) In the following example, a list of input files is specified on the teamcpak command: teamcpak -o "-x -m" gather c:\a.exe c:\b.exe d:\rexx\*.cmd demoga.
(DATA (TARGETROOT . . (RULE (SOURCE (TARGET ) (RULE (SOURCE (TARGET ) . . ) f:\demoapp ) *.bin *.dll bin\files ) ) *.hlp targetroot ) ) EXITPRIOR, EXITPOST, and EXITREPLACE String... These keywords are optional. They specify a user exit program to run as part of the gather operation. To specify an exit that is global to the Gather operation, specify EXITPRIOR or EXITPOST in the DATA clause. You can specify each of these keywords only once in the DATA clause.
v The resolved SOURCE file specifications v The resolved TARGET specification The exit keyword accepts any executable file or command. The exit program must return an integer return value, zero meaning successful; it must also accept or ignore the additional Gather parameters added to the end of the invocation string. When used in the context of the RULE clause, exit keywords must follow the TARGET keyword.
214 User’s Guide
Chapter 18. Using the Tivoli Software Distribution packaging tool The Tivoli Software Distribution packaging tool supports automated distribution between a single Tivoli Software Distribution server and its TCP/IP-connected clients. The Tivoli Software Distribution tool works either by itself or in conjunction with TeamConnection’s Gather tool to enable you to distribute files through Tivoli Software Distribution.
-o "string" Specifies that the string listed in quotes be passed to the Tivoli Software Distribution tool. For a list of possible flags to be passed, see “Command line flags”. inputFile Specifies the files to be copied and the name of the package specification file. You can specify this parameter in these ways: v Specify the name of an include file, whose contents is a list of input files. One of these input files must be a package specification file with the extension .pkf.
Example of the teamcpak softdist command The following is an example of the teamcpak softdist command. teamcpak -i -o "-a -n -t" softdist Client.lst The -i parameter specifies that the input file Client.lst is to be used. The -o parameter passes the following options to Tivoli Software Distribution: v -a creates directories on the target. v -n indicates that no error notices are to be sent to Tivoli Software Distribution. v -t indicates that any existing files on the target are to be overwritten.
) ) [(LOGNODE ManagedNode)] [(LOGFILE directory)] Keywords for a Tivoli Software Distribution package file DATA This keyword is required. It must be the first keyword in the package file, and it can be specified only once. All other keywords are nested within the DATA clause. Example: (DATA . . other keywords go here . . ) PACKAGEFORMAT softdist This required keyword must be the first keyword within the DATA clause. It can be specified only once.
(DATA . . (MANAGER Distrib1) . . NODES This keyword specifies the nodes to which the files are to be distributed. These must already have been defined to the profile manager as subscriber ManagedNodes or PCManagedNodes. To distribute files to non-subscribers, you need to use Tivoli Software Distribution options set in an import file package definition. Example: (DATA . . (NODES "tcaix01 tcaix02") . .
(DATA . . (DISTRIBUTE CHANGED) . . INSTALLPGM Use this keyword to specify an installation script to be run during distribution on each node that receives files. Specify the full file path name of the script. Example: (DATA . . (INSTALLPGM /tivoli/fpTeamcAIX/tcinstl.ksh) . . LOGNODE This keyword specifies the system on which the log file is located. The node name you specify must be a managed node. The default is the current build machine or a machine running teamcpak. Example: (DATA . . (LOGNODE tcaix04) .
Log file Check the file name you specified in the LOGFILE keyword for error messages. Mail Check Tivoli mail messages generated during the distribution. -k option Run the teamcpak command with the -k option to keep the package file after the distribution has been run. This allows you to reprocess a distribution from the Tivoli GUI and test variations. -x option Run the teamcpak command with the -x option to leave any distributed files on the target. Trace facility Run teamcpak with the trace facility.
v The Client.lst file you create containing the list of files passed to teamcpak. The first line contains the package file by convention. The example also contains customized installation files (tcinstall.ksh), TeamConnection tar files, and an installation script (tcinst.ksh). /usr/teamc/tivoli/Client.pkf /usr/teamc/tivoli/tcinstall.ksh /tcinstall/v208/fullpak/aix4/tar/client.tar /tcinstall/v208/fullpak/aix4/tar/msgen_us.tar /tcinstall/v208/fullpak/tcinst.
else print -u3 /.profile already updated fi # Set up error logging # - if *.warning is in file (preceeded by spaces and tabs only grep "|[]*\*.warning" /etc/syslog.conf if (($? != 0)) then print -u3 'Updating /etc/syslog.conf' touch /var/spool/syslog chmod 666 /var/spool/syslog exec 4>> /etc/syslog.conf print -u4 '*.warning /var/spool/syslog' stopsrc -s syslog startsrc -s syslog else print -u3 /etc/syslog.
else # Clean up installation directory after listing contents print -u3 We have successfully copied TeamC installation files print -u3 Installation directory contents: ls -laR ${INST_DIR} >> ${INST_TMP} 2>&1 fi cd / # Remove installation stuff print -u3 TeamC cleaning up temporary installation directory rm -rf ${IMAGE_DIR} cat ${INST_TMP} >> ${INST_LOG} rm -rf ${INST_TMP} exit 0 # end of file 224 User’s Guide
Part 6. Appendixes The following appendixes contain various pieces of information that you can refer to as you plan for and use TeamConnection. © Copyright IBM Corp.
226 User’s Guide
Appendix A. Environment Variables You can set environment variables to describe the TeamConnection environment in which you are working. You are not required to set your TC_FAMILY environment variable for the TeamConnection client command line interface. However, if the TC_FAMILY environment variable is not set, the -family must be specified for every client command. See “Setting environment variables” on page 234 for more information about setting environment variables.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose NLSPATH Specifies the search path for locating message files. PATH TC_BACKUP Flag Setting Used by NLS path Client, family server Specifies where tcadmin is to Client, build search for the family create utilities. server, family server Controls whether or not the following commands create backup files. If this Family server environment variable is set to off or OFF, the commands do not create backup files.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose TC_BUILDMAXWAIT Maximum amount of time to wait (in seconds) between queries for new jobs. Default Flag Setting Used by Build server setting is 15, maximum setting is 300. TC_BUILDOPTS Specifies build options for -s, -n sending build log file messages to the screen, and setting the Build server logging level.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose TC_BUILD_RSSBUILDS_FILE Specifies the name of startup files to be used to provide information about build servers Flag Setting Used by Build server to the build process. TC_CASESENSE Changes the case of the Case Client arguments in commands, not in queries. TC_CATALOG Specifies a specific file for the Family server, oe build server TeamConnection message catalog.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose TC_MAKEIMPORTRULES Specifies the name of the rules file that TeamConnection uses when importing the makefile Flag Setting Used by Make import tool data into TeamConnection. If you set this environment variable, then you do not have to use the /u option with the fhomigmk command. Specify the full path name of the rules file.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose TC_MODPERM Controls whether or not the read-only attribute is set after a part is created, checked in or Flag Setting Used by Client unlocked in TeamConnection. To cause the read-only attribute to be set, specify TC_MODPERM=ON. To prevent the read-only attribute from being set, specify TC_MODPERM=OFF. The default is TC_MODPERM=ON.
Table 3. TeamConnection environment variables (continued) Environment variable Purpose TC_TRACESIZE Specifies the maximum size of the trace file in bytes. If the maximum is reached, wrapping Flag Setting Used by Client, family server, build server occurs. The default is one million bytes. TC_USER Specifies the user login ID for single-user environments OS/2 and Windows 95 (if not using User ID Client, build server the login facility).
Table 4. TeamConnection dynamically set build environment variables (continued) Environment variable Purpose TC_LOCATION Directory where build script is invoked. Flag Setting Used by Build server (except MVS build server) Setting environment variables For methods of setting your environment variables, refer to your operating system documentation.
Appendix B. Importing makefile information into TeamConnection TeamConnection provides a command to help you import makefile information into the TeamConnection database. The fhomigmk command reads a makefile and creates the parts in it. Build tree connections are created based on a rules file.
found, TeamConnection uses default rules. “Creating a rules file” on page 237 explains the rules, the format of this file, and the default rules. /x Specifies that you want to run the command file that was produced by the /c parameter. /s Specifies that the build tree is to be displayed after the command is issued. If specified, the command file is run even if the /x parameter is not specified.
used in the commands is mywork. After the commands are issued, the resulting build tree is shown using the TeamConnection GUI. Creating a rules file The import rules file is a text file that describes how you want TeamConnection to create and connect parts. In this file you supply a set of rules, one per line, using the following syntax: file mask The mask specifying the names of the files to which this rule applies. The * and ? wildcards are supported. For example, you could specify file names such as *.
v * indicates to use the name in the makefile, relative to the current working directory. For example, if a makefile specifies a file src\abc.cbl and the makefile specifies f:\mysrc\, the content is expected in f:\mysrc\src\abc.cbl. For a file of *.cbl, the content is expected in src\abc.cbl relative to the current working directory. parameters The build parameters to be attached to the part. Enclose the parameter in double quotes if it has spaces. Use the value none to indicate no parameters.
Appendix C. TeamConnection Merge The TeamConnection VisualMerge provides a way for you to merge two or three selected files together to make one single file. You can select options for viewing differences and collisions, as well as view the composite output of the merged files. Both a command line (tcmerge) and a graphical user interface are provided. The figure below describes the merge of three files into a single file.
The following lists the parameters which may be used with the tcmerge command. Parameter Description First file or directory to merge. A combination of filenames and directory names is not valid. Second file or directory to merge. [] Third file or directory to merge. (Optional) [-ti[tles] ] Names of files or directories being merged. [-out ] The file or directory into which the merged differences will be written.
Appendix D. Enabling an OS/2 Workframe project for TeamConnection TeamConnection lets you create a Workframe version 3 project that has TeamConnection options as well as a set of TeamConnection actions. For each project, you specify on the Project Options window the values for these options. By doing this, you logically connect a Workframe project with a set of TeamConnection parts.
Query mask Any valid TeamConnection -where clause for parts. Leave blank to see all parts. (This is used in the project’s Show Parts action.) Show filter Check this if you want to display the PartFull Filter window instead of using the query mask in the Show Parts action. Profile Names the rules file to use for the Import Make action. Specify the fully qualified name unless you are sure it will be found in your path correctly. Select the Find push button if you need help.
View part information Displays an unprimed View Part Information window. Edit part Displays an unprimed Edit Part window. Show parts If the project attribute Show filter is not set, issues a query based on the project attribute’s query mask. If the project attribute Show filter is set, displays the PartFull Filter window. Part actions Extract part Displays the TeamConnection Extract Parts window to extract the selected part.
Using your project: a simple scenario Suppose you are working on a defect in the family FAMILY1, release REL1_1. You have created a TeamConnection work area called SANDBOX to work in. You want to use the Workframe to access your TeamConnection parts. Here is what you might do. 1. Create a TeamConnection Workframe project called DefectABC. 2. Open the project. Select Tools setup from the View pull-down menu. 3. Select any of the actions.
Appendix E. Enabling a Workframe/NT project for TeamConnection TeamConnection lets you create a Workframe/NT project that has TeamConnection options as well as a set of TeamConnection actions. Workframe/NT doesn’t use the TeamConnection dialogues. Instead, WorkFrame/NT uses monitored commands to invoke TeamConnection. You must perform the following steps to integrate TeamConnection with WorkFrame/NT: 1. Install VisualAge C++ 2. Install the TeamConnection Client 3.
TC_BECOME The current TeamConnection user. Required for all commands. TC_RELEASE The current TeamConnection release. Required for all commands. TC_COMPONENT The current TeamConnection component. Required for all commands. TC_WORKAREA The name of the current TeamConnection work area. NULL is the default if a work area is not specified. TC_TOP Root of the work directory. Required for all commands. TC_MAKEIMPORTRULES The path and file name of the import rules file. Required for all Import Makefile.
Part actions The current release and work area are specified with environment variables. See “Setting up your project options:” on page 245. TC Extract Part Extract the specified part. TC View Part Information View information about the specified part. TC Build Part Build the specified output part. TC Create Part Create the specified part in TeamConnection. TC Unlock Part Unlock the specified part.
248 User’s Guide
Appendix F. Enabling and Using the ENVY/ManagerTeamConnection Bridge Overview of the ENVY/Manager-TeamConnection Bridge ENVY provides a repository with operational support tailored specifically for highly-interactive, prototyping environments that emphasize iterative development, such as VisualAge Smalltalk or VisualAge Generator.
Scope of this documentation This documentation is intended for users and administrators installing and using the bridge. It is assumed that you familiar with both the VisualAge Smalltalk and TeamConnection products. The following subsections describe the mechanics of enabling the ENVY/ManagerTeamConnection Bridge for VisualAge Smalltalk Pro (Version 4.0 or later), the process of exporting ENVY components to TeamConnection, and the process of importing these components back into ENVY/Manager.
How the bridge communicates with TeamConnection The bridge functions are initiated from within the VisualAge Smalltalk environment. Each operation that interacts with TeamConnection runs for some time in the Smalltalk image, but at some stage will make use of functions built into an appropriate version of the TeamConnection client and server. The bridge itself is implemented in Smalltalk, with the primitive functions provided in one of the DLLs in TeamConnection.
These configuration maps should be imported into your development library so that it can be loaded by all of the users sharing that library. The step-by step instructions are described in “Installing and activating the ENVY/Manager-TeamConnection Bridge” on page 253 . Usually, the Library Supervisor or the first user to use the bridge will perform this operation and then inform other users that the tool is available in the library.
v TC_COMPONENT is used as the default TeamConnection component for parts stored in TeamConnection through the bridge. If TC_COMPONENT is not defined or is empty, the value root is used. v TC_RELATIVE is used to specify the initial destination path for files retrieved from TeamConnection through the bridge. If TC_RELATIVE is not defined or is empty, the current directory according to the image is used. It is not necessary to define any of these variables for the bridge to work.
developers” on page 261, you must also import the configuration map called VAGen ENVY/TC Bridge, as described in the previous steps. 8. Select the OK pushbutton to initiate the import process. During the process of importing the TCEMBR.DAT file into the VisualAge Smalltalk Pro manager.dat file, the System Transcript window will issue a message stream that confirms the success of the import. 9. In the Configuration Maps Browser window, select ENVY/ManagerTeamConnection Bridge from the Names list. 10.
Using the ENVY/Manager-TeamConnection Bridge You can perform TeamConnection functions on ENVY components, provided that you supply parameters necessary to identify a bridge configuration. Bridge configuration parameters are defined by the Default Properties notebook, as described in “Setting default properties”. Each time the bridge interacts with TeamConnection, it uses the parameters in a bridge configuration to ensure that the behavior of the operation is in accordance with the users’ specifications.
Context page The context page is used to specify the TeamConnection family, release, and work area used as the context for the default bridge configuration. Family Use this field to input the name of your TeamConnection family server. Select the Test Server pushbutton to return an information window that provides server-specific information. If you cannot successfully communicate with the TeamConnection server, you may have specified an invalid family name.
cache services (TCCS) on how to manage the locking behavior for parts that you are exporting to or importing from the TeamConnection repository. Obtain and release Also known as optimistic locking, TCCS will attempt to check out the part(s) before checking in changes that you have made in the ENVY environment. If this action is successful, the part(s) will not be locked in TeamConnection after the export.
Replace existing files Files that currently exist in the target directory are automatically overwritten. Export page The Export page provides default settings options for exporting ENVY components or files to a TeamConnection database. Storage in TeamConnection The Component field identifies the TeamConnection target component for your export action.
mismatches. If you make a change to an application, it is important to update all the exported configuration maps that contain the application and to export all of the configuration maps again. Note: The Export all required maps too checkbox located on the Export page of the Default Properties notebook defaults to this behavior. The following describes two simple cases in which a mismatch might occur: 1. Export a configuration map that contains several applications. 2.
Note: ENVY components must be versioned in ENVY before being exported to TeamConnection. 2. In the Selection Required window, select the desired configuration map or application in the Names list, which will prime the Versions list with a version number. 3. Select the version in the Versions list and move it to the Selected Versions list using the right-arrow pushbutton.
1. Select Configuration Maps, Applications, or Files from the Import cascade menu. 2. If the Show this dialog when exporting and importing option has been set in the default bridge configuration, you will be presented with the Import Properties notebook, which is primed by values in the Default Properties notebook. 3. When you are satisfied with the current values in the Import Properties notebook, select the OK pushbutton. 4.
v A development team using VisualAge Generator wants to perform problem tracking and build generation. v A family is created in TeamConnection with a release r1, defined with a track-driver process (i.e., all part changes are made in reference to work areas). v A build agent and its corresponding build processor has been started to handle build requests for generation, and similarly for preparation.
BOM file for each application contains an entry (at least the name, edition/timestamp, and TCPart type) for each class and method in each application. Object mapping in TeamConnection After a ENVY/Manager-TeamConnection Bridge export action, the following parts are created in TeamConnection in wa1 for f1 in the component and release specified as context for the export action: v For each application of the configuration map there will be an application part.
Refer to the VisualAge Generator Generator’s Guide for more details on the OVR part. 2. In TeamConnection (build function): a. The build administrator selects the EZEPREP collector of the initial build tree of a program proxy in wa1 for f1, and requests a build. b. TeamConnection places the generator build event on the build queue, and the generator build agent detects a new build event that it can service. c.
f. If there are tables and/or map groups used by the program, the generator determines whether there is already a build tree for them. If not, initial build trees are added for them using the program’s OVR part. g. TeamConnection re-examines the build tree of the EZEPREP collector and determines that new build events have been added to the build scope for preparation of the generation outputs, and possibly for generation and preparation of tables and map groups.
4. In TeamConnection (change control): v A project administrator completes the fix record(s) for the defect d1 and adds the work area wa2 to a system test driver. Eventually the driver is committed to the release and the feature is completed.
Appendix G. Source Code Control User’s Guide Differences between other source code control providers and TeamConnection The purpose of this document is to help Visual Basic, Visual C++, and PowerBuilder users, make TeamConnection their Visual environments source code control provider. This document assumes the reader is a new user of TeamConnection, but has some familiarity with source code control. Note: This component is for a client operating in a Windows 95 or NT environment.
Components are used to organize the data in a family. Components are arranged in a hierarchical tree structure, with a single top component called root. The component owns the parts that may be in it, and controls access to the parts. Once you are given access to a component, you have access to all the parts and subcomponents in that component. The component also controls the process that TeamConnection uses, for example, to report and fix a defect.
Note: If you have not already done so, follow the directions and install the TeamConnection client for your workstation. The following directions assume that you have successfully installed the TeamConnection client. Connecting TeamConnection to an IDE In order for TeamConnection to be your source code control provider, both of the following Registry structure conditions must be in place: v HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider contains the key name ProviderRegKey.
– Port Address v Component v Release v WorkArea You also need to know the project name. The project name is used by your development tool to relate to the TeamConnection attributes of family, release, work area, and component by the Source Code Control DLL. Opening a project One of the few differences you see when using TeamConnection as your source code control provider occurs when you open or save a project (depending on the IDE you are using).
Check-in The steps to check-in a file vary by the development environment. In most cases pressing mouse button 2 when the mouse pointer is over a file icon of a file checked out to you, brings up a menu that includes the file check-in option. Selecting the file checkin option opens the Check-In window. Checking the keep checked out box on the Check-In window sets the keep locked flag, TeamConnection saves the file, but keeps it checked out to you.
designate TeamConnection as the Source Code Control provider. From the TeamConnection GUI you can create new work areas (if you have the correct authority), retrieve previous versions of a part, open or process defects, and perform many other actions against parts. Migrating project data bases One key issue for programmers and project managers moving from another source code control system to TeamConnection is how to migrate the database of projects.
Starting a new project Starting a new project in Microsoft Visual Basic, Visual C++, or PowerBuilder is essentially the same regardless of the source code provider. The only operational difference is that the TeamConnection Source Code Control Settings window opens at some point. When the TeamConnection Source Code Control Settings window opens, enter the family attributes, component, work area, and release. Starting Visual Basic: In order to use TeamConnection source code control with Visual Basic.
7. To place the files under source code control, select the Add to Source Code Control option of the Tools menu. Starting PowerBuilder: To create a new project under PowerBuilder, do the following: 1. Start PowerBuilder. 2. Select the Library icon. Note: If TeamConnection Source Code Control is already installed (the TeamConnection Settings window will open), you can proceed with Step 5 3. From the Source menu, select Connect. The Connect dialog box will display. 4.
Appendix H. Supported expandable keywords TeamConnection supports expandable keywords in text files. When a file containing expandable keywords is extracted from TeamConnection, the current value of each keyword is added to the file. This information can help you identify what version of source code is used for your deliverables. TeamConnection supports the following keywords. Keyword Description $ChkD; The time and date stamp applied during check in. $FN; The file name complete with its path.
keyword to appear in the output, add a minus sign (-) after the dollar sign ($). For example, if the statement is prepared as follows: static char _filex_hdr[]="$−KW; $−FN; $−Ver; $−ChkD; $−EKW;"; Then the expanded keywords will look like: static char _filex_hdr[]="$@(#) bin/filex.hdr 1:1 1998/03/20 18:13:19 $−EKW;"; Be aware that if a file is extracted, then locked and checked in, the version information can no longer be updated because the keyword does not appear in the output.
Appendix I. Authority and notification for TeamConnection actions TeamConnection ships with IBM-supplied authority groups, interest groups, component processes, and release processes. Your family administrator can modify these preconfigured authority groups, interest groups, and processes to fit the needs of your organization. Each authority group consists of actions normally performed by a particular type of user.
For this action These users have authority These users are notified AccessDelete v Component owner User whose access was deleted, v Explicitly defined for the component where access is being altered subscribers v Component owner User whose access is being restricted, subscribers AccessRestrict v Explicitly defined for the component where access is being restricted ApprovalAbstain v Approval record owner Approval record owner, subscribers v Explicitly defined for the component that manages the
For this action These users have authority These users are notified ApproverCreate v Release owner New approver, subscribers v Explicitly defined for the component that manages the associated release ApproverDelete v Release owner Deleted approver, subscribers v Explicitly defined for the component that manages the associated release BuilderCreate v Explicitly defined for the component that manages the associated release Subscribers BuilderDelete v Explicitly defined for the component that ma
For this action These users have authority These users are notified CollisionReject v Component owner Release owner, subscribers v Explicitly defined for the component that manages the associated release CompCreate v Parent component owner New component owner v Explicitly defined for the parent component CompDelete v Component owner Component owner, subscribers v Explicitly defined for the component being removed CompLink CompModify v Component owner of the component being linked Owners of
For this action These users have authority These users are notified CoreqDelete v Work area owner of all specified work areas Not applicable v Explicitly defined for the component associated with the release DefectAccept v Defect owner for the component associated with the defect Defect owner, defect originator, duplicate defect originators, subscribers DefectAssign v Defect owner, defect originator New owner, defect originator, v Explicitly defined for the component associated with duplicate d
For this action These users have authority These users are notified DefectModify v Defect owner can modify: Defect owner, defect originator, duplicate defect originators, – answer, abstract, environment, driver, prefix, reference, release, and all configurable fields subscribers v Defect originator can modify: – originator, severity, name, abstract, environment, driver, prefix, reference, release, and all configurable fields v Explicitly defined for the component associated with the defect, these us
For this action These users have authority These users are notified DefectVerify v Defect owner Defect owner, defect originator, v Explicitly defined for the component associated with duplicate defect originators, subscribers the defect DefectView v Defect owner, defect originator Not applicable v Explicitly defined for the component associated with the defect DriverAssign v Driver owner New owner, subscribers v Explicitly defined for the component associated with the release DriverCheck v D
For this action These users have authority These users are notified DriverExtract v Driver owner Not applicable v Explicitly defined for the component associated with the release DriverFreeze v Driver owner Driver owner, subscribers v Explicitly defined for the component associated with the release DriverModify v Driver owner Driver owner, subscribers v Explicitly defined for the component associated with the release DriverRefresh v Explicitly defined for the component associated with Compon
For this action These users have authority These users are notified EnvModify v Release owner Tester, subscribers v Explicitly defined for the component associated with the release FeatureAccept v Feature owner FeatureAssign v Feature owner FeatureCancel v Feature originator Feature owner, feature originator, v Explicitly defined for the component associated with duplicate feature originators, subscribers the feature New owner, feature originator, v Explicitly defined for the component associa
For this action These users have authority These users are notified FeatureModify v Feature owner can modify: Feature owner, feature originator, – abstract, prefix, reference, and all configurable fields duplicate feature originators, subscribers v Feature originator can modify: – abstract, name, prefix, reference, and all configurable fields v Explicitly defined for the component associated with the feature, these users can modify: – abstract, name, originator, prefix, reference, priority*, and tar
For this action These users have authority These users are notified FeatureVerify v Feature owner Feature owner, feature originator, v Explicitly defined for the component associated with duplicate feature originators, subscribers the feature FeatureView v Feature owner Not applicable v Explicitly defined for the component associated with the feature FixActive v Fix record owner, component owner, work area owner Subscribers v Explicitly defined for the component associated with the fix record
For this action These users have authority These users are notified HostCreate v Owner of the user ID for which a host list entry is being created or deleted Not applicable v Superuser HostDelete v Owner of the user ID for which a host list entry is being deleted Not applicable v Superuser MemberCreate v Driver owner Driver owner, subscribers v Explicitly defined for the component associated with the release MemberCreateR v Driver owner Driver owner, subscribers v Explicitly defined for th
For this action These users have authority These users are notified NotifyDelete v Component owner Not applicable v Owner of user ID v Explicitly defined for the component associated with the notification list Note: Users can delete themselves from a notification list without requiring any authority ParserCreate v Explicitly defined for the component associated with Subscribers the release ParserDelete v Explicitly defined for the component associated with Subscribers the release ParserModify v
For this action These users have authority These users are notified PartCheckOut v Component owner Subscribers v Explicitly defined for the component associated with the part PartChildInfo v Component owner Not applicable v Explicitly defined for the component associated with the part PartConnect v Component owner Subscribers v Explicitly defined for the component associated with the part PartDelete v Component owner Subscribers v Explicitly defined for the component associated with the pa
For this action These users have authority These users are notified PartLink v Component owner Subscribers v Explicitly defined for the component associated with the part PartLock v Component owner Subscribers v Explicitly defined for the component associated with the part PartLockForce v Component owner Subscribers v Explicitly defined for the component associated with the part PartMark v Component owner Subscribers v Explicitly defined for the component associated with the part PartMerg
For this action These users have authority These users are notified PartRecreateForce v Component owner Subscribers v Explicitly defined for the component associated with the part PartRecreate v Component owner Subscribers v Explicitly defined for the component associated with the part PartRefresh v Component owner Subscribers v Explicitly defined for the component associated with the part PartRename v Component owner Subscribers v Explicitly defined for the component associated with the p
For this action These users have authority These users are notified PartUndoForce v Component owner Subscribers v Explicitly defined for the component associated with the part PartUnlock v User who checked out or locked the part originally, component owner Subscribers v Explicitly defined for the component associated with the part PartView v Component owner Not applicable v Explicitly defined for the component associated with the part PartViewMsg v Component owner Not applicable v Explicit
For this action These users have authority These users are notified ReleaseExtract v Release owner Not applicable v Explicitly defined for the component associated with the release ReleaseLink v Release owner Release owner, subscribers v Explicitly defined for the component associated with the release ReleaseMerge v Release owner Release owner, subscribers v Explicitly defined for the component associated with the release ReleaseModify v Release owner Release owner, subscribers, new v Expl
For this action These users have authority These users are notified ShadowCreate Explicitly defined for the component associated with the release Not applicable ShadowDefine Superuser Not applicable ShadowDelete Explicitly defined for the component associated with the release Not applicable ShadowDisable Explicitly defined for the component associated with the release Not applicable ShadowEnable Explicitly defined for the component associated with the release Not applicable ShadowModify E
For this action These users have authority These users are notified SizeReject v Sizing record owner Subscribers v Explicitly defined for the component associated with the sizing record TestAbstain v Test record owner Subscribers v Explicitly defined for the component associated with the test record’s release TestAccept v Test record owner Subscribers v Explicitly defined for the component associated with the test record’s release TestAssign v Test record owner New test record owner, subscr
For this action These users have authority These users are notified VerifyAbstain v Verification record owner Subscribers v Explicitly defined for the component associated with the verification record’s defect or feature VerifyAccept v Verification record owner Subscribers v Explicitly defined for the component associated with the verification record’s defect or feature VerifyAssign v Verification record owner VerifyReady Takes place automatically; no authority is required Verification record
For this action These users have authority These users are notified WorkAreaComplet v Work area owner Subscribers v Explicitly defined for the component associated with the release WorkAreaCreate v Defect or feature owner Work area owner, subscribers v Explicitly defined for the component associated with the defect or feature WorkAreaFix v Work area owner Subscribers v Explicitly defined for the component associated with the release WorkAreaFreeze v Work area owner Subscribers v Explicitly
For this action These users have authority These users are notified WorkAreaTest v Work area owner Subscribers v Explicitly defined for the component associated with the release WorkAreaUndo v Work area owner v Explicitly defined for the component associated with the release WorkAreaView v Work area owner Not applicable v Explicitly defined for the component associated with the release Appendix I.
300 User’s Guide
Appendix J. Sample REXX execs, build scripts, and parsers This appendix is composed of the IBM-supplied REXX execs, build scripts, and parsers. Your family administrator can modify these samples to fit the needs of your organization. The samples in this appendix may not be available on all platforms. Refer to the readme file for a complete list of samples available with TeamConnection. All samples are provided as-is and any use of or modifications to the samples are the sole responsibility of the customer.
Script name Function Inputs Environment variables defClone Creates a new defect based on values contained in a specified defect. defectNumber TC_FAMILY [TC_BECOME] defDrvr Lists all defects for a specified driver. driverName TC_FAMILY [TC_BECOME] defFfea Creates a new defect based on values featureNumber TC_FAMILY defNew contained in a specified feature. [TC_BECOME] Displays the number of the most recent TC_FAMILY defect that was entered in the system.
Script name Function Inputs Environment variables drvrMem Lists the defect and feature members of a specified driver for a specified release. driverName [releaseName] TC_FAMILY [TC_RELEASE] mailTo Sends a message to the addresses read through stdin. messagefile subject ownerChg Re-assigns all current work and objects owned by userLogin1 to userLogin2. userLogin1 userLogin2 TC_FAMILY [TC_BECOME] prtChckin Checks parts into the TeamConnection partPathName family.
Script name prtWaGt rByArea Function Inputs Extracts all the parts associated with a specific work area and places them in the releaseName workareaName path specified by the relativePathName parameter. relativePathName Generates a manager’s report based on the areaName ... TC_FAMILY familyName [TC_BECOME] specified areas or departments of interest.
Sample build scripts fhbcob2.cmd Calls the COBOL Visual Set for OS/2 compiler. fhbcob2l.cmd Calls the COBOL Visual Set for OS/2 compiler and link editor. fhbocomp.cmd Calls the VisualAge for C++ icc compiler. fhbolib.cmd Calls the OS/2 implib utility. fhbolin2.cmd Calls the VisualAge for C++ icc link editor. fhbolink.cmd Calls the link386 link editor. fhborc.cmd Calls the OS/2 resource compiler. fhbplbld.cmd Calls the OS/2 PL/1 compiler. fhbpllnk.cmd Calls the OS/2 PL/1 link editor. edcc.
fhbwcomp.c Calls the Microsoft Visual C++ compiler fhbwlink.c Calls the Microsoft linker gather.cmd Calls the Gather tool. Sample parsers fhbcbprs.cmd A parser for COBOL applications. fhbopars.cmd A parser for C applications. fhbcpp.c func.c fhbcpp.h A C parser for COBOL applications. mvsasmp.c mvsasmp.h A parser for MVS assembly language applications. fhbplprs.cmd A parser for PL/1 applications. Sample package files gather.pkf A package file for the Gather tool. softdist.
Customer support Your options for IBM VisualAge TeamConnection Enterprise Server support, as described in your License Information and Licensed Program Specifications, include electronic forums. You can use the electronic forums to access IBM VisualAge TeamConnection Enterprise Server technical information, exchange messages with other TeamConnection users, and receive information regarding the availability of fixes. The following forums are available. v IBM Talklink Use the TEAMC CFORUM.
DB2 service maintenance and technical library To download the latest service maintenance for DB2, use the DB2 Service and Support on the World Wide Web at: v http://www.software.ibm.com/data/db2/db2tech Note: Even though DB2 is bundled with VisualAge TeamConnection you should contact VisualAge TeamConnection Support to report DB2 problems. The licensing for VisualAge TeamConnection does not entitle you to contact directly DB2 Support.
Bibliography IBM VisualAge TeamConnection Enterprise Server library The following is a list of the TeamConnection publications. For a list of other publications about TeamConnection, including white papers, technical reports, a product fact sheet, and the product announcement letter, refer to the IBM VisualAge TeamConnection Enterprise Server Library home page. To access this home page, select Library from the IBM VisualAge TeamConnection Enterprise Server home page at URL http://www.software.ibm.
TeamConnection technical reports The following is a list of technical reports available for TeamConnection. Refer to the IBM VisualAge TeamConnection Enterprise Server Library home page for the most up-to-date list of technical reports. 29.2147 SCLM Guide to TeamConnection Terminology 29.2196 Using REXX command files with TeamConnection MVS Build Scripts 29.2231 TeamConnection Interoperability with MVS and SCLM 29.
Describes how to monitor DB2 database activity and analyze system performance. v Glossary A comprehensive glossary of DB2 terms. Related publications v Transmission Control Protocol/Internet Protocol (TCP/IP) – TCP/IP 2.
312 User’s Guide
Glossary This glossary includes terms and definitions from the IBM Dictionary of Computing, 10th edition (New York: McGraw-Hill, 1993). If you do not find the term you are looking for, refer to this document’s index or to the IBM Dictionary of Computing. This glossary uses the following cross-references: Compare to Indicates a term or terms that have a similar but not identical meaning. Contrast with Indicates a term or terms that have an opposed or substantially different meaning.
build associate. A TeamConnection part that is not an input to or an output from a build. An example of such a part is a read.me file. TeamConnection uses the build target to determine the scope of the build. See also build tree. build cache. A directory that the build processor uses to enhance performance. build tree. A graphical representation of the dependencies that the parts in an application have on one another.
v The work area or driver’s release v Another work area TeamConnection generates a collision record when a user attempts to replace an older version of a part with a modified version, another user has already modified that part, and the first user’s modification is not based on this latest version of the part. command. A request to perform an operation or run a program from the command line interface.
defect. A TeamConnection object used to formally report a problem. The user who opens a defect is the defect originator. case it is the environment where the problem occurred. (3) The string that matches a build server with a build event. delete. If you delete a development object, such as a part or a user ID, any reference to that object is removed from TeamConnection. Certain objects can be deleted only if certain criteria are met. Most objects that are deleted can be re-created. environment list.
development project can be created as a TeamConnection file. Examples include source code, executable programs, documentation, and test cases. file allocation table (FAT). The DOS-, OS/2-, Windows 95-, and Windows NT-compatible file system that manages input, output, and storage of files on your system. File names can be up to 8 characters long, followed by a file extension that can be up to 3 characters. fix record.
automatically granted through inheritance or object ownership. Contrast with base authority and explicit authority. import. To bring in data. In TeamConnection, to bring selected items into a field from a matching TeamConnection object window. inheritance. The passing of configuration management properties from parent to child component. The configuration management properties that are inherited are access and notification. Inheritance within each TeamConnection family or component hierarchy is cumulative.
originator. The user who opens a defect or feature and is responsible for verifying the outcome of the defect or feature on a verification record. This responsibility can be reassigned. owner. The user who is responsible for a TeamConnection object within a TeamConnection family, either because the user created the object or was assigned ownership of the object. P parent component. All components in each TeamConnection family, except the root component, are created in reference to an existing component.
restricted authority. The limitation on a user’s ability to perform certain actions at a specific component. Authority can be restricted by the superuser, the component owner, or a user with AccessRestrict authority. See also authority. indicate whether the defect or feature affects the specified component-release pair and the approximate amount of work needed to resolve the defect or implement the feature within the specified component-release pair. root component.
TeamConnection part. A part that is stored by the TeamConnection server and retrieved by a path name, release, type, and work area. See also part, common part, and type. TeamConnection superuser. See superuser. tester. A user responsible for testing the resolution of a defect or the implementation of a feature for a specific driver of a release and recording the results on a test record. test record.
firmware) used with the product properly exchange accurate date data with it.
Index Special Characters /Ft(dir) builder parameter 157 A Accept Defects window 52 Accept Test Records 96 Activate Fix Records 90 Add Driver Members 88 approval command approving a fix 82 Approval Records window 81 approve state 45 authority basic 26 build 177 for checking in parts 34 for checking out parts 33 for extracting parts 33 B build action 7 build administrator 13 build agent installing on separate machines 137 startup file, creating 144 stopping 145 build environment 149 build event criteria u
builder (continued) for MVS creating 159 environment supported 162 naming 160 passing parameters to a build script 164 versions of 160 for OS/2 creating 147 environment supported 149 naming 148 passing parameters to a build script 151 versions of 148 removing from a part 156 building an application an example build scripts at work 191 creating a build tree 184 creating builders and parsers 184 extracting resulting executable 192 list of tasks 181 starting a build on the client 189 starting servers and agent
concurrent development definition of 51 example of 34, 70 how to work in 31 reconciling differences in reconciling differences in configuration management configuring processes 97 connect function 31 create action 6 Create Builder 147 Create Parser 175 Create Parts window 185 Create Work Areas window no-track process 73 tracking process 89 3 54 D DEBUG 153, 154 defect command accepting 53 closing 70 modifying ownership 79 verifying 70 defects accepting 52, 80 approving the fix 81 closing 69 definition of
examples of (continued) starting make import 236 teamcpak command for Gather 208 teamcpak command for NVBridge 217 writing a build script 153 expand keywords 20 extract action 7 Extract Parts window 62 extracting parts an example of 62 authority needed 33 previous versions of 100 resulting build executable 192 versus checking out 33 F family 6 family administrator responsibilities 12 features definition of 10 states of canceled state 43 closed state 44 design state 43 open state 43 return state 43 review s
H help diagram push button 21 how do I 21 how to access 21 hierarchy component example 7 displaying component structure 25 how do I help 21 I importing makefile information 235 input part 30 installation build components on separate machines 137 creating an MVS build server 137 integrate state of drivers 47 of work areas 46 Integrate Work Areas window 68 integrating commit versus integrate 97 interfaces becoming familiar with 17 description of 5 K keyword DATA 209, 218 EXITPOST 212 EXITPRIOR 212 EXITREPLA
parameters (continued) where specified (continued) attributes of part in a build tree 152 parameters of part -build command 152 parser command connecting parser to parts 178 creating a parser 176 parsers command file fhbopars.
releases (continued) using a configured process 97 versioning 35 report command listing work areas in a release 100 searching for parts 57 to find parts 27 used to view differences 75 Restrict Drivers 93 restrict state of drivers 48, 93 of work areas 46 retrieving past versions of objects 35 return state 43 review state 43 REXX execs 301 rules file creating 237 example of 238 RUNPGM JCL 141 S sample files shipped build script for NVBridge tool 215 build scripts 305 for package function 306 parsers 306 REXX
TC_CASESENSE 227 TC_COMPONENT 22, 227, 238 TC_DBPATH 227 TC_FAMILY 22, 51, 151, 183, 227, 234, 235, 236, 245, 301 TC_INPUT 151, 153, 154, 245 TC_INPUTTYPE 151, 245 TC_LOCATION 151, 245 TC_MAKEIMPORTRULES 227, 235, 238 TC_MAKEIMPORTTOP 227, 236 TC_MAKEIMPORTVERBOSE 227, 236 TC_MIGRATERULES 227 TC_NOTIFY_DAEMON 227 TC_OUTPUT 153, 154 TC_OUTPUTTYPE 151, 245 TC_RELATIVE 83 TC_RELEASE 151, 227, 235, 236, 245, 301 TC_TOP 33, 227 TC_TRACE 227 TC_TRACEFILE 227 TC_TRACESIZE 227 TC_USER 227 TC_WORKAREA 151, 227, 235,
window examples (continued) Parts Filter 27, 56 Reconcile Collision Record 74 Refresh Drivers 92 Refresh Work Areas 66 Restrict Driver 93 Tasks 18 Verify Defects 70 work area automatic creation of 28 canceling 29 creating 53 definition of 8 freezing 28 freezing, an example 65, 85 integrating, concurrent development 72 integrating, serial development 68 linking parts between work areas 32 moving to complete state 96 moving to test state 95 naming 29 reactivating to fix state 90 refreshing, concurrent develop
332 User’s Guide
Readers’ Comments — We’d Like to Hear from You IBM VisualAge TeamConnection Enterprise Server User’s Guide Version 3.0 Publication No.
SC34-4499-03 IBMR _________________________________________________________________________________ Readers’ Comments — We’d Like to Hear from You Cut or Fold Along Line Fold and Tape Please do not staple Fold and Tape _____________________________________________________________________________ NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES BUSINESS REPLY MAIL FIRST-CLASS MAIL PERMIT NO.
IBMR Printed in the United States of America on recycled paper containing 10% recovered post-consumer fiber.
