Defaults

#### Search Results

Search

# Defaults

As a system administrator, you can set system-wide defaults for various objects and functions.

This section covers the following topics:

- System Defaults

- Monitor Defaults

- Report Defaults

- Bundle Defaults

- Automatic Archiving Defaults

- User-Defined Archives

- Automatic Reviving Defaults

- Automatic Cleanup Defaults

- CA Spool Defaults

- Natural Advanced Facilities Defaults

- Trigger Container File

- User Exits

- Default Code Pages

- Node Definitions

- Email Message Definitions

- 3GL Interface

- 3GL Interface Maintenance

## System Defaults

This section covers the following topics:

- Modifying System Defaults

- Displaying System Defaults

- Components of System Defaults

- Integrating Natural Applications

### Modifying System Defaults

To modify the system defaults:

1. Select the System Administration > Defaults > System node in the object workspace.

2. Invoke the context menu and choose Open.

3. The System Defaults are displayed, and you can change them. The fields are described under Components of System Defaults.

4. Choose OK to save your changes.

### Displaying System Defaults

To display the system defaults:

1. Select the System Administration > Defaults > System node in the object workspace.

2. Invoke the context menu and choose Display.

3. The System Defaults are displayed. The fields are described under Components of System Defaults.

4. Select Cancel to close the window.

### Components of System Defaults

#### General

Field | Explanation
--- | ---
NOM definition-data file (DBID/FNR) | The Adabas database ID and file number of the Entire Output Management definition-data file (logical file 206).
NOM active-data file (DBID/FNR) | The Adabas database ID and file number of the Entire Output Management active-data file (logical file 91).
NOM trigger container file | See Trigger Container File.
Use owner ID | If selected: Operating-system resources should be accessed with the user ID of the report owner or bundle coordinator. This allows users whose ID is not defined externally (RACF, BS2000 user ID, etc.) to use Entire Output Management. If not selected: The Entire Output Management user must have authorization to access operating-system resources.
Use Owner ID | User ID is ESY User | Browse | Submit Job
Selected | Yes | Report Owner | User ID
No | Report Owner
Not selected | Yes | User ID | User ID
No | - | Monitor
Support long names | If selected: Report names and bundle names may consist of up to 25 alphanumeric characters. If not selected: Report names may consist of up to 17 alphanumeric characters and bundle names of up to 8 alphanumeric characters.
Date format | Select the format to be used for date information in Entire Output Management: American (MM/DD/YY) American (MM/DD/YYYY) European (DD/MM/YY) European (DD/MM/YYYY) German (DD.MM.YY) German (DD.MM.YYYY) International (YY-MM-DD) International (YYYY-MM-DD)
Automatic user definition | Automatic creation not allowed: User IDs must be defined manually with the Users function. This is the default. Automatic creation: If a user enters an ID which exists neither for a user nor a distribution list, Entire Output Management automatically defines the user ID with a default profile. The default profile will be taken from the user ID `DEFAULT`. Show window to decide: If a user enters an ID which exists neither for a user nor a distribution list, he/she will be prompted to decide whether he/she wishes to use the default profile `DEFAULT`.
Daily cleanup | Once a day, cleanup processing is performed which deletes: active reports (or marks them for archiving), expired active reports from archive/revival, log records, printout records, and active bundles. If you run the monitor as a single task, it will be unable to process any reports, bundles or printouts while performing daily cleanup. To avoid this, you can define multiple tasks (daily cleanup is done by task 1) or execute the daily, report and spool cleanup as a stand-alone batch job. To achieve the latter, execute the program `NOMCLEAN` in the library `SYSNOM` in a standard batch Natural job, ensuring that `LFILE 206` is set correctly to point to your Entire Output Management system file. You should schedule the batch job so that it finishes before the time specified for daily cleanup. Time = The time when you want to execute the cleanup process. Next run = The date and time of the next cleanup run.

#### Applications

See Integrating Natural Applications below.

#### Log/Printouts

Field | Explanation
--- | ---
Log
Types | Select the types of information to be logged. You can log maintenance information for reports, bundles, logical printers, distribution lists, and information about logon/logoff activities of users.
Retention | Enter the default retention period for log records. This is the period of time that log records are kept in the Entire Output Management database. You set this period by specifying a number and a unit of time (days, weeks or months).
Printouts
Types | Specify the type(s) of printouts to be deleted automatically at the end of the printout Retention period: Printed successfully. Printing error. Printing failed.
Retention | Specify the default retention period for printouts. This is the period of time that printouts are kept in the Entire Output Management database. You set this period by specifying a number and a unit of time (days, weeks or months).
Type: Print on hold | Specify the default retention period for held printouts. This is the period of time that printouts in Hold status are kept in the Entire Output Management database. You set this period by specifying a number and a unit of time (days, weeks or months).

#### Interval/Timeout

These settings apply to the expansion of the treeview. If a treeview node is expanded and the number of records to be listed is very large, the expansion may take very long. In this case, you can expand a treeview node not all at once but in intervals (portions). This form of treeview expansion is controlled by the following fields.

Field | Explanation
--- | ---
Use standard interval settings for all users | If selected, these settings apply to all users and cannot be changed by a user individually. If not selected, every user can set his/her own treeview intervals (via Options in the Menu Bar).
Use intervals to display large amounts of data: If selected, intervals are used for treeview expansion; if not selected, intervals are not used. If intervals are used, they are controlled by the following options: Number of intervals for splitting: The number of "portions" into which the records will be split when the treeview is expanded. Number of records without displaying intervals: If the number of records does not exceed this value, the treeview expansion will not be in intervals. This refers not only to the overall number of records, but also to the number of records in individual intervals (as indicated by the interval placeholders): An individual interval will be split into further sub-intervals if this number is exceeded for it. Abort if the number of records processed is greater than: If the number of records processed exceeds this value, the treeview expansion will be aborted. If you do not want it to be aborted, set this field to "0".
Use standard timeout settings for all users | If selected, the timeout setting specified in the field below applies to all users and cannot be changed by a user individually. If not selected, every user can set his/her own timeout interval (via Options in the Menu Bar). Abort if processing takes longer than: The procedure triggering the abortion of the treeview expansion will be started if the communication with the server in conjunction with treeview splitting exceeds the specified number of seconds. The specified value must be smaller than the RPC timeout value.
Perform search in advance when opening the search dialog | This option applies to the search for active reports in a folder. If this option is not selected, the Search dialog initially displays an empty result list. This prevents a search with unknown search criteria, as this might cause a system time-out in environments with a large number of active reports. If this option is selected, the Search dialog initially displays the result list of active reports based on the current search criteria.

### Integrating Natural Applications

You can specify Natural applications which are to be displayed on the Main Menu of Entire Output Management, from where the users can invoke them (not available in the Output Management GUI client).

To integrate applications in the Main Menu:

1. In the Applications section of the System Defaults window, you specify each application as follows:

   Field | Explanation
   --- | ---
   Title | The text which is to be displayed on the Main Menu.
   Library | The Natural library in which the application is contained.
   Program | The name of the Natural program which is to be executed as startup transaction.
   Parameters | The application-specific startup parameters.

The defined applications are displayed for all users on the Main Menu of Entire Output Management. Under Natural Security, only users with the appropriate access rights will be able to log on to an application.

To return from an application to the Entire Output Management Main Menu, the application must finish with `RETURN`.

#### Automatic Display of Other Software GmbH products

If Entire Operations, Entire Event Management or Natural NSPF are installed at your site, these products are automatically displayed on the Main Menu of Entire Output Management. In this way, it is easy for users to "toggle" between them and Entire Output Management.

Under Natural Security, only users with the appropriate access rights will be able to log on to a product.

## Monitor Defaults

This section covers the following topics:

- Modifying Monitor Defaults

- Displaying Monitor Defaults

- Components of Monitor Defaults

The Monitor runs as one or more subtasks under Entire System Server or as one or more batch jobs and controls the generation, printing and distribution of reports and bundles.

Before you specify several Monitor tasks or allow several Natural tasks, you should check the value of `NATNUMSUB` in the Entire System Server startup parameters:

`NATNUMSUB=subtask-maximum`

`subtask-maximum` is the maximum number of subtasks (recommended: 20).

In z/OS, subtasks run under the Monitor Entire System Server node. In UNIX, each Monitor task uses a separate process.

### Modifying Monitor Defaults

To modify the monitor defaults:

1. Select the System Administration > Defaults > Monitor node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Monitor Defaults are displayed, and you can change them.

   The fields available vary depending on the spool type. They are described under Components of Monitor Defaults.

4. When you have made you changes, choose OK to save them.

### Displaying Monitor Defaults

To display the monitor defaults:

1. Select the System Administration > Defaults > Monitor node in the object workspace.

2. Invoke the context menu and choose Display.

