• first visit to city: 1 call to arrange interview + 1 visit to bank to pay fee + 1 visit embassy to submit documents + interview;
• second visit to city: 1 visit embassy to take passport with visa.

• minimum - supports service fee payments through any bank;
• maximum - supports online payments - over the phone (like in US embassy) or over the internet.

• cursor 1 - load 4 fields only;
• cursor 2 - load all fields from table (20 fields);
• cursor 3 - load all fields from table (20 fields) + have ORDER BY key field;
• cursor 4 - load all fields from table (20 fields) + have ORDER BY non-key/non-idexed field.

• test case for cursor # 1 =   958.853 mcs {ok} - less fields in select
• test case for cursor # 2 = 2.189.540 mcs {ok} - more fields in select
• test case for cursor # 3 = 2.323.017 mcs {ok} - more fields in select + ORDER BY by key
• test case for cursor # 4 = 4.931.463 mcs {ok} - more fields in select + ORDER BY by non-key

• more fields in select decrease performance 50-70% but as time-per-record is still quite small then we can disregard it;
• sorting resultset by key fields - almost no difference in performance;
• sorting resultset by non-key/non-idexed fields - make things 2-3 time slower;
• trimming spaces in all fields before storing values in a vector almost not affects the performance.

• These results obtained on IBM DB2 8.2.x;
• First data loading takes about 9-11 seconds, so before DB2 cached table it could takes essentially more time;
  thus if data is static (master data, translation tables and so on) - it is ok not to cache because DB2 do the data caching;
  but if there is some dynamic data... need to make extra testing on this. 

Отвечать не нужно :) не теряй времени, спеши воспользоватся сервисом ;)

Вранье это все! Не будут они на "любые темы" общаться - только сиски/письки...  :-P

• queue file is locked only when it is trying to open it, so most of the time you can modify it;
• on opening queue file SyncUtil use the exclusive access, so other applications cannot modify it;
• you can easily add new lines to the end of queue file to make more processes started in some time;
• also you can modify "LastRunTime" and "TimeDelta" parameters in a queue file;

In my case resources that need a synchronized access are - the Tandem NonStop environment, HP-UX environment, Linux environment. So all these environments located on remote or local servers and they cannot be accessed by multiple clients at the same time because of some specific limitations (single logon, conflicts at initialization scripts - whatever). Other examples of synchronized access I have seen at sites are - 3rd part hardware boxes doing some specific things.

So, in terms of code examples it looks like following (for *.BAT/*.CMD file):

  set QFile=c:\AccessQueues\tandem-xx63.q
  SyncUtil WaitAndLock %QFile% %BuildID% 50 20
  set ExitCode=%errorlevel%
  if "%ExitCode%" neq "0" (
    echo Cannot lock environment for build!
    goto end
    )

As you can see SyncUtil has the "WaitAndLock" function which wait until resource is free and try to allocate it for usage. The %BuildID% parameter is the unique identifier describing the client which is trying to access the resource. So, every client trying to use the resource should have own unique identifier in %BuildID%.

Another important parameter - the %QFile% it should be a full path to the queue file used to access specific resource. In my case I have a number of such files:

Other parameters in this code example - 50 and 20 are - the client priority and the waiting poll time. Thus, different clients can have different priority, 00 is highest priority, 99 is lowest. And waiting poll time is an interval in seconds between attempts to got access to the resource. In my case it has no sense to make attempts frequently than once per 20 seconds. In my system I have following queue files:

• D:\queues\tandem-xx63.q  - all processes trying to access the $XX63 environment on Tandem use this queue file;
• D:\queues\hpux.q  - all processes trying to access the HPUX environment use this queue file;
• also a number of *.Q files at - D:\R????\build\bin\build.q  - but these ones used for other kind of synchronization I'll describe in a next part.

Thus, the rule is following - the one resource = the one queue file.

And finally, after specific script finished to use the resource it should execute following code (for *.BAT/*.CMD file):

  SyncUtil UnLock %QFile% %BuildID% 20

to report that resource is released and can be used by other clients.

As you can see this approach is quite simple - not too much script code is used to implement and also the good thing - SyncUtil source code is also very simple - 900 lines of code in Borland Delphi 5 for all with command line parsing and help and diagnostic messages printing. The simplicity usually is the good thing.

Some Technical Details on Implementation

The queue file content looks like following:

; Queue file.
; (pri), (timestamp), (WaiterID), (WaiterPID), (WaiterParentPID) [, optional data ]
50,20090714-145858.734,VSH,0000086C,00000370
50,20090714-150311.110,ORD,000007F1,00001103
50,20090714-150334.345,MDC,00000459,000001F3

Lines started with ";" (semicolon) are comments. All other lines are records inserted by clients waiting for access to specified resource. In a single line data fields delimited by commas, and fields meanings are - priority of this clients wait request, timestamp when this record appears in a queue file, the client id (it is the %BuildID% value from code example above), the client PID, and PID of parent process for the client reqested access to the resource.

Note: PIDs here used to validate if process reqested access to the resource is still alive or not. If SyncUtil find that specified process is no longer exists this record removed from the queue file and if resource was locked by this client it is released so other clients can start to use the resource.

Another interesting part here is the queue file concept. The idea behind - SyncUtil always opening queue file in exclusive access mode, so only a single instance of SyncUtil can use the queue file at the moment. The exclusive file access here is something similar to the transactions in a database - it is a guarantee that file changes will be consistent, have no conflicts, data overlaps and so on. But please note that to make a deadlock it is enogh to open a queue file for view (or edit) in any text viewer/editor holding files opened (for example - open file for view in FAR)! Thus, to keep system running normally please avoid opening queue files for viewing for a long time because it could freez the access to resource. 

See also: Part 1 (http://dmitry-bond.spaces.live.com/blog/cns!D4095215C101CECE!765.entry)
See also: Part 3 (http://dmitry-bond.spaces.live.com/blog/cns!D4095215C101CECE!784.entry)

• for client_build.bat EventName=ClientBuild,
• for nt_build.bat EventName=NtBuild and
• for custom_build.bat EventName=CustomBuild.

• create new process holding predefined set of events before dealing with synchronization events in your script or ...
• create a separate process holding all synchronization events used by your scripts or ...
• assume that child processes will not change events state before the wait operation started.

See also: Part 2 (http://dmitry-bond.spaces.live.com/blog/cns!D4095215C101CECE!781.entry)
See also: Part 3 (http://dmitry-bond.spaces.live.com/blog/cns!D4095215C101CECE!784.entry)

Practice did show - it perfectly works!

So, my conclustions are

• or pay 30-50$ more for the good hardware;
• or buy hardware with passive cooling and then make it active by yourself