This blog was discontinued. pls visit the new site.

https://www.ibm.com/developerworks/mydeveloperworks/blogs/dbtrue/?lang=en

or

http://www.dbtrue.com/blog/

Please visit my new blog and DB2FAQ

www.yhcss.com is my new site and you can find a DB2 FAQ I'm running. The Faq is just at the beginning and your input is highly appreciated.

the DB2FAQ locate here: db2faq.yhcss.com

Programmers Only: Optimistic Locking

转一篇关于locking的文章，学习ing।

LOCKING BASICS

For the purposes of this article, let us assume that we have chosen LOCKSIZE PAGE (or ANY) for the table spaces used in the examples. In this article, whenever I use the word PAGE you may substitute ROW if you like.

The DB2 for z/OS lock manager (also known as the IRLM) is designed to monitor access to data stored in DB2 tables. The IRLM is consulted every time an application requests a lock. The IRLM then decides whether or not the requested lock can be obtained concurrently with existing locks held by other users or if the requested lock must wait in a queue and be handled serially. If the latter situation occurs, then the request will either be granted after the other incompatible locks are released or it won't be granted at all and the requester will timeout while waiting. In other words, the IRLM decides and enforces the logic that is needed — concurrent versus serialized access logic (see my prior columns on locking, listed in Resources).

The IRLM needs no special directions for the length of time to hold exclusive (X) page locks. They're held from the time they're acquired until they're released at COMMIT. Period. No more discussion. The COMMIT may be explicitly coded or may be implicit (such as COMMITs after ROLLBACKs or at program termination). Once you've acquired a page X-lock you no longer need to worry about someone else updating or deleting your data during your unit of recovery. What the application programmer must worry about and understand is the concept of duration for readers. But not just any readers. In this article, we're talking about a reader who intends to update the data he has read. Our reader is worried about other users updating his data between his read and his update. Our reader recognizes that there's a vulnerable duration between the initial read and the eventual update. If someone else is able to update the data during this unprotected duration, then what will happen when our reader does his update? Our reader's update will overlay the update that occurred during the duration. He will never ever be rewarded for overlaying
someone else's update. This duration between the read and the following update, this potential data integrity exposure, is entirely under the control of the application
programmer.

PESSIMISTIC LOCKING TECHNIQUES

There are many ways of protecting the data between the read and the subsequent update. If we are pessimists, we will assume that there are users out there lying in wait for our data, exactly our data, our page, our row. Therefore, we must protect the data we're reading at any cost. But not all pessimistic locking has the same impact on concurrency and performance. The techniques vary from extreme to potentially tolerable.

Probably the most pessimistic technique would be to BIND the program with ISOLATION RR. With ISOLATION RR, the application attempts to acquire an S-lock on every page read (for every single SQL statement on every table the application uses) whether or not a row qualified on that page. And it holds and accumulates the S-locks until COMMIT. This isn't a very realistic solution for multiple reasons. First, concurrency and performance would suffer dreadfully and, second, online applications would still be in trouble unless they used CICS conversational techniques or the equivalent. Likewise, binding with ISOLATION RS, which "only" acquires locks on pages in which rows qualify (accumulating those locks until COMMIT), is seldom a realistic solution.

Another pessimistic technique would be to have a LOCK TABLE IN EXCLUSIVE MODE statement embedded in the program for those tables being read and subsequently updated. Just kick everyone else out of the tables. While this technique may work for a few applications, it isn't a very realistic solution for day-to-day batch activity and certainly not for online applications.

A third pessimistic technique would be to use the FOR UPDATE OF clause in a DECLARE CURSOR statement. Surprised? The FOR UPDATE OF clause is pessimistic because it assumes that someone will update the data if it isn't "tied up." The application programmer is so sure that someone will update our reader's data that he's willing to acquire not just one lock but two: a U-lock that will be held while our reader is evaluating the data and then an X-lock when he actually does the update. The conversion of the U- to an X-lock is done by means of an upgrade process. Our reader will upgrade the lock on every page that he reads for update and pay for two lock acquisitions just because the application programmer is so pessimistic. And, by the way, this technique works in batch but not online.

A fourth pessimistic technique would be to BIND the application with ISOLATION CS and CURRENTDATA YES. This technique works to protect our reader some — but not all — of the time. Hmmmm. Now there's a scary technique upon which to base the integrity of corporate data: pessimism accompanied by high CPU overhead, concurrency issues, and no dependability. ISOLATION CS with CURRENTDATA YES ensures that our reader will only be allowed to read clean, committed data. Whenever a qualified row is found on a page, an S-page lock will be acquired on the page. The S-locks will not be accumulated; they will be released when the CURSOR moves off the page.

This technique seems much more benign than the others. However, it doesn't work at all for online pseudo-conversational applications. And for batch applications? It depends on the access path that was chosen. If the access path is one WHERE the qualified row is found at FETCH, then the S-lock will be held while the row is returned to the application. If the access path is one WHERE the qualified row is found at OPEN, then the S-lock will be acquired and released at OPEN. It will not be held at FETCH when the row is returned to the application. And since it won't be held at FETCH, it won't be held during the vulnerable duration. One thing we don't need is access-path-dependent data integrity.

