Clarified that setting CHNGPGS_THRESH to 40 is recommended when running DB2 version 9.5; whereas, setting DB2_ USE_ ALTE RNAT E_PA GE_C LEAN ING= ON is recommended for DB2 9.7 Added information regarding what effect setting SOFTMAX=1000 can have on the system Changed the recommendation for STMTHEAP from AUTOMATIC to 20000 based on feedback from the DB2 performance team Clarified that other automatic maintenance settings are not recommended Added information that when using the DB2 9.7 statement concentrator, it is recommended that you be at fixpack level 5 or greater and that VARGRAPHICS database should not be used
On January 30, 2012, updates for both the
TWA Rome Development team are looking for customers and business partners who are interested in participating in a Beta program for the next release of Tivoli Workload Scheduler for Applications and TWA 8.6 FP1 and SPE Features.
The Beta program provides participants with the opportunity to get an early look at the next release and provide feedback directly to the Development team to influence the future direction of the product. It will start on February 2012 ending on May 2012.
Beta program participants will receive education on the new features by webcast or recorded talk, and will be able to download Beta code from a web site and install it in their own test environment.VMware images are also provided.
We understand that participants have primary duties to perform at their companies and many demands on their time, there is no minimum time commitment in order to participate in the Beta program.
Participant benefits of a successful Beta Program include:
The opportunity to influence this product release and future directions
The ability to validate product code and documentation to ensure compatibility
The opportunity to obtain support from Development during the Beta Program
Please contact firstname.lastname@example.org if you are interested in this Beta or if you have any questions. The two steps to register are to complete a form with background information and to agree to an online Beta license.
Self Tuning Memory Manager (STMM) is a feature introduced since DB2 9 to get you out of memory tuning hell. It allows DB2 instances to adjust all database shared memory (buffer pools, sort heap, lock list, package cache, catalog cache, etc) to improve the overall performance. By default, STMM is turned on. Overall, STMM works great for IBM Tivoli service management products.
As Rick mentioned, statement concentrator could be a huge performance booster for IBM Tivoli service management products, so we generally recommend its usage for Maximo. However, during our performance benchmark, we did find a few interesting things about STMM, when statement concentrator is turned on. The following chart shows the overall system page hit rate (throughput) under different workload (number of users). In this benchmark, we gradually added users into the system to observe its performance. Interestingly, when STMM is turned on for all shared memory area, the system's performance started to degrade when approaching near 3000 users and then kept getting worse with more users added:
One symptom we could observe was that STMM kept increasing the size of the package cache, which reached 2GB at the end of 4000-user stage. DB2 statement concentrator enables queries that are identical except for the values of literals to share the same access plan. In addition to the "shared" plan, it also put a small "stub" entry for each original query (with literals) in the package cache. When these large number of small "stub" entries fill up the package cache, it trigger STMM to increase the size of the package cache, which then quickly got filled up again and enlarged again and again ... Eventually, DB2 spent majority of its time in just managing this extra large package cache which caused the performance degradation.
To resolve this problem, we turned off STMM for package cache (only) and use a smaller, fixed size for it (pckcachesz). We have observed near 50% CPU decrease on DB2 with 25% improvement in overall response time.
Note that DB2 9.7 FP5 includes a fix to address this problem. With FP5, when both statement concentrator and STMM for package cache is turned on, the package cache size is always under 100MB for our benchmark.
LeandroCassa 270002840B Tags:  things external automation srm restapi integration process little tpae tiny restful useful rest engine ccmdb tivoli system 3 Comments 17,601 Views
The XML output is similar to the integration framework format. And it is possible to extend the existing serializers to generate different outputs.
The URL above returns the list of person records on the target system.
Where 1 is the PERSONUID. If referring to a CI object, it would be CIID and not the CINUM; this is actually the unique ID of the table that represents the object.
The displayname and status are the fields to filter by. the operator ~eq~ stands for equal. MAXADMIN is the person I'm looking for and I'm also filtering by ACTIVE users. Using the first URL in this post, you can identify all fields that you can use to filter by. There are many operators (like ~eq~) that can be found in the information center reference provided at the beginning of this post, this post is limited to the most basic operations possible through the REST API.
the following document describes how to preserve customized if you want to upgrade from Tivoli Workload Scheduler V8.4 to Tivoli Workload Scheduler V8.5.x .
Please review this file and post your question on IBM TWA Forum !
This is the pdf:
Note: This blog entry was originally created by Zach Zhang in the Asset Management Group. I wanted to share this info with the Process Automation Group too.
There's some intermediate resource required by Oracle database to execute sql statements. One among them is Oracle Temporary Table Space when pure-in-memory operations could not be performed due to resource limitation or specific execution plan.
Before we start to discuss how and when Maximo application will use temp in Oracle database, there's one thing worth mentioning: it's Oracle database to decide when and how to use the Temp segment, while any application code just want the query result.
Tivoli Workload Scheduler 8.5.1 Fixpack 3 and Tivoli Dynamic Workload Console 8.5.1 Fixpack 3 have been shipped at the end of December 2011 and can be downloaded from Fix Central.These fixpacks (TWS and TDWC) deliver 160 APARS plus internal defects to our customers.Notice that the IBM ID needs to be entitled to download them from fixcentral.
If a customer or IBMer is experiencing a problem with the entitlement, please refer to the following links:
- Page where IBM internal can be entitled:http://www-947.ibm.com/systems/support/fixes/en/fixcentral/help/index.html- Entitlement error and resolution for customers:http://www-947.ibm.com/systems/support/fixes/en/fixcentral/help/faq_sw.html#entitlement_error
The fixpacks can be found by accessing the Fix Central section of the Tivoli Workload Scheduler: http://www.ibm.com/support/fixcentralThis fixpack's main themes
"Most important New features:Enhancements to the file transfer job type"
- Support for transfer mode selection
- Support for local and remote code page (valid only for FTP servers running on z/OS systems)
- Support for remote custom codepages (valid only for FTP servers running on z/OS systems)
- Support for the FTP, FTPS, FTPES, WINDOWS, SSH, protocols
TWS Improvement on current behaviour:
Ambiguity for jobs scheduled when Daylight Saving Time switches off
"If a job stream or a job run on a timezone where the Daylight Saving Time
(DST) switches off, that is the clock is put one hour back, and if you define
a time dependency for such job streams or jobs in relation to another
timezone, it might happen that this time dependency occurs during the
second, repeated time interval. In this case the time dependency would be
resolved during the first time interval.
Now Tivoli Workload Scheduler recognizes that the time dependency
occurs on the second, repeated time interval and resolves it accordingly.
No user action is required to activate this behaviour"
TWS Every job is now Daylight Saving Time aware:
"If the EVERY keyword is defined for a job when the Daylight Saving Time
switches off, that is the clock is put one hour back, the job does not run
during the second, repeated time interval.
Now the command EVERY JOB is DST aware and it runs also during the
second, repeated time interval. No user action is required to activate this behaviour."