Zhengol: Let's start here

Tibco Products Installation Sequences

2009-11-04T14:02:00.001+08:00

Tibco Products Installation Sequences

In this post, we only talk about the tibco products of EMS, Administrator, Running Agent, BusinessWorks, BusinessEvents. Here are the sequence to install the products,

1. install TIBCO EMS. EMS is a messaging system to produce/consume message to/from queues/topics.

2. install Tibco Running Agent. It incluses Tibco Rendezvous, Tibco Hawk (Tibco monitor tool), Tibco Designer (BE, BW development tool)

3. install Tibco Administrator which is the running env for BE, BW or others.

4. install Tibco BusinessWorks which can integrate with many products besides tibco product itself and run as process.

5. install Tibco BusinessEvents which is another tool to handle event/concept/scroecard with rules.

TIBCO EMS: Destination Features

2009-10-14T10:10:00.001+08:00

TIBCO EMS: Destination Features

You can set a secure mode for access control at the queue or topic level

You can set threshold limits for the amount of memory used by the EMS

You can route messages sent to destinations to other servers

You can also create bridges between destinations of the same or different types to create a hybrid messaging model for your application

You can control the flow of messages to a destination

You can exchange messages with other message services.Queues can receive TIBCO Rendezvous and TIBCO SmartSockets messages. Topics can either receive or send Rendezvous and TIBCO SmartSockets messages

You can set queues to be exclusive or non-exclusive. Only one receiver can receive messages from an exclusive queue

You can specify a redelivery policy for queues. When messages must be redelivered, you can specify a property on the queue that determines the maximum number of times a message should be redelivered

You can trace and log all messages passing through a destination

You can include the user name of the message producer in the message with sender_name and sender_name_endorced

Administrator operations can use wildcards in destination names

You can set the failsafe mode on a topic or queue to direct the server to write persistent messages to disk synchronously to guarantee messages are not lost under any circumstances.

You can specify that a consumer is to receive batches of messages in the background to improve performance

EMS: Setup Fault Tolerance

2009-10-12T16:20:00.001+08:00

EMS: Setup Fault Tolerance

Here is the summary to setup fault tolerance servers, tcp://ems1:7222 and tcp://ems2:7222 for example,

In server ems1,ems2, change the property server to same values EMS-SERVER for example.

b. In server ems1, change ft_active to tcp://ems2:7222. In server ems2, change ft_active to tcp://ems1:7222.

c. In both servers, set properties ft_heartbeat, ft_actiation, ft_reconnect_timeout in file tibemsd.conf. The values can be different in bot servers.

d. Make sure both servers use the shared configuration files (users.conf, groups.conf and others) except tibemsd.conf and shared state files(meta.db, async-msgs.db,sync-msgs.db). tibemsd.conf should have 2 copies seperately in both servers. In server ems1, setup 2 folders for configuration and shared state files. Copy all configuration files to the configuration folder named Con for example. Copy all shared state files to another one named DataStore for example.

e. In server ems1, ems2, map above folders to a same driver, like Z: for example.

f. In server ems1,ems2, set properties users, groups, topics, queues, acl_list, factories, routs, bridges, transports, tibrvcm, durables like below to let the server know where to get those configuration files.

users = Z:/Con/Configureusers.conf

groups = Z:/Con/groups.conf

g. In server ems1, ems2, set properties store value like below

store=Z:/DataStore

Note that above property only specify the folder path

h. In servers ems1,ems2, set the property store_minimum_sync, store_minimum_async to the same value

i. If authorized property is set enabled, create a TIBCO EMS id/password pairs. The id should be same as the server property value. In this example, create id named EMS-SERVER. And set the password property accordingly in servers ems1, ems2.

j. Restart TIBCO EMS service in both servers to validate the settings.

All properties above can be founder in tibemsd.conf file.

祖国生日快乐

2009-10-01T14:47:00.001+08:00

祖国生日快乐

祝愿我们伟大祖国繁荣昌盛!!!

祝愿我们伟大的民族长盛不衰!!!

EMS: Steps to Send/Receive Message

2009-09-29T14:28:00.001+08:00

EMS: Steps to Send/Receive Message

Here are the steps to send/receive message from client side, (java code)

Create a connection factory.

ConnectonFactory f = new com.tibco.tibjms.TibjmsConnectionFactory(String serverURL);

Create a connection

Connection c = f.createConnection(String username, String password);

If the server property authorization is disabled, you do not need to specify the username and password.

Create a session

Session s=c.createSession(Boolean transcationFlag, Int delivery_mode);

Get destination

Javax.jms.Queue d=s.CreateQueue(String queueName);

Javax.jms.Topic d=s.CreateTopic(String topicName);

Once the Queue/Topic exists, then return the destination object.

Create message producer to send message, or

MessageProducer p=s.createProducer(Destination d);

Create a Message object, TextMessage object for example,

TextMessage tm = s.createTextMessage();

You can set property for the message and the text body.

tm.setText(String textBody);

tm.setStringProperty(String propertyName, String propertyValue);

p.send(tm);

Create message consumer to receive message

MessageConsumer p=s.createConsumer(Destination d, String selector);

For synchronously receiver,

p.receive();

For asynchronously receiver, you need to implement MessageListener class and restruture the onMessage function.

Class myMessageListener implements MessageListener