One horrid side effect of this technique is that the BIND parameter applies to all read-only SQL, not just the reads that you intend to update. Our reader may actually timeout trying to acquire an S-lock on a page even though his desired row is clean and all he wants to do is read it.

Before we move on to the optimistic locking techniques, I want to point out that none of these pessimistic locking techniques (except for locking everyone out of the data completely) will protect our reader/updater from timeouts. Just because you have an S- or a U-lock on the page while you're in your application deciding to update or not doesn't mean that someone else won't have another S-lock at the same time. So, when you decide to update and request your X-lock, there's absolutely nothing to make that other user with his S-lock move out of the way. And you wait ever so patiently for your X-lock. And timeout.

OPTIMISTIC LOCKING TECHNIQUES

The concept behind optimistic locking assumes that most, if not all of the time, no one out there is interested in your page, in your about-to-be-updated data. It does not assume that there will never be a stranger lurking out there waiting to take advantage of your optimism. It doesn't mean that you're uninterested in the integrity of your data. It doesn't assume you're willing to overlay someone else's update. It just means that you are realistic about the fact that it's highly unlikely that another user will want to update exactly your row on your page at the same time you do. If you're optimistic, there's no need to kick everyone else out of the data. And there's
no need to acquire and accumulate locks on every page whether a row qualifies on that page or not. There's no need to acquire U-locks on every page and then pay for the upgrade to an X-lock (two locks on every page). And there's no need to make rules that apply to all of your read-only SQL whether you intend to update that data or not.

MINIMAL OPTIMISM

The first optimistic locking technique has been employed in DB2 applications since DB2 began. I first saw the technique in an online application. The programmer realized that locks, no matter what kind or how acquired, weren't held across screen displays. While the user was staring at the data on a screen, any other user could be updating that data. After a user changed the data and hit the "OK — do the update" key, a pessimistic programmer would open a CURSOR declared with the FOR UPDATE OF clause, reread the data, and then update the data WHERE CURRENT OF CURSOR. Our optimistic programmer wouldn't pay for the overhead of rereading the data and the overhead of the U-lock followed by the X-lock. Our optimistic programmer would just code the update — but not foolishly so. The UPDATE would contain a substantial WHERE clause to ensure that the data hadn't changed between the initial read and the update

(Listing 1 shows an example).

This rich WHERE clause syntax ensures that our user's data hasn't changed between the time he read the data and then updated the data, all without the overhead of the reread and without the overhead of upgrading a lock. In the second optimistic locking technique, the programmer maintains and checks a counter or an update timestamp in the updating SQL to confirm that the data hasn't changed during the vulnerable duration. In order to use this technique in V8, the table design must include either a counter or a timestamp that's updated by every update statement. Because optimistic locking techniques are so important for performance and
concurrency, tables created under DB2 9 for z/OS contain an automatic update timestamp.

Although these two optimistic techniques were initially used for online applications, they can be used in batch applications in which pessimistic techniques cause too darned much overhead. The combination of using either of these techniques along with binding programs with ISOLATION CS and CURRENTDATA NO ensures that our reader will only be allowed to view clean, committed data, while avoiding locks in all but very rare situations. Reduced CPU overhead and rare contention. Nirvana. With extreme optimism, tempered by "I'm optimistic but I'm not stupid" WHERE clause techniques, the programmer can now avoid almost all read locks.

MORE TO COME

Now that you understand the concept of optimistic locking, whether implemented by a rich WHERE clause or by using the update timestamp or counter technique, we can move on to more complex scenarios. In my next column, I'll discuss three related issues: built-in optimistic locking (part of V7's static scroll cursors), multirow reads followed by set updates WHERE CURRENT OF CURSOR (V8), and the new built-in timestamp (V9).

Bonnie Baker is a consultant and corporate trainer specializing in application performance issues on the DB2 for z/OS platform. An IBM DB2 Gold Consultant, a five-
time winner of the IDUG Best Speaker award, and a member of the IDUG Speakers' Hall of Fame, she is best known for her series of seminars entitled "Things I Wish They'd Told Me 8 Years Ago" and for writing this column. You can reach her through Bonnie Baker Corp. at 1-813-837-3393 or bkbaker@bonniebaker.com.

Listing 1.
A WHERE clause that ensures data hasn't changed between an initial read and an update.
UPDATE tname
SET UPDCOL1 = :HVUPDCOL1,
UPDCOL2 = :HVUPDCOL2
WHERE UPDCOL1 = :ORIGINALVALUECOL1
UPDCOL2 = :ORIGINALVALUECOL2
NO_UPDCOL3 = :ORIGINALVALUECOL3, etc.... listing all columns in the table


Programmers Only: Optimistic
Locking, Part 2
When it comes to DB2 for z/OS locks, a pessimistic approach rarely pays.
By Bonnie Baker

In my last column I explained the concept of optimistic locking in DB2 for z/OS. I explained how optimistic locking techniques can be used in application programs to reduce locking overhead (including potential timeouts) and improve performance. I explained that SQL functions — such as for update of and update where current of
cursor) — and BIND parameters — such as ISOLATION RR/RS, FOR UPDATE OF, or CURRENTDATA(YES) — are very pessimistic and will most likely consume many more DB2 resources than necessary.

