Ant and Make

Both are "builder" of application.

In instance, Make is used by perl, C, ...

To run it : make Makefile
The makefile contain : the target:dependency:script to run

example:

in C, there are file.C and headerfile.h. file.c is source code. headerfile.h is like library in which there are main function,variable that can be used among the file.c (ex. include stdio.h)

in C, you compile and then linking :
gcc -c thesourcecode then gcc -o theresultprevcommandANDsomelib

in C, when you have (at same folder):
file1.c and header1.h
file2.c and header2.h

to compile : gcc -Wall -ansi -o theprogram code1.c code2.c
Note: see @ bottom page, if you are confused why no need out headerfile.h at above command!!


You'll compile it like this if you dont want to compile all-in-once, example if you just modify one of the file, you dont need to compile all files :

gcc -c file1.c ==> resulting file1.o = a machine code file
gcc -c file2.c
gcc -o theprogram file1.o file2.o

Here are example makefile content:

''''''''''''''''''''''''''''
default: theprogram

code1.o: code1.c header1.h
gcc -Wall -ansi -c code1.c

code2.o: code2.c header2.h
gcc -Wall -ansi -c code2.c

prog: code1.o code2.o
gcc -Wall -ansi -o theprogram code1.o code2.o

clean:
rm code1.o code2.o

cleanall: clean
rm prog
'''''''''''''''''''''''''''''''

target : dependency
script to run

Note: if too long in a row use "\" as splitter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

step beginning : make makefile
will execute the make default, which dependens on theprogram,
so theprogram is run, but dependens on code1.o and code2.o,
so the code1.o and code2.o will be run, the script to get the codeX.c, the dependency.


step final: make clean
to remove the machine code files.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

in perl, as i remember:

make ==> to prepare the environment
make test ==> to test if any dependency failed
make makefile ==> run the instalation
make clean ==> cleanup some junk during instalation

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Ant, is java-based tool, can be use in vary programming, including replacing Make,
it is more advance with more feature.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Excerpt from http://www.unix.com/programming/47881-help-compiling-header-files-c-file-using-gcc.html

There are two basic ways to compile header files in C:

AAA

If the headers are in the same location as the source you include them like this:
Code:
#include "myheader.h"

if they are standard headers then inlude like this:
Code:
#include


then compile with
Code:
gcc -o myoutputfile myoutputfile.c

BBB

If the headers are located in some other (non-standard) location you would include like standard headers:

Code:

#include
and then use the -I (uppercase i ) flag to include the directory containing them.

Code:
gcc -I/path/to/directory/containing/header_name -o myoutputfile myoutputfile.c

or leave them quoted and use on of:
Code:
gcc -iquote /path/to/directory/containing/header_name -o myoutputfile myoutputfile.c

or
Code:
gcc -include /path/to/directory/containing/header_name/header_name.h -o myoutputfile myoutputfile.c

IHS + WAS + Plugin

Install IHS
==> Put server name as the identification of the "web server name" which will be used for "folder name" of plugin at IHS and WAS, and also log name as unique identity.
==> Put username and password, as it will be used for registering to Http admin.
==> Http admin is a service in windows, but it isnt accessible from browser.
==> Http server is another service created by the installer.

As i remember we dont need to install plugin, since it is along with the IHS installer,
and during the ihs instalation it asked where the WAS directory is.

But incase plugin wasnt there, just install it reside in IHS installer folder called plugins.


On WAS admin console:
==> go to servers = web servers = new
==> Put servername as same as the "web server name" above, as it is a folder name in the ihs plugin config dir.
==> Put hostname as the hostname/DNS name of where the IHS server is.
==> Put the "service name" of IHS correctly as in services.msc (in oder to be able restart webserver using was admin console)


At this point, the plugin is:
1. in IHS is general plugin of WAS default instalation (context root : snoop, hello, etc)
D:\Program Files\IBM\HTTPServer\Plugins\config\webservername

2. in WAS, plugin not available yet.

At WAS console, u must generate plugin (click the webserver and button will be available):
It will be in D:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\win2003Node01Cell\nodes\win2003Node01\servers\"webservername you insert when adding webserver"\

* That folder was created when you add new web server, plugin file will be created under it
* This plugin is only for default_host VH and others if any, but not for the admin_host VH
* admin_host VH is VirtualHost where /ibm/console is (WAS admin console login)
* default_host VH is VirtualHost where /snoop, /hello, /UTC (in my case) are.
* notice there is server.xml there, there you can see the webserver username and decoded password.
* you can decode the WAS user's password by using www.sysman.nl/wasdecoder


At WAS console, u must propagate plugin:
WAS will copy above plugin to IHS plugin - webserver name folder.

Restart the IBM Http service.

Now, u have successfully made it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

For redirecting/loadbalancing the WAS admin console using plugin, i think you must edit it manually the plugin-cfg.xml.

Allowing Web servers to access the administrative console
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tins_configACAccess.html

Procedure

1. Use the administrative console to change the admin_host virtual host group to include the Web server port (80 by default).
1. Click Environment > Virtual Host > admin_host > Host Aliases > New.

The default port that displays is 80, unless you specify a different port during profile creation.
2. Specify the IP address, or the name of the machine that is hosting the HTTP server.

For example, if you installed a WebSphere Application Server product on a machine that is named waslwaj.rtp.ibm.com, specify the name in this field.
2. Click Apply > Save.
3. Stop and restart the application server.

For example, to access the administrative console of a stand-alone application server, stop and restart the server1 process.
To stop server1, open a command window and navigate to the profile_root /bin directory. Then issue the following command:

./stopServer.sh server1

After receiving the following message, you can restart the application server:

Server server1 stop completed.

To start the application server, issue the following command:

./startServer.sh server1

When you receive a message that is similar to the following message, the server1 process is running:

Server server1 open for e-business; process id is 1719

4. Stop and restart a deployment manager.

For example, to access the administrative console of a deployment manager, stop and restart the deployment manager.
To stop the deployment manager, open a command window and navigate to the profile_root /bin directory. Then issue this command:

./stopManager.sh

Then issue the following command to stop the deployment manager:

./stopManager.sh

After receiving the following message, you can restart the deployment manager:

Server dmgr stop completed.

To start the deployment manager, issue the following command:

./startManager.sh

When you receive a message that is similar to the following message, the deployment manager is running:

Server dmgr open for e-business; process id is 1720

5. Edit the plugin-cfg.xml file to include the following entries:






...
...
...









...
...
...

AffinityURLIdentifier="jsessionid" Name="/ibm/console/*"/>

UriGroup="admin_host_server1_SERVER1HOSTserver1_Cluster_URIs" VirtualHostGroup="admin_host"/>


If your HTTP server has an HTTP port other than 80, add an entry to the VirtualHostGroup:



The port variable is your HTTP server port.

MQ 7 on windows

After installer launched, the prequisite ask about the Websphere Eclipse Platform 3.3,
you must install it first, by go to the prereqs folder (in the same installer CD as MQ installer),
then run the IES (Ibm eclipse SDK).

Configure:
1. crtmqm qmanager
2. runmqsc qmanager
3. runmqsc qmanager
4. define qlocal(qname)


To test it:
use the amqsput.exe in the bin directory :
amqsput qlocal qmanager (CATCH CATCH qlocal is at caps lock, if you dint put '' when created it)
type some text
enter twice to end it

Use the amqsget command.


>>>>>>>>>>>>>>>>>>>
Now, difference between amqsput and amqsputc, when u use amqsputc u must set this variable first:

set MQSERVER=SYSTEM.DEF.SVRCONN/TCP/127.0.0.1(1414)
where first parameter is channel with type of SVRCONN (other type can result error)

amqsputc qname qmanager
>>>>>>>>>>>>>>>>>>>>

WAS and MQ

You can test using UTC.ear (reside in deploy tool of WAS instlation folder)

CCSID : usually 850 (this is ID of the qmanager that u will use) You can see at the properties of the qmanager.
This must be put exactly same in the QCF and Q creation at WAS console.

At WAS - servers - you can ignore the Websphere MQ Server (No need to register to here, this is only for zOS mq).


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
HERE IS the PROCEDURE

Excerpt from:
http://activexpert.blog.co.in/2009/09/14/integrate-websphere-application-server-and-mq/

WebSphere Application Server can interoperate with WebSphere MQ in the following ways:

* By configuring WebSphere MQ as an external JMS provider using the WebSphere MQ messaging provider.
* By integrating a service integration bus into a WebSphere MQ network of queue managers using the default messaging provider and WebSphere MQ links.
* By integrating WebSphere MQ for z/OS® queues into a bus using the default messaging provider and a WebSphere MQ server.
WebSphere MQ links provide a traditional WebSphere MQ-style solution to connecting resources. WebSphere MQ servers add the ability to directly access WebSphere MQ queues from within a bus.

Method1: No bus: The WebSphere MQ messaging provider
The WebSphere MQ messaging provider does not use service integration. It provides JMS messaging access to WebSphere MQ directly from WebSphere Application Server.

Method2: Multi-bus: WebSphere MQ network as a foreign bus (using WebSphere MQ links)
A WebSphere MQ link provides an indirect connection between a service integration bus and a queue manager within a WebSphere MQ messaging network. With this type of connection, the messaging bus is seen by the WebSphere MQ network as a virtual queue manager, and the WebSphere MQ network is seen by service integration as a messaging bus. A Websphere MQ link allows WebSphere Application Server applications to send point-to-point messages to WebSphere MQ queues (defined as destinations in the service integration bus), and allows WebSphere MQ applications to send point-to-point messages to destinations in the service integration bus (defined as remote queues in WebSphere MQ). The link also allows WebSphere Application Server applications to subscribe to messages published by WebSphere MQ applications, and WebSphere MQ applications to subscribe to messages published by WebSphere Application Server applications. The link converts messages between the formats used by WebSphere Application Server and those used by WebSphere MQ, and handles data conversion of messages.

Method3: Single-bus: Queue manager as a bus member (a WebSphere MQ server)
A WebSphere MQ server provides a direct connection between service integration messaging engines in WebSphere Application Server and queue managers or queue sharing groups in WebSphere MQ for z/OS. WebSphere MQ server is designed to exploit the high availability, and optimum load balancing characteristics provided by a WebSphere MQ for z/OS network. WebSphere MQ server defines the connection and quality of service properties used for the connection, and also ensures that messages are converted between the formats used by WebSphere Application Server, and those used by WebSphere MQ.

=> Installation instructions for setting up a new WebSphere MQ installation to interoperate with WebSphere Application Server.

1. Install a supported version of WebSphere MQ
2. Follow the WebSphere MQ instructions for verifying your installation setup.
3. Configure WebSphere Application Server and WebSphere MQ to interoperate effectively.
4. At Node scope (not Server scope) set the WebSphere Application Server MQ_INSTALL_ROOT environment variable to the directory where WebSphere MQ is installed. WebSphere Application Server uses the MQ_INSTALL_ROOT setting to find the WebSphere MQ libraries for the WebSphere MQ messaging provider. If you use the default messaging provider and configure a WebSphere MQ server bus member, the bus uses the MQ_INSTALL_ROOT setting to establish a direct binding to WebSphere MQ rather than a TCP/IP network connection.
5. At Cell scope or Node scope, set the WebSphere Application Server MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN environment variable to True. This allows application server startup to automatically take account of changes that are made to the MQ_INSTALL_ROOT environment variable and WebSphere MQ JMS client libraries while the application server is stopped. If you do not set this variable, you must restart the application server a second time after any changes of this type, to enable the application to perform messaging using the WebSphere MQ messaging provider.

* Configuring a unified connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider that you want to support the destination.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Connection factories to display a table of existing unified connection factories, with a summary of their properties.
5. To view or change the properties of an existing unified connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the connection factory into the namespace.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the unified JMS connection factory for more details.
3. Click Apply. This defines the JMS connection factory to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the unified JMS connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a queue connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the queue connection factory that you want to configure.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Queue connection factories to display a table of existing queue connection factories, with a summary of their properties.
5. To view or change the properties of an existing queue connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the connection factory into the namespace.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the queue connection factory for more details.
3. Click Apply. This defines the connection factory to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the queue connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a topic connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the topic connection factory that you want to configure.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Topic connection factories to display a table listing any existing topic connection factories, with a summary of their properties.
5. To view or change the properties of an existing topic connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties. You can specify other properties, as described in a later step.
Name
The name by which this topic connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI Name
The JNDI name that is used to bind the topic connection factory into the name space.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the topic connection factory for more details.
3. Click Apply. This defines the destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the topic connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a queue for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the queue destination that you want to configure.
3. Optional: Change the Scope setting to the level at which the JMS destination is visible to applications.
4. In the contents pane, under Additional Properties, click Queues to display a table of existing queue destinations, with a summary of their properties.
5. To view or change the properties of an existing queue destination, click its name in the list. Otherwise, to create a new queue, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this queue destination is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the queue destination into the namespace.
Base Queue Name
The name of the queue to which messages are sent, on the queue manager specified by the Base Queue Manager Name property.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the queue destination for more details.
3. Click Apply. This defines the queue destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the queue destination, according to your needs.
7. Optional: If you want WebSphere Application Server to try to use the WebSphere MQ queue manager’s remote administration utilities to create the queue, configure the WebSphere MQ Queue Connection properties.
If you have already created your underlying queue in WebSphere MQ using its administration tools (such as runmqsc or MQ Explorer), you do not need to configure any of the WebSphere MQ Queue Connection properties. You only need to configure these properties if you want WebSphere Application Server to try to use the WebSphere MQ queue manager’s remote administration utilities to create the queue.
To be able to browse or change these MQ Config properties, you must have installed the WebSphere MQ client. If you have not done this, the administrative console displays messages like the following:
The WMQQueueDefiner MBean has encountered an error.
WMSG0331E: The MQ Client is required for this functionality, but it is not installed.
Note: For any changes to these properties to take effect on the queue manager, the WebSphere MQ Queue Manager on which the queue resides (or will reside) must be configured for remote administration and be running.
For more details about these properties, see WebSphere MQ config properties for the queue destination.
8. Click OK.
9. Save any changes to the master configuration.
10. To have the changed configuration take effect, stop then restart the application server.

* Configuring a topic for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the topic destination that you want to configure.
3. Optional: Change the Scope setting to the level at which the topic destination is visible to applications.
4. In the contents pane, under Additional Properties, click Topics to display a table of existing topic destinations, with a summary of their properties.
5. To view or change the properties of an existing topic destination, click its name in the list. Otherwise, to create a new topic destination, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties. You can specify other properties, as described in a later step.
Name
The name by which this topic destination is known for administrative purposes within IBM® WebSphere Application Server.
JNDI Name
The JNDI name that is used to bind the topic destination into the namespace.
Base Topic Name
The name of the WebSphere MQ topic to which messages are sent.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the topic destination for more details.
3. Click Apply. This defines the topic destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the topic destination, according to your needs.
7. Click OK.
8. Save any changes to the master configuration.
9. To have the changed configuration take effect, stop then restart the application server.

* Configuring WebSphere MQ connection pooling
1. Display the Message Listener Service properties for the application server
1. In the navigation pane, click Servers > Application Servers
2. In the content pane, click the name of the application server.
3. Under Additional Properties, click Message Listener Service properties.
2. Select Custom Properties, to enable WebSphere MQ connection pooling, add the following custom properties:
MQJMS.POOLING.THRESHOLD
The maximum number of unused connections in the pool.
MQJMS.POOLING.TIMEOUT
The timeout in milliseconds for unused connections in the pool.
3. Click OK.
4. Save any changes to the master configuration.
5. To have the changed configuration take effect, stop then restart the application server.

WAS + MQ

Follow the instruction

1. Service integration :make the BUS and Q destination point
2. Resource : make the Q connection factory and Q (and relate it with above value)
3. You can follow the Service integration Bus breadcrumb till you find the message in the Q pool.
(the message is readable)

To test use this:

1. install apps called Universal Test client (UTC.ear) at install-root\deploytool\itp\plugins\com.ibm.ws.ast.st.utc_6.1.6.v200811230003\IBMUTC.ear

this tool can be used to verify the Q in the pool.

WAS + TDS

From TDS:
A. installing the IBM TDS.
B. installing the WASembedded-IBMTDS
C. start the instance in the services.msc.
D. start the server1 in the TDS profile WAS.
E. go to TDS admin console : http://localhost:12100/IDSWebApp/IDSjsp/Login.jsp?showConsoleAdminLogin=true
F. default user:superadmin passwd: secret
G. Register the instance LDAP you want (ex. localhost 389)
H. Then you can manage this LDAP localhost 389 by the url
G. user: cn=...(usually root) passwd:.... (depends on what you put during the installation)
I. Go to server admininstration, add suffix ex. o=nehalorg
J. Go to directory management - manage entry : add o=nehalorg (parent leaves it empty) at the value you can put it same nehalorg (so there wudnt be multiple values).
K. From here you can create our own LDAP structure.
L. if you want to add an object (ex. class=person)and get "invalid dn entry". make sure in the relative dn you dint just put the calue, do like this "cn=value" (eihter it is cn or o or ou or whatever, you can see it right under it, there is one mandatory value, if it is cn then you put cn)


From WAS:
A. Security -> secure admin and infra -> available realm = standaolne ldap ==> set and then configure

B. primary admin user name =
a.either full DN (cn=wasuserPerson,ou=brno,o=nehalorg) or
b.the value (wasuserperson)
(only after you modify the "advance ldap setting" filter like cn=%v , notice %v is value).
At this time, WAS change the type to "custom ldap" instead of IBM TDS (uid=%v, objectclass=ePerson).

C. put the BaseDN (as the point to start search).
D. Bind DN is not necessary,it is only for anonymous connection.
E. restart java.
F. if you changed the "advance ldap setting" then you can use the value, instead of the long dn.
G. case doesnt sensitive.

NOTE:
1. SECJ0369E: Authentication failed when using LTPA. The exception is javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - Inappropriate Authentication].
==> This means you use "user" which has no passwd attribute (it depends on the object class)

2. LdapRegistryI E SECJ0361E: Authentication failed for wasuserinet because user is not found in the registry.
==> if you have ensured that you use full dn, and this still appears, This means you need to configure the ldap filter search in "advance ldap setting".

java -Xdump:help

Usage:

-Xdump:help Print general dump help
-Xdump:none Ignore all previous/default dump options
-Xdump:events List available trigger events
-Xdump:request List additional VM requests
-Xdump:tokens List recognized label tokens
-Xdump:dynamic Enable support for pluggable agents
-Xdump:what Show registered agents on startup

-Xdump::help Print detailed dump help
-Xdump::none Ignore previous dump options of this type
-Xdump::defaults Print/update default settings for this type
-Xdump: Request this type of dump (using defaults)

Dump types:

-Xdump:console Basic thread dump to stderr
-Xdump:system Capture raw process image
-Xdump:tool Run command line program
-Xdump:java Write application summary
-Xdump:heap Capture raw heap image
-Xdump:snap Take a snap of the trace buffers

Example:

java -Xdump:heap:none -Xdump:heap:events=fullgc class [args...]

Turns off default heapdumps, then requests a heapdump on every full GC.


.............................

java -Xdump:java:help

Write application summary:

-Xdump:java[:defaults][:=, ...]

Dump options:

events= Trigger dump on named events
[+...] (see -Xdump:events)

filter=[*][*] Filter on class (for load,throw,catch,uncaught)
#.. Filter on exit code (for vmstop)

file= Output file
range=.. Limit dumps
priority= Highest first
request= Request additional VM actions
[+...] (see -Xdump:request)

opts=

Default -Xdump:java settings:

events=gpf+user
filter=
file=/home/alfred/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt
range=1..0
priority=10
request=exclusive
opts=

*range means count, 1..0 : every occurence of event, 1..4: first four events (4 writes only)

*Tip: Deleting dump agents and create a new dump configuration can require a long set of command-line options. To reuse command-line options, save the new dump configuration in a file and use the -Xoptionsfile option. See http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.diagnostics.60/diag/appendixes/cmdline/cmdline_specifying.html for more information on using a command-line options file.