First force the parameter “always allow dump” to TRUE:

[root@labotest]/root# sysdumpdev -K

Check if a primary dump device is set to a logical volume, with type sysdump:

[root@labotest]/root# sysdumpdev -l
primary              /dev/hd7
secondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    TRUE
dump compression     ON
type of dump         traditional

Check the size needed for dump device:

[root@labotest]/root# sysdumpdev -e
0453-041 Estimated dump size in bytes: 1763075686

Check if you have enough space in the primary dump device (hd7), else increase to the right size:

[root@labotest]/root# lslv hd7 | grep PP
MAX LPs:            512                    PP SIZE:        32 megabyte(s)
LPs:                60                     PPs:            60
STALE PPs:          0                      BB POLICY:      relocatable
INTRA-POLICY:       middle                 UPPER BOUND:    32

Cleanup old snaps:

[root@labotest]/root# snap -r

On the HMC, perform a reboot, by selecting DUMP (default).

 --> select the LPAR --> Operation --> Restart --> Dump
Or with HMC command line
hscroot@HMC:~> chsysstate -r lpar -o dumprestart -n sysh1 -m P-570

After the reboot you can check into errlog (errpt -a), to see if the dump is success, and/or

[root@labotest]/tmp/ibmsupt# sysdumpdev -L
0453-039

Device name:         /dev/hd7
Major device number: 10
Minor device number: 16
Size:                1307898880 bytes
Uncompressed Size:   7879498205 bytes
Date/Time:           Thu Aug  4 17:15:26 GMT+02:00 2011
Dump status:         0
Type of dump:        traditional
dump completed successfully

Once the LPAR is running again, perform a snap:

[root@labotest]/root# snap -ac

This snap is located into /tmp/ibmsupt/snap.pax.Z

Now you are able to send it to IBM FTP site:

rename the snap file to /tmp/ibmsupt/<PMR_number>.snap.pax.Z  
(Example:  85885.500.624.snap.pax.Z)

upload the renamed file to IBM FTP server:

ftpserver: ftp.emea.ibm.com
user: anonymous
password: (your email address)
directory: /toibm/aix/
transfer mode: binary

A system dump indicates a severe problem with an AIX system. System dumps usually halt the system, necessitating a reboot.

[root@labotest]/root# errpt
67145A39 0413095315    U    S    SYSDUMP    SYSTEM DUMP

To copy the core, be sure to have enough space !

Copy the system dump from dumpdevice to a file

[root@labotest]/root# savecore -f -d /tmp

Next, uncompress the dump using the dmpuncompress command, uncompress can be very big!

[root@labotest]/root# dmpuncompress  vmcore.0.BZ

Lastly, format the dump:

[root@labotest]/root# /usr/lib/ras/dmprtns/dmpfmt -c vmcore.0
This dump appears complete - The end-of-dump component was found.

Lastly, format the dump:

[root@labotest]/root# /usr/lib/ras/dmprtns/dmpfmt -c vmcore.0

Analyse the dump:

[root@labotest]/root# kdb  vmcore.0  vmunix.0

Like using the dbx

(0)> stat
	SYSTEM_CONFIGURATION:
	CHRP_SMP_PCI POWER_PC POWER_6 machine 
	with 2 available CPU(s) (64-bit registers)

	SYSTEM STATUS:
	sysname... AIX
	nodename.. lpar_name
	release... 1
	version... 7
               … lines omitted …
	time of crash: Mon Apr 
13 09:52:09 2015
	age of system: 13 day, 
18 hr., 37 min., 28 sec.
	xmalloc debug: enabled
	FRRs active... 0
	FRRs started.. 0

	CRASH INFORMATION:
	CPU -1 CSA 053A7E80 
at time of crash, error code for LEDs: 
	70000000