You might recall that I told you that optimistic locking techniques have been around since DB2 was a V1R1 baby; however, until now, the techniques have always been enforced by developers using application program logic and special WHERE clause predicates. Finally, I explained that a program that uses optimistic techniques is far less likely to be a victim of data integrity exposures than one that foolishly relies on pessimistic techniques such as CURRENTDATA(YES) and assumes that DB2 is always holding necessary locks.

Now that we understand the optimistic locking concept, whether implemented by a rich WHERE clause that reapplies qualifying predicates or by using the UPDATE TIMESTAMP or update counter technique, we can move on to more complex scenarios. In this column, I'll discuss four related issues: V4's row-level locking, V7's static scroll cursor with its "built-in" optimistic locking, V8's dynamic scroll cursor and row-positioned cursor, and DB2 V9's new data type that folks are calling a "built-in timestamp."

ROW-LEVEL LOCKING

Now why would a discussion about row-level locking be in this particular column? Well, many people who are using pessimistic locking techniques encounter more than their endurable quota of timeouts and deadlocks. To solve the problem, they could try to do less locking by using optimistic locking techniques, or they could blame the problem on page-level locking and switch to row-level locking in an attempt to solve the timeout problems. But by doing so, their pessimism just becomes more granular. Locks are acquired on rows instead of pages. In a worst case scenario, if someone reads six rows FOR UPDATE OF on a single page, that person will acquire six U-locks instead of one. And, as the rows are updated WHERE CURRENT OF CURSOR, that person will make six trips (instead of one) to the lock manager to upgrade the locks from U to X.

Locking problems can often be solved by other less onerous means. Sometimes creating indexes to allow better access paths that touch fewer pages will solve a locking problem. If you filter out the rows you want from the rows you don't want by using a great index with matching and screening predicates, then you won't read as many pages. And if you don't read a page, you won't ask for a lock on that page. Nor will you be told that you can't read it because someone else has an incompatible lock on the page. But you don't necessarily have to create more indexes. Often, switching from pessimistic locking techniques to optimistic locking techniques will solve any locking problems you have.

V7'S STATIC SCROLL CURSOR

There are many ways of protecting data (optimistically, of course) between a read and a subsequent update. One is by declaring the cursor as a static scroll cursor. But not just any static scroll cursor. The cursor must be a SENSITIVE static scroll cursor — sensitive to change by others as well as by our own program. With these cursors, the DB2 developers have given us built-in optimistic locking. At OPEN CURSOR a result set of all the qualified rows is materialized. Remember, we have told DB2 that the cursor is sensitive, with each update or delete to the base table, both by ourselves (DECLARE SENSITIVE) and by others (FETCH SENSITIVE). DB2 will make sure that our result set stays in sync with the real table. In order to stay in sync, each FETCH from the static CURSOR causes a simultaneous read to the real table to see if anyone else has changed or deleted the underlying row. We get the most current COMMIT-ted image of our row
regardless of what's in the result set. If we then look at the data and decide to either UPDATE WHERE CURRENT OF CURSOR or DELETE WHERE CURRENT OF CURSOR, DB2 has to read the base table to make the change. Because the base table has to be read anyway, DB2 can simultaneously and automatically check to see any of the values on the row have changed between the time we fetched our in-sync image and the time we decide to update the row. If the values have changed, then DB2 gracefully lets us know. DB2 is essentially using the rich WHERE clause technique that I mentioned in Part 1 of this article (available online at DB2mag.com). And we don't have to code the WHERE clause ourselves. DB2 is doing it for us. If the row hasn't changed, the update is performed and our change is perpetuated to the result set. If the row has been changed by someone else, the UPDATE isn't successful and a message is returned to the program.

One side benefit of this technique is that for the first time we can now use the UPDATE/DELETE WHERE CURRENT OF CURSOR technique on a cursor that has an ORDER BY clause. Before the advent of static scroll cursors, we couldn't use FOR UPDATE OF and UPDATE WHERE CURRENT OF CURSOR if we had sort syntax (for example, ORDER BY) in our CURSOR. Coding both an ORDER BY clause and a FOR UPDATE OF clause in the CURSOR declaration netted a slap on the coding wrist that this cursor was an "unambiguously read-only cursor."

Well, we still can't use ORDER BY and FOR UPDATE OF in the same cursor declaration, but we can use ORDER BY in the CURSOR declaration and follow the FETCH with an UPDATE WHERE CURRENT OF CURSOR. We can do so without fear — as long as the CURSOR is a SENSITIVE STATIC SCROLL CURSOR with built-in optimistic locking.

V8'S DYNAMIC SCROLL CURSORS, ROW-POSITIONED CURSORS,
AND LOCKING

In V8, we're allowed to DECLARE DYNAMIC SCROLL CURSORs. By definition, these cursors are always reading rows from the base table — never a sortout file, never a result set. If the cursor has an ORDER BY, there must be an index available for DB2 to use in order to avoid the data sort. Otherwise, the BIND will fail. In other words, we know that, sort syntax or not, DB2 will always be reading the base table.

