gtmpcat consists of two routine files -- a platform-independent main program (gtmpcat.m), and an initialization file, which is specific to the CPU architecture, operating system and GT.M version. Both the main program and the appropriate initialization file must be available in the $gtmroutines search path. Run gtmpcat as follows:
$gtm_dist/mumps -run gtmpcat <options> corename|processid
As it executes, gtmpcat provides a running account of its actions on its stdout, as well as a detailed report in a file whose name it provides on stdout at the end of its processing.
Option values are separated from option flags by whitespace. The options are:
Options |
Abbr |
Description |
|
---|---|---|---|
--asver |
-a |
Specify an explicit GTM version for the core/process, if it is not the same as that specified by the -version option (which in turn defaults to that of the gtmpcat process). Note that GT.M versions are not abbreviated, for example, V6.0-001, not V60001. |
|
--callin |
n/a |
Specifies the path of the executable that created the core or the path to load in the given process to run against. Typically, this is a call-in type module that can also be used to diagnose LKE or DSE cores or processes. |
|
--cmdscript |
-s |
Use this option for the prototyping of additional information extraction. This option executes once every time you run GTMPCAT. This option also implies interactive mode. As soon as interactive mode setup is complete, GTMPCAT invokes the specified entryref. This options is like a gtmpcat-plugin in a way that it runs with full access to GTMPCAT routines, variables, and the debugger. |
|
--cmdfile |
-c |
Specifies the path of the file containing interactive mode commands. It is ignored unless specified with --interactive (i). |
|
--debug |
* |
-d |
Enable interactive debugging of gtmpcat itself. On encountering an error, gtmpcat executes a BREAK command before gtmpcat either continues or exits depending on the error severity and whether an error resume point is defined. This enables some interactive debugging. Also, for a successful run, a ZSHOW dump is created with the name gtmpcat-DEBUG.zshowdump.txt. This file is overwritten/recreated as needed. The default is -nodebug. |
--debuglines |
* |
n/a |
Enables debugging of the lines written to and read from the debugger. Used for debugging gtmpcat. The default is --nodebuglines. |
--devicedetail |
* |
-e |
Include a separate section in the report to show the actual control blocks in use and their addresses. The default is --devicedetail. |
--gtmdeftypes |
-g |
Specifies the location of GTMDefinedTypesInit.m when it is not there in the current path. |
|
--ignoreunexprslt |
* |
-u |
When a GTM version is built with debugging flags, GTM can output extra lines when, for example, starting up and/or displaying the results of simple commands like .Write $Zversion.. As part of determining what version a particular install directory has, gtmpcat executes the Write $ZVersion command in a GT.M process. If this command prints extra lines, it can cause gtmpcat initialization to fail. This option can be used to ignore the extra lines returned. The default is --noignoreunexprslt . |
--interactive |
* |
-i |
Tells gtmpcat to enter interactive mode, as described below. Use this only under the direction of FIS GT.M Support. The default is --nointeractive . |
--localvar |
* |
-l |
Include local variables, both the current local vars plus any saved (NEW'd) vars on the M stack (either explicit or implicit) in the report. Since the local variables of a process are likely to contain protected (confidential) information that is being processed, the default is ---nolocalvar to omit them. Before sharing a gtmpcat report with anyone, you must determine whether the report contains protected information and whether the recipient is permitted to view the information in the report. GT.M Support at FIS does not accept protected information. |
--lockdetail |
* |
n/a |
Include a detailed dump of M lock related control blocks showing the block addresses and relationships. The default is --nolockdetail. This option is useful only to debug GT.M itself. |
--lvdetail |
* |
n/a |
Include a detailed dump of the actual local variable structures. As this option can produce a report with protected information in local variable subscripts, please review the warnings above in the -localvar option. The default is --nolvdetail. This option is useful only to debug GT.M itself. |
--memorydump |
* |
-m |
Includes a memory map dump of all allocated storage. Only available when the core file or process is running GT.M V5.3-001 or later, and then only if $gtmdbglvl is non-zero in the process. The default is -nodump. Use this only under the direction of FIS GT.M Support. |
--mprof |
* |
-p |
Enable M-profiling across the gtmpcat run. After loading the initialization file, gtmpcat turns on M-profiling, Just before gtmpcat completes execution, it turns off M-profiling and dumps the result in a global called ^trace. This option requires a GT.M database and global directory be available. |
--msdetail |
n/a |
Includes additional fields from the M stack-frame. The default is --msdetail. |
|
--mumps |
n/a |
the core or process is a mumps executable (default). |
|
--mupip |
n/a |
the core or process is a mupip executable. |
|
--output |
-o |
Specifies the desired output file/directory. If the value given is a directory (relative or absolute), the default file name is created in the given directory. If the value is a file, that is the file-name used to hold the report. |
|
--ppi |
* |
n/a |
Specifies whether to extract personally identifying information from the core. If --ppi is not specified, GTMPCAT does not:
|
--regiondetail |
n/a |
Collects spanning regions information. Currently, this option collects data but does not display the output. |
|
--tracedump |
-t |
Read and format the internal GTM trace table. Default is --notracedump. This is useful only to debug GT.M itself. |
|
--version |
-v |
Specifies the directory with the GT.M version of the core/process. The default is the version used by gtmpcat itself, that is, in $gtm_dist. |
|
|
When gtmpcat runs, it needs to know how the structures and fields for a given version of GT.M are defined. There is one of these initialization files for each OS, architecture, and GT.M version. Once gtmpcat knows the architecture and GT.M version of the process/core, it invokes the proper initialization file to define the layout of everything it is interested in. The format of the gtmpcat initialization file is:
gtmpcat<OS>On<architecture><gtmversion>.m
For example, the name of gtmpcat initialization file on Linux x86_64 running GT.M V6.0-000 is gtmpcatLinuxOnX8664V60000.m