(content by Holly_Fitzgerald)
The Accelerated Value Program is pleased to announce that Accelerated Value Central (AVC) will again be part of the upcoming IMPACT 2012 Conference to bring you exclusive events and opportunities that will enhance your IMPACT 2012 experience.
Over the coming months we will be providing additional information on our AVC events, designed exclusively for you - our AVP clients(*). This information will be provided directly to you by your Accelerated Value Leader and / or Specialist as well as published in our News item entitled Accelerated Value Central at Impact 2012 (April 29 - May 04)
. Be sure to bookmark the News item to stay on top of these exclusive AVC events.
Additional information about the conference can be found on the main IMPACT 2012 page
Please visit the IMPACT 2012 registration site
for more information including Early Bird Registration.
We look forward to seeing you in Las Vegas!
* If you're not an AVP client, see what AVP has to offer: WebSphere Software Accelerated Value Program
Today, we are announcing an upcoming change to the Twitter accounts for the IBM Business Process Management (BPM) product family. For your convenience, and to better align with our product family strategy, we are consolidating the IBM_Lombardi, IBM_Modeler, IBM_Monitor, and IBM_ProcessServ Twitter accounts into one Twitter account. Effective Wednesday, February 1, 2012, we will consolidate these four Twitter accounts into one Twitter account called IBM_BPM. To denote product-specific tweets, we will use the following #hashtags:
- IBM Business Process Manager Standard / IBM Business Process Manager Express / IBM Business Process Manager Advanced: #bpm
- IBM Integration Designer: #iid
- WebSphere Lombardi Edition: #lombardi
- WebSphere Business Modeler: #modeler
- WebSphere Business Monitor: #monitor
- WebSphere Enterprise Service Bus: #wesb
- WebSphere Integration Developer: #wid
- WebSphere Process Server: #wps
So, what does this change mean for you?
Current IBM_ProcessServ followers
If you are currently following the IBM_ProcessServ Twitter account, an action is not necessary. The account name will change and you will follow the new account automatically.
Current IBM_Lombardi, IBM_Modeler, and IBM_Monitor followers
If you are following the IBM_Lombardi, IBM_Modeler, or IBM_Monitor Twitter accounts, new tweets will cease on Wednesday, February 1, 2012. To avoid any interruption, follow the IBM_ProcessServ account before February 1, 2012 in advance of the change or the IBM_BPM account beginning on February 1st. If you follow the IBM_ProcessServ account before February 1st, you will automatically migrate to the IBM_BPM account. Beginning February 1st, tweets that previously were sent from the IBM_Lombardi, IBM_Modeler, and IBM_Monitor Twitter accounts will originate from the IBM_BPM account.
Note: The IBM_Adapters Twitter account will remain active.
As you might have noticed, this blog was renamed last week from the WebSphere Process Server Support Blog to the IBM Business Process Management Products Support Blog to encompass a wider variety of products within the IBM Business Process Management family of products. Initially, most of the blog entries will focus on the WebSphere Process Server product. However, we hope to offer topics on a wide range of IBM Business Process Management products as listed in the blog description.
As always, we welcome your comments on the blog entries and will respond to them as quickly as possible.
I recently published two new technotes related to some common issues that I have encountered in Support. Both of these issues are common issues that multiple IBM WebSphere Process Server users have come across. If you are encountering delays with WebSphere Process Server start-up, or WS-AT headers in your web services, then these publications might help you solve your problem. Check them out!
Do you follow us on Twitter? Our presence on Twitter is extensive! We provide links to technical support-related information that exists in many different formats such as problem and solution documents, developerWorks articles, IBM Red Books, IBM Red Papers, YouTube videos, blogs, and so on. We also provide links to educational opportunities and other related information to help you get the most out of your investment in our products.
There are two Business Process Management products that do not have a Twitter account named for them. However, we are currently providing information about those products through related Twitter accounts.
- IBM Business Process Manager Version 7.5 products were released earlier this year. To obtain information on IBM Business Process Manager Standard, IBM Business Process Manager Express, and IBM Business Process Manager Advanced, you can follow either the IBM_ProcessServ or the IBM_Lombardi Twitter account. Information pertaining to those products are provided through both of those accounts at different times; you won't miss any Business Process Manager-related tweets if you are following one account and not the other.
- WebSphere Enterprise Service Bus Version 7.5 was released earlier this year. To obtain information about this release and previous releases, follow the IBM_ProcessServ account.
We provide Business Process Management-related information through the following Twitter accounts:
- Twitter Account: IBM_Adapters
Products covered: WebSphere Adapters
- Twitter Account: IBM_Lombardi
Products covered: IBM Business Process Manager Standard, IBM Business Process Manager Express, IBM Business Process Manager Advanced, WebSphere Lombardi Edition
- Twitter Account: IBM_Modeler
Products covered: WebSphere Business Modeler and WebSphere Business Compass
- Twitter Account: IBM_Monitor
Products covered: WebSphere Business Monitor
- Twitter Account: IBM_ProcessServ
Products covered: IBM Business Process Manager Standard, IBM Business
Process Manager Express, IBM Business Process Manager Advanced,
WebSphere Enterprise Service Bus, and WebSphere Process Server
If you have any suggestions for content that you would like to see through our Twitter accounts, you can leave us comments here or send us a direct message through Twitter.
A good place to start when trying to determine what combination of components will work with a specific version of WebSphere Process Server is the Detailed System Requirements page on the Process Server support site.
As stated on the individual pages for the product version, we list out the base product and fix pack levels that should work for a particular version of WebSphere Process Server. It has come to our attention that there are some dependencies from the Feature Packs for SCA and XML, primarily with regard to the BO Lazy parsing feature of WebSphere Process Server V184.108.40.206, that require a certain version of the feature packs to be installed.
Specifically, with WebSphere Process Server V220.127.116.11, it is required to have the feature pack levels be at:
- Feature Pack for SCA Version 1.0.1 Fix Pack 7
- Feature Pack for XML Version 1.0.0 Fix Pack 7
The Detailed System Requirements page states that these are needed as a minimum, but since there are changes in the later feature pack updates, this is actually what is required instead of just being the minimum. A formal technote is also being put together to document this.
The tricky part is that if you are using Installation Manager to update your WebSphere Process Server product, it will recommend the latest and greatest version of the feature packs, which, at this time, is the Feature Pack for SCA Version 1.0.1 Fix Pack 11 and the Feature Pack for XML Version 1.0.0 Fix Pack 9. By following these recommendations, your product will be in an unsupported configuration and can cause issues.
In this situation, the configuration is not supported only if you are using the Lazy Parsing mode.
The Installation Manager itself cannot know of these requirements, so we are unable to put a sanity check in that tool when the upgrade is being done using the online repository.
For more information, see the following Flash document: WebSphere Process Server 7.0.0.x BO Lazy parsing mode is not compatible with SCA 18.104.22.168
Are you a visual learner? Do you search for knowledge on YouTube? There is an extensive selection of Business Process Management, education, developerWorks, and general support YouTube videos that are available to help you maximize your investment in IBM Business Process Management software. Here's a short list of some of the Business Process Management YouTube channels:
- Follow the BPMSupport channel from our IBM Business Process Manager Level 2 Support Team for videos that describe some common issues. Look for more videos to come!
- Look to the BPMInAction channel for various demos and insights from Bill Hahn on how to use the IBM Business Process Manager products.
- View the developerWorks channel for a wide variety of tips and information across the IBM product portfolio. This channel includes the "This week On developerWorks (TWOdW)" podcasts.
- See the IBMElectronicSupport channel for tips about using the IBM Electronic Support options including how to use the different features in the IBM Support Portal, the Service Request Tool, Passport Advantage, and My Notifications.
- Follow the WebSphereEducation channel to find short demos on how to use various functions within a variety of IBM software products. Currently, there are several videos for WebSphere Lombardi Edition and the IBM Business Process Manager products. You can find more information about the WebSphere Educational opportunities including information on IBM Business Process Manager education at the following URL: http://www.ibm.com/software/websphere/education/
- See the WebSphereServiceZone channel if you are interested in learning about the services that are available through the IBM Software Services for WebSphere Team. You can find more information about IBM Software Services for WebSphere at the following URL: http://www.ibm.com/developerworks/websphere/services/
Here are some of the more popular YouTube videos from these channels:
Recently, I have run across some interesting information with how the WebSphere Process Server Version 7 HTTP Import Binding handles timeouts. The WebSphere Process Server HTTP Import Binding has 2 properties for handling timeouts and retries:
- Read Timeout : Specifies the time, in seconds, that the binding waits to read data while receiving a
response message. Setting this field to 0 causes the binding to wait
- Number of Retries: Specifies the number of times the request is retried when the
system receives an error response.
Source: WebSphere Process Server Information Center 1) Read timeout=0 behavior
In WebSphere Process Server v7 there has been an addendum
made to the read ReadTimeout
Note: The HTTP transport
channel has its own Read timeout value, which is the amount of time that the
channel waits for a read request to complete on a socket after the first read
request occurs. This setting is described in HTTP transport channel settings in the WebSphere
Application Server Information Center.
As a result, a setting of 0 in Version7 will actually fall through and timeout on the HTTP Transport channel settings (typically a default of 60 seconds). If you require a long timeout value, you will need to use an arbitrary large number for this property instead of 0. Currently there is no setting that truly represents an indefinite wait.
2) Number of Retries behavior
The description for retries can be misleading.
Note that the description of this property is specifically describes retrying when the system receives an error response.
In a scenario where instead the HTTP Service does not respond, or the response is late, you may observe some unexpected behavior.No Response Scenario
Retry: 5Late Response Scenario
Read Timeout: 30
Behavior of the service: The service does not respond.
Expectation: In this case, 6 total requests (original+5 retries) are sent out in 30 second intervals.
Actual behavior: The current behavior of the binding is that only 1 request is sent as no error is returned. This particular invocation will wait 180 seconds then return an error.
Read Timeout: 30
Behavior of the service: Return after 45 seconds
Expectation: 2 requests are sent out. Unknown. The proper behavior to handle a late response or responses can be arbitrary.
Actual Behavior: The current behavior is that only 1 request is sent out. When the response comes in late at 45 seconds, it causes an error as it has exceeded the timeout value. The first retry is then submitted at the 45 second mark. Depending on the timing of the 2nd response; this might lead to additional unexpected behavior.
In summary, the retry mechanism currently is geared towards handling errors rather than no responses. You might encounter unexpected behavior when dealing with late or no response. If you have a service that might be slow to respond, you might set the high timeout values to avoid running into these problems.
We have submitted this issue and further work to create more meaningful retry behavior logic in these two situations.
As you may be aware, the primary way that data is represented within WebSphere Process Server is as a Business Object (BO). This is essentially a container that houses all the values of your data and can be manipulated or inspected within the various components that exist in WebSphere Process Server. This blog entry is to break down what needs to be understood about these Business Objects and how they are handled by WebSphere Process Server specifically. Please note, this entry is only directly applicable to EMF style BOs, not Lazy parsing style (this is new in version 7 of WebSphere Process Server).
The first thing to know is that Business Objects are represented as XML Schemas in WebSphere Process Server. For instance, if you are using the WebSphere Integration Developer (WID) to create your object, you can observe that once you have finished modeling your BO in the BO Editor, it has created an xsd file for you within the module. This is nothing more than an XML schema containing element and attribute declarations. These schemas can also exist directly in a wsdl file as well.
Regardless of where the schemas are defined (wsdls and xsds), the important aspect that differentiates the elements is their name as well as the namespace in which they are defined. What this means in the WebSphere Process Server world is that if there are multiple elements defined that have the same name and are defined in the same namespace this has potential to cause problems, even if the elements are defined in totally different actual files.
The reasoning for this is that when all these elements are loaded into the EMF system, which is what the BO as modeled in at runtime, these two things are what tells them apart. You can essentially think of a namespace as a big bucket in EMF. Every element and attribute that is defined in a namespace is tossed into a common bucket and is known from then on as a "feature" (more on this in a moment). The only caveat, is that there can only be one element or attribute with a specific name existing in this namespace bucket. So what essentially happens is that if you have defined two different elements with the same name in the same namespace, at runtime, only one of these will be usable. When a component attempts to use the other one, it will instead load the unexpected element and this is where problems can arise since this element may actually have distinct structures in each case. This them becomes a guessing game on which element will actually be loaded and used (and this ultimately will depend on the classloading policy in place).
There is a good technote that describes this behavior and a sample of how to remedy it:EMF FeatureNotFoundException with multiple schemas sharing namespace that have global elements
Whether the root cause is something as mentioned above or some other problem related to your schemas, the exceptions in WebSphere Process Server can be confusing since the data is stored in EMF and the terminology is slightly different. In EMF, the elements and attributes you would see in your xml schema are referred to as "features". So when you receive an exception of FeatureNotFound, this correlates to the system being unable to find a particular element or attribute within the object it is searching. The first place to check, of course, is if there even exists such as element and if so, you can move on to ensuring that no duplicates exist.
WebSphere Integration Developer provides a good warning if duplicates do exist in the modules or a modules dependency, so this should help to catch most instances. However, when adding in shared libraries or other schemas just sitting in the server's classpath, this would need to be investigated manually. SCA and ArtifactLoader trace may be enabled to help in finding what is loaded and from where as needed.
Earlier this week, Fix Central was updated to prompt for an IBM ID prior to downloading fixes.
When you visit the Fix Central site
, you will see the following announcement:
As of January 31, 2012, each IBM client accessing Fix Central (whether through their employees or other authorized representatives) is required to have an individual IBM ID to download fixes (some exemptions may apply). The registration is quick and simple and will provide users with a customized experience to better serve their needs. Fix Central downloads are available only for IBM clients with hardware or software under warranty, maintenance contracts, or subscription and support. Software code, samples, updates and fixes being accessed on this website (collectively, the Code) are subject to the terms of the license agreements which govern the use of the associated Code.
If you use Fix Central and don't already have an IBM ID, you can see this News item
or the Fix Central site
for how to get one. Keep your IBM ID handy so you won't have any delay if you need a fix.
Modified on by Bill Wentworth
This blog entry is an addendum to the detailed migration procedure from WebSphere Process Server V7.0.0 to IBM Business Process Manager Advanced V8.0, which was described by Sharath Srinivas here. The document was co-authored by Werner Tod and Matthias Benda, who are IBM consultants for the IBM Business Process Management family of products.
This blog describes the necessary extra steps for the migration of a WebSphere Process Server V7 environment with WebSphere Business Monitor V7 that is implemented in the same WebSphere cell.
To ensure the proper sequence of migration steps, we reference the migration step numbers from Sharath’s migration procedure. In case we need to add activities to a migration step, we add an “A” to the original step number. For example, “1A”.
For details regarding the individual migration steps, see the corresponding information in the IBM Business Process Manager and IBM Business Monitor V 8.0.1 product documentation.
2A. In addition to IBM Business Process Manager V8.0.1 Fix Pack 2, also install IBM Business Monitor 8.0.1 Fix Pack 2 on the target systems.
2A.1 Select to automatically deploy Cognos BI service, which used by IBM Business Monitor instead of the previously used AlphaBlox, during the profile migration process or manually by running the configuration wizard from the administrative console. To deploy Cognos BI automatically during the profile migration process, you must set some parameters for deploying the Cognos BI service. Even if your source version is 7.5.x, you must set the parameters because the Cognos BI service configuration cannot be migrated to the target environment without setting the parameters.
Complete the following steps:
(a) From the install_dir/scripts.wmb/migration/ directory, run the CognosConfig script.
(b) From the command line, set the following parameters to appropriate values: Cognos database, Cognos database username, Cognos database password, Admin user name, Admin password, Cluster/Server/Node.
(c) Manually publish the cube after completing the product migration:
1. Open the Admin Console at Applications > Monitor Models.
2. Select the version of a monitor model under Version properties.
3. Click Manage Cognos cubes.
4. Select the monitor model version and click Publish
Before creating the snapshot of the source profile, you have to migrate the WebSphere adapter configuration (if you use additional adapters) and copy the third-party libraries (if you use any in your environment). The adapter migration is described in detail in the IBM Business Process Manager and IBM Business Monitor product documentation. Make sure that your third-party libraries are compatible with the target version of IBM Business Process Manager and that they are copied to the same location as in the source environment.
In some cases, the old host names still show within URLs in the target profile. You have to replace those occurrences in the target environment before you can continue!
Steps 21A and 22A:
The database schema upgrade also has to be applied to the Monitor database. Create and run the appropriate scripts in addition to those for the Common database and the BPC database.
After upgrading the schema of the Monitor database, you also have to migrate the existing Monitor data:
Run the DataMigration script to migrate the database: 801monitor_root/scripts.wbm/migration/DataMigration/DataMigration.sh
Run the DataMigration script using the following parameters:
DataMigration.sh -dbType database_type -dbName database_name -dbSchema database_schema_name -host database_host_name -port database_port -dbUser database_user_name -dbPassword database_password -dbDriverType jdbc_driver_type
database_type is the type of database. The value must be one of the following values:
database_name is the name of the IBM Business Monitor database (by default, MONITOR)
database_schema_name is the schema name of the IBM Business Monitor database (by default, MONITOR)
database_host_name is the fully qualified host name or IP address of the node where the IBM Business Monitor database is installed
database_port is the database port
database_user_name is a user with access to the IBM Business Monitor database
database_password is the password for the user
jdbc_driver_type is the JDBC driver type that is used to connect to the IBM Business Monitor database. This parameter is required only when the database type is DB2ZOS. The value must be 2 if the database is local and 4 otherwise.
If you chose to deploy the IBM Cognos BI service automatically during profile migration, you must create the database that IBM Cognos BI uses for the content store. If the database that the IBM Cognos BI service uses for the content store is a remote database, ensure that a local database client is installed on the Cognos server and that the MONITOR database is cataloged. The cataloged database name must match the database name that is configured in the WebSphere data source for the MONITOR database.
To create the database that IBM Cognos BI uses for the content store, complete the following steps:
From the IBM Business Monitor V8.0.1 monitor_root/dbscripts/Cognos/DB2/ directory, open the createDatabase.sql script in a text editor and change the database name.
Replace the values for the following variables with the values for your environment:
@COG_DB_NAME@ - Required for SQL Server and DB2 on z/OS
@COG_DB_PASSWORD@ - Required for SQL Server and Oracle
@COG_DB_USER@ - Required for SQL Server and DB2
@STORGRP@ - Required only for DB2 on z/OS
@TSDIR@ - Required only for Oracle
@SCHEMA@ - Required only for Oracle
Save your changes and close the file. Important: If you are using a remote database and prefer not to run the scripts on the installation program of the database server, you must copy the scripts to the database server before continuing.
From the command line, run the script using the following command for your database software:
db2 -tf createDatabase.sql
Note: If you migrated from V7.5.x and the IBM Cognos BI service was deployed in the earlier environment, you can reuse the existing database instead of creating one.
Steps 25A, 26A and 27A:
Go through all these steps in order to also migrate the WebSphere Business Monitor profile to the target IBM Business Monitor profile. Remember to include steps 16A and 20A!
Before migrating the business space, it is a good practice or even necessary to complete the steps to implement the additional configuration for Business Process Choreographer. These steps are documented in the IBM Business Process Manager product documentation as part of the post-migration activities. However, they should already be implemented at this stage.
We welcome your feedback! Share your comments below.
interior glass stair steps Mar-2013 (modified) credit: (cc) Some rights reserved by Mrodaikusek
Over the past few weeks, I've seen multiple questions related to the DateTime field and time zones with WebSphere Process Server. The question is why does the timezone get normalized in WebSphere Process Server?
The DateTime field in the original message is usually a local timezone set as: <DueDate>2012-03-06T09:43:54.167-06:00</DueDate>
However, after the data passes through WebSphere Process Server, the time is normalized to UTC/GMT/Zulu time. For example: <DueDate>2012-03-06T15:43:54.167Z</DueDate>
The answer to the question is that the XML functionality and XML components that WebSphere Process Server provide, use the convention to always normalize the datetimes value to the UTC/GMT/ZULU timezone. WebSphere Process Server does not provide options to configure specific timezones for its output. The following document describes this issue: http://www.ibm.com/support/docview.wss?uid=swg21503646
Note:: Although the document is written for web services, the same general principles apply to other situations with XML output.
The key point to remember is that the serialization that WebSphere Process Server uses is one of many possible XML messages. However, the value it has chosen is valid and conforms to XML specifications. So, if your destination service conforms to the full XML apecifications, it should be able to understand and treat the DateTime field exactly the same no matter if it is provided in UTC or a local time zone format.
From a logical point of view, any of the time zones still represent the same point in time. It is the same situation as why the numbers "1.0", "1.00" , and "01.0" are all equal in XML.
There are an infinite number of different possible options that you might want related to the format of the XML message, which is beyond the scope of what can be reasonably provided by the product. As other example, we have run across requests for WebSphere Process Server to customize
- The namespace prefixes chosen
- The order of namespace declarations
- The white space tabbing.
Each of these requests for customizations actually reveal a deficiency in the consuming service not being able to fully understand the XML specification and logically equivalent XML messages. Because there are an infinite amount of options, an architectural decision was made to not provide these customization options, but only ensure that we will provide a message that is valid and logically equivalent.
If customization of the message is desired in a specific format, you can use custom code to modify or adjust the message using a custom DataHandler, WebServiceHandler, or other exit point, where you can work with the XML string directly.
Another option is to declare the field as a string, then the value is not normalized to the UTC time zone. Then, you can use the Java Datetime API with the Java String API to produce the desired format.
After nearly 10 years of working on an IBM documentation team, I was fairly surprised to hear that a colleague had recently discovered the feedback mechanism that is built into IBM information centers. Have you seen it? It's located at the bottom of every WebSphere Process Server Information Center topic. As a former member of a documentation team, we really appreciated it when our customers took the time to tell us when we have provided the right solution or when we can make improvements.
Here is a screen shot of the link to the feedback mechanism:
After you click Feedback
, you are presented with a form that gauges your overall satisfaction with the documentation and provides you with the opportunity to provide specific comments about the last topic that you were reviewing. The information that you submit through this form is sent directly to the WebSphere Process Server Information Development Team, who is responsible for maintaining the documentation. Members of the Information Development Team and their Development colleagues will review your comments and take the appropriate action for the next possible documentation update. Optionally, you can provide your contact information in the form if you would like to receive a response to your comments.
- Tell the team when a topic really helped you solve a problem.
- Suggest an example that might make the information more clear
- Request that steps are re-reviewed if you experienced difficulties, but were able to complete your task.
This form cannot be used for technical support.
The Information Development Team welcomes your comments!
A question I ran into today was how to change the default "Shared Resources" location that is used during the installation process.
When WebSphere Process Server is installed by the Launchpad, it automatically "imports" WebSphere Application Server into Installation Manager and uses a hard-coded default value for the Shared Resources location; commonly in the following form: "/IBM/BPMShared". This location is set during the first install or import of a product into Installation Manager and is shared with other related products. It is suggested that you use a location with sufficient disk space. This technote
describes the method to modify a file that Launchpad uses to specify the default location (<Install image>/launchpad/content/userExtensions.js).
For those of you who wish to dive a little deeper into the subject:
The Shared Resources location is controlled by the com.ibm.cic.common.core.preferences.eclipseCache
property, which is used during the InstallationManager command to import WebSphere Application Server.
As a result:
- When using the Launchpad to install the product, this property is set through the userExtensions.js script.
- If you wish to take more control without modifying the Launchpad files, you can use silent install and specify the location. The sample response file for a silent install has a section set aside for you to modify the com.ibm.cic.common.core.preferences.eclipseCache value.
- If you are looking for an interactive method, you will have to take control from Launchpad and manually install WebSphere Application Server using the WAS directory in the WebSphere Process Server disk image. Then, using Installation Manager, you can perform the Import and then specify your own Shared Resources location.
Remember: You can set this location only on the first product install or WebSphere Application Server import. If you already have products installed, unfortunately, you will have to uninstall and reinstall to change the location.
As a WebSphere Process Server administrator, do questions on wstemp ponder you? Well, read on...
- I see that the wstemp directory gets filled up with sub-directories as I work on application deployments and server administration tasks. What are these sub-directories?
The wstemp directory is used as a temporary directory for the server. The temporary files are mostly created during application installation and uninstallation tasks. They are also created while running wsadmin scripts and store current session data for logged in administrative console user. wstemp is created for the deployment manager and each custom profile in the cell configuration.
- Can I delete these sub-directories? Can I delete them when servers are running?
When the logged in user logs out of the administrative console, the user session details are no longer required. The sub-directory anonymous* holds this information and are is removed when you log out. When there are no installation tasks in progress, the temporary files that are created in these tasks are no longer needed. The sub-directory appdep* holds this information. When there is no script task in progress using wsadmin, the sub-directory, Script* contents are no longer required.
Most of the wstemp directories are deleted when the servers are shut down. While manually deleting the contents, the general rule is - it is safe to delete the contents when the servers are stopped. But on environments where downtime is kept minimal, the directories will keep piling up and consume valuable disk space. So can you delete directories without stopping the servers?Specifically, to be on the safe side, if the administrator is sure that there are no application deployment tasks in progress, appdep* directories can be removed. When there are no script actions in progress, Script* directories can be removed. The only caution is while dealing with anonymous* directories. It is not advisable to remove these directories when the servers are running.
- Are there any known defect fixes for wstemp not cleaned up?
Depending on the WebSphere Application Server version you are running, refer to the Fix List web site for more information.
- For V7.0.0, click here
- For V6.1.0, click here