So, with these cursors, even with sort syntax we can UPDATE WHERE CURRENT OF CURSOR. We can't use FOR UPDATE OF if we have an ORDER BY, but we can update anyway. The problem is that, unlike with static scroll cursors, there is no built-in optimistic locking. So, how do we ensure that there's no data integrity exposure? The optimistic locking techniques that we've talked about aren't available.

The problem is exacerbated if we use the new "row-positioned" option that allows us to FETCH more than one row, let's say 100 rows, with one connect to DB2. If we then UPDATE WHERE CURRENT OF CURSOR, 100 rows will be updated and we won't be able to check 100 timestamps. Nor will we have the ability to apply 100 rich WHERE clause comparisons.

I've come up with some approaches that work, but none that I really like. First, remember that we know we're accessing the base table; this means that BINDing with
CURRENTDATA(YES) will cause DB2 to hold locks on the row or rows between the FETCH and the UPDATE WHERE CURRENT OF CURSOR.

What I especially don't like about this approach is that CURRENTDATA is a BIND parameter and applies to all the read-only SQL in the program, not just the CURSOR in question. To make it apply to just the CURSOR in question, we'd have to isolate the cursor in its own program. And besides, CURRENTDATA(YES) was in the list of pessimistic techniques I mentioned in the last column.

A second, SQL-specific technique is to use the WITH clause on our cursor declaration and use WITH RS for our isolation. WITH RS will cause DB2 to acquire an S-lock on each page that has a qualified row on it and accumulate those locks (very important for our row-positioned cursor) until the locks are upgraded to X-locks by the UPDATE WHERE CURRENT OF CURSOR. At COMMIT all the X-locks and any outstanding S-locks will be released. This approach is also a pessimistic technique that causes upgrade overhead (see Part 1), but at least it's SQL specific. And because of that I like it better than CURRENTDATA(YES). If anyone has a better, more optimistic technique to handle data integrity exposures from concurrent updaters, please share the technique with me so that I can share it with others.
V9'S BUILT-IN TIMESTAMP

In Part 1, we discussed adding an update timestamp column to our table so that we could check it for change each time a row was updated. However, the burden of
maintaining the timestamp fell to the programmer. If someone slipped into SPUFI and updated the row, the timestamp might not get changed. The rules may not be obeyed. In V9, we have new SQL syntax for an automatically updated timestamp. You can now create/alter tables and include a ROW CHANGE TIMESTAMP. The name of the column can be anything you like (MY_UPD_TIMESTAMP) but the definition of the column includes new parameters: GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP.

Now the program code can use the optimistic UPDATE TIMESTAMP technique (see Part 1) without worrying that other applications (such as SPUFI or QMF) might not be obeying the rules.

STICK WITH IT, OPTIMISTICALLY

If I could make one thing stick in every programmer's brain, I would say that figuring out when a lock is held and when one isn't, when there is data integrity exposure and when there isn't, is a complex, confusing, and painful process. Using a single approach whenever possible has many advantages. Whenever that single technique is unusable, choose the most optimistic of the available options.

Bonnie Baker is a consultant and corporate trainer specializing in applications performance issues on the DB2 for z/OS platform. She is an IBM DB2 Gold Consultant, a five-time winner of the IDUG Best Speaker award, and a member of the IDUG Speakers' Hall of Fame. She is best known for her series of seminars entitled "Things I Wish They'd Told Me 8 Years Ago" and writing the "Programmers Only" column. She can be reached through Bonnie Baker Corporation at 1-813-837-3393 or bkbaker@bonniebaker.com.

IDUG User View: Locking Up DB2 Performance
A new locking feature in DB2 9 for z/OS improves the performance outlook.
By David Beulke

Supporting multiple systems and dealing with application developers and managers who often don't have a clue makes the DBA's job a challenge. Fortunately, DB2 9 for z/OS offers a new optimistic locking feature that can improve system performance-and perhaps the DBA's (and application developer's) mood.

Database locking is a necessary overhead and a core component of all DBMSs. Locking maintains integrity by preventing multiple transactions from changing the same data at the same time. But taking and maintaining database locks can be expensive, especially for complex systems, applications, or transactions.
Optimistic locking now uses new features defined within DB2 tables to reduce deadlocks and overall locking overhead, improving system and application performance. (Read Programmers Only for more on optimistic locking.)

To use the new feature for optimistic locking, you need to define a new ROW CHANGE TIMESTAMP column in a DB2 table with new parameters (GENERATED ALWAYS, FOR EACH ROW ON UPDATE, AS ROW CHANGE TIMESTAMP) as follows:

CREATE TABLE BEULKE.PRODUCT_TBL (
PROD_NBR INTEGER NOT NULL,
PROD_INVENTORY INTEGER NOT NULL,
PROD_LAST_UPD NOT NULL
GENERATED ALWAYS
FOR EACH ROW ON UPDATE
AS ROW CHANGE
TIMESTAMP);

These parameters tell DB2 to always populate and pay special attention to thetimestamp and table. The last update timestamp has been embedded in some

applications for years; now IBM has endorsed and improved on this technique.

These new features enable DB2 to retrieve rows from a specific time period and understand when they were last modified. DB2 not only notes the row timestamp
information but also the record ID (RID) and change token information. Noting the row attributes allows applications and users to query the database via timestamp to get a specific row or group of rows based on WHERE timestamp clause criteria.

