Part 1: Mapping Stock Market Trend to Human Capital Issues

It is this seasonal period during the year that a large population of workers suffers from some degree of procrastination again. When I traced into the root of this potential mental disease and I strongly believe that the source of the problem lies in the fact the working environment itself is procrastinating at a seasonal basis. May be I should rephrase it as "at a cyclical basis".

If I'm able to plot the factors for this scenario, I shall get a graph similar to how our financial stock market behaves.

Bearish trend versus Bullish trend and the stagnant "Cold War" period.

A typical characteristic that determines the emergent of bearish trend (And I'm saying a huge big black bear), is the price moves down steadily that lasts for months even years, with some intermittent technical rebound. Metaphorically, we as a bunch of employees experiencing the same bearish nature when working in an environment which's not stimulating and where job responsibilities generalized to the effect of flattening your morale. We're experiencing "technical rebound" too when given slight workload relief, provided with better salary, company sponsored vacation or others which I think just to patch up your marginal spiritual break down.

Generalization is another issue, thought I'm personally not against it. The logic is simple, generalize at microscopic level can be beneficial but at a macroscopic, the direction can cause a havoc to the company reputation, human capital and to the country's GDP (Haha, Am I sounds too exaggerated now?). I can't really imagine when Intel starts to sell lingerie and cosmetics, instead of focusing in making use of silicones. WHAT? Lingerie made from silicon? Don't be silly.

What about the "Cold War" period? It is difficult for an employer to identify employees that are in such a period. From the surface, everything is normal. They worked long hour, delivering tasks as promised, seldom get sick and blah blah. Ok fine, some of them might show certain level of performance degradation but that doesn't represent the entire population. What's behind the scene is the fact that they are staying for some personal reasons which might attributed to monetary and comfort of environment. I understand that it is arguable that "monetary and comfort of environment" are the main reasons that retains people but realistically only for a short term. Soon or later the need for self actualization, career interest, spiritual enrichment and all sorts of "funny" excuses will start to emerge to overhaul your good old dream as perfect employer. This phenomenon happens all around the globe.

Visionary employers will and should do their best to create a strategic "golden crossover" for individuals in bearish trend or cold war period. The importance of this preventive measure is to reduce the likelihood that other individuals which are enjoying bullish trend being affected by their counterpart peers.

A crossover involving a security's short-term moving average (such as 15-day moving average) breaking above its long-term moving average (such as 50-day moving average) or resistance level.

To be continued.

Passed IBM DB2 Certification Exam 701

Officially I didn't hold a full time job as DBA in any of my previous employments, however this doesn't stop me from getting one or two DBA certifications, because my hunger for knowledge and piss off with some moments where intricacy of DB technical details hinder my architecting and design process.

Besides all the formal knowledge and information I acquainted, one of the most important experience is to further understand the scope, responsibility and difficulties that real DBA faced in their daily operational routines and when application development needs conflicted with the interest of maintaining corporate data policy and security auditing.

In the enterprise application paradigm, the only way a solution architect can architect a better solution is to completely understood and blend every piece of the jigsaw puzzle together into a coherent whole, in the right way.

That's my motivation. Now let me share my preparation process.

1.) Read up the IBM DB2 701 Preparation Materials from IBM

Nothing much to say here.

2.) Read up DB2® Universal Database™ v8 for Linux®, UNIX®, and Windows® Database Administration Certification Guide, by George Baklarz, Bill Wong

You can opt to skip the last part regarding Application Development, even though no harm for you to take a look into it. That part is more relevant when you were taking exam 703.

3.) Do at least one project dealing with DB2 DBMS

4.) Do your own exploration and experiments with some of the concepts in the materials like HADR, Roll Forward and etc.

5.) Get enough coffee and sleeps. Trade off between these 2 important constraints :-)


Lastly, I'd like you to know that DB2 V9 series of examination is already available and you should jump on the bandwagon of V9 if your company or projects are using it or potentially will. I sticked to V8 because that's the one bundled together with IBM DBW DWE V9.1 and I dealt with that version of DB2 the most.

P/S: I got a 100% score in this exam. Cheers. I finally revenged on my 98% score in exam 700. :EVIL:

DB2 Infinite Active Log Space

In DB2, when a database is created, 3 log files are allocated. They are known as primary log files. In Linux/Unix environment, they will be 1000 * 4K pages for each log file by default, whereas in Windows it is 250 * 4k pages.

By default, up to two secondary log files will be created if needed, and their size will equal that of each primary log file used. However, the total number of secondary log files allowed is also configurable (via the logsecond database configuration parameter).

You might think you can avoid running out of log space by configuring a database to use a large number of secondary log files. However, the maximum number of secondary log files allowed is 254. If the size of your log files is relatively small, you can still run out of log space quickly when transaction workloads become heavy. You should avoid allocating a large number of secondary log files, if possible, because performance is affected each time a log file has to be allocated. Ideally, you should allocate enough primary log files to handle most situations, then use just enough secondary log files to handle peak times in transaction workloads. If you're concerned about running out of log space and want to avoid allocating a large number of secondary log files, you can configure a database to use what is known as infinite logging. To enable infinite logging, simply set the database configuration parameters userexit and logsecond to YES and -1, respectively.