View Expiration
I will give you a concrete example. We create views to access different version of source control we keep in Clearcase. Some views I use every day. Many views are accessed infrequently. The administrators have put in a policy where views not accessed in the last 30 days get disabled, and then get deleted after 60 days. This is a reasonable policy. If you do not use a view, there is no real need to waste disk space. However the implementation of the disabling and deleting is broken. When I do not access my view frequently, the view gets corrupted by an automated expiration program.
So I find myself unable to recreate views I need infrequently. I then have to submit a trouble ticket. For some reason I have found that my trouble tickets remain unserviced for weeks unless I start making calls and escalating the bad service. This is no way to live as a developer. So the last time this happened, I hit up the administrator as to how he fixed the problem. He showed me that the viewed were stored in a certain directory on the network. When the view gets corrupted, he just renames the directory that corresponds to my view name. Then I am able to recreate the view through the normal process.
I have already used this trick to "fix" views that had been corrupted by the administrator policy. We had it good in the PVCS Version Manager days. I never had to deal with nonsense like this. At times I wish we could go back to simpler days. The fault does not lie with the IBM Rational Product itself. It is the organization that has erroneously implemented an enterprise policy that has created problem for me and my team. Their poor customer service only adds to the problem. It would be great if I could act like a normal consumer and fire this organization, replacing them with someone better. Too bad I do not have the clout at this time to do this for my entire customer organization. But if I had my way, we would be showing some teams the door.
View Setup and Configuration
The viewtag is the name of the view. It must be a unique identifier. It also must take the form of a valid directory name. Here is some guidance on the config spec for a view:
- Each view gets a default config spec
- The default retrieves the most recent version on the main branch
- Can be modified using the "cleartool edcs" command
- Do not change while files are opened in the IDE
- Is case sensitive
In most simple projects, the development takes place on the main branch. The default config spec is taken from the file located at $ATRIAHOME/default_config_spec. CHECKEDOUT in a config spec allows modification of elements. And \main\LATEST allows creation of new elements. Note that a config spec can include other files.
I have more reading to do in my Clearcase Manual book. When I have read and studied the book some more, I will post again and share what I have learned.
Visual C++ Integration and the CLI
A Clearcase view can be assigned to a drive letter like a network drive. There is a "share from Clearcase" option which allows links from one VOB to another VOB. You should not allow Clearcase to auto merge any "resource.h" file from VC++. Clearcase cannot correctly detect some conflicts with this file. When adding files to Clearcase, you must check out the parent directory first.
There are a number of files that you should not add to Clearcase. In general the files that should not be added are those that are generated by the IDE. These files can have extensions such as .aps, .bsc, .clw, .dll, .exe, .exp, .lib, .ncb, .obj, .opt, .pch, .pdb, .res, and .tlb. The full list is extensive. But following the rule of not checking in generated files is usually sufficient.
Clearcase also integrates with other Microsoft tools such as Visual Basic. However I work exclusively with Visual C++ so I will not go into this integration.
The cleartool command starts the command line interface tool. It has an extensive set of commands. It operates in two modes: single command mode and interactive prompt mode. With the single command mode, you type "clearcase
Commands as well as arguments have abbreviations. Here are some additional properties of the single command mode of the CLI:
- The command is first processed by the command shell
- The command shell expands environment variables
- The C run time library interprets quotes to delimit arguments
- The Clearcase commands expand special characters such as the asterisk (*)
Clearcase commands return 0 for success, and a non-zero for errors.
Welcome Back Clearcase
The Windows version of Clearcase is integrated with Windows Explorer. You can issue the "cleartool man" command to see the reference pages. Clearcase is both a version control system and a configuration management system. It is designed for use by teams. Clearcase has a command line interface (CLI) as well as a GUI one. The Clearcase Home Base allows access to most of the tools in Clearcase.
Clearcase objects have properties which are separate from Windows properties. A VOB (versioned object base) is a public storage area. A view is a private storage area for one user. There are two types of views: snapshot and dynamic. You need to use a view to access the VOB. Starting the view activates it so that data appears as a directory to Windows. You must mount at least one VOB and start at least one view to use Clearcase.
The config spec contains the rules that a view uses to select a version. A view can have only one checkout of a given element. Once checked out, only you and the administrator can undo your checkout. There are two types of checkouts: reserved and unreserved. Reserved checkouts are the default, and give an exclusive right to extend a branch to a new version. Unreserved checkouts allow multiple views to get a copy on the same branch, and requires a merge on checkin. The Merge Manager is a GUI tool to help resolve conflicts during the merge.
The Version Tree Browser is a tool which, among many other things, allows you to:
- compare versions of a file
- view meta data (such as labels)
- view a history of events on an object
A View Profile is an optional feature that allows common Clearcase information to be shared by a development team.
Goodbye For Now
So I expect my posts to this blog will be limited unless there is another drastic change in employment. It is sad but I think I shall uninstall my copy of DB2 for Windows. I have already shared the little bit I know about IBM tools in previous posts, mostly about the DB2 database. And who knows? Maybe the new project shall start using another hot IBM tool such as Websphere.
I have already tossed out my book on Understanding DB2. Luckily I did not pitch my library full of Oracle books. They shall come in handy during the next gig. If you want to keep up with my exploits when my next job takes me through a move to the Oracle 10g database, check out my Oracle Development blog. Cheerio for now.
Performance, Problems, and Misc
Frequently you will receive error messages when using the DB2 database. For example you might get the SQL0911N if there is a deadlock that is detected and resolved by DB2. The "SQL" in the SQL0911N error number means that this is an error that comes from the Database Manager. This is the most common error you will encounter as a database developer.
It the event that you suspect that an error is a DB2 bug, technical support may request that you run the db2support utility. It collects all kinds of information and stores it in a file named "db2support.zip". Guess what type of file this is?
The system catalog is contained in the SYSIBM schema. There are read only views for SYSIBM tables in the SYSCAT schema. For example, SYSCAT.TABLES is a view for the underlying SYSIBM.SYSTABLES table.
There is an entity called the Communications Database (CDB) in DB2. It is currently a set of system table with connection information. They are stored in the host database. The CDB used to be a separate database in prior versions of DB2. However it is not part of the catalog.
The DB2 Model
- db2ipccm - listens for local connections
- db2tcpcm - listens for TCP/IP connections
- db2tcpdm - listens for TCP/IP discovery requests
The listener assigns a coordinator agent to work on behalf of a client. DB2 engine dispatch units (workers) are implemented as threads in the Windows version of DB2. The client runs in a different address space than the DB2 engine. This ensures that the database continues even when a client goes down.
The first process to be run when the instance starts is db2sync. It is the system controller. By default there is one coordinator agent per database connection. An application shall get an error if it needs an agent but no free ones are available. DB2 has a Connection Concentrator which allows more database connections than coordinator agents. This is a good option for applications with small amounts of transactions. It improves performance in this scenario.
There are two types of shared memory in DB2 - instance level and database level. Instance level shared memory is used for the following functions:
- snapshots
- event monitoring
- audit logging
- tracing
Database level shared memory is used for the following functions:
- buffer pools
- the lock list
- the sort area
- database heap (log buffer, catalog cache)
- package caching
- utility heap (backup and restore)