The new column feature reduces locking overhead by allowing the majority of applications to be rebound and reduces locking profiles from Repeatable Read (RR),
Read Stability (RS), or Cursor Stability (CS) to Uncommitted Read (UR). Uncommitted Read avoids database locks; the application can maintain database transaction integrity by using the new timestamp column within the application UPDATE SQL statements. The new timestamp column provides both the timestamp and the record ID (RID) of the row that DB2 can use to verify that no other application has changed the data in question.

Another DB2 9 SQL phrase, SKIP LOCKED DATA, also helps avoid locks by not retrieving or affecting data rows with incompatible locks. You can use the phrase within SELECT, UPDATE, and DELETE SQL statements to avoid deadlocks.

Use both the isolation level UR and the SKIP LOCKED DATA phrase cautiously. Although the techniques can dramatically reduce locking and improve performance, they require that you thoroughly know your applications. Research each application in detail before using this performance boost, and read the DB2 manuals for full details. Because these techniques can significantly reduce deadlocks and locking overhead, especially in a data sharing environment, they're worth the research and implementation time.

These techniques and other performance topics are covered at International DB2 Users Group conferences around the world (www.idug.org).
David Beulke [davebeulke@cs.com], a past president of IDUG, is a DB2 consultant,
author, and lecturer who specializes in database performance, data warehouses, and
Internet applications.

New Start

一年了。

前几天有个朋友说看你的blog觉得你日子过的蛮happy的。苦笑。

心情好的时候才写blog，心情不好郁闷了确是很不习惯上来晒的。

anyway,重新做人。

希望这里还可以是朋友们交流DB2 UDB的一块自留地，谢谢。

我又回来了。

new H1b filing rule out

Wish good luck this year!

http://www.mitbbs.com/ym_article/lianglaw/31080710.हत्म्ल
(梁勇律师事务所，lianglaw.com专稿)移民局刚刚公布了有关H-1B Cap 申请相关规定
及Q&A，相关规定的内容包括以下几点：

1。如果第一天H-1B 申请就额满的话，原本只是将隔天送件的申请件一起并入“抽签”
的行列，现在移民局改为5个工作天内送达的申请通通并入一起可加入“抽签”的申请
案。(这样竞争就更激烈了，不论是在申请后5个工作天内的那一天额满，都是一并加入
抽签的行列。)

2。禁止同一个雇主为同一个员工提出多个申请，即使是工作内容不相同也不行。唯一
可以例外的是如果是“关系企业”(像是母子公司) 的话，是可以各自为同一个员工申
请一个H-1B 的申请。

3。如果被移民局发现出现同一个雇主为同一个员工提出多个申请的话，将会拒绝或撤
销H-1B的申请，所付出的申请费也不会退回。(这家公司为这个员工所申请的所有H-1B
都会被拒绝或撤销，但是为其他员工的申请如果没有违返规定则不影响。)

4。移民局将变更抽签的顺序，若是20,000个美国硕士以上名额的申请在开放后5天内额
满的话，移民局会将20,000个美国硕士以上名额的申请人优先抽签。若是这些拥有美国
硕士以上学位者没有被抽中的话，会将再放入65,000个名额一起抽签，等于美国硕士以
上学位申请人在5天内送件者有两次抽签的机会。

5。移民局同时也表示，他们会继续接受学校发出证明申请人完成所有课程、论文及答
辩，只差领取毕业证书的证明信。但是如果你并没有符合完成其学位的证明却声称已经
取得学位的话，是不会退会申请费的。

6。目前移民局将继续接受H-1B快速审理的申请，$1000 快速审理的开始计算时间是以
抽签决定后开始计算。

7。由于移民局会将收到的所有H-1B Cap 案件送交给其他移民处理中心做电脑输入的动
作，因此，申请人在收到收据时可能与寄件的地址不符，这一点请申请人不要担心。

所有要求以移民局原件为主，移民局原文可在本网 http://www.lianglaw.com/H1.htm
取得，相关消息包括：
Full Text Advance Copy of the H-1B Cap Filing Rule(03/19/2008)
USCIS FAQs: Interim Rule on H-1B Visas(03/19/2008)
USCIS Fact Sheet: Changes to the FY2009 H-1B Program(03/19/2008)
USCIS Announces Interim Rule on H-1B Visas(03/19/2008)

***谢谢您阅读本文，如需转载，请注明出处，其他相关新闻请查看本所网址:http://www.lianglaw.com

转 心不在焉时干的最牛事

发信人: 恶少 (觉醒), 信区: Joke
标 题: 转 心不在焉时干的最牛事
发信站: 两全其美网 (Tue Feb 5 21:59:49 2008), 本站(lqqm.net)

1、昨天游完泳，直接把后备箱打开，钥匙丢进去，然后关上后备箱……　　穿着三点式在野外等了一个半小时。

　　2、有一次煮饭,淘完米直接把米倒进没放内锅的电饭煲中...后来拿吹来吹啊吹....

　　3、就发生在中午，丢人啊~　中午打算叫楼下面馆送碗刀削面来吃吃~ 脑袋也不知道想什么~ 电话通后，我直接说：“您好~麻烦送一碗刀削面”，后面就听到我妈妈的声音出现：“女儿！你中午想吃刀削面啊！”　我妈刚开始还觉得有点莫名其妙，回过神 来就大笑~~ 我当时也愣了下~ 脸都红了，尴尬啊~~

