===== How to Send a Crash Dump File to PARSEC for Analysis ===== If your system ever does crash, immediately see to it that the system's SYSDUMP.DMP file has been correctly copied to its secondary/alternate file -- see [[How To Capture a VMS Crash Dump]]. Then open a new case (or re-open an old one) with PARSEC -- see [[How To Initiate a VMS (OpenVMS) Tech Support Call]]. Let your Tech Support specialist know that you have a current, valid crash dump file that you'd like to have analyzed -- s/he will further instruct you as to how and where to transfer that file to PARSEC so that a crash dump expert can analyze it for you. This crash dump analysis can often pin-point exactly which process caused the crash, including what application or other program it was running, and sometimes pinpointing the exact instruction which caused a BUGCHECK (software error) or the context during a MACHINECHECK (hardware fault). A crash dump file contains binary data, so it must be file-transferred to PARSEC's FTP-server using binary (image) mode, not text (or ascii) mode. If you need to have a PARSEC VMS internals expert perform crash dump analysis for you (recommended), then your specialist will arrange for you to SFTP or FTP (in //binary// file transfer mode) that DUMPFILE_COPY.DMP file to our system; our internals expert will take it from there. Whenever possible, //send the copied Dump File//, not the original System Dump File. The reason for this is that, in copying the Dump File to its alternative, SDA augments dumped file identifiers (FID) with actual file-specifications wherever available, plus some additional information. In other words, the SDA COPY command also includes the actions of the SDA COLLECT command: SDA> help copy COPY Copies the contents of the dump file to another file. Format COPY [/qualifier...] output-filespec SDA> help collect COLLECT Collect file identification to file name translation data on both OpenVMS Alpha and OpenVMS for Integrity servers, and process unwind data only on OpenVMS for Integrity servers. PARSEC recommends that you SFTP or FTP the //copied Dump File// to us for analysis, as this provides us with the full, contextual information from your VMS system. Without this, several vital clues to your crash event may be missing. See [[How To Capture a VMS Crash Dump]]. This wiki article emphasizes sending crash dump and/or BACKUP save-set files via SFTP or FTP in //binary// (//image//) mode. This is especially important if you must first transfer the file from VMS to an intermediary system, like your desktop or laptop (Windows) system, in order to finish the file transfer through your organization's firewall (many customer sites fully restrict Internet access to/from VMS systems). Be sure __all__ "hops" of the file transfer are done in binary mode: VMS system ----------> Windows PC ------> (firewall) ------> PARSEC FTP-site binary binary PARSEC's customer-support FTP site, ''ftp.parsec.com'', enables //binary// (//image//) mode file transfers as its __default__. In the following example, assume that the fictitious customer's/organization's name is "AcmeCo" (Wiley E. Coyote's primary Amazon-like -- before there was Amazon.com -- supplier of Road-Runner-catching gadgets), so the connection is made with username "''acmeco''" and password "''acmecosupport''" To send AcmeCo's latest DUMPFILE_COPY.DMP to PARSEC: ''$ **SET DEFAULT DISK$ARCHIVE:[DUMPS]** ! where you've copied your crash dump file...''\\ ''$ **sftp acmeco@ftp.parsec.com**''\\ ''fwipper@ftp.parsec.com's password: **acmecosupport** <- This password does not echo, of course...'' #---------------------------------------------- # Welcome to PARSEC's FTP service for Clients! # You will be "trapped" in a chrooted directory # That means you can simply upload files here # without worrying about where to put them or # making sub-directories. #---------------------------------------------- Connected to ftp.parsec.com. sftp> put DUMPFILE_COPY.DMP ...This file transfer will take “a long time”... sftp> quit $ In some situations, PARSEC (or others) may request that you send a BACKUP save-set file which contains your copied Dump File. Many sites mark the copied-dump files with the NOBACKUP file attribute: ''$ **SET FILE /NOBACKUP DUMPFILE_COPY_05122016.DMP;**''\\ ''$ **DIRECTORY /FULL DUMPFILE_COPY_05122016.DMP;**''\\ Directory DSA2:[LRICKER.CRASH_ANALYSIS] DUMPFILE_COPY_05122016.DMP;1 File ID: (47086,142,0) Size: 95221/95328 Owner: [STAFF,LRICKER] Created: 5-DEC-2016 13:17:34.72 Revised: 5-DEC-2016 13:23:18.67 (2) Expires: ...%< snip >%... File attributes: Allocation: 95328, Extend: 11923, Global buffer count: 0, No version limit, Contiguous best try Backups disabled <<<--- that file attribute... Record format: Fixed length 512 byte records Record attributes: ...%< snip >%... Total of 1 file, 95221/95328 blocks. To create that save-set (*.BCK) file with this entire dump-copy usefully saved in it, use a BACKUP command like this: ''$ **SET DEFAULT STAFF:[LRICKER.CRASH_ANALYSIS]**''\\ ''$ **BACKUP /IGNORE=(NOBACKUP) DUMPFILE_COPY_05122016.DMP DMPSAV.BCK /SAVE**''\\ Here, the qualifier ''/IGNORE=(NOBACKUP)'' ensures that the //contents// of the copied dump file are included in the save-set, overriding the “Backups disabled” file attribute. Be certain to SFTP or FTP a BACKUP save-set file in //binary// mode, just as you’d send the copied Dump File itself in binary mode. If you fail to do any of the above steps correctly, you’ll be burning a lot of wasted time preparing and FTP-transferring an “empty but very large dump file” to your crash dump support team!