PARSEC Technical Information

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!