　　4、第一天上班 有人电话找经理(女的) 把电话给经理顺便说了一声 妈
有人找你接电话

　　5、戴着眼镜（框式的）洗脸。镜片上一片迷茫………………

　　6、盘算着给老妈打电话,　领导突然进来,于是对他说:妈,材料找到了，给你!!!!!!!!

　　7、把钱捏在手里 ,然后揉成一团,抓在手里,觉得很不舒服 ,扔了

　　8、去好朋友家，聊天中，她爸回来，张嘴就叫“阿姨”，尴尬中，她妈又出现，张嘴又叫“叔叔”……然后无限怀疑自己的智商

　　9、我有两个：一次好朋友结婚，头天去她家时她给我拍了张照片，我当时没看她相机里的照片，回头就忘记这回事；

第二天喝喜酒的时候她拿出相机，我说看看你都拍了些什么照片，翻着照片我就发现有张照片里的人特别象我，脑子里就没反应过来，还傻呼呼的喊人家看有个女孩子张得很象我，等反应过来，觉得自己特傻，怎么会不认得自己的照片；

第二个比较惨，骑车快速经过一辆面包车，车门刚好打开～～我结实的撞到车门上，惨～

　　10、最丢脸的一次,洗脚的时候也不知道在想啥,本来要脱袜子的,差点把裤子脱下.....

　　11、从讲台往座位走，一同学的脚伸到过道上，本来想说“请让下”，结果脱口而出“谢谢” 　

　　12、有次上photoshop课，我一边给男朋友发短信一边很勇敢的大声对老师喊道:"老公!我的电脑没连上!"　闹怏怏的教室瞬间安静了　5秒后全体暴笑　老师是个50多岁的小老头　推着眼镜盯盯瞅我　这个庐山瀑布汗呀

　　13、给女友家打电话，她爸爸接的，说：“喂？” 我硬是顶着她爸的声音回答说：“阿姨好，请问***在吗？”　她爸能同意我们在一起真是奇迹！

　　14、早上扔垃圾,,拿着挺顺手,一路上了公车,活活开了一小时,到了公司,,下车才发现垃圾袋还在手上,我带着绕了大半个城市,结果扔到写字楼垃圾箱.

　　15、某日深夜狂欢结束后回家
一路上不知道在想什么进了电梯以后就等啊等啊 等好久也没到我家那层楼 心里开始狂汗 难道是电梯出问题了? 这会也没人在啊喊救命都没人甩我 同时 鬼电影里面的画面就一张一张的闪过 顿时觉得浑身寒毛竖立　正要打电话给BF ,叫他来救我突然发现自己没按楼层电梯还一直在一楼没动.....

　　16、拿学校饭卡给工行的工作人员取款,别人看了一眼,利索的丢了出来,我又塞回去大大声的说我取钱啊,他有利索的丢出来懒散的说卡错了,我讪讪的取回来，又从钱包拿了一张建行的卡递给他……

　　17、很小的时候，家里要烧煤的，妈妈煮好的米饭放在厨房，我拿个小铲子弄了一铲子的煤，将盛着米饭的锅盖打开，将煤一下子都倒了进去。。。

　　18、上大学时和一群朋友一起吃饭，想着下午的考试，心不在焉，吃完了照例从包里拿纸巾出来擦嘴，是无意识的擦了好久，突然发现朋友们都不说 话了，看着我，这才发现自己拿着擦嘴的是一个卫生巾！朋友们可是有男有女啊！我当时真不想活了！是护舒宝的丝薄日用！不可理解的是，我还把外面粉色的包装 拆了！

　　19、我有一次早晨起吃早点（饼和稀饭），边看新闻边吃。当时正好播的是我们那边的一场事故之类的。我看得特别认真，顺手就把遥控器拿起来啃，还把遥控器套子啃下来一块，狂嚼了半天，吐出来一看差点没郁闷死。我一直想不明白我是怎么把它啃下来的