{

Public void onMessage(Message message)

{

// add code here to handle if message is sent to queue/topic

System.out.println(“The imcoming message is: “+message);

}

In the main class, set consumer listener

p.setMessageListener(new myMessageListener);

Note that, for the MessageConsumer class, you need to start the connection before receive message from Queue/Topic

start();

Note: another way to get the ConnectionFactory/Queue/Topic object JNDI interface.

TIBCO EMS: Access Control

2009-09-25T14:05:00.001+08:00

TIBCO EMS: Access Control

EMS Permissions

administrator permission

The permission defines the right for users/groups to create, modify, delete, and view users, destinations, routes, factories and others.

Notes: users in admin group have all administrator permissions regardless of the permission settings.

You can not grant revoke administrator permissions from any users in admin group.

Users with change-admin-acl and view-user/group permission can grant or revoke permissions to other users but can only grant or revoke permissions that have been granted.

Users in groups inherit the administrator permission.

destination-based administrator permission

The permission defines the right for users/group to create, modify, delete, purge, view destinations.

Notes: any destination-lever permission granted to a user or group for a wildcard destination is inherited for all child destinations.

user permission

The permission defines the right for users/group to send, receive to/from queue or publish, subscribe to/from topic. Besides, it defines the right to create durable subscriptions to topics.

Server/Destination Connection Settings

Once the authorization is disabled (default setting), the server grants any connection request and doest not check permissions when a client connects to a destination.

Note: users must always log in with the correct administration username and password to perform any administrative function.

Once the authorization is enabled, the server grants connections only from authorized users. The server will check the destination permission if the destination has secure property.

Note: secure is a destination-based property. The server will not check the destination permission even if the destination permissions have defined but the secure property does not set.

TIBCO EMS: Ways to Persistent Message

2009-09-18T16:49:00.001+08:00

TIBCO EMS: PERSISTENT MESSAGE

Persistent messages sent to Queues

Note: server always persistent the message to disk

Persistent messages published to Topics

Note: only persistent the message if the subscribe is one of Durable Consumer or Fault Tolerant Consumer.

Persistent Messages and Failsafe Destinations

Note: once the failsafe in queue or topic are set, the producer or publisher will wait until server persistent the message to disk. Else the server return control to producer or publisher before complete the persistent operations.

TIBCO EMS: Message Delivery Modes

2009-09-18T16:35:00.001+08:00

TIBCO EMS: Message Delivery Modes

There are 3 types delivery mode in the message which is put into JMSDeliveryMode message header field.

PERSISTENT

Note:Server sends confirmation message to producer. The message is persisted on disk by the server.

NON_PERSISTENT

Notes: It depends on authorization and npsend_check_mode (defins in file tibemsd.conf) settings to send confirmation message to producer.

RELIABLE_DELIVERY

Note: a extended delivery mode by TIBCO itself. It has the benefit feature of PERSISTET and not its performance issue.

Hello to solve the error -1072896636 when load xml file

2009-09-06T23:03:00.001+08:00

I have a xml file which defines a internal DTD to validate its contend and make sure the format is valid.

But when I used xmlms 6.0 XML DOM object to load the xml file, the property parseError of the dom object says that there is a parse error. The error code is -1072896636 and its error message is DTD is prohibited.

The reason is that later than xmlms 6.0 one property named prohibitDTD's default value is changed to true by default while it was false in previous versions. So before load any xml file with internal DTD, you should remember to set the property to false before proceed to load the xml file.

Set xmlDoc = CreateObject("Msxml2.DOMDocument.6.0")

xmlDoc.setProperty "ProhibitDTD",False

xmlDoc.load xmltoload.xml

..........

Base ClearCase and ClearQuest Integration

2009-03-17T14:49:00.002+08:00

Base ClearCase and ClearQuest Integration

There are 2 ways to use ClearCase, UCM and Base ClearCase. Both usage patterns can integrate with ClearQuest. In this post, the mainly integration steps between Base ClearCase and ClearQuest will be covered. Below are the steps to enable the CQ and CC integration from scratch,

a. In ClearCase side, Create a ClearCase VOB and mount it.

b. Create views , edit the config spec if need to view and upload source codes.

c. In ClearQuest, setup schema repository and create one production user database.

d. In the CQ designer, apply ClearCase 1.0 package and enable the package to the CQ record type. The package can be applied to any state entity and all those entities can be used to associate with ClearCase versions.

e. Check in the schema and upgrade the user database.

f. Start configuring the integration. In the Base CC and CQ integration, ClearQuest Integration Configuration tool is used to configure the integration settings instead of ClearCase Project Explorer which is used for the UCM CC and CQ integration. Here are the main steps to setup the settings.

Open ClearQuest Integration Configuration tool
Specify the VOB which need to enable the integration
Specify Checkout Policy. (Table 1)
Specify Checkin Policy. (Table 2)
Specify Type Restrictions. (Table 3)
Specify Element Type Restrictions. (Table 4)
Specify Trigger Selection for different platform. (Table 5)
Specify ClearQuest Record Type. Only one record type can be specified here.If the trigger type is V2-Perl, multiple record types which have applied CQ package “ClearCase 1.0” can be used for the integration but need to specify those record types in configure.pl.

g. Edit config.pl to specify the CQ connection and User DB. (Table 6)

The configuration file contains parameters that define local policy choices and how to access Rational ClearQuest user database. The configuration file is located under

ccase-home-dir\lib\CQCC\config.pl.

Define the Rational ClearQuest user database and database set

CQCC_DATABASE_SET- to define the db set value

CQCC_DATABASE_ENTITY_LIST- to define the record types to associate with the CC changes.

For example,

&SetConfigParm("CQCC_DATABASE_SET", "CQCONNECTION");

&SetConfigParm("CQCC_DATABASE_ENTITY_LIST ", "DBNAME: entity1,entity2");

Customize CQSchema object

It accomplishes the following tasks:

Defines a new CQSchema and provides a set of similar record types and properties.(DefineCQSchema)

$s = &DefineCQSchema(NAME=>"MainSchema",

ENTITY_LIST => "entity1,entity2",

RESTRICTIONS => "STANDARD");

Relates the field names of the defect record type to those used by the record types that you specify. (ChangeFieldMap). If multiple record types are used, the field names in the mapping must be present in all record types.

$s->ChangeFieldMap(OWNER => "Owner",

STATE => "State",

ID => "id", #Note: ID shouldn't need to change

HEADLINE => "Headline",

RATL_MASTERSHIP => "ratl_mastership",

# Other mappable names

QUERY_STATES => "Submitted,Assigned,Opened",

MODIFY => "modify"

);

Defines one or more queries(SetQuery) that are used by the trigger to provide the Query option that the developers see and specifies the final RESTRICTIONS check that is made before associations are made.

$s->SetQuery("STANDARD",

"<OWNER> eq <*USER*>",

"<STATE> in <QUERY_STATES>");

Defines the query output format

$s->SetResultSet("STANDARD",

"<ID>,<STATE>,<HEADLINE>",

"%s %-9.9s %1.1s %1.1s %-45.45s");

Below changes in the config.pl can minim meet the requisite to run the Base CC and CQ integration. For the detailed specification of config.pl, you should read

http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?rcss=isacc&topic=/com.ibm.rational.clearcase.int.doc/topics/cc_cq_int/default_topic.htm

h. use cqcc_launch -test to check the configuration

Table 1. Checkout Policy

Policy Settings	Comments
Never prompt the user for change requests	No need to associate CQ record when do check out action.
Prompt the user for optional change requests	Prompt the user to specify the CQ record to associate with the changes optional. Optional here means when system prompts the user to specify the CQ record, user can assign a CQ record to associate or not.

Table 2. Checkin Policy

Policy Settings	Comments
Never prompt the user for change requests	No need to prompt user to specify the CQ record when user does check in action. If there is a CQ record has associate with the checked-out file, the change set will log into the CQ record after check in
Prompt user for optional change requests	Prompt user to specify the CQ record to associate with the changes optional. If no CQ record specified, the function works as the setting “Never prompt the user for change requests” If CQ record specified, log the changeset in this CQ record no matter the CQ record is same as the check-out one or not.
Prompt user and require one or more change request	Prompt the user to specify the CQ record to associate with the changes. Once the option is set, one or more CQ record must be associate with the changes. If multiple CQ records selected, log the changeset in each of the CQ record

Table 3. Branch Type Restrictions

Policy Settings	Comments
Policies apply to branches of all types	Apply the check out/in policies to all branch types.
Policies apply to branches of selected types	Apply the check out/in policies only to the selected branch types.

List 4. Element Type Restrictions

Policy Settings	Comments
Policies apply to branches of all types	Apply the check out/in policies to all element types.
Policies apply to branches of selected types	Apply the check out/in policies only to the selected element types.

Table 5. Trigger Selection

Policy Settings	Comments
V1-VisualBasic	Can be used only in Windows platform
V1-Perl	Can be used both in Windows and Unit/Linux platform
V2-Perl	The new version of V1-Perl. If V2-Perl is set, you have the following options. Use a local configuration file and local trigger scripts Use a shared, centrally located configuration file and local copies of trigger scripts Use a shared, centrally located configuration file and shared trigger scripts. (set the option “Use the trigger scripts in Path directory” and place the cqcc_launch.bat/pl in the same directory of config.pl

Table 6. Variables in confige.pl

Configuration parameter	Description
CQCC_ASSOC_BATCH_CONFIRM	Displays a window that confirms that the batch completed successfully.
CQCC_ASSOC_BATCH_ENABLE	Allows delay in processing multiple Rational ClearQuest association transactions until end of single Rational ClearCase operation or user-defined batch
CQCC_ASSOC_BATCH_SERIES	Specifies that a user-defined series is active and normal Rational ClearCase series-end processing should be suppressed
CQCC_AUTO_ASSOCIATE	Sets one or more change requests for automatic association on checkout and checkin without user interaction
CQCC_AUTO_ASSOCIATE_ENABLE	Specifies whether developers can use CQCC_AUTO_ASSOCIATE
CQCC_COMMENT_PATTERN	Sets pattern by which developers can make associations in a checkout or checkin comment
CQCC_CQWEB_ONLY	Forces use of Rational ClearQuest Web interface
CQCC_CQWEB_VERSION	Specify either 2.0 (Java™) or "1.0" (ASP with IIS) as Rational ClearQuest Web server protocol
CQCC_DATABASE_ENTITY_LIST	Defines logical name of database and related record types (entities) that support associations.
CQCC_DATABASE_SET	Database set name (connection) for one of multiple schema repositories; used with CQCC_DATABASE_ENTITY_LIST
CQCC_DEBUG	Controls level of output generated for problem diagnosis; 0 (none), 1 (basic), 2 (verbose)
CQCC_GUI_ENABLE	Allows use of Perl/TK graphic user interface
CQCC_LOG_OUTPUT	Records to a log file messages for problem diagnosis
CQCC_MULTIPLE_ASSOCS	Allows or prevents multiple defects to be associated with change
CQCC_MULTISITE	Enables Rational ClearCase MultiSite support
CQCC_POSTCHECKIN_COMMIT	Allows commitment of associations in Rational ClearQuest user database to be delayed until checkin completes in Rational ClearCase VOB
CQCC_QUERY_ENABLE	Allows developer-selected queries for making associations
CQCC_QUERY_FILTER	Controls which queries are presented to developers for associations
CQCC_RESTRICTIONS_TIMEOUT	Specifies number of seconds that a restrictions check can be reused during batch processing
CQCC_SERVER	Name of Rational ClearQuest Web server
CQCC_SERVERROOT	Name of folder in which Rational ClearQuest Web server is located
CQCC_SERVER_SSL	Enables secure communications for the Rational ClearQuest Web connection.
CQCC_TIMER	Allows recording of internal timing data
CQCC_WEB_DATABASE_SET	CQCC_DATABASE_SET for Web server
CQCC_REPLICA_NAME	For Rational ClearQuest Web client to specify user database replica name

The Main Difference between UCM/Base ClearCase and ClearQuest Integration

2009-03-17T14:49:00.001+08:00

The Main Difference between UCM/Base ClearCase and ClearQuest Integration

In Base CC and CQ integration, it is in VOB lever. In UCM CC and CQ integration, it is UCM Project Lever.

In Base CC and CQ integration, the configuration is more flexible. Once the VOB has enabled CQ and CC integration, it also can configure the check-out/in policies and can specify which branch type or element type use the policies settings. In UCM CC and CQ integration, all changes in that UCM project must associate with CQ items. In other words, Base CC and CQ integration, it is a loose integration while it is more close in UCM CC and CQ integration.

In Base CC and CQ integration, one change/version can associate multiple CQ records but it does not in UCM CC and CQ integration.

In Base CC and CQ integration, same CQ record can use in different branches while in UCM CC and CQ integration, same CQ record can only work on one stream.

In Base CC and CQ integration, it can use the web interface to do integration without any CQ client installed while in UCM CC and CQ integration, it is a must to install the CQ client.

To use which type of integration mainly depends on the model you use the CC. In most cases, UCM is more easy/standard process to use compared with Base ClearCase. In UCM model, user do not need to know more details about the CC working mechanism itself like, config spec, branch, element type and others but only need to know the relationship between view,stream,integration stream and know when to deliver, merge, rebase.

Usage of Config Spec

2009-03-09T17:18:00.001+08:00

Usage of Config Spec

Config Spec is used to select file versions based on the rules defined in that configuration. It is a must to know if base ClearCase pattern is used. Below is the detailed usage of Config Spec.

https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bcfg_hwcfgwrk.htm

Make VOB Replica

2009-02-24T13:54:00.001+08:00

Make VOB Replica

There are 4 phases to setup a VOB replica. Here are the details for each phase.

Prerequisites

Make sure MultiSite licenses are installed.

Check the license server configuration and make sure there are CC and CC Multisite licenses in the license server.

Rename the original replica appropriately.

Even though the original VOB has not yet been replicated, its VOB database has a VOB replica object, named original

The administrator (VOB owner, CC Admin users) renames the VOB replica object to a meaningful name using below command. Below example is to change the original replica to BEI_HUB

multitool rename replica:original BEI_HUB

Make sure the VOB is not locked.

cleartool lslock vob:vob_tab

Make sure that all VOB source container are accessible using the checkvob command. In a view context, run below command,

cleartool checkvob –log c:\temp\cclog.log –pool –source

Determine the size of the VOB database and source pools.

Using below command to get the space and make sure the –workdir directory has the greater space then the vob size when export the vob.

cleartool space vob_tag

Export Phase

Backup the original VOB.

Enter export command and use proper transfer method.

Below example is to create a new vob replica ZHA_HUB on host zhaccserver

multitool mkreplica –export –workdir c:\temp\workdir –fship –sclass CLASS_NAME zhaccserver:ZHA_HUB@vob_tag

Verify the replica-related changes.

Below command list all replicas of the vob.

multitool lsreplica –invob vob_tag

For above example, it should output 2 replicas named BEI_HUB and ZHA_HUB

Also you can list the history events happened to the original vob replica using below command:

cleartool lshistory replica:BEI_HUB@vob_tag

Transport phase

Send the export packet to the new site. In the most cases, we use the shipping server to transfer the packages.

Import Phase

In the receiving host, Verify the export packages have arrived.

Enter import command to import the packages.

In below example, the new replica will be created with permission and identity preserver options.

multitool mkreplica –import –preserve –work c:\temp\workdir –tag vob_tag –vob unc_path_of_storage_pool path_of_the_packet_to_import

Delete the replica-creation packet.

Make sure that the owner,group and group list of the new VOB are the same as the owner, group and group list of the new VOB are the same as the owner, group and group list of the other identities and permissions-preserving replicas in the VOB family. To change these values, run the cleartool protectvob command on the new VOB replica.

Any changes on the new vob replica, sync updates to its sibling replicas.

Make the new replica self-mastering before begin to set feature lever.

Set the feature level of the new replica on the replica host.

Send an update packet to all other replicas in the VOB family

ClearCase MultiSite Administration Web Console

2009-02-23T16:20:00.001+08:00

ClearCase MultiSite Administration Web Console

The ClearCase MultiSite Administration Web Console is a web-based interface that MultiSite administrators can use to manage all replicas at their site.

To access the ClearCase Multisite Administration Web Console from a web client, input below URL:

http://replica_host_name/msweb/

Using this web console, you can perform specific tasks:

Access and View. Like view replica properties, vob family and replica server information, scheduled jobs.
Generate and View synchronization health status for a VOB family
Troubleshoot a failed synchronization
Create,Schedule,and Modify properties of a scheduled job
Force a synchronization between replicas
Modify the Multisite Administration ACL (access control list)

佘艳：天堂有你更美丽

2008-12-28T20:14:00.005+08:00

天堂有你更美丽

有一个美丽的小女孩，她的名字叫做佘艳，她有一双亮晶晶的大眼睛，她有一颗透亮的童心。她是一个孤儿，她在这个世界上只活了8年，她留在这个世界上最后的话是“我来过我很乖”。她希望死在秋天，纤瘦的身体就像一朵花自然开谢的过程。在遍地黄花堆积，落叶空中旋舞时候，她会看见横空远行雁儿们。她自愿放弃治疗，把全世界华人捐给她的54万元救命钱分成了7份，把生命当成希望的蛋糕分别给了7个正徘徊在生死线的小朋友。

1、我自愿放弃治疗

她一出生就不知亲生父母，她只有收养她的“爸爸”。

1996年11月30日，那是当年农历10月20日，因为“爸爸”佘仕友在永兴镇沈家冲一座小桥旁的草丛中发现被冻得奄奄一息的这个新生婴儿时，发现她的胸口处插着一张小纸片，上面写着：“10月20日晚上12点。”

家住四川省双流县三星镇云崖村二组的佘仕友当时30岁，因为家里穷一直找不到对象，如果要收养这个孩子，恐怕就更没人愿意嫁进家门了。看着怀中小猫一样嘤嘤哭泣的婴儿，佘仕友几次放下又抱起，转身走又回头，这个小生命已经浑身冰冷哭声微弱，再没人管只怕随时就没命了！咬咬牙，他再次抱起婴儿，叹了一口气：“我吃什么，你就跟我吃什么吧。”

佘仕友给孩子取名叫佘艳，因为她是秋天丰收季节出生的孩子。单身汉当起了爸爸，没有母乳，也买不起奶粉，就只好喂米汤，所以佘艳从小体弱多病，但是非常乖巧懂事。春去春又回，如同苦藤上的一朵小花，佘艳一天天长大了，出奇得聪明乖巧，乡邻都说捡来的娃娃智商高，都喜欢她。尽管从小就多病，在爸爸的担惊受怕中，佘艳慢慢地长大了。

命苦的孩子的确不一般，从5岁起，她就懂得帮爸爸分担家务，洗衣、煮饭、割草她样样做得好，她知道自己跟别家的孩子不一样，别家的孩子有爸爸有妈妈，自己的家里只有她和爸爸，这个家得靠她和爸爸一起来支撑，她要很乖很乖，不让爸爸多一点点忧心生一点点气。

上小学了，佘艳知道自己要好学上进要考第一名，不识字的爸爸在村里也会脸上有光，她从没让爸爸失望过。她给爸爸唱歌，把学校里发生的趣事一样一样讲给爸爸听，把获得的每一朵小红花仔仔细细贴在墙上，偶尔还会调皮地出道题目考倒爸爸……每当看到爸爸脸上的笑容，她会暗自满足：“虽然不能像别的孩子一样也有妈妈，但是能跟爸爸这样快乐地生活下去，也很幸福了。”

2005年5月开始，她经常流鼻血。有一天早晨，佘艳正欲洗脸，突然发现一盆清水变得红红的，一看，是鼻子里的血正向下滴，不管采用什么措施，都止不住。实在没办法，佘仕友带她去乡卫生院打针，可小小的针眼也出血不止，她的腿上还出现大量“红点点”，医生说，“赶快到大医院去看！”来到成都大医院，可正值会诊高峰，她排不上轮次。独自坐在长椅上按住鼻子，鼻血像两条线直往下掉，染红了地板。他觉得不好意思，只好端起一个便盆接血，不到10分钟，盆子里的血就盛了一半。

医生见状，连忙带孩子去检查。检查后，医生马上给他开了病危通知单。她得了“急性白血病”！这种病的医疗费是非常昂贵的，费用一般需要30万元！佘仕友懵了。看着病床上的女儿，他没法想太多，他只有一个念头：救女儿！借遍了亲戚朋友，东拼西凑的钱不过杯水车薪，距离30万实在太远，他决定卖掉家里唯一还能换钱的土坯房。可是因为房子太过破旧，一时找不到买主。

看着父亲那双忧郁的眼睛和日渐消瘦的脸，佘艳总有一种酸楚的感觉。一次，佘艳拉着爸爸的手，话还未出口眼泪却冒了出来：“爸爸，我想死……”

父亲一双惊愕的眼睛看着她：“你才8岁，为啥要死？”

“我是捡来的娃娃，大家都说我命*，害不起这病，让我出院吧……”

6月18日，8岁的佘艳代替不识字的爸爸，在自己的病历本上一笔一画地签字：“自愿放弃对佘艳的治疗。”

2、8岁女孩乖巧安排后事

当天回家后，从小到大没有跟爸爸提过任何要求的佘艳，这时向爸爸提出两个要求：她想穿一件新衣服，再照一张相片，她对爸爸解释说：“以后我不在了，如果你想我了，就可以看看照片上的我。”

第二天，爸爸叫上姑姑陪着佘艳来到镇上，花30元给佘艳买了两套新衣服，佘艳自己选了一套粉红色的短袖短裤，姑姑给她选了一套白色红点的裙子，她试穿上身就舍不得脱下来。三人来到照相馆，佘艳穿着粉红色的新衣服，双手比着V字手势，努力地微笑，最后还是忍不住掉下泪来。

她已经不能上学了，她长时间背着书包站在村前的小路上，目光总是湿漉漉的。

如果不是《成都晚报》的一个叫傅艳的记者，佘艳将像一片悄然滑落的树叶一样，静静地从风中飘下来。

记者阿姨从医院方面得知了情况，写了一篇报道，详尽叙说佘艳的故事。旋即，《8岁女孩乖巧安排后事》的故事在蓉城传开了，成都被感动了，互联网也被感动了，无数市民为这位可怜的女孩心痛不已，从成都到全国乃至全世界，现实世界与互联网空间联动，所有爱心人士开始为这个弱小的生命捐款，“和谐社会”成为每个人心中的最强音。短短10天时间，来自全球华人捐助的善款就已经超过56万元，手术费用足够了，小佘艳的生命之火被大家的爱心再次点燃！宣布募捐活动结束之后，仍然源源不断收到全球各地的捐款。所有的钱都到位了，医生也尽自己最大努力，一个接一个的治疗难关也如愿地一一闯过！大家沉着地微笑着等待成功的那一天！有网友如是写道：“佘艳，我亲爱的孩子！我希望你能健康的离开医院；我祈祷你能顺利的回到学校；我盼望你能平安的长大成人；我幻想我能高兴的陪你出嫁。佘艳，我亲爱的孩子……”

6月21日，放弃治疗回家等待死神的佘艳被重新接到成都，住进了市儿童医院。钱有了，卑微的生命有了延续下去的希望和理由。

佘艳接受了难以忍受的化疗。玻璃门内，佘艳躺在病床上输液，床头旁边放着一把椅子，椅子上放一个塑料盆，她不时要侧身呕吐。小女孩的坚强令所有人吃惊。她的主治医生徐鸣介绍，化疗阶段胃肠道反应强烈，佘艳刚开始时经常一吐就是大半盆，可她“连吭都没吭一声”。刚入院时做骨髓穿刺检查，针头从胸骨刺入，她“没哭，没叫，眼泪都没流，动都不动一下”。

佘艳从出生到死亡，没有得到一丝母爱的关照。当徐鸣医生提出：“佘艳，给我当女儿吧！”佘艳眼睛一闪，泪珠儿一下就涌了出来。第二天，当徐鸣医生来到她床前的时候，佘艳竟羞羞答答地叫了一声：“徐妈妈。”徐鸣开始一愣，继而笑逐颜开，甜甜地回了一声：“女儿乖。”

所有的人都期待奇迹发生，所有的人都在盼望佘艳重生的那一刻。很多市民来到医院看望佘艳，网上很多网民都在问候这位可怜的孩子，她的生命让陌生的世界撒满了光明。那段时间，病房里堆满了鲜花和水果，到处弥漫着醉人的芬芳。

两个月化疗，佘艳陆续闯过了9次“鬼门关”，感染性休克、败血症、溶血、消化道大出血……每次都逢凶化吉。由省内甚至国内权威儿童血液病专家共同会诊确定的化疗方案，效果很好，“白血病”本身已经被完全控制了！所有人都在企盼着佘艳康复的好消息。但是，化疗药物使用后可能引起的并发症非常可怕。而与别的很多白血病孩子比较，佘艳的体质差很多。经此手术后她的体质更差了。

8月20日清晨，她问傅艳：“阿姨，你告诉我，他们为什么要给我捐款？”

“因为，他们都是善良人。”

“阿姨，我也做善良人。”

“你自然是善良人。善良的人要相互帮助，就会变得更加善良。”

佘艳从枕头下摸出一个数学作业本，递给傅艳：“阿姨，这是我的遗书……”

傅艳大惊，连忙打开一看，果然是小佘艳安排的后事。这是一个年仅8岁的垂危孩子，趴在病床上用铅笔写了三页纸的《遗书》。由于孩子太小，有些字还不会写，且有个别错别字。看得出整篇文章并不是一气呵成写完的，分成了六段。开头是“傅艳阿姨”，结尾是“傅艳阿姨再见”，整篇文章“傅艳阿姨”或“傅阿姨”共出现7次，还有9次简称记者为“阿姨”。这16个称呼后面，全部是关于她离世后的“拜托”，以及她想通过记者向全社会关心她的人表达“感谢”与“再见”。

“阿姨再见，我们在梦中见。傅艳阿姨，我爸爸房子要垮了。爸爸不要生气，不要跳楼。傅阿姨你要看好我爸爸。阿姨，医我的钱给我们学校一点点，多谢阿姨给红十字会会长说。我死后，把剩下的钱给那些和我一样病的人，让他们的病好起来……”

这封遗书，让傅艳看得泪流满面，泣不成声。

3、我来过，我很乖

8月22日，由于消化道出血，几乎一个月不能吃东西而靠输液支撑的佘艳，第一次“偷吃东西”，她掰了一块方便面塞进嘴里。很快消化道出血加重，医生护士紧急给她输血、输液……看着佘艳腹痛难忍、痛苦不堪的样子，医生护士都哭了，大家都愿意帮她分担痛苦，可是，想尽各种办法还是无济于事。

8岁的小佘艳终于远离病魔的摧残，安详离去。

所有人都无法接受这个事实：那个美丽如诗、纯净如水的“小仙女”真的去了另一个世界吗？记者傅艳抚摸着佘艳渐渐冰冷的小脸，泣不成声，再也不能叫他阿姨了，再也不能笑出声来了……

四川在线等网站沉浸在泪海里，互联网被泪水打湿透了，“心痛到不能呼吸”。每个网站的消息帖子下面都有上万条跟帖，花圈如山，悼词似海，一位中年男士喃喃低语：“孩子，你本来就是天上的小天使，张开小翅膀，乖乖地飞吧……” 8月26日，她的葬礼在小雨中举行，成都市东郊殡仪馆火化大厅内外站满了热泪盈眶的市民。他们都是8岁女孩佘艳素不相识的“爸爸妈妈”。为了让这个一出生就被遗弃、患白血病后自愿放弃自己的女孩，最后离去时不至于太孤单，来自四面八方的“爸爸妈妈们”默默地冒雨前来送行。

她墓地有她一张笑吟吟的照片，碑文正面上方写着：“我来过，我很乖(1996.11.30.--2005.8.22)”

后面刻着关于佘艳身世的简单介绍，最后两句是：“在她有生之年，感受到了人世的温暖。小姑娘请安息，天堂有你更美丽。”

遵照小佘艳的遗愿，把剩下的54万元医疗费当成生命的馈赠留给其他患白血病的孩子。这7个孩子分别是杨心琳、徐黎、黄志强、刘灵璐、张雨婕、高健、王杰。这七个可怜的孩子，年龄最大的19岁，最小的只有2岁，都是家境非常困难，挣扎在死亡线上的贫困子弟。

9月24日，第一个接受佘艳生命馈赠的女孩徐黎在华西医大成功进行手术后，她苍白的脸上挂上了一丝微笑：“我接受了你生命赠与，谢谢佘艳妹妹，你一定在天堂看着我们。请你放心，以后我们的墓碑上照样刻着：我来过，我很乖……”

在中国不知有多少这样不幸的家庭？！谁是我们的摩西？指引我们，让我们看到希望?!

祝所有善良的人们幸福平安！！！

Undo a Deliver Operation

2008-12-17T11:01:00.001+08:00

Undo a Deliver Operation

Any time before completing the deliver operation, you can undo changes made as a result of the operation. This undo procedure is valid only if you have started a deliver operation, have not checked in modifications in the target view, and have not completed the deliver operation.

An undo deliver command is provided, which cancels all checkouts in the integration view and removes all merge arrows created during the current deliver operation.

If you checked in any versions to the integration view, using the undo deliver command is not sufficient to undo the deliver operation. In this case, you must either complete the operation (recommended) or use cleartool rmver -xhlink to remove the versions you checked in before canceling the operation. Because rmver erases part of your organizational development history, your organization may not allow individual developers to use it. Be very conservative in using this command, especially with the -xhlink option, which may have unintended consequences.

File Merge Algorithm

2008-12-17T09:30:00.001+08:00

File Merge Algorithm

A merge combines the contents of two or more versions into a single new version. Before know how the merge works, we need know below terms:

The source contributors: one version from your development stream and one version from the target stream.
The base contributors: the common ancestor of the source versions.
The destination version: the merge output, which in a deliver operation becomes a new version in the target stream and in a rebase operation becomes a new version in the development stream

How files and directory are merged

To merge files and directories:

The base contributor is identified.
Each contributor is compared with the base contributor using the Rational ClearCase merge algorithm.
For any line that is unchanged between the base contributor and any other contributor, the line is copied to the merge output file.
For any line that has changed between the base contributor and one other contributor, the change in the contributor is accepted. Depending on how you started the merge operation, the change may be copied to the merge output file. However, you can disable the automated merge capability for any merge operation. If you disable the capability, you must approve each change to the merge output file.
For any line that has changed between the base contributor and more than one other contributor, you are required to resolve the conflicting difference manually.

About Baseline Considerations in the Deliver Operation

2008-12-16T16:03:00.001+08:00

About Baseline Considerations in the Deliver Operation

If the foundation baseline of the source stream is different from that of the target stream, the deliver operation includes activities in the foundation baseline plus all activities created after the foundation baseline. This baseline difference prevents you from delivering only selected changes.

S1. For example, the Feature stream in figure below is configured with baseline 0. The developer working in the Developer1 stream delivers activity Activity1 to the Feature stream.

The owner of the Feature stream creates baseline 1 in that stream. Activity1 is included in baseline 1. The developer in the Developer1 stream continues working on a new activity and delivers activity Activity2 to the Feature stream.

If the integrator of the Feature stream delivers work to the Integration stream, the deliver operation includes Activity2 plus the activities in included in baseline 1. The integrator can not deliver only Activity2.

S2. Another baseline consideration arises when you deliver to an alternative target stream, as shown in the figure below.

The Developer1 stream delivers Activity1 to an alternative target, the Integration2 stream. As an intermediate step, the deliver operation creates a hidden baseline D (referred to as a deliver baseline) in the Developer1 stream. If the Developer1 stream next tries to deliver only Activity2 to the Integration1 stream, the deliver operation requires that the changes associated with the deliver baseline (Activity1) be delivered. In this case, you can not deliver only activity2, but must deliver Activity1 (which is included in the deliver baseline) also.

Handling Elements That Are Not Visible During a deliver (or rebase) Operation

2008-12-15T14:50:00.001+08:00

Handling Elements That Are Not Visible

During a deliver (or rebase) operation, you might see the following warning message about elements not being visible in the integration view:

1 elements were skipped because they are not visible. You should determine why they are not visible before you complete this deliver or rebase operation. If these elements should be visible, cancel this operation, fix the problem, and re-run the operation

Do not ignore this message. The deliver operation found versions of elements in the development stream that need to be considered for merging to the target stream, but does not find the elements in the target stream. The following cases are some reasons for this situation:

A new element was added to source control, but the directory that catalogs the element is not checked in. In this case, cancel this deliver (or rebase) operation, check in the directory, and start a new deliver (or rebase) operation.

While a change to the element was being made(in the development stream, for a deliver operation; in the stream from which you are rebasing, for a rebase operation), someone operated on the element ( in the target stream, for a deliver operation; in the development stream, for a rebase operation), as follows:

® The name of the element or the name of a VOB symbolic link to the element was removed.

® The element itself or the VOB symbolic link to the element was removed.

In either of these cases, decide whether the removal was appropriate. If the removal was appropriate, you can allow the deliver (or rebase) operation to ignore the element.

The change may be obsolete because you intended or remove the name of the element or the element itself.

Because the cause of the problem can not be determined by the deliver or rebase operation, you must find the cause, fix the problem, cancel the current deliver9or rebase)operation, and start a new operation.

About Higacked Files

2008-12-15T11:43:00.001+08:00

What is HiJacked Files

The hijacked file is the file which is modified but without checked-out. In the ClearCase, only checked-out files can be edited and saved after updating. All elements in CC source control are give the file attribute of read-only. When the file is checked out, the ready-only attribute is cleared and it can be modified then. In Dynamic List view, the file attribute can not be changed while it can in snapshot view somehow. So the hijaced file is only for Snapshot view.

Hijacked Files Operations when Update The Snapshot View

When you update the snapshot view, you have these choices for the hijacked files:

Leave hijacked files in place
Rename the hijacked files and load the selected version form the VO
Delete hijacked files and load the selected version from the VOB

The procedure of the deliver operation

2008-12-11T11:47:00.000+08:00

The procedure of the deliver operation

The deliver operation proceeds in the following order:

When you start the deliver operation, your development stream is placed in the deliver-in-progress state.
Dependencies between versions in the change sets of the activities that are as yet undelivered in the target stream are checked.
Each directory in your development stream is evaluated sequentially. Versions are checked out and changes are merged to the target stream when needed. If a reserved directory checkout is encountered in the target stream, the deliver operation stops. Any successful directory merges are retained.
An attempt is made to check out each element that requires a merge. If an element that cannot be checked out is encountered (for example because another team member’s deliver operation has already checked out the element), the element is skipped and more attempts are made to check out the remaining elements.
If an element cannot be checked out, the deliver operation does not proceed to the following step. In this case, you have two options:

Wait until the other developer completes or cancels the deliver operation, and then restart your deliver operation. However, with a deliver operation in progress, any new versions you create in your development stream are not delivered until the next deliver operation.
Undo your deliver operation and continue working on your activities.

After all elements that can be checked out are successfully checked out, each element is merged. Diff Merge starts and requests your input when merge conflicts are encountered.
When all merges are finished, you are prompted to build and test the work in your integration view.
The deliver operation stays in the deliver-in-progress state until you formally complete the operation (issue the complete command). To complete the deliver, the following is done:

The merge results in the target stream are checked in.
The state of the stream is changed to Complete.

Delete activities when ClearQuest Record is linked with a UCM activity

2008-12-11T11:22:00.001+08:00

Delete activities when ClearQuest Record is linked with a UCM activity

You can enable ClearQuest and ClearCase integration to manage the developement process. ClearQuest is used as a defect tracking tool and ClearCase is used as source control repository. If a Rational ClearQuest record is linked with a UCM activity and you want to delete the activity, you should do:

Remove the link between UCM activity and ClearQuest records (In ClearCase side)
Delete ClearQuest records(in ClearQuest side)

Before you remove the link between UCM activity and ClearQuest records, below requisiton must be fulfilled:

no changeset in that activity. If yes, move the change sets to other activity
the operator to do this must be the owner of the ClearQuest record. Not the submitter but the owner

Then you can use below command to remove the link

cleartool rmactivity clearquest_record_id

executing above command does not delete the ClearQuest record. So you must login the ClearQuest and do the Delete action then. The access control of the Deletion is defined in the ClearQuest schema. You should ask the ClearQuest admin to confirm if you have the right to delete the record.

How file/directory checkouts are canceled

2008-12-11T09:42:00.001+08:00

How file/directory checkouts are canceled

How file checkouts are canceled

When you cancel the checkout of a file element, the request is handled as follows:
You have prompted to rename the fie in your view to filename.keep
The VOB is notified that you no longer have the version checked out in your view
In a snapshot view, the version that was in your view when you performed the checkout operation is copied from the VOB
In a dynamic view, the version-selection rules in the config spec are used to select a version.

How directory checkouts are canceled

When you cancel a directory checkout, the VOB is notified that you no longer have the version of the directory checked out to your view. But you are not prompted to rename a canceled directory checkout to directory-name.keep.
If you cancel a directory checkout after any changes you made to rename,move, create link will lost. Any new elements you created (with mkelem or mkdir) become orphaned. But pls note that if you just only modify the content (add/remove/update lines) in the file and check in the file, the file version and its content is still there although you undo check out against that folder.

Orphaned elements are moved to the VOB lost+found directory under names of this form:

element-anme.UUID

In a snapshot view, view-private objects are not removed nor is the update operation for the directory in the view started. To return the directory in your view to its state before you checked it out, you must start the Update Tool.

Action	Result after undo checkout its parent directory	Input into lost+found
rename element	stay in the view but the Kind is view-private	No
create dir and add to source control	stay in the view but the Kind is view-private	Yes
create element and add to source control	stay in the view but the Kind is view-private	Yes
create link and add to source control	stay in the view but the Kind is view-private	No
delete element	can not show again until you update the view	No

In a dynamic view, view-private objects are not removed, but the view does revert to its previous state.

Action	Result after undo checkout its parent directory	Input into lost+found
rename element	recover the name to its previous one	No
create dir and add to source control	dispear	Yes
create element and add to source control	dispear	Yes
create link and add to source control	dispare	No
delete element	show again	No

To move the elements from the lost+found directory

To move an element from the lost+found directory to another dirctory within the VOB, use the cleartool mv command.
To move an element from the lost+found directory to another VOB, use the relocate command.

To delete an element in the lost+found directory

To delete an element in the lost+found directory permanently, use rmelem command.

Checking out directory

2008-12-11T09:35:00.000+08:00

Checking out directory

Directories and files under Rational ClearCase source control. Having versions of directories can be helpful if, for example,you rename a source file used in a particular release and then modify your makefile to reflect this change. If you need to rebuild a previous release, you can set up your view to sleect the version of the directory that contains the file under its previous name.

On Unix system

To add a file or subdirectory to Rational ClearCase control, you must first check out the parent directory. It is common mistake that, after checking out a parent directry and adding elements to it, users forget to check in the directory. If you check out a directory, you can see its modified contents form your view, but other users can not see the modifications until you check in it.

On Windows system

You rarely need to check out a directory explicitly. The parent directory of a file is checked out and checked in when you add the file to source control. in a directory under version control, a new version of the directory is created when you add or rename a file element under source control. Before you modify the contend in the view, if you check out the parent directory explicitly, you can see its modified contents from your view, but other users can not see the modifications until you check in it.

Modifications here means the operations of mkdir,mkelement,rename,ln and exclude the operations that only update the contents in the source files

Reserved and Unreserved Checkouts

2008-12-09T16:41:00.001+08:00

Reserved and Unreserved Checkouts

In some version control systems, only one user at a time can reserve the right to create a new version on a branch or in a stream. In other systems, many users can compete to create the same new version.Both models are supported by allowing tow kinds of checkouts: reserved and unreserved.

The view with a reserved checkout has the exclusive right to check in a new version for a branch or stream. Many views can have unreserved checkouts. A unreserved checkout does not guarantee the right to create the successor version. If several views have unreserved checkouts, the first view to check in the element on a branch or stream creates the successor; developers who arew working in other views must merge the check-in changes into their own work before they can check in.

For example, one file in view A is checked out with Reserved option. The file is checked out in view B with Unreserved option too ( only can be checked out with Unreserved option since it has been Reserved by view A). That means the file in view B can not be checked in unless the files in View A has been checked-in.

In above example, if the file is checked out in View A and B with Unreserved option, it can be checked in at any time without considering the check-in sequence. The first check-in makes the successor version and later one will create antoher version after merge operation.

The status of a checkout can be changed from reserved to unreserved or from unreserved to reserved. Users can not change an unresearved checkout to a reserved checkout if the version is checked out as reserved in another view. Here are the 2 ways to do this

Using cleartool command

Cleartool reserve element-name

Cleartool unreserved element-name

- Using the GUI
In Rational ClearCase Explorer, select the checked-out version and click either Tools->Reserve or Tools->Unreserve

In Windows Explorer, right-click a checked-out version. Then click ClearCase->Properties of Version.