3. The monitor defaults are displayed. The fields are described under Components of Monitor Defaults.

4. Select Cancel to close the window.

### Components of Monitor Defaults

- General
- Spool Parameters
- Container Files
- Monitor Tasks

#### General

Field | Explanation
--- | ---
Node | Displays the name/number of the Entire System Server node under which the Entire Output Management Monitor is run as a subtask or batch job.
System | Displays the system type (e.g. z/OS).
Spool type | Displays the spool type (JES2, JES3 or UNIX).
Batch module | This field is only available for JES2 and JES3. Enter the name of the Natural batch module to be used by the Monitor. The module must reside in the Entire System Server load library or in one of the Entire System Server steplib libraries defined for the Natural task that is started. For information on creating the batch module, see the Installation and Customization documentation.
System server job name | This field is only available for JES2 and JES3. Enter the name of the Entire System Server job.
Printer tasks | The number of tasks attached to print reports and bundles (maximum 32). See also the recommendations under Monitor Tasks.
Wait factor | These fields are used to adjust monitoring to the load in your installation. It is the time in seconds the Monitor waits between two consecutive monitoring cycles. During each cycle, the Monitor performs all the work accumulated since the end of the last cycle.
Minimum | Enter the minimum time in seconds the Monitor is to wait between two consecutive monitoring cycles.
Maximum | Enter the maximum time in seconds the Monitor is to wait between two consecutive monitoring cycles.
Increment | If there is no activity during the minimum wait time, the wait time is increased by the value you enter here, until the maximum is reached. When activity occurs, the wait time returns to the minimum. Enter the number of seconds by which the wait time should increase.
Error handling | Retries | The number of retries for a failed Monitor operation. The action in error will not cause an error message, but it will be tried again after the time specified in the Interval field.
Interval | The time in seconds after which a failed Monitor operation is tried again.
Emergency emails | You can specify one or more email addresses. In the case of severe errors, the Monitor will send error information to these addresses. See Email Message Definitions for details.
Jobcards or Additional Parameters | Enter a job card to be used as a default when no other job card is specified. The following substitution variable can be used: `§USER`. Trace: Tracing requires a huge amount of database space and deteriorates performance considerably; therefore, the trace function should only be used if requested by our support. If the text `TRACE=` appears in the jobcards, the Monitor will write a detailed activity trace to its SYSOUT file(s). If the SYSOUT files are not available, for example, if the tracing Monitor routine runs in a server environment or online, the trace output is written to the System Automation Tools log file, which can be retrieved with the utility NOMLOG (see Displaying the Monitor Log under Monitor Management). In addition, the Monitor trace switches on the tracing facilities of Entire System Server and the Natural Data Collection trace function if required by the specified program level. `TRACE` can be specified as follows: `TRACE=OFF` - No tracing will be performed. `TRACE=ON` - Everything will be traced (across all levels and all components). `TRACE=level` - Everything will be traced up to the specified program level (as determined by the Natural system variable *LEVEL). `TRACE=(level,[component,...])` - Tracing will be performed up to the specified program level for the specified component(s). `level` can be `1 - 99`. `component` can be: `MONITOR` = All Monitor administration traces (this is also always traced in conjunction with one of the other components). `SCAN` = The scanning of spool systems for matching reports. `COPY` = The copying of reports to a container file. `CREATE` = The creation of active reports and bundles. `PRINT` = Printout management. Note The tracing of printers is not controlled by this job card. To trace printer tasks, you use the corresponding printer attribute; see Attributes of Physical Printers.

#### Spool Parameters

Field | Explanation
--- | ---
JES2 and JES3
These fíelds are used to define the SYSOUT classes dedicated to Entire Output Management.
Execution (JES3 only) | Enter a list of execution classes to be processed by Entire Output Management. This method creates considerable performance overhead and should only be used for compatibility reasons. In future, only SYSOUT classes should be used for processing by Entire Output Management. If, however, you still need this method during a transitional period: in addition to searching SYSOUT classes for output, execution classes can also be searched. In this case, the following limitations apply: no default definitions are checked for processing; messages that no report definition has been found for a certain SYSOUT file are not logged.
Sysout | Enter a list of SYSOUT classes to be processed by Entire Output Management. Only those jobs with SYSOUT files in these classes are processed.
Internal | Define one SYSOUT class to hold temporary SYSOUT files. This class must not be one of the classes defined in the Sysout field above.
Print | Enter the class in which reports and bundles are to be printed.
Error | Define one SYSOUT class to hold the SYSOUT files which cause an error during processing. This class must not be one of the classes defined in the Sysout field above.

#### Container Files

For information on the use of container files, see Container Files and Active-Data File in the Concepts and Facilities documentation.

To define a container file for the Monitor:

1. On the Monitor Defaults screen, select Container Files.

2. A window is displayed, in which you specify:

Field | Explanation
--- | ---
Destination | The destination of the container file, as specified in the `DEST=(,...)` parameter of the DD statement (JES).
DBID / FNR | The database ID and file number of the container file.

#### Monitor Tasks

This function is used to define subtask processing for the Entire Output Management Monitor.

You can split the workload of the Monitor between different tasks, each with its own wait factors.

The management functions of the Monitor (for example, cleanup, active bundle flushing) are always performed by Task 1. In addition, Task 1 will take over the work for any other task that fails.

To define subtasks:

1. In the Monitor Defaults window, select Monitor Tasks.

   The list of tasks is displayed:

2. Make the task specifications as desired.

#### Recommendations

The number of additional Monitor tasks depends on your execution environment. The following table gives some recommendations:

Environment | Total Number of Monitor Tasks | Additional Tasks for Functions | Wait Factors (in seconds) | Number of Printer Tasks
--- | --- | --- | --- | ---
Minimum | Maximum | Increment
General recommendation | 2 | Manage Printouts/Special | 5 | 30 | 1 | 2
Many short printouts | 2 | Manage Printouts/Special | 1 | 20 | 1 | 4 - 10
Few large printouts | 3 | Manage Printouts/Special, Copy Sources | 10 | 30 | 1 | 2 - 4
Many short printouts plus a few large printouts | 3 | Manage Printouts/Special, Copy Sources | 1 | 20 | 1 | 4 - 10

#### Multiple Tasks for Copying of Sources

In a multi-node environment, the workload of copying sources may be too great for a single task to handle. In this case, you can split this workload between up to 9 tasks.

If the copying of sources is handled by multiple tasks, each of the tasks dedicated to copying sources cannot perform any other function.

To define multiple tasks for copying sources:

1. In the Monitor Task Profile window, select as task function Copy Sources (multiple).

2. Next to it, specify the number of tasks for copying sources.

## Report Defaults

You can define default parameters for report processing. These defaults apply to newly-created reports and can be modified for each report.

This section covers the following topics:

- Modifying Report Defaults

- Displaying Report Defaults

- Components of Report Defaults

### Modifying Report Defaults

To modify the report defaults:

1. Select the System Administration > Defaults > Report node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Report Processing Defaults are displayed, and you can change them.

   The fields are described under Components of Report Defaults.

   The Action options correspond to those described in the General Attributes of a report.

4. Choose OK to save your changes.

### Displaying Report Defaults

To display the report defaults:

1. Select the System Administration > Defaults > Report node in the object workspace.

2. Invoke the context menu and choose Display.

3. The Report Processing Defaults are displayed.

   The fields are described under Components of Report Defaults.

   The Action options correspond to those described in the General Attributes of a report.

4. Select Cancel to close the window.

### Components of Report Defaults

Field | Explanation
--- | ---
Report Retention | These fields determine how long reports are stored in the Entire Output Management database. When this retention period expires, the reports are purged and/or archived, depending on the selected Action. The default retention period is the system-wide period defined by the system administrator.
Action | Possible actions: Purge report after = The report will be purged when the retention period expires. It will not be archived. Archive report after = The report will be archived when the retention period expires. Archive report directly and keep online = The report will be archived the next time the archive job runs, but its content is still available for online viewing until the retention period expires. Archive report directly, purge online immediately = The report will be archived the next time the archive job runs, it will be purged when its processing is completed. (none) = No default is set for new reports. When an active report is archived, its content is no longer available online. After this, it only exists in the archive data set and has to be revived before it can be viewed or printed again.
Number | Specify the number of days/weeks/months the report is to be stored in the Entire Output Management database.
Unit | Possible values: Working days Absolute days Weeks Months If you select "working days", you have to specify a calendar which distinguishes between working and non-working days.
Calendar | If you specify "working days" as the Unit of time, you have to specify the name of the calendar which determines which days are considered to be working days. See also Calendars.
Example: If you want reports to be kept for two working days, you specify Number `2` and Unit `working days`. Assuming that in the calendar referenced, Saturday and Sunday are defined as non-working days, this means that if a report is created on a Friday evening, it will be retained until Tuesday evening.
Copy report content to NOM database | You can use this option to take the report contents from the spool and store them in the Entire Output Management directory file for later viewing or archiving. To set no default for new reports, select (none).
Create report definitions for active reports by separation | With this option, you can have report definitions created automatically for reports produced as a result of separation. To set no default for new reports, select (none).
Jobcards or Additional Parameters | Enter the job cards to be used for printing with batch jobs. The following substitution variables can be used: `§USER` and `§REPORT`.
Separator Pages | Start | Enter the name of the separator page to be printed at the beginning of the report.
End | Enter the name of the separator page to be printed at the end of the report.
Copies | Specify how many times each separator page is to be printed.
See Separator Pages for further information.

## Bundle Defaults

You can define default parameters for bundle processing. These defaults apply to newly-created bundles. They can be modified for each bundle.

For further information, see Adding a Bundle Definition in the User's Guide.

### Modifying Bundle Defaults

To modify the bundle defaults:

1. Select the System Administration > Defaults > Bundle node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Bundle Processing Defaults are displayed, and you can change them.

   The fields are described under Components of Bundle Defaults.

4. Choose OK to save your changes.

### Displaying Bundle Defaults

To display the bundle defaults:

1. Select the System Administration > Defaults > Bundle node in the object workspace.

2. Invoke the context menu and choose Display.

3. The Bundle Processing Defaults are displayed.

   The fields are described under Components of Bundle Defaults.

4. Select Cancel to close the window.

### Components of Bundle Defaults

Field | Explanation
--- | ---
Retention | Period | Enter the number of absolute days, working days, weeks or months the bundles are to be kept in the Entire Output Management database. See the Retention field description under Attributes of a Bundle in the User's Guide.
Unit | Possible values: Working days Absolute days Weeks Months If you select "working days", you have to select a calendar which distinguishes between working and non-working days.
Calendar | Select a calendar, if "working days" is the unit for the retention period. For more information, see Attributes of a Bundle in the User's Guide. See also Calendars.
Example: You have defined a calendar in which Saturday and Sunday are marked as holidays. If have specified "2" as the Period, and "working days" as the Unit and the bundle is created on Friday evening, it will be retained until Tuesday evening.
Bundle separator pages | Start | Enter the name of the separator page to be printed at the beginning of the bundle.
End | Enter the name of the separator page to be printed at the end of the bundle.
Copies | Specify how many times each separator page is to be printed for the bundle.
See Separator Pages for further information.
Printers | Printer | You can enter up to 5 logical printer names. These are the printers on which the bundle will be printed. The select a printer, use the Select button on the right. For further information, see Selecting Printers for a Bundle.
Copies | Specify the number of copies to be printed on the respective printer. See Setting the Number of Copies for a Printer.
Report separator pages | If this option is selected, the report separator pages are printed. This is the default. If this option is not selected, the report separator page are not printed. The number of separator pages can be defined for each report in the bundle. See Attributes of a Bundle in the User's Guide.
Hold before print | If this option is selected, the bundle is placed in Hold status in the printout queue until it is released manually for printing. If this option is not selected, the bundle is printed immediately.
Jobcard or Additional Parameters | Enter the job card to be used for printing on system printers. The following substitution variables can be used: `§USER` and `§BUNDLE`.

## Automatic Archiving Defaults

You can set default parameters for archiving. These parameters enable you to create archive data sets and schedule automatic archiving.

For further information on archiving, see the sections Archive Administration and Archiving Task.

This section covers the following topics:

- Modifying Parameters for Archiving

- Displaying Parameters for Archiving

- Archiving Parameters

- Archiving Schedule Parameters

### Modifying Parameters for Archiving

To modify the archiving parameters:

1. Select the System Administration > Defaults > Archiving node in the object workspace.

2. Invoke the context menu and choose Open Parameters.

3. The Archiving Parameters window is displayed, and you change the data.

   The fields are described under Archiving Parameters below.

4. Choose OK to save your changes.

### Displaying Parameters for Archiving

To display the archiving parameters defaults:

1. Select the System Administration > Defaults > Archiving node in the object workspace.

2. Invoke the context menu and choose Display Parameters.

3. The archiving defaults are displayed. The fields are described under Archiving Parameters below.

4. Select Cancel to close the window.

### Archiving Parameters

Field | Explanation
--- | ---
Parameters for All Operating Systems
Default retention | Enter the default retention period for archive records. This is the period of time that reports are kept in the Entire Output Management database. When this period expires, the reports are marked for deletion in the archive catalog.
Number | Enter the number of units the reports are to be kept.
Unit | Days, Weeks, Months or Years.
Data set prefix | Archive | Enter a prefix to be used for creating archive data set names. A sequential number is added automatically to this prefix to create a name for an archive data set.
Condense | You may enter a different prefix for archive data sets created by the condense job, so that these can be distinguished from normal archive data sets.
Delete empty archive data sets automatically | Automatic deletion of empty archive data sets.
Condense threshold | Numbers of active reports in an archive that will cause automatic condense marking of this archive.
Job skeleton/Scripts | The name of the job skeleton used for the archive task on mainframes is `JARCSKEL`. `JARCSKEL` must be located in the library `SYSNOMU`. The job skeleton used for condensing has to be saved in library `SYSNOMU` and must be named `JCDNSKEL`. The name of the script used for the archive task on Linux is `nomarc.bsh` and the one for condensing `nomcdn.bsh`, see section Scripts in Installation on UNIX, Completing the Installation in the Entire Output Management documentation.
Jobcards or Additional Parameters | Enter the job cards to be used for archiving with a batch job. See also Limiting the Amount of Archiving and Condensing below.
Parameters for z/OS only
Provide the expiry date on every condense step (EXPDT) | Select to provide the expiry date on every condense step. This will cause operating-system messages to be issued for the second and subsequent steps and these might require operator intervention. Deselect to provide an expiry date (or output file retention period) only on the final condense step. This is the default and is compatible with earlier versions of Entire Output Management.
Generic Name | Enter the generic name for tapes used in your installation. This parameter is used for archiving to tapes. The default is `TAPE` (`UNIT=TAPE` in JCL).
Storage Class (SMS) | Enter the name of the storage class for the storage management system.
Archive to disk with generation data sets | GDG | Select to use a generation data set. For information on generation data sets, see the appropriate IBM documentation.
Max. generations | Maximum generations. This field is taken from the definition of the generation data set and cannot be modified.

#### Limiting the Amount of Archiving and Condensing

In some cases, the number of active reports to be archived/condensed may be too high for one archiving/condensing run and should therefore be split. With the parameters `ARCHMAX` and `CONDMAX`, you can limit the number of active reports to be archived and condensed respectively. They are specified in one of the lines for the jobcards (see above) in the form of a comment for the job entry; for example: `//* ARCHMAX=20000`.

`ARCHMAX` can be used on all operating systems, `CONDMAX` can only be used on mainframes, but not on UNIX.

- `ARCHMAX=nnnnnn` - Archiving will stop when the specified number of archived active reports is reached. Message `NOM0494` will be issued as a reminder that archiving has to performed again for the remaining active reports.

- `CONDMAX=nnnnnn` - Condensing will stop when the specified number of condensed active reports is reached. The source archive dataset will continue to have the status "condense". Message `NOM0487` will be issued as a reminder that condensing has to performed again for the remaining active reports. Repeated condense jobs will create new condense datasets.

### Archiving Schedule Parameters

Field | Explanation
--- | ---
No archive schedule | No archive schedule is active.
Next run | Displays the date and time for which the next archiving run is scheduled (as calculated from on the archive schedule parameters specified on this screen).
Archive every day / on selected days of the month/week | You can either select archiving to be performed every day or on certain days of the month or on certain week days: Archive every day: If you choose this option, archiving will be daily. Archive on selected days of the month: If you choose this option, a list of days (1 to 31) will be displayed, on which you select the desired date(s). For archiving on the last day of the month, you select "Last day". Archive on selected days of the week: If you choose this option, a list of week days (Monday to Sunday) will be displayed, on which you select the desired day(s).
Start time | You can specify the time of the day when archiving is to start.
Calendar | If you select a calendar here, archiving is performed only on days defined as working days in that calendar, but not on days defined as holidays. See also Calendars.
Holiday rule | Should an archiving date fall on a calendar holiday, you can select either "Before holiday" or "After holiday" to perform it on the last working day before the holiday or the first working day after the holiday respectively.

## User-Defined Archives

You can define up to 9 custom archive types in addition to the standard archive. This enables you to:

- create multiple hierarchies for archived reports. For example, reports which need to be revived quickly can be archived to disk, with all other reports being archived to tape.

- archive to non-standard data sets (that is, data sets which cannot be accessed as a Natural work file) such as optical disks.

The Entire Output Management Monitor submits an archive job for each type which has active reports to be archived. It also submits a condense job for each type which has archive data sets to be condensed. It submits a revive job for each data set/volume containing reports to be revived.

Notes:

1. You cannot condense data sets of different types into a single output data set.
2. Entire Output Management assigns the logical volser name `NOMUDA` to all user-defined archives.

This section covers the following topics:

- Listing the Archives

- Creating a New Archive

- Components of User-Defined Archives

- Modifying an Archive

- Displaying an Archive

- Renaming an Archive

- Cross-Referencing an Archive

- Deleting an Archive

### Listing the Archives

To list the archives:

1. Select the System Administration > Defaults > Archiving node in the object workspace.

2. Invoke the context menu and choose List.

   A list of all user-defined archives is displayed.

### Creating a New Archive

To create a new user-defined archive:

1. Select the Archive folder in the object workspace.

2. Invoke the context menu and choose New.

3. The New User-Defined Archive window is displayed in the content pane. The fields are described under Components of User-Defined Archives.

4. Choose OK to save your data.

### Components of User-Defined Archives

Field | Explanation
--- | ---
Name | Enter an archive name (must be unique).
Number | The internally allocated type number.
Description | Enter a description.
DSN Prefix | The prefix used for data sets created for this archive type. If you leave this field blank, the value is taken from Automatic Archiving Defaults.
Job Skeletons | The name of the member in `SYSNOMU` to be used for submitting archive, revive and condense jobs.
Default Retention | The archive retention value to be used for any report which does not have its own retention value. If you leave this field blank, the value is taken from the Automatic Archiving Defaults.
User Routine | The user routine library and member to be invoked for this archive type. If you leave this field blank, the archive will be handled as a standard batch Natural work file.
Archive/Revive Jobcards | Jobcards to be used for archive/condense and revive jobs. If you leave these blank, they are taken from the Automatic Archiving Defaults and Automatic Reviving Defaults.

### Modifying an Archive

You cannot modify a user-defined archive if there are any reports, active reports or archive data sets of this type.

To modify a user-defined archive:

1. Select an instance of the System Administration > Defaults > Archiving node in the object workspace.

2. Invoke the context menu and choose Open.

3. The User-Defined Archive Type window for the selected instance is displayed, and you can change it. The fields are described under Components of User-Defined Archives.

4. Choose OK to save your changes.

### Displaying an Archive

To display a user-defined archive:

1. Select an instance of the System Administration > Defaults > Archive node in the object workspace.

2. Invoke the context menu and choose Display.

3. The selected archive is displayed. The fields are described under Components of User-Defined Archives.

4. Select Cancel to close the window.

### Renaming an Archive

To rename a user-defined archive:

1. Select an instance of the System Administration > Defaults > Archive node in the object workspace.

2. Invoke the context menu and choose Rename.

   A window is displayed.

3. Enter the new name, and select OK.

### Cross-Referencing an Archive

To display cross-reference information for a user-defined archive:

1. Select an instance of the System Administration > Defaults > Archive node in the object workspace.

2. Invoke the context menu and choose XREF.

   The XREF of Archive Type window is displayed, showing which relation types and how many objects of each relation type the archive is related to.

   The object list of the first relation type is expanded by default.

3. To display the object list of another relation type, click on the relation-type name or the arrow preceding it.

### Deleting an Archive

To delete a user-defined archive:

1. Select an instance of the System Administration > Defaults > Archive node in the object workspace.

2. Invoke the context menu and choose Delete.

3. Confirm your choice.

## Automatic Reviving Defaults

The reviving parameters enable you to schedule automatic reviving.

For further information, see the section Start Reviving Task.

This section covers the following topics:

- Modifying Reviving Defaults

- Displaying Reviving Defaults

- Reviving Parameters

### Modifying Reviving Defaults

To modify the reviving parameters:

1. Select the System Administration > Defaults > Reviving node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Reviving Parameters are displayed, and you can change them.

   The fields are described under Reviving Parameters below.

4. Choose OK to save your changes.

### Displaying Reviving Defaults

To display the reviving parameters:

1. Select the System Administration > Defaults > Reviving node in the object workspace.

2. Invoke the context menu and choose Display.

3. The reviving defaults are displayed. The fields are described under Reviving Parameters below.

4. Select Cancel to close the window.

### Reviving Parameters

Field | Explanation
--- | ---
Job skeleton | The name of the job skeleton. The member resides in the library `SYSNOMU`.
Jobcards or Additional Parameters | Enter the job cards to be used for reviving.
Schedule | The following fields are used to define the automatic scheduling of the reviving process.
No revive schedule | No revive schedule is active.
Next run | Displays the date and time for which the next revive run is scheduled (as calculated from on the revive schedule parameters specified on this screen).
Revive every day / on selected days of the month/week | You can either select reviving to be performed every day or on certain days of the month or on certain week days: Revive every day: If you choose this option, reviving will be daily. Revive on selected days of the month: If you choose this option, a list of days (1 to 31) will be displayed, on which you select the desired date(s). For reviving on the last day of the month, you select "Last day". Revive on selected days of the week: If you choose this option, a list of week days (Monday to Sunday) will be displayed, on which you select the desired day(s).
Not before | Reviving will not be performed before the time specified here.
Every | You can specify a time interval here. For example, to perform reviving every 6 hours, you specify `06:00`.
Not after | Reviving will not be performed after the time specified here.
Calendar | If you select a calendar here, reviving is performed only on days defined as working days in that calendar, but not on days defined as holidays. See also Calendars.
Holiday rule | Should a reviving date fall on a calendar holiday, you can select either "Before holiday" or "After holiday" to perform it on the last working day before the holiday or the first working day after the holiday respectively.

## Automatic Cleanup Defaults

The cleanup parameters enable you to schedule automatic cleanup.

This section covers the following topics:

- Modifying Cleanup Defaults

- Displaying Cleanup Defaults

- Cleanup Parameters

### Modifying Cleanup Defaults

To modify the cleanup parameters:

1. Select the System Administration > Defaults > Cleanup node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Cleanup Parameters are displayed, and you can change them.

   The fields are described under Cleanup Parameters below.

4. Choose OK to save your changes.

### Displaying Cleanup Defaults

To display the cleanup parameters:

1. Select the System Administration > Defaults > Cleanup node in the object workspace.

2. Invoke the context menu and choose Display.

3. The cleanup defaults are displayed. The fields are described under Cleanup Parameters below.

4. Select Cancel to close the window.

### Cleanup Parameters

Field | Explanation
--- | ---
Cleanup Process
Spool cleanup | Select this option to activate automatic SPOOL cleanup. This automatically deletes SPOOL files and container-file entries no longer needed by Entire Output Management.
Report cleanup | Select this option to activate automatic report cleanup. This automatically deletes active reports with location SPOOL, if corresponding SPOOL file no longer exists because it was deleted outside Entire Output Management.
Cleanup Schedule
No cleanup schedule | No cleanup schedule is active.
Next run | Displays the date and time for which the next cleanup run is scheduled (as calculated from on the cleanup schedule parameters specified on this screen).
Cleanup every day / on selected days of the month/week | You can either select cleanup to be performed every day or on certain days of the month or on certain week days: Cleanup every day: If you choose this option, cleanup will be daily. Cleanup on selected days of the month: If you choose this option, a list of days (1 to 31) will be displayed, on which you select the desired date(s). For cleanup on the last day of the month, you select "Last day". Cleanup on selected days of the week: If you choose this option, a list of week days (Monday to Sunday) will be displayed, on which you select the desired day(s).
Not before | Cleanup will not be performed before the time specified here.
Every | You can specify a time interval here. For example, to perform cleanup every 6 hours, you specify `06:00`.
Not after | Cleanup will not be performed after the time specified here.
Calendar | If you select a calendar here, cleanup is performed only on days defined as working days in that calendar, but not on days defined as holidays. See also Calendars.
Holiday rule | Should a cleanup date fall on a calendar holiday, you can select either "Before holiday" or "After holiday" to perform it on the last working day before the holiday or the first working day after the holiday respectively.

## CA Spool Defaults

CA Spool Defaults are only available on mainframes.

CA Spool, among other spooling systems, can serve as source for the output data to be processed. Here you can define whether the CA Spool interface should be active or not.

Entire Output Management scans the specified destinations and moves the output into its own database container for further processing. The destinations to be scanned should be defined as virtual printers reserved for Entire Output Management. The destination is switched to the specified Temporary Destination (also a virtual printer) in order to avoid processing the same queue entry again.

This section covers the following topics:

- Modifying CA Spool Defaults

- Displaying CA Spool Defaults

- CA Spool Defaults

### Modifying CA Spool Defaults

To modify the CA Spool defaults:

1. Select the System Administration > Defaults > CA Spool node in the object workspace.

2. Invoke the context menu and choose Open.

3. The CA Spool Defaults are displayed, and you can change them.

   The fields are described under CA Spool Defaults below.

4. Choose OK to save your changes.

### Displaying CA Spool Defaults

To display the CA Spool defaults:

1. Select the System Administration > Defaults > CA Spool node in the object workspace.

2. Invoke the context menu and choose Display.

3. The CA Spool defaults are displayed. The fields are described under CA Spool Defaults below.

4. Select Cancel to close the window.

### CA Spool Defaults

Field | Explanation
--- | ---
Scan CA Spool queue | Activate the CA Spool interface? Enter `Y` (yes) or `N` (no).
CA Spool Interface Version | Specify your current interface version of CA Spool (for example, 90).
CA Spool Version (1/2) | Specify your current version of CA Spool. For versions earlier than 2.0, specify `1`. For other versions, specify `2`.
Temporary Destination | Specify a virtual CA Spool destination to which Entire Output Management routes the output to be processed.
Time Limit | Enter the maximum number of seconds the Monitor is allowed to scan for output arriving through the CA Spool interface in one cycle. A value of `0` means no limit.
Destination | Specify up to 20 destinations to be scanned by Entire Output Management.
DBID / FNR | Specify the database ID and file number of the corresponding Entire Output Management container file in which to store the created reports.

## Natural Advanced Facilities Defaults

Instead of printing output from Natural programs in the Natural Advanced Facilities spool file (FSPOOL), you can route it to an Entire Output Management file (SYS2), from which it can be distributed, bundled or separated.

Here you can define whether the NAF/NOM interface is active and from which Natural Advanced Facilities environments output is to be processed. A separate Entire Output Management container file can be assigned to each FSPOOL file. However, you can also assign the same Entire Output Management container file to all FSPOOL files.

This section covers the following topics:

- Modifying Natural Advanced Facilities Defaults

- Displaying Natural Advanced Facilities Defaults

- Natural Advanced Facilities Defaults

### Modifying Natural Advanced Facilities Defaults

To modify the Natural Advanced Facilities parameters:

1. Select the System Administration > Defaults > NAF node in the object workspace.

2. Invoke the context menu and choose Open.

3. The Natural Advanced Facilities Defaults are displayed, and you can change them.

   The fields are described under Natural Advanced Facilities Defaults below.

4. Choose OK to save your changes.

### Displaying Natural Advanced Facilities Defaults

To display the Natural Advanced Facilities parameters:

1. Select the System Administration > Defaults > NAF node in the object workspace.

2. Invoke the context menu and choose Display.

3. The Natural Advanced Facilities defaults are displayed. The fields are described under Natural Advanced Facilities Defaults below.

4. Select Cancel to close the window.

### Natural Advanced Facilities Defaults

Field | Explanation
--- | ---
NAF interface active | Process spool data from Natural Advanced Facilities? Enter Y (yes) or N (no).
Time limit | Enter the maximum number of seconds the Monitor is allowed to scan for output arriving through the Natural Advanced Facilities interface in one cycle. A value of `0` means no limit.
FSPOOL DBID / FNR | The database ID and file number as defined in the FSPOOL parameter.
Container DBID / FNR | The database ID and file number of the Entire Output Management container file. Output is filed to a database and is subject to the transaction logic of the database. Be sure to issue an ET as soon as possible. Be sure to regularly issue new ETs to prevent the Hold queue from overflowing (when there is a large amount of output).Remember that output from BTs is also affected. Be sure that no user transaction is open during an Adabas CLOSE or DEFINE PRINTER. For further information, see the section ET/BT Logic in the Natural Advanced Facilities documentation.

## Trigger Container File

Entire Output Management uses the trigger container file to process print data from various sources:

- Natural: Output files from Natural applications can be processed. In JES, these output files can belong to any output class. For more information, see the members `NOMTP`, `NOMTP--D`, `NOMTP--P` and `NOMSR--L` in the libraries `SYSNOMU` and `SYSNOMS` respectively. Please note that the API described as "NOM trigger processing" in these members is also used by Entire Operations.

- Remote mainframe nodes: If print data from remote mainframe nodes are to be processed, they are copied into the trigger container file. See also Node Definitions.

If the trigger container file is to be used for any of these purposes, it has to be defined and activated.

To define and activate the trigger container file:

- In the System Defaults, you specify:

  - DBID/FNR: The database ID and file number of the trigger container file.

  - Process trigger queue: Select this field to activate the processing of the print data queued in the trigger container file. Deselect it it to deactivate processing.

For the activation/deactivation to take effect, you have to restart the Monitor.

## User Exits

The user exits described below are located in the Natural library `SYSNOMS`.

This section covers the following topics:

- Activating/Deactivating User Exits

- Displaying the Activation Status of User Exits

- User Exit Descriptions

### Activating/Deactivating User Exits

To activate or deactivate a user exit:

1. Select the System Administration > Defaults > User Exits node in the object workspace.

2. Invoke the context menu and choose Open.

3. The User Exits screen is displayed, listing the available user exits.

   Their functions are described below.

4. To activate a user exit, select it. To deactivate a user exit, deselect it.

   Then choose OK to save your changes.

### Displaying the Activation Status of User Exits

To display the activation status of the user exits:

1. Select the System Administration > Defaults > User Exits node in the object workspace.

2. Invoke the context menu and choose Display.

3. The User Exits screen is displayed, showing which user exits are activated and which are not.

   Their functions are described below.

4. Select Cancel to close the window.

### User Exit Descriptions

User Exit | Explanation
--- | ---
NOMEX001 | This exit is called by the Entire Output Management Monitor while scanning the spool queue. A call to this function indicates that no report definition was found for the specified source and the spool exit 001 flag was set. The exit must set the "process" flag to `TRUE` to advise Entire Output Management to make the source as subject for its normal cleanup processing, or `FALSE` to advise it not to process this output. In this case, the exit must switch the output from the Entire Output Management input queue to prevent subsequent processing for the same output.
NOMEX002 | This exit is called by the Entire Output Management Monitor while scanning the spool queue. The function is called if the exit 002 flag is set to allow the modification of spool attributes before they are stored in the Entire Output Management database.
NOMEX003 | This exit is called by Entire Output Management to allow/disallow access to Natural NSPF.
NOMEX004 | This exit is called by Entire Output Management to allow suppression of log messages.
NOMEX005 | This exit is called by Entire Output Management to allow modification of print job substitution variables.
NOMEX006 | This exit is called by Entire Output Management to make available information about completed printouts.
NOMEX007 | This exit is called by the Entire Output Management user interface when certain fields are to be modified online. This exit may set initial values for the fields and prohibit modification.
NOMEX008 | This exit is called by Entire Output Management to allow the integration of user-written application logic with Entire Output Management, allowing the storing of notes for an active report or even for a specific line of an active report. The exit is invoked whenever the status of an active report changes. A documented example is provided in the library `SYSNOMS`. Please note that this example does not store any data permanently, it is only a template to show options.
NOMEX009 | This exit is called by Entire Output Management to suppress optimization for counting lines of BS2000 input files. Assuming Rename=N (BS2000 files will not be renamed): Normally, when a BS2000 file is printed more than once by Entire Output Management, Entire Output Management will count the records in the file only once and pass this record count on for further processing. This makes sense, because Entire Output Management assumes that the contents of the file do not change. Upon special customer request, this exit was created to allow suppression of this optimization. This means that for each print to Entire Output Management the same file is counted again, because the file can change its contents and length. In this case, the flag `NOMEX009-COUNT-OPTIMIZE` should be set to false. If renaming is deactivated, reports resulting from BS2000 input files with changing contents can lead to inconsistencies. To avoid these, such reports should be stored in the NOM database; that is, they should be defined with the general attribute Copy report content to NOM database.
NOMEX010 | This exit is called by Entire Output Management to receive or suppress a log message.
NOMEX011 | This exit is called by Entire Output Management immediately before a record is written to the required target (PC) and allows modification of browsed active report data as well as suppression and insertion of records. The object must be in a library accessible to the Entire Output Management online system. NOM221S contains a sample NOMEX011 as well as the parameter data area NOMEXP11. Output parameters for NOMEX011: `P-EXP-RC` - Return code: 0 = include record as is. 4 = include modified record (`P-EXP-RECORD`). 8 = insert `P-EXP-RECNO` lines from `P-EXP-INSERT-LINES` (next call to exit is with the same record). 12 = suppress record. 16 = terminate export with message `P-EXP-RT`. 99 = continue export without calling NOMEX011 again. `P-EXP-RT` - Error text for `P-EXP-RC` = 16. `P-EXP-RECNO` - Number of records to insert. `P-EXP-RECORD` - Modified record to be exported. `P-EXP-INSERT-LINES` - Up to 10 lines to be inserted. `P-EXP-WORK` - Work area for NOMEX011, maintained across calls.
NOMEX012 | Unused.
NOMEX013 | This user exit is called immediately before a report is opened. It will supply attributes of the active report to be opened, spool attributes, and the source attributes. Some fields can be changed and returned to Entire Output Management. For a description of what is to be tested, see the program source. Meta data can be associated with UNIX/Windows files (see also UNIX/Windows Identification Attributes in the User's Guide). These meta data are the properties of the print data. They are stored in the field `#SPOOL-ATTR-EXTENDED`.
NOMEX014 | This user exit is invoked by RMPRRP (print reports) and RMPRBU (print bundles) once at the start of a printout within the printer task to retrieve the properties of a printout - especially the extended attributes, which are stored in the field `#SPOOL-ATTR-EXTENDED`. On meta data, see also NOMEX013 above. For a description of the parameters for this user exit, see the source of NOMEX014. All parameters are input-only parameters and cannot be changed - exceptions: the fields `NOMEX014-ERROR-CODE` and `NOMEX014-ERROR-TEXT`. If an error code is set at return time, Entire Output Management will display it instead of starting the printout. If error code 5 is set, any user message can be displayed; all other error numbers will display the corresponding Entire Output Management error message with `NOMEX014-ERROR-TEXT` containing the parameters of the message.
UEX-HTML | This user exit is called by Entire Output Management during the loading of files on Linux to be able to deactivate HTML conversion. By default, HTML tags in the loaded files are converted. Note This user exit is always active when available. It cannot be activated/deactivated like the other user exits, as explained under Activating/Deactivating User Exits above.

## Default Code Pages

This function is used to specify the code pages which are to be available in Entire Output Management. The defined code pages can be used in report and node definitions.

To add/remove a code page:

1. Select the System Administration > Defaults > Code Pages node in the object workspace.

   The Default Code Pages screen is displayed, listing the code pages already available in Entire Output Management.

2. To add a code page, choose Select. A selection list of several commonly used code pages is displayed. Select one and choose OK.

   Or:
   On the Default Code Pages screen, enter the desired code-page name in the field below the list, and choose Add.

3. To remove a code page from the Default Code Pages, select it and choose Delete.

   If a code page is used by any report or node definition, it cannot be removed.

Any code-page name specified on the Default Code Pages screen is automatically checked for validity (using a Natural `MOVE ENCODED` statement).

For further information on code pages, see Unicode and Code Page Support in the Natural documentation.

## Node Definitions

This section covers the following topics:

- General Information on Nodes

- Listing Node Definitions

- Creating a New Node Definition

- Modifying a Node Definition

- Displaying a Node Definition

- Deleting a Node Definition

- Attributes of a Mainframe Node

- Attributes of a UNIX or Windows Node

### General Information on Nodes

The source of the print data processed by Entire Output Management can be either the same mainframe or UNIX environment in which Entire Output Management runs or any other supported mainframe, UNIX or Windows environment. Thus it is possible to transfer the output of any mainframe, UNIX or Windows application and process it with Entire Output Management.

The environment in which Entire Output Management runs is called local node. Any other environments are called remote nodes.

If you only process print data from the local node, you only have one node definition for the local node; this is created automatically by Entire Output Management. In addition, to process print data from remote nodes, you have to create a node definition for each remote node.

If the print data come from a remote UNIX node, the transfer of the data is done by EntireX. If they come from a remote mainframe node, the transfer of the data is done either by Entire System Server in conjunction with Entire Network or by Entire Systems Management Adapter (BS2000 only). Therefore the use of remote UNIX and Windows nodes requires that EntireX and Entire System Server on UNIX be installed, and use of remote mainframe nodes requires that either Entire System Server and Entire Network or Entire Systems Management Adapter (BS2000 only) be installed.

The print data from a remote mainframe node are copied into the trigger container file on the local node. Therefore this file has to be defined and its processing activated; see Trigger Container File.

#### Code Pages

The code page used on a remote node may be different from the one on the local node.

If the print data come from a remote UNIX node which uses a different code page, EntireX automatically converts the data to match the local code page.

If the print data come from a remote mainframe node which uses a different code page, Entire Output Management converts the data to match the local code page. This requires the following:

- The Natural profile parameters `CFICU` and `CP` have to be set for the Natural environment of the local node.

- In the node definition of the remote node, you have to specify the code page used on the remote node.

If a different code page is to be used for an individual report, you can specify this in the corresponding report definition.

For general information on code pages, see Unicode and Code Page Support in the Natural documentation.

#### Entire Operations

For Entire Output Management to be able to process Entire Operations data from remote nodes, Entire Operations has to be installed on the same local node as Entire Output Management.

### Listing Node Definitions

To list the nodes which are already defined:

1. Select the System Administration > Defaults > Node Definitions in the object workspace.

2. Invoke the context menu and choose List.

   A window is displayed listing all defined nodes.

### Creating a New Node Definition

To create a new node definition:

1. Select the Node Definitions folder in the object workspace and invoke the context menu.

2. Choose New.

   The New Node Definition window is displayed.

3. Select the type of node to be defined: Mainframe or UNIX.

   The New Node Definition window displays the available attributes for the selected node type.

   The fields are described under Attributes of a Mainframe Node or Attributes of a UNIX or Windows Node respectively.

4. Specify the attributes as desired, and choose OK to save the node definition.

### Modifying a Node Definition

To modify a node definition:

1. Select an instance of the System Administration > Defaults > Node Definitions in the object workspace.

2. Invoke the context menu and choose Open.

3. The Node Definition for the selected instance is displayed, and you can change it.

   The fields are described under Attributes of a Mainframe Node or Attributes of a UNIX or Windows Node respectively.

4. Choose OK to save your changes.

### Displaying a Node Definition

To display a node definition:

1. Select an instance of the System Administration > Defaults > Node Definitions in the object workspace.

2. Invoke the context menu and choose Display.

3. The node definition is displayed. The fields are described under Attributes of a Mainframe Node or Attributes of a UNIX or Windows Node respectively.

4. Select Cancel to close the window.

### Deleting a Node Definition

A node definition can only be deleted if it is not used by any report.

To delete a node definition:

1. Select an instance of the System Administration > Defaults > Node Definitions in the object workspace.

2. Invoke the context menu and choose Delete.

3. Confirm your choice.

### Attributes of a Mainframe Node

#### General Attributes

Field | Explanation
--- | ---
Node name | Specify the name of the node. This field is case-sensitive.
Node number | Specify the node number which identifies the Entire System Server node. If the node is in use by any reports, you can only change the node number to one with the same spool type.
Description | You can enter a short text description of the node.
Node status | The current status of the node. Possible values: Active: The node is scanned to get output to Entire Output Management. Deactivated: A logon to this node is not possible. Suspended: A logon to this node is currently not possible; it is reactivated by the Entire Output Management Monitor as soon as a logon is possible again. This status is set automatically and cannot be changed manually. Inactive: The node is inactive and has to be (re-)started. Error: A non-recoverable error occurred, and the node is not active. To reactivate it, you have to change the status manually. Monitor: This node is automatically defined during the installation. It is defined as environment for the Monitor, is never suspended, and its status cannot be changed. The Monitor attempts to log on to each node at each Monitor cycle. If a node cannot be accessed, the Monitor will write an error message to the Monitor log once, and set the node status to "Suspended". If the node is active again, a message will be written to the Monitor log that it has been reactivated, and file processing will start again. Set status: Depending on the current node status, you can set the status to "Active" or "Deactivated".
System | Displays the operating-system type and product name of the node.
ESY user ID | Specify the user ID used to log on to the target Entire System Server.
Code page | You can select the code page to be used by the node. A code page is required if the Spool type (see below) is different from that of the Monitor node. For the definition of code pages, see Default Code Pages.
Spool type | Possible spool types of a node are: SPOOL, JES2 and JES3. You can select the spool type depending on the spool system available in the node environment. As long as the node definition is used in any report definition, the spool type cannot be changed.

#### Spool Attributes

Field | Explanation
--- | ---
Spool Type SPOOL (BS2000)
Rename files | Select this option to rename files, or deselect it to not rename them. Entire Output Management renames the print files during processing by adding an internal ID to make them unique. If renaming is deactivated, the option Copy files (see below) must be selected to copy the source to a container file. To avoid inconsistencies with reports resulting from BS2000 input files with changing contents, they should be stored in the NOM database; that is, the reports should be defined with the general attribute Copy report content to NOM database.
Copy files | Select this option to copy BS2000 files to an Entire Output Management container file; or deselect it to not copy them. At least one destination has to be defined: for a local node, see Container Files; for a remote node, see Trigger Container File. When this option is active, the original BS2000 files will not be processed by Entire Output Management after being copied, in particular cleanup processing will not delete them.
Virtual printer | Enter the names of virtual printers (RSO) defined in BS2000. The printouts for this device are processed by Entire Output Management. (The printers must be virtual and must not be enabled for the spooling system). If the type of carriage control is not contained in the RECFORM attribute, the printout must be routed to the printer assigned to the corresponding carriage control. As of BS2000 spool version 3.0 B, exactly one virtual printer (not RSO), which can be addressed with the `PRINT-DOCUMENT` command, can be assigned to a BS2000 ID. In this case, enter *V in the recform field and leave the others empty.
Spool Type JES2
Spool classes | These fields are used to define the SYSOUT classes dedicated to Entire Output Management.
Sysout | Enter a list of SYSOUT classes to be processed by Entire Output Management. Only those jobs with SYSOUT files in these classes are processed.
Internal | Define one SYSOUT class to hold temporary SYSOUT files. This class must not be one of the classes defined in the Sysout field above.
Print | Enter the class in which reports and bundles are to be printed.
Error | Define one SYSOUT class to hold the SYSOUT files which cause an error during processing. This class must not be one of the classes defined in theSysout field above.
Spool Type JES3
Spool classes | The same as for JES2; see above.
Execution | Enter a list of execution classes to be processed by Entire Output Management. This method creates considerable performance overhead and should only be used for compatibility reasons. In future, only SYSOUT classes should be used for processing by Entire Output Management. However, if you still need this method during a transitional period: in addition to searching SYSOUT classes for output, execution classes can also be searched. In this case, the following limitations apply: no default definitions are checked for processing; messages that no report definition has been found for a certain SYSOUT file are not logged.

### Attributes of a UNIX or Windows Node

Field | Explanation
--- | ---
Node name | Enter the desired node name here. A node on a UNIX or Windows system is identified by its name, not by a node number. This name must be registered at a broker and entered in the member `SATSRV` of the library SYSSATU in a section like this:
    node_name SATSRV TYPE=ACI
              BROKER-ID=...
              SERVER-CLASS=NPR
              SERVER-NAME=...
              SERVICE=node_name
              USER-ID=...
              WAIT-TIME=30S
For details, see the Entire System Server Installation for UNIX documentation. This field is case-sensitive.
Node status | The current status of the node. Possible values: Active: The node is scanned to get output to Entire Output Management. Deactivated: A logon to this node is not possible. Suspended: A logon to this node is currently not possible; it is reactivated by the Monitor as soon as a logon is possible again. This status is set automatically and cannot be changed manually. Inactive: The node is inactive and has to be (re-)started. Error: A non-recoverable error occurred, and the node is not active. To reactivate it, you have to change the status manually. Monitor: The node is defined as environment for the Monitor, is never suspended, and invokes Entire System Server on UNIX via EntireX. Used on UNIX systems. Local monitor: The node is defined as Monitor, it invokes Entire System Server as a subprogram without using EntireX. Used on UNIX systems. If UNIX nodes are defined, the Entire Output Management Monitor will try to log on to each node at each Monitor cycle. If a node cannot be accessed, the Monitor will write an error message (`NOM2026`) to the Monitor log and set the node status to "Suspended". When the node is active again, a message will be written to the Monitor log that it has been reactivated, and file processing will start again. Set status: Depending on the current node status, you can set the status to "Active", "Deactivated" or "Local monitor".
Message after nnnn minutes | This field can be used to suppress the repeated display of the message `NOM2026` if the node cannot be accessed. If you leave this field empty, the message `NOM2026 (Node ... has been suspended)` is issued every time the node cannot be accessed. If you specify a time interval (number of minutes): the message `NOM2026` is issued only once within the specified time interval, and the message `NOM2071 (Node ... exceeded maximum suspended time)` will be issued once when the specified time interval has been exceeded.
Description | This field describes the node definition.
Temp. path | Enter a directory here where files are stored that could not be processed by Entire Output Management. This is done to keep the directories "clean" of non-processable files which would waste CPU time. A directory name must not contain wild characters, because it is used to identify file directories uniquely. The last character must be '/' (this is concatenated automatically), the back slash is not allowed. For Windows systems it will be created automatically. This field is case-sensitive.
User ID | Enter the user ID used on the target node to log on to the machine. Entire Output Management will get exactly the rights this user ID has on the specified node. This field is case-sensitive.
Password | Enter the password used on the target node to log on to the machine. It is stored and sent across the network in an encrypted format. This field is case-sensitive.
Confirm | As the password is entered without being displayed, you have to confirm your password typing it twice. This field is case-sensitive.
Group | On UNIX systems enter the group ID here, on Windows systems it is the domain name. Leave this field blank to get to the default group / domain. This field is case-sensitive.
Paths | Enter up to 10 default paths here. When creating a report, one of these paths must be selected for the report. A directory name must not contain wild characters, because it is used to identify file directories uniquely. The last character must be '/' (this is concatenated automatically), the back slash is not allowed. For Windows systems it will be created automatically. On Windows systems drive letters (e.g. 'C:/') will be recognized. These paths are owned by Entire Output Management. The Monitor will try to find reports for any of the files, copy them to the specified container file and create active reports. Then the file in the specified directory will be deleted. If no reports are found and no default report exists, the file will be moved to the directory specified in the 'Temp' field, a time stamp will be added, and Entire Output Management will forget about it. These fields are case-sensitive.
Container DBID /FNR | Specify the database ID and file number of the container file which is connected to this path. Only the first entry is mandatory, if the other lines are left empty, they will default to the first line.

## Email Message Definitions

This section covers the following topics:

- General Information on Email Message Definitions

- Attributes of an Email Message Definition

- Listing Email Message Definitions

- Creating a New Email Message Definition

- Modifying an Email Message Definition

- Displaying an Email Message Definition

- Deleting an Email Message Definition

### General Information on Email Message Definitions

With this function, you can define certain events which will trigger the sending of emails to specified email addresses. For each error situation, you can specify which text is to be sent by email and to whom. As trigger, you can use any message number issued by Natural or Entire Output Management. In this way, you can inform the appropriate persons whenever a certain error situation has occurred.

Note
On UNIX systems, the sending of these emails requires that the mail program `mutt` is available.

#### Emergency Emails

In the case of certain severe error situations, Entire Output Management will automatically send emergency emails. These are sent if one of the following errors occurs:

Message Number | Error
--- | ---
`NAT1222` | Memory allocation errors.
`NAT1801`, `NAT1804`, `NAT1806`
`NAT3001` to `NAT3255` | Database errors.
`NAT5751` | Memory allocation errors.
`NAT6104`
`NAT9969` | Escaped from error loop.
`NOM0136` | Warning during license check.
`NOM0137` | Error during license check.

Emergency emails are provided by Entire Output Management and are not user-modifiable. However, you can specify their recipients (in the Emergency emails field of the Monitor Defaults).

### Attributes of an Email Message Definition

Field | Explanation
--- | ---
Name | The name identifying the message definition.
Subject | The title to be used as subject of the sent email.
General
Email triggers | The error number(s) which trigger(s) the sending of the email. The email will be sent if any of these errors occurs. You can specify `NATnnnn` and `NOMnnnn` message numbers. If you specify multiple numbers, separate them from each other by a semicolon. You can use asterisk notation for the message numbers. Examples: If you specify `NAT3*`, any NAT message number from `3000` to `3999` will trigger the email. If you specify `NOM*`, any NOM message will trigger the email.
Check cycle (min.) | The time interval in which Entire Output Management checks if one of the errors specified as triggers has occurred. To begin with, it is recommended to use a time interval of 30 minutes. Depending on how many emails are actually sent, you may then decide to increase or decrease the time interval. To deactivate the email message definition, you set this field to `0`.
Email text library | The Natural library in which the text member is stored. Note The NOM monitor user needs access permission for this library, set in Natural Security.
Email text member | The Natural text member which contains the email text to be sent. If the text contains the string `&MESSAGES`, this will be replaced in the actual email by the message number which triggered the sending of the email. If the text contains the string `&LAST`, this will be replaced in the actual email by the time when the trigger check was performed last.
Email addressees
From / Sender name | On UNIX systems: You specify the mail address to be used as sender. On mainframes: The internal default email address provided by Entire System Server (SEND-MAIL) will be used as sender. In addition, you can specify a sender name, which will precede the sender address when the email is sent. The sender name must not contain quotation marks.
Reply to | The email address to which the recipients' replies are sent.
Recipients | The email addresses of the email's recipients (direct, CC or BCC). If you specify multiple addresses, separate them from each other by a semicolon.
Recipients CC
Recipients BCC
Depending on the character set used, the character `@` (at sign) may not be represented correctly in some environments. Therefore it should be specified within email addresses as `(a)`.
Test email
Start email test | Click to send a test email to all recipients.
Test result | Displays the test result (Success or Error) along with additional information.

### Listing Email Message Definitions

To list all existing email message definitions:

1. Select System Administration > Defaults > Email Messages in the object workspace.

2. Invoke the context menu and choose List.

   A list of all existing email message definitions is displayed.

### Creating a New Email Message Definition

To create a new email message definition:

1. Select the Email Messages folder in the in the object workspace, invoke the context menu, and choose New.

2. The New Email Message Definition window is displayed. Specify the attributes as desired.

   They are described under Attributes of an Email Message Definition.

3. Choose OK to save the definition.

### Modifying an Email Message Definition

To modify an email message definition:

1. Select an instance of the System Administration > Defaults > Email Messages in the object workspace.

2. Invoke the context menu and choose Open.

3. The Email Message Definition of the selected instance is displayed, and you can change it.

   The fields are described under Attributes of an Email Message Definition.

4. Choose OK to save you changes.

### Displaying an Email Message Definition

To display an email message definition:

1. Select an instance of the System Administration > Defaults > Email Messages in the object workspace.

2. Invoke the context menu and choose Display.

3. The Email Message Definition of the selected instance is displayed.

   The fields are described under Attributes of an Email Message Definition.

4. Select Cancel to close the window.

### Deleting an Email Message Definition

To delete an email message definition:

1. Select an instance of the System Administration > Defaults > Email Messages in the object workspace.

2. Invoke the context menu and choose Delete.

3. Confirm the deletion.

## 3GL Interface

- Control Block

- Data Field

- Work Area

- Transaction Logic

The 3GL interface is only available on mainframes.

The 3GL interface can transfer output line by line to Entire Output Management for further processing. The interface provides the functions OPEN, PUT, CLOSE. It consists of a control block, a data field and a work area. Several lists can be transferred to Entire Output Management at the same time, but each list must have its own control block and work area.

### Control Block

Field | Offset | Length | Explanation
--- | --- | --- | ---
Function code | 0 | 2 | Possible values: 1 = OPEN 2 = PUT 3 = CLOSE 5 = End transaction 6 = Backout transaction
Carriage control character | 2 | 2 | Possible values: 1 = ASA code 2 = IBM machine code 3 = Siemens EBCDIC code 4 = without carriage control character.
Interface description | 4 | 2 | Enter the number of the interface here which you have described in the 3GL Interface Defaults.
Return code | 6 | 4 | 0 or error code.
ET possible | 10 | 2 | Reserved for internal use.
ET/BT necessary | 12 | 2 | Needed only when the caller is controlling the transaction logic (when automatic ET > 0). 0 = No open transaction. 1 = Transaction open.
Report opened | 14 | 2 | Possible values: 0 = No OPEN has been performed for this control block. 1 = A report has been opened for this control block.
Execute ET | 16 | 2 | Reserved for internal use.
Automatic ET | 18 | 2 | Possible values: 0 = Transaction logic controlled by interface. >0 = Transaction logic controlled by caller.
Database number | 20 | 2 | Database ID of the container file.
File number | 22 | 2 | File ID of the container file.
Line length | 24 | 4 | Must be supplied for the PUT function so that it can provide the line length.
Defaults at OPEN | 28 | 2 | Possible values: 0 = Default values are not written to the control block fields at OPEN. 1 = Defaults are written to fields.
Debugging | 30 | 2 | Reserved for internal use.

### Data Field

Field | Offset | Length | Explanation
--- | --- | --- | ---
Data | 0 | 251 | Contains the spool attributes during an OPEN and the print lines during a PUT.

### Work Area

Field | Offset | Length | Explanation
--- | --- | --- | ---
Work area | 0 | 4096 | Only for internal use. The work area contains compressed output among other data.

### Transaction Logic

The print lines are stored in an Adabas database. Like any other changes to a database, the stored records must be confirmed (END TRANSACTION) or rejected (BACKOUT TRANSACTION). The transaction logic can either be executed automatically by the interface or can be determined by the caller.

Bytes 1 to 63 of the spool attributes must uniquely identify the print data.

#### Automatic ET

If the field "Automatic ET" is set to "0", the interface performs an ET in the following situations:

1. during processing of the OPEN;

2. during processing of the PUT, if n records have been stored in the database since the last confirmation (n = value of "Automatic ET");

3. during processing of the CLOSE.

It is recommended to always choose "1" as the value for "Automatic ET".

#### Transaction Logic Controlled by Caller

In addition to the OPEN, PUT, CLOSE functions, you must also perform the functions END TRANSACTION and BACKOUT TRANSACTION before calling Adabas with ET or BT. After the CLOSE you must always perform an Adabas ET call.

You should only use this option when you are performing other database changes in your program. In all other cases, you should only work with "Automatic ET".

## 3GL Interface Maintenance

3GL Interface Maintenance is only available on mainframes.

A 3GL interface, among others, can serve as source for the output data to be processed. OPEN, PUT and CLOSE transfer the list data to these 3GL interfaces

OPEN transfers the interface number+attributes (spool attributes) for identification and display purposes. PUT transfers one print line at a time. A CLOSE call tells the interface that the list is complete. An entry is created for processing of the list. For further details, see the section 3GL Interface.

The 3GL maintenance functions enable you to describe your own interface. The data entered are used to interpret the spool attributes and also to dynamically generate the Report Definition > 3GL Identification and Active Reports > Spool Attributes screens.

### Listing All 3GL Interfaces Defaults

To list all 3GL interfaces:

1. Select the System Administration > Defaults > 3GL Interfaces node in the object workspace.

2. Invoke the context menu and choose List.

   A window listing all user-defined interfaces is displayed.

### Creating New 3GL Interface Defaults

To create new 3GL interface defaults:

1. Select the 3GL Interface folder in the object workspace.

2. Invoke the context menu and choose New.

3. The New 3GL Interface Defaults window is displayed in the content pane, and you can enter data. The fields are described under 3GL Interface Defaults.

4. Choose OK to save your data.

### Modifying 3GL Interface Defaults

To modify 3GL Interface defaults:

1. Select an instance of the System Administration > Defaults > 3GL Interface node in the object workspace.

2. Invoke the context menu and choose Open.

3. The 3GL Interface Defaults for the selected instance are displayed, and you can change them.

   The fields are described under 3GL Interface Defaults.

4. Choose OK to save your changes.

### Displaying 3GL Interface Defaults

To display 3GL Interface defaults:

1. Select an instance of the System Administration > Defaults > 3GL Interface node in the object workspace.

2. Invoke the context menu and choose Display.

3. The 3GL Interface defaults are displayed. The fields are described under 3GL Interface Defaults.

4. Select Cancel to close the window.

### Deleting 3GL Interface Defaults

To delete 3GL Interface defaults:

1. Select an instance of the System Administration > Defaults > 3GL Interface node in the object workspace.

2. Invoke the context menu and choose Delete.

3. Confirm your choice.

### 3GL Interface Defaults

Field | Explanation
--- | ---
3GL Interface nnn
active | Enter "Y" to activate this interface. For the Monitor to begin scanning for output arriving through this interface, you must bring it down and back up again.
Time Limit | Enter the maximum number of seconds the Monitor is allowed to scan for output arriving through the 3GL interface in one cycle. "0" means no limit.
Description | Enter a short description of the interface being defined.
NOM Container File
DBID, FNR | Enter the database ID and file number of the Adabas file to be used as spool container.
Identifying Attributes
Prompt | Enter the four-digit number (library SYSNOMU) in SYSERR of the field prompt. This text is used in the report definition to describe the identifying attributes. It will also be used in the display of spool attributes of an active report.
Offset | Enter the offset in spool attributes parameter. The value of the specific attribute will be extracted from this offset in the given length.
Length | Enter the length in spool attributes parameter. The value of the specific attribute will be extracted from the specified offset in the given length.
Order | Enter a number from 1 to 4 to specify the order in which the primary identification attributes will be evaluated.
Generic (*) | Enter "Y" if this attribute is to be used generically for report identification. Note that only one attribute can be used in this way.
File Identification

#### Example

In the 3GL interface 104 during OPEN, the user ID is in bytes 1 to 8, the terminal ID in bytes 9 to 16, the program name in bytes 17 to 24 and the list name for post selection in bytes 33 to 40.

The prompts User ID, Terminal ID, Program and List Name were stored via SYSERR in the texts of numbers 1040, 1041, 1042, 1043 in the library SYSNOMU. When 3GL interface 104 is selected for report identification, a screen like the 3GL Interface Defaults screen is displayed.

### On this page

- System Defaults
- Monitor Defaults
- Report Defaults
- Bundle Defaults
- Automatic Archiving Defaults
- User-Defined Archives
- Automatic Reviving Defaults
- Automatic Cleanup Defaults
- CA Spool Defaults
- Natural Advanced Facilities Defaults
- Trigger Container File
- User Exits
- Default Code Pages
- Node Definitions
- Email Message Definitions
- 3GL Interface
- 3GL Interface Maintenance