　　20、还有一次是旅游的时候，和女朋友一起去的。当时景区人特多。我顺手就把女友的手拉起来说；“老婆，拉紧我的。”然后，就感觉女友的手直 往下松，我以为她不好意思，便往紧拽。后来她不走了，我回过头一看。才发现是一个男的。然后旁边还有一个女的很怪异得看着我。我吓了一身的汗，干笑了几 声，红着脸就溜了，郁闷死了。`````

　　21、跑完步气喘吁吁,边喝水边准备离开,结果没按好结束键跑步机停不下来,我整个人就势滑了出去,杯子里的水也洒了一地被教练当作反面典型对旁边的人说,千万不要像她一样没停机就下来.好丢脸啊


　　22、还有一次在三楼进了电梯，然后一直按3键，还奇怪为什么按不亮。　另外一次是一个同事的。那天同事一边用遥控器开空调，一边让我帮她倒杯水，结合起　来使我看到的场景非常诡异：只见她拿遥控器对着我一按，嘴里说：请你帮我倒杯水！
　我发誓绝不是角度误差，空调在相反的方向。

　　23、去买衣服，到试衣间试衣服，一进去就脱了上衣，脱了bra，然后穿衣服，穿上以后觉得怪怪的，看到旁边的bra，才反映过来～～汗～

　　24、一次去买热干面,前面有一对情侣正在买,老板问他们要不要放香菜,男的说不要，女的说怎么不要。我就在旁边想"香菜,为什么男的要香 菜,女的不要香菜……"　想的正出神呢，老板问我，吃什么？　我毫不犹豫的大声答到：“香菜！！！”　老板＋旁边的那对情侣不解的看着我！

　　25、家里新买的微波炉,很兴奋地用它来做鱼.弄好时间,调好火侯,十五分钟后激动地打开微波炉,晕,什么都没有.鱼还在桌上.郁闷地再次操作,时间到,没等打开微波炉就发现鱼仍然在桌上.于是,决定一个星期都不再吃鱼.

　　26、有一次，去买水果刀，拿着刀看了又看，然后叫那个买刀的找个东西让我试一下，刀快不快，结果俺特短路的用刀割自己的大指头，血喷呀 ``````````````我还高兴的说“嗯，快”惊得那个买刀的怎么都不收钱，非要送我此刀``````　一转身，那个痛呀``````钻心

　　27、小学几年级忘了，有次上自习不认真，就拿剪刀把圆珠笔芯最前面的头给剪了，把笔芯里面的油吹出来玩，然后吹着吹着就把油给吸嘴里去了

Evernote 2.2

Ordered the license for Evernote 2।2 at a price of 19.99$ with 3$ 3 years download warranty. It's the first software I bought ever, except the Winxp coming with laptops and some versions of Linux.

Evernote is a great product. Like Microsoft Onenote but much cheaper(I notice that from lenovo website you can buy a copy of Onenote at 20$ if you buy a tablet, wow, that's great! But my x60 tablet is coming from Lenovo outlet store and I just cannot customize that. What a pity!). Acutually its free edition is powerful enough for normal laptop users. But you'll feel the strong temptation when you're using a Tablet. Handwriting is very important feature. Say, I ever considered that I can handwrite with sticknote and use some snipping tools to copy the handwriting to notes, but it's too fussy. Then, what could you do when you want to make some change to the handwritings? There're some other advanced features like handwriting recoganization is very useful -- but not the decided point.

Richard Hammond presents Bloody Omaha

http://www.youtube.com/watch?v=WRS9cpOMYv0

bloody work done!

文革与希特勒的种族屠杀之胡思乱想

最近看《金婚》，有关于文革的一些镜头。lp说她爸妈那时候觉得就应该那样的，觉得那样就对。而我好像接触到的人对那段历史多是大摇其头的。也许是，这就是只有深受其害才能知其利害对错，而很多根正苗红的无产阶级们是不是只是play而已。反正痛的不是自己。人性中卑劣的一方面被名正言顺的发扬光大了。

联想到希特勒的种族屠杀。犹太人似乎是一个一直受迫害的民族，嗯，似乎偶是一直这样受教育的。近代尤以希特勒为甚。当年学习修正版历史的时候被教育说因为犹太人如何富裕如何精明商业而与普通民众有间隙，民众被挑拨对犹太人的仇恨，所以如何又如何的。这个说法不太经得起推敲吧，总感觉到这后面有太多的背景故事是我们不熟悉的，不然，以犹太人的素质不应该受到千年的迫害而是应该得到充分的敬重吧。

今天看到这样一个帖子，应该是交代了一些真实的背景，贴到这里给自己当个索引，以后想起来可以参考：）

（那个文章正文贴到回复中了...）

Dialogue Concerning the Two Chief World Systems

LINK

Today Galileo is a famous and romantic name। We have all been taught the story of his heroic fight in the name of science against the intractable ignorance of the tyrannical Catholic church. The reality is not so starkly drawn, but no less interesting for that; Galileo's own arrogance created many enemies, and Rome's anxiety over its authority in the schismatic era of the Protestant reformation made their collision inevitable.

......

网友爆内部消息：08年春晚赵本山小品《卖股》

http://www.mitbbs.com/news_wenzhang/Headline/30259744.हत्म्ल

赵本山： 现如今，执照越来越难考了，关系越来越难搞了,媳妇越来越难找了，股票越来越难炒了。这不，刚48块买的股票就被套牢了，这心急火燎的，今天我去证券市场看能否把这只股票高价位卖出去。哎呀，到了。 Mitbbs.com

范　伟： 哎呀，这不是大忽悠吗？ Mitbbs.com

赵本山： 荣幸之至。哎呀 ，小样儿，身上穿着名牌西服，手里提着笔记本电脑。怎么地，抢银行发财了？ Mitbbs.com

范　伟： 怎么能这么说话呢？我是跟着人家炒股炒发的，是股票这位天使娘娘改变了我苍白无力的命运。你这是上这儿卖拐还是卖车来了？ Mitbbs.com
jiaoyou8.com

赵本山： 改行了，现在的好心人赚不了钱，我也炒股呢。 Mitbbs.com

范　伟： 看你一脸愁容，赔钱了吧？你是散户吧？ Mitbbs.com

赵本山： 啊？ Mitbbs.com

范 伟： 涨了笑赔了哭，不是庄家是散户。 Mitbbs.com

赵本山： 你啥眼神，没看出我的真实身份吗？ Mitbbs.com

范　伟： 什么身份？ Mitbbs.com

赵本山： 不瞒你说，我现在是忽悠集团的董事长，我公司的股票“中国忽悠”准备进行网下申购，我特地亲自到一线市场考察考察。 Mitbbs.com

范　伟： 忽悠，接着忽悠。 Mitbbs.com

赵本山： 信不信由你。听说过平民股神赵百万没有？ Mitbbs.com

范　伟： 那当然了，怎么? Mitbbs.com

赵本山： 鄙人。 Mitbbs.com

范　伟： 啥？你？！ Mitbbs.com

赵本山： 对头。你不信？那好，你今天想买哪只股票？我能知道这只股票是涨是跌？你信不？ Mitbbs.com

范　伟： 我不信。我今天买中石油，肯定赔不了。 Mitbbs.com

赵本山： 我的妈呀，完了，你指定有病。 Mitbbs.com

范　伟： 我没病啊。你看我腿也好了，脑袋也小了，末梢神经也正常了，聪明的智商也占领了高地了。 Mitbbs.com

赵本山： 没病你买两股，没病买两股。 Mitbbs.com

范　伟： 买就买。我今天就买1000股中石油给你瞧瞧。 Mitbbs.com

赵本山： 看，病得不轻啊。瞧，瞧，中石油跌了吧？ Mitbbs.com

范　伟： 哎呀，大哥，它怎么说跌就跌了呢？ Mitbbs.com

赵本山： 你信我了吗？ Mitbbs.com

范　伟： 我我我~~~我信，大哥，你说我该怎么办呢？ Mitbbs.com

赵本山： 别急，这么着，我先给你来个小学算术题，检查一下你的智力有问题没？ Mitbbs.com

范　伟： 那大哥你说。 Mitbbs.com

赵本山： 请听题，说你用1块买了100股中国忽悠，那么需要多少钱？ Mitbbs.com

范　伟： 这也太简单了。100元，对不对？ Mitbbs.com

赵本山：别着急，我先向你介绍一下中国忽悠这只股票，我公司总资产万亿，属于大盘蓝筹股，具有超强的成长性，垄断资源明显，年利润增长率预计为1000>以上，公司旗下有无数 个分公司，分公司里有无数成员，每天作案无数次，业绩那真是相当可观，是亚洲最赚钱的企业…… Mitbbs.com

范　伟： 大哥你别说了，赶紧提问题吧。 Mitbbs.com

赵本山： 好的，假如你用1元申购成功1000股，上市合理价位是25元，你算算你的资金变成多少了？ Mitbbs.com

范　伟： 250啊？ Mitbbs.com

赵本山： 看看，默认了吧。那是2500元。连这么简单的题都算错了，250还炒股呢？这样下去，你肯定得赔，晚年就是穷光蛋。 Mitbbs.com

范　伟： 哎呀，大哥，那怎么办呢？ Mitbbs.com

赵本山： 别着急，我自有办法。你说你放着好股不炒，偏要买那破石油呢？ Mitbbs.com

范　伟： 大哥，我糊涂啊。那你能帮我解套吗？ Mitbbs.com

赵本山： 没关系，前几年给你卖拐卖车，把你整残疾了，是我对不住你，现在我帮你是应该的。 Mitbbs.com

范　伟： 大哥，那我就买10000股中国忽悠，你看行不？ Mitbbs.com

赵本山： 那可不行，中国忽悠还有几个月才能申购，这么地，我先把我手头的股票给你分一部分，就算是哥对你的补偿。 Mitbbs.com

范 伟：行吗？Mitbbs.com

赵本山：绝对的黑马，刚刚的。我认识庄家，明天准备拉升。保赚。每股50元，买不买？ Mitbbs.com

范　伟： 我买，我买。 Mitbbs.com

（开始网上交易） Mitbbs.com

范　伟： 大哥，你看我的资金不多了，买不了你的股票，哎呀，我的手气不好。 Mitbbs.com

赵本山： 什么手提电脑？啥手提电脑？大兄弟，你要给我我跟你急昂…… Mitbbs.com

范　伟： 对对对，大哥你说得太对了，你把电脑拿去，像我这样的炒股水平，以后也就用不着电脑了。 Mitbbs.com

赵本山： 那我就把它收下了，不过哥不缺这玩意儿，哥打算把它捐给贫困地区。听哥的，完了把中石油卖了， 准备申购我的新股，明白不? Mitbbs.com

范　伟： 明白，明白。 Mitbbs.com

赵本山： 我就喜欢明白人。从今往后好好跟哥学啊，你看哥一开始什么也没有，现在有钱了，哥是股神，你怕啥呢？Mitbbs.com

范 伟： （激动地）大哥，啥也不说了，还是那句话，缘分呢！Mitbbs.com

赵本山： 没关系，中国忽悠上市的时候，我会及时通知你的。后会有期。Mitbbs.com

范 伟： 谢谢啊！Mitbbs.com

madison travel

It will my 3rd time there. Everytime with very different mode.

Life is hard and I must fight a way.

尽力而为，但求问心无愧。