Output of information on subsystems (special window: SUSY)

The SUSY function enables the DAMP user to display information on

• the BS2000 nucleus (Control Program, CP)

• all subsystems that were loaded with DSSM

• all loaded user program contexts

The Control Program and the user program contexts are assigned pseudo subsystem names by DAMP. The Control Program receives the subsystem name 'CP', and all user contexts are given the subsystem name 'USERPROG'. If there are several loaded usercontexts in a task, the uniqueness of the subsystem name is ensured by DAMP by means of an internally assigned 'USERPROG' version number CTXNRxxx (where 'xxx' is a sequential number starting with 001, 002, ...).

User dumps contain information on the following subsystems:

• all loaded user contexts

• all nonprivileged subsystems connected to the task

This information is usually missing in area dumps.

In the case of system dumps, SLEDs, SNAPs and the active system, details on the following subsystems are displayed:

• Control Program

• all loaded privileged and nonprivileged subsystems

SUSY is called as follows:

SHOW-EDITED-INFORMATION INFORMATION=*SUBSYSTEM-INFORMATION, WINDOW=<w>

For information on the layout of the generated window and an explanation of the fields, see "Output of information on subsystems (special window: SUSY)".

You can page within the SUSY window with /+, ++, / -, --, +n and -n; see "Paging in a diagnostic window" (Modifying the diagnostic windows) for further details.

ENTRY names are not supported in the SUSY window.

The header lines of the SUSY window

The header lines of the SUSY window contains several input fields in which the subsystems, holder tasks or CSECTs to be output can be entered. 

Figure 45: Header lines of the SUSY window

Possible entries in the header lines of the SUSY window

It is possible to combine new entries in the various fields with previous entries, i.e. entries made in the input fields earlier which are still being displayed retain their validity and new entries can be made.

• Subsystem field
  If no entry is made in any other field, a list of the CSECTs of this subsystem is displayed. Entering *USER is equivalent to entering USERPROG.
  If, however, a CSECT name or an address is also entered, the system only searches the specified subsystem.

  If Subsystem=*ALL and, for example, a CSECT name is entered, all the subsystems are searched for this CSECT.

  If only Subsystem=*ALL is specified, the system switches to the subsystem list. Any entry made in the “Holder-Task” field is taken into account to only a limited extent.

  If you mark a subsystem name in one of the output lines, the corresponding CSECT list is displayed.

  The context names are output in the overview window as an alternative to the other information on the subsystems. To do this, you must either mark a subsystem version or enter “CTX” in the mode field.

• Version field
  The version of the desired subsystem can be entered in this field.

• Holder-Task field
  If a TID is entered in the field “Holder-Task”, the list of subsystems is abbreviated to those whose holder task matches the specified TID. The same effect can be achieved by marking the TID under “Holder” in one of the output lines.

  At the same time, the system attempts to change the active task (the task with the specified TID is activated if necessary). One side-effect of this can be that a user program is added to or disappears from the end of the subsystem list.
  The original overview can be redisplayed by entering *ALL in this field or SSA in the “Mode” field.

• Csect-Name field
  If a CSECT name is entered in the field, the output format changes and a list of all subsystems in which this CSECT occurs is displayed. 

  You can restore the subsystem list by entering *ALL in the “Subsystem” field.

  This function is also permitted for modules of the CP (Control Program) in order, for example, to display their identification field (ETPND).

• Address field
  An address which is to be localized, i.e. converted into a module and a displacement, can be entered in the field “Addr”. The resulting output is in the format of the CSECT list and contains all modules within which this address could lie.

• Mode field
  This field is a combined input/output field and has the following meaning:

  SSA	A list of all subsystems is displayed.
  SSC	Only the subsystems connected with the current task are displayed.
  SSH	A list of all subsystems whose holder task matches the specified TID is displayed (only as an output field).
  CTX	The context name is output for all subsystems.
  INF	CTX is reversed.
  CS2	The layout of the CSECT list is switched. Instead of the ETPDN, the P mode and the HSI byte is output for each CSECT. This mode is only supported for diagnostic objects of x86 servers.
  CS1 or CSE CS2 is reversed.
  EDT	The data corresponding to the settings of the SUSY window is output in its entire length to the current EDT area.
  LST	The entire subsystem and CSECT information of the object is output to the current EDT area.

  The current task (in the SLED or SNAP) is the last task selected by the person performing the diagnosis (by marking an item in window W2 or by explicitly entering a TID or TSN etc.).

Layout of the subsystem list

Figure 46: Subsystems overview

The individual columns of the subsystem list shown in figure 46 have the following meanings:

• The column Subsystem
  Name of the subsystem.
  If a field in this column is marked, output switches to the CSECT list format for this subsystem.

• The column Vers
  Version of the subsystem.
  If a field in this column is marked, a switch occurs to output of the context name for the marked subsystem.

• The column Holder
  TID of the holder task (if it exists).
  If a field in this column is marked, an abbreviated subsystem list with all subsystems “held” by this task is displayed.

• The column Mem
  Memory area in which the subsystem was loaded. The value “SYS” for system memory or “USR” for user memory is displayed.

• The column SubS-Type
  Subsystem type.
  This column can contain the values Nuc, Priv, NPriv, TU, Usr-Ctx, Pool-Ctx, TaskLoc, and undefined.

• The column META
  Address of the ANITA metadata.
  If a field in this column is marked and one of the keys to is pressed, the ANITA metadata for this subsystem is displayed in the desired window. This area contains a list of load information that was generated for the subsystem.
  This field is empty for the subsystem CP.
  There is likewise no display for subsystems loaded before DSSM.

• The column First Ad.
  Start address of the subsystem.
  This field contains the lowest address of the found CSECTs of the subsystem. If no load information for the subsystem is available, the start address is not supplied. 

Layout of the CSECT list

Figure 47: List of CSECTs of the subsystem AIDSYSA

The columns of the CSECT list shown in figure 47 have the following contents:

• The Subsystem column
  shows the name of the subsystem only if CSECTs which belong to several subsystems are displayed. Otherwise, this field is empty, and the subsystem name displayed in the title line applies.

• The Address column
  contains the address of the CSECT or an address within the CSECT. The former is the case only if the list was generated by entering an address in “Address” field. This field can be marked. If, for example, one of the keys to is then pressed, the selected window is positioned to the marked address.

• The Module and Reladd columns
  show the address from the “Address” column after conversion to module-relative form.

• The Length column
  contains the module length.

• The ETPND-Info column
  contains the ETPND information with the module name, version number and thecompilation date.

  In the case of prelinked modules, the module length may be zero. In system, user or area dumps, the ETPND information may be missing if the associated virtual page is not contained in the diagnosis object, since the dump generator only stores the referenced code pages.

  In the standard window, CSECTs of all subsystems can be specified when localizing memory segments. Even the automatic relocation of address fields considers the CSECTs of all subsystems. This means that SUSY is no longer required for localizing CSECTs. However, this applies only if the CSECT names in the scope covered by all the subsystems are unique. If this condition is not met (e.g. in the NKVT and NKVD subsystems or if different versions of the same subsystem coexist), this procedure always displays the first matched name. Targeted localization is then only possible using SUSY or the SEARCH-IN-SUBSYSTEM statement (see "SEARCH-IN-SUBSYSTEM Perform CSECT search in subsystem").

• The PMODE/HSI column
  contains, for diagnosis objects of x86 servers, information on the processor mode in which the code is executed and on the type of code generation. This output occurs in the CS2 mode.

  The different possible types of output have the following meanings:

  PMODE	Meaning
  CISC	emulation in /390 mode
  X86	native on x86 server
  HSI	Meaning
  R	mixed binary_no
  U	mixed binary_yes
  00	BLS information is not available or is obsolete. This value is generally displayed in the case of CISC coding.

You can use the keys and entries normally used for paging in the SUSY overview window. The paging functions +/, ++, - / , --, +n, -n are supported.

There are some class 5 subsystems which occupy different address space strips in the holder task and in the connected user tasks. The information used by DAMP for localization contains the addresses which are valid in a user task. However, the expected modules will not be found at this location in the holder task.