SLS Application Guide

This part contains information about SMF operations including system backups, standby archiving, and restoring data.

Introduction to Storage Library System for OpenVMS

Backup Copy of Data

The purpose of a backup copy is to be able to recover data after unexpected loss, including:

• Equipment failure
• Human error
• Site catastrophe

Your data safety policy must accommodate disaster recovery. It is important to quickly retrieve damaged or missing information to minimize your organization's down time.

Frequency of backup:

Backup copies typically occur in cycles. They are created periodically and lose importance after some number of periods have passed.

Example:

An organization might make backup copies of user data every week and discard a saved copy when it becomes five weeks old.

Archive Copy of Data

The purpose of an archive copy is business oriented. An archive copy is made to preserve data to satisfy business requirements.

Frequency of archive:

Archive copies are typically created at the close of a business-related event or process. After the archive copy is made, the original information may be deleted or retained for read-only access. Archive copies are typically kept forever, unless they are explicitly deleted by the storage administrator.

Because archive copies are not frequently accessed, nearline or offline storage is suitable for archived data.

Examples:

• An organization might make archive copies of its yearly payroll account and retain them for 15 years to satisfy a government requirement.
• An organization might make archive copies of inactive project data to make more online storage space available.
• A business may make an archive copy of software at each stage of development. The archive copy is then removed to an off-site storage vault.

Defining Data Safety Policy

The storage administrator decides which data to move from online to nearline and offline storage. This decision needs to maximize resource efficiency without sacrificing the ability to restore lost data.

To define the data safety policy, consider the following:

• Which data has to be copied
• The purpose for copying the data
• How often and at what time the data is to be copied
• The class of storage best suited for the data
• The likelihood of its need
• Operational staff support

Policy Implementation and Administration

SLS software allows you to implement decisions about saving and restoring data. The storage administrator is responsible for reviewing and responding to the needs for saving and restoring data as they change.

Ongoing policy administration includes responding to changes in:

• The data to be saved
• Computing available storage resources for the movement of data to nearline or offline storage
• The personnel assigned to the media management tasks

SLS Administrator Menu

Operator Menu

User Menu

3.1.1.1 Server Software

SLS server software gives users access to the full functionality of SLS software. SLS provides this access at the node or OpenVMScluster system where the SLS software is executing.

SLS server software manages the:

• Media database--A set of RMS files that describe all removable storage media known to SLS software. These files are part of the Media and Device Management Services for OpenVMS (MDMS) portion of the SLS product. For detailed information about the MDMS databases, see the Media and Device Management Services for OpenVMS Guide to Operations.
  
  A node or OpenVMScluster system executing SLS server software provides media management services both for itself and for any client nodes connected to it. The media database contains information about volume names, locations, magazines, tape jukeboxes, and pool access authorization.
• SLS history files--Information is recorded at the local node about user files backed up or archived under SLS control.

3.1.1.2 Client Software

SLS client software:

• Provides backup scheduling and archiving services for the node or OpenVMScluster system on which it is executing
• Acts as a client of another node executing SLS server software when it requires media management services
• Provides users with full functionality when a node or OpenVMScluster system executing SLS client software is communicating with another node or OpenVMScluster system executing SLS server software

Similar to the SLS server software, SLS client software also maintains historyfiles in which it records information about user files backed up or archived locally under its control.

The node executing SLS client software communicates using DECnet software to a server node running SLS server software. The server node maintains the media database.

SLS Server and Client Processes

1 The SLS client node. This node runs the client process only. At this node, data is copied to the local device for safekeeping and statutory requirements.

2 The SLS server node. This node executes both the SLS server and client processes. At this node, the SLS server process maintains the volume and magazine databases.

3 The volume and magazine databases. These databases maintain records of media used for operations at both the server and client nodes.

Two-Node SLS Client-Server Process

1 This node (VOLKS1) executes the standby SLS server process. Its SLS client process communicates with the active SLS server process on node VOLKS2. In the event of a failure of the active SLS server process on VOLKS2, VOLKS1 would become the active server node.

2 This node (VOLKS2) executes the active SLS server process. In the event of a failure of the SLS server process on this node, VOLKS1 would become the active server node.

3 The SLS databases are maintained on a VAX Volume Shadow set. The SLS volume database maintains information about volumes created in this OpenVMS Cluster system.

4 The devices are available for backing up or archiving data from the OpenVMS Cluster system.

See Three-Node SLS Client-Server Process describes a three-node configuration that includes a two-node OpenVMS Cluster system and an additional node connected to the OpenVMS Cluster system. The third node in this diagram is not part of the OpenVMS Cluster system and is connected either through a wide-area DECnet connection or a mixed-interconnect OpenVMS Cluster system connection.

Three-Node SLS Client-Server Process

1 This node (VOLKS1) executes the standby SLS server process. Its SLS client process communicates with the active SLS server process on node VOLKS2. In the event of a failure of the active SLS server process on VOLKS2, VOLKS1 would become the active server node.

2 This node (VOLKS2) executes the active SLS server process. In the event of a failure of the SLS server process on this node, VOLKS1 would become the active server node.

3 The SLS databases are maintained on a VAX Volume Shadow set. The SLS volume database maintains information about volumes created in this OpenVMS Cluster system.

4 The devices are available for backing up or archiving data from the OpenVMS Cluster system.

5 This node (MERKUR) is connected to the OpenVMS Cluster system by DECnet communications software. Only the SLS client process is required to run on node MERKUR. When a request is made from the SLS client process on MERKUR, a connection request is first made of the OpenVMS Cluster system alias name (WAGON). Next, the connection to the active SLS server process is made so the request can be served.

6 The information about the data copied and the volumes used for the backup operation is maintained in the SLS volume database, located on the OpenVMS Cluster system.

See Three-Node SLS Client-Server Process describes a five-node configuration that includes a three-node OpenVMS Cluster system plus an additional node connected to the OpenVMS Cluster system. This examples includes characteristics that apply to any configuration in which data is stored on a MSCP-served devices and RSM devices.

Five-Node SLS Client-Server Process

1 This node (VOLKS1) executes the standby SLS server process. Its SLS client process communicates with the active SLS server process on node VOLKS2. In the event of a failure of the active SLS server process on VOLKS2, VOLKS1 would become the active server node.

2 This node (VOLKS2) executes the active SLS server process. In the event of a failure of the SLS server process on this node, VOLKS1 would become the active server node.

3 The SLS databases are maintained on a VAX Volume Shadow set. The SLS volume database maintains information about volumes created in this OpenVMS Cluster system.

4 The devices are available for backing up or archiving data from the OpenVMS Cluster system. These devices can also be used for saving data from the DFS-served system (STEEND) and the MSCP-served device on VOLKS3.

5 The devices are available for backing up or archiving data from the OpenVMS Cluster system.

6 This node (MERKUR) is connected to the OpenVMS Cluster system by DECnet communications software. Only the SLS client process is required to run on node MERKUR. When a request is made from the SLS client process on MERKUR, a connection request is first made of the OpenVMS Cluster system alias name (WAGON). Next, the connection to the active SLS server process is made so the request can be served.

7 The information about volumes is maintained in the SLS volume database, located on the OpenVMS Cluster system.

8 The node VOLKS3 maintains data on a device that is MSCP-served to the OpenVMS Cluster system (WAGON). Data stored on the device connected to this node can be backed up onto the devices in the WAGON system.

9 The node STEEND maintains data that is DFS-served from the OpenVMS Cluster system (WAGON). Data stored on the device connected to this node can be copied onto media on the devices in the WAGON system.

Naming Your SLS System History File Sets

Assign your SLS system history set name to a HISNAM_n symbol. For each SLS history set name, assign one symbol beginning with HISNAM_1, continuing with HISNAM_2, and

HISNAM_3, for all assignments made.

Required assignment:

For each HISNAM_n symbol assignment, there must be a corresponding HISDIR_n symbol assignment.

Maximum number of history file sets:

There is an absolute maximum of 124 SLS system history file sets that can be maintained. However, the combined length of all SLS system history set names, separated by commas, must not exceed 980 characters.

Defining SLS System History File Set Directories

Assign a HISDIR_n symbol to your SLS system history file set directory. For each file set name, assign one symbol beginning with HISDIR_1, continuing with HISDIR_2, and HISDIR_3, for all assignments made.

Required assignment:

For each HISDIR_n symbol assignment, there must be a corresponding HISNAM_n symbol assignment.

Rules for SLS System History File Set Names and Directories

These rules apply to the specification of SLS system history file set names and directories:

• The HISDIR_n symbol must consist of a device and directory specification.
• The directory assigned HISDIR_n must be enabled for World Read access.
• Each SLS system history set must be kept in a separate directory.
• If the SLS system history files are to be spread over many directories, the HISDIR_n symbol may be assigned a logical name search list of the directories.

Example: SLS System History File Assignments

The following example shows SLS system history file set name and directory assignments.

Single assignment:

If you have a SLS system history set for image backup operations on a disk named LARGE_DISK_1, you could assign the following:

$ HISNAM_1 := FULL

$ HISDIR_1 := LARGE_DISK_1:[SYSBAK.FULL]

Characterizing SLS System History Files

Each SLS system history file requires an SBATTR.COM file to characterize the amount of historical information that will be maintained. Refer to See Operator's Responsibilities for more information.

Determining the Space Required for SLS System History File Sets

You determine the amount of space required in the SLS system history file for each file saved with the SBATTR.COM command file. Consider the following items:

• The number of records per file saved
• The maximum size of the file name stored
• The maximum number of SLS system history files saved for each file
• Whether or not the node name is stored

Important:

Do not delete any files in the SLS system history file directory, and do not edit any file other than SBATTR.COM.

History Records for Individual File Versions

You choose to maintain records for multiple versions or the most recent version of files saved by assigning either of the allowable values from See Values for SEPARATE_VERSION.

Declaring the Maximum File Name Size

SLS uses the value assigned to the FILENAME_SIZE symbol as a key to determine the length of the file name stored in the SLS system history files.

Depending on the length of the key, the file name can include:

• Node name without the double colon (::)
• Device name without the single colon (:)
• Directory, excluding the root directory
• File name and type, but not the version

Considerations/Recommendations:

The storage administrator determines the length of the file name. Consider the following when making this decision:

• If directory structures contain many levels, assign a large value. When processing, the SBATTR.COM file adds four characters to the primary key. Because the SBATTR.COM file adds four characters to the primary key, you can define a maximum value of 251 for the FILENAME_SIZE symbol.

Keep in mind that larger values consume more storage space.

• If directory structures do not contain may levels, assign a smaller value.

The default value of 124 is recommended. Assigning a smaller value creates the potential for file names that are not unique.

Example:

$ FILENAME_SIZE == 124

Declaring the Maximum Number of SLS System History Pointers Per File

If more than one copy of the same file is saved, the SLS system history file keeps track (with the use of pointers) of each separate volume on which a copy of the file resides.

The POINTERS symbol determines the number of versions SLS retains for each file. Once the number of pointers is exceeded, SLS overwrites the oldest version of the file.

Default:

The following example shows the default value for POINTERS.

$ POINTERS == 4

Changing values:

Once you establish a number of pointers for your particular SLS system history file, you can change them only through a conversion process. Otherwise, changing the pointers to a lower or higher value causes errors.

Follow the steps in See How to Change Pointer Values to increase or decrease pointer values. To illustrate how this works, consider the following example:

Example:

Two history sets defined in SYS$MANAGER:TAPESTART.COM:

$ HISNAM_1 := GENERIC

$ HISDIR_1 := SLS$ROOT:[HIST]

$ HISNAM_2 := MY_HIST

$ HISDIR_2 := SLS$ROOT:[HIST.MY_HIST]

The history set MY_HIST was created with the default POINTERS value of 4. Now, there is a need for 8 pointers.

Choosing to Store the Node Name in the Files File

Choose whether to save the node name in the Files file by assigning one of the allowable values to NULL_NODE from See Values for NULL_NODE.

Requirements for Transferring Files

Information can be entered into an SLS history file about existing backup files, if the volumes:

• Were written with the DCL BACKUP command and the command line was not greater than 512 bytes
• Were entered into the volume database, are allocated, and are in the proper sequence (for example, when you type STORAGE REPORT VOLUME the list of volumes is in the proper sequence)
• Included the density attribute in the database that reflects the density of the tape

Adding Existing Backup Files to the SLS Catalog

There are two methods to use for transferring existing backup files to SLS history files.

• IF you do not have a listing of old volumes available, THEN use method 1.
• ELSE use method 2.

Method 1:

Choose the one of the commands shown in See Transferring Existing Backup Files if no Listing Available:

Method 2:

Enter the following command:

$ SUBMIT/USER=SLS SLS$SYSTEM:SYSREADLIST.COM/-

_$ PARAMETER=(listing_file,first_reel,history_set)

Where:

Considerations for User History Files

Consider using the same amount of storage space for SLS user history files as you did for the SLS system backup history files.

The logical name SLS$USRBAK located in the file named SLS$PARAMS:ASNUSRBAK.COM, defines the location of the SLS user history file in the user's process logical name table. This command file executes when each user logs in.

To create and update SLS user history files, you must use one of the following methods:

• Save the files with the Save Screen of the Operator or User Menu (See Performing User Save Operations.)
• Enter the STORAGE SAVE command with the /RECORD qualifier (Storage Library System for OpenVMS Command Reference Guide)

How to Determine the SLS User History File Location

See Values for SLS$USRBAK Logical describes the values allowed for the SLS$USRBAK logical in SLS$PARAMS:ASNUSRBAK.COM. This value determines the location of the SLS user history files.

Cleaning SLS System History Files

SYSCLN is a procedure that cleans up old entries in the SLS history files by:

• Deleting old null pointers that point to freed volumes
• Performing RMS conversion on the data files

The result is more efficient file access and the conservation of disk space.

The SYSCLN and CLEANUP Relationship

SYSCLN can be started by CLEANUP on any day beginning at the time indicated in the CLEANUP_Q assignment. SYSCLN stops after the assigned number of hours have passed for the given day. The next time SYSCLN is started by CLEANUP, it starts cleaning from where it stopped.

Controlling the Cleanup Process

The assignments to the CLEANUP_Q symbol specify the name of the batch queue that will run the CLEANUP process and the time of day the CLEANUP process will be run.

Allowed qualifiers: You can include any of the allowed qualifiers for the DCL SUBMIT command as part of the CLEANUP_Q assignment.

Restrictions: This table shows restrictions, reasons, and recommendations for the assignments to CLEANUP_Q.

Setting the Days and Durations for Cleaning SLS History Files

Assign the days and durations which the SYSCLN process is permitted to run to the SYSCLN_RUN symbol.

The CLEANUP_Q default assignment selects the normal SLS batch queue and sets the time to run at 3:00 a.m. The default assignment is:

CLEANUP_Q := 'F$EXTRACT(0,F$LOCATE("/",BATN),BATN)'/AFTER=03:00

Example:

This example shows the CLEANUP_Q assignment and explains the SYSCLN_RUN assignments.

$ CLEANUP_Q := 'F$EXTRACT(0,F$LOCATE("/",BATN),BATN)'/AFTER=04:00

$ SYSCLN_RUN := WED=03,FRI=03,SAT=51

• On Wednesdays, SYSCLN starts at 04:00 and runs for three hours.
• On Fridays, SYSCLN starts at 04:00 and runs for three hours.
• On Saturdays, SYSCLN starts at 04:00 and runs for a maximum of 51 hours.

Rule:

Use only the three letter abbreviation for the name of the day.

SYSCLN Menu Diagram

See SYSCLN Menu shows the options available on the SYSCLN Menu.

SYSCLN Menu

Menu Options

See SYSCLN Menu Options Descriptions describes the SYSCLN Menu options.

Start SYSCLN Processing

Description

The Start SYSCLN Process option displays a screen that enables you to manually start the SYSCLN process.

Start SYSCLN Processing Screen Diagram

See Start SYSCLN Processing Screen illustrates the Start SYSCLN Processing screen.

Start SYSCLN Processing Screen

 

Procedure

Perform the steps described in See Start SYSCLN Processing to use the Start SYSCLN Processing menu option.

 

Start SYSCLN Processing

Step	Action
1	Enter 14 from the Operator Menu and press Return. Result: The software displays the SYSCLN Menu.
2	Enter 1 from the SYSCLN Menu and press Return. Result: The software displays the Starting SYSCLN Processing screen. The software displays the following message: Reply received on node_name from user SLS at node_name Batch hh:mm:ss SYSCLN job started If the previous SYSCLN job was terminated before it completed, the software asks if you want to start cleaning from the beginning of the system history file sets or from where the last job ended. The default [Y] starts the clean from the beginning. If you want to choose the default, press Return, otherwise, enter N.
3	Press Return to exit the screen.

Shutdown SYSCLN Processing

Description

The Shutdown SYSCLN Processing option displays a screen that enables you to shutdown the current SYSCLN process.

Shutdown SYSCLN Processing screen diagram

See Shutdown SYSCLN Processing screen illustrates the Shutdown SYSCLN Processing screen.

Shutdown SYSCLN Processing screen

 

Procedure

Perform the steps described in See Shutdown SYSCLN Processing to use the Shutdown SYSCLN Processing menu option.

 

Shutdown SYSCLN Processing

Step	Action
1	Enter 14 from the Operator Menu and press Return. Result: The software displays the SYSCLN Menu.
2	Enter 2 from the SYSCLN Menu and press Return. Result: IF SYSCLN is currently active, THEN the software displays the Shutdown SYSCLN Processing Menu and displays the following message: Reply received on node_name from user SLS at node_name Batch hh:mm:ss SYSCLN flagged for termination at dd-mmm-yyyyhh:mm:ss.cc ELSE (SYSCLN is currently inactive), the software displays a screen to inform you that SYSCLN is not running.
3	Press Return to exit the screen.

Inquire SYSCLN Status

Description

The Inquire SYSCLN Status option allows you to display the current time and status of the SYSCLN process.

Procedure

Perform the steps shown in See Inquire SYSCLN status to use the Inquire SYSCLN Status option.

Abort SYSCLN Processing

Description

The Abort SYSCLN Processing option displays a screen that allows you to abort the currently running SYSCLN job.

Procedure

Perform the steps described in See Abort SYSCLN Process to use the Abort SYSCLN Processing menu option.

Delete User Histories Screen Diagram

Delete User Histories Screen Diagram

See Delete User Histories Screen Diagram illustrates the Delete User Histories screen.

Procedure

Perform the steps described in See Delete User Histories to use the Delete User Histories menu option.

Requirement:

This screen requires input. Pressing Return without entering any data displays the prompt "Press Return to continue". Pressing the Return key again brings you back to the main menu without submitting the batch job.

1-30 SLS Catalog Safety and Maintenance

Configuring SLS System Backup Operations

This chapter explains how to configure various symbols for your system backup operations. It includes the following topics:

• A description of system backup operations
• An introduction to system backup command files
• Information about defining scheduling parameters for system backup operations
• Information about defining the system backup operation
• A list of files created during a system backup operation

SYSBAK.TEMPLATE

$!

$! SYSBAK.TEMPLATE SLS V2.2

$!

$!

$! COPYRIGHT (c) Helett-Packard Development Company, L.P 2004

$!

$!

$! This file contains parameters to run a system backup.

$!

$! -------------------------------------------------------------------------

$! Automatic Scheduling Parameters

$!

$! DAYS_1 :==

$! TIME_1 :==

$! NODE_1 :==

$!

$! DAYS_2 :==

$! TIME_2 :==

$! NODE_2 :==

$!

$! DAYS_3 :==

$! TIME_3 :==

$! NODE_3 :==

$!

$! -------------------------------------------------------------------------

$! Disk File Selection Parameters

$!

$ FILES_1 :== SYS$SYSDISK:

$!

$! Backup Type Definition Parameter for this file only

$!

$! QUALIFIERS_1 :==

$!

$ PROGRESS == 1000

$!

$! -------------------------------------------------------------------------

$! Default Backup Type Definition Parameter

$!

$ QUALIFIERS :== /RECO/IGNO=INTE/VERI

$!

$! -------------------------------------------------------------------------

$! Backup privileges

$!

$ PRIVS :== BYPASS

$!

$! -------------------------------------------------------------------------

$! Saveset Name Generation Parameter

$!

$ SAVESET_GEN == "F$EXTRACT(0,15,DO_DISK) + "".BAK"""

$!

$! -------------------------------------------------------------------------

$! Online History Parameters

$!

$ HISTORY_SET :== DAILY

$ SBUPDT_Q :== SYS$BATCH

$!

$! -------------------------------------------------------------------------

$! Listing File Parameters

$!

$ LISTING_GEN == """SLS$SYSBAK:"" + F$EXTRACT(0,15,P1) + NODE + F$EXTRACT(0,15,DO_DISK)"

$

$ FULL :== 0

$ PRINT_Q :== SYS$PRINT ! /DELE

$!

$! -------------------------------------------------------------------------

$! Reel Selection Parameters

$!

$ MEDIA_TYPE :== 9TRACK

$ PREALLOC == 0

$ AUTOSEL == 1

$ TAPE_POOL :== 'HISTORY_SET'

$ REEL_SIZE == 2400

$ NOTES :== SYSTEM BACKUP

$ CONTINUE :==

$ CONTLOADOPT == 2

$!

$! -------------------------------------------------------------------------

$! Reel Retention Parameters

$!

$ SCRATCH_DAYS :== 60

$ OFFSITE_DATE :==

$ ONSITE_DATE :==

$!

$! -------------------------------------------------------------------------

$! Reel / Saveset Protection Parameter

$!

$ PROTECTION :== S:RW,O:RW,G:R,W:R

$!

$! -------------------------------------------------------------------------

$! Tape Drive Selection Parameters

$!

$ N_DRIVES == 1

$ DENSITY :== 6250

$ DRIVE_TYPE :==

$!

$! -------------------------------------------------------------------------

$! Volume Mount Parameters

$!

$ @SLS$DATAC:MNTDEF MNT$M_READCHECK MNT$M_MESSAGE -

MNT$M_WRITECHECK MNT$M_TAPE_DATA_WRITE

$ MNTFLAGS == MNT$M_MESSAGE .OR. MNT$M_TAPE_DATA_WRITE

$

$ QUICKLOAD == 0

$!

$! -------------------------------------------------------------------------

$! Status Mail Parameter

$!

$ STATUS_MAIL :==

$!

$! ----------------------------------------------------------------------------------------------------------------

$! Backup Job Chain Parameter

$!

$ NEXT_JOB :==

$!

$! -------------------------------------------------------------------------

$! User Message Parameter

$!

$ REPLY_MSG :== REQUEST/TO=(TAPES)

$!

$! -------------------------------------------------------------------------

$! Tape Label Parameter

$!

$ TAPE_LABELS == 2

$!

$! -------------------------------------------------------------------------

$! Batch Log File Parameter

$!

$ LOG_FILE :== !/[NO]PRINT/[NO]KEEP

$!

$! -------------------------------------------------------------------------

$! Summary File Generation

$!

$ SUMMARY_FILE == 2

$!

$! -------------------------------------------------------------------------

$! Pre- & Post- Processing DCL Commands

$!

$! PRE_PROCESS_FIRST :==

$! PRE_PROCESS_EACH :==

$! POST_PROCESS_EACH :==

$! POST_PROCESS_LAST :==

$EXIT

For detailed instructions about creating system backup command files for system backup operations, see See Symbols for System Backup Control.

Running Manual Backup Operations

For a manual system backup operation, define the symbols in the system backup command file to reflect the characteristics of your required system backup operation. You are not required to make assignments to the scheduling symbols (DAYS_n, TIME_n, and NODE_n) for a manually executed system backup command file.

Enter the following command to manually execute a system backup command file:

$ STORAGE STARTUP SYSTEM_BACKUP filename_SBK.COM

Running Automatically Scheduled Backup Operations

There are three symbols that control the automatic scheduling of system backup operations:

• DAYS_n
• TIME_n
• NODE_n

Making assignments to each of these symbols defines the day, time, and node on which the system backup operation will run. Make more than one set of scheduling assignments to execute the same operation on different days.

How the automatic schedule works:

The following table describes how the automatically scheduled system backup operation occurs.

Symbols for Automatic Scheduling

You may specify as many DAYS_n, TIME_n and NODE_n triplets as you need for any system backup operation. SLS software uses the triplet of the first DAYS_n symbol that matches the current day.

Rule:

You may specify as many triplets as needed, but they must be numbered sequentially, beginning at the number one.

Specifying a Day of the Week

To specify a day of the week for automatic scheduling, use the name of the day in the assignment.

Allowable assignments:

For the day of the week, use:

• MONDAY
• TUESDAY
• WEDNESDAY
• THURSDAY
• FRIDAY
• SATURDAY
• SUNDAY

Restriction:

Do not abbreviate the name of the day.

Example: Volume usage report

To automatically schedule a volume usage report for each Tuesday, assign:

$ DAYS :== TUESDAY

Multiple assignments:

Multiple assignments are allowed when separated by commas.

Example: System backup operation:

To automatically schedule a system backup operation for Monday and Friday, assign to the DAYS_n symbol:

$ DAYS_1 :== MONDAY,FRIDAY

Specifying a Day Offset into a Month

There might be a need to automatically schedule a process for the third day of the month, or two days before the end of the month.

Format:

The format of this assignment is:

MONTH direction offset

Where:

• direction is a:
• Plus sign (+) to indicate days from the beginning of the month
• Minus sign (-) to indicate days from the end of the month
• offset is the number of days

Example: From the beginning of the month:

If you want to schedule generation of a volume usage report for the fourth day of the month, assign:

$ DAYS :== MONTH + 4

Example: From the end of the month:

If you want to schedule a system backup operation for the last day of the month, assign:

$ DAYS_1 :== MONTH - 1

Specifying a Week Offset into a Month

There might be a need to automatically schedule a process for the second Sunday of the month, or the next to last Tuesday of the month.

Format

The format of this assignment is:

MONTH direction week_offset * day_of_week

Where:

• direction is a:
• Plus sign (+) to indicate days from the beginning of the month
• Minus sign (-) to indicate days from the end of the month
• week_offset is the nth week occurrence
• day_of_week is any day of the week

Week Offset Assignments

Example: From the beginning of the month:

If you want to schedule generation of a volume usage report for the second Sunday of the month, assign:

$ DAYS :== MONTH + 2 * SUNDAY

Example: From the end of the month:

If you want to schedule a system backup operation for the next to last Thursday of the month, assign:

$ DAYS_1 :== MONTH - 2 * THURSDAY

Day Offset from a Week Offset

Example: Day offset from a week offset:

If you want to schedule a system backup operation or generation of a volume report on the day before the third Saturday, or two days after the first Wednesday, you can add a day offset to the week offset assignment described in Week Offset Assignments.

Example: Specify days before:

If you want schedule a system backup operation two days after the first Wednesday, assign:

$ DAYS_1 :== MONTH + 1 * WEDNESDAY + 2

Example: Specify days after:

If you want to schedule generation of a volume report on the day before the third Saturday, assign:

$ DAYS :== MONTH + 3 * SATURDAY - 1

Specifying the Days to Run System Backup Operations

Examine See How to specify the days to run system backup operations to determine how to specify the days to run system backup operations.

More information:

Refer to See How to Define Automatic Scheduling Days for more detailed information on specifying days for automatic scheduling.

Specifying the Time of Day to Run System Backup Operations

Assign a time value to the following symbol using hours and minutes:

Example:

To run the backup at 4:00 p.m.:

$ TIME_1 :== 16:00

Additionally, you may assign any allowable qualifiers of the DCL SUBMIT command.

Overriding the Default Queue with the Time Definition

The default queue is assigned to the BATN symbol in the SYS$MANAGER:TAPESTART.COM file. To override this

assignment, specify the queue name with the /QUEUE

qualifier in this file.

Example:

To run the backup at 1:00 a.m. on the SYS$BATCH queue:

$ TIME_2 :== 01:00/QUEUE=SYS$BATCH

Specifying the Node Executing the DCL SUBMIT Command

Assign to the NODE_n symbol the node name of the node that will execute the DCL SUBMIT command. This node does not have to be the node that actually executes the backup job.

Specifying this node on an OpenVMScluster system:

Assign to the NODE_n symbol one of the nodes running the SLS server.

For a specific OpenVMScluster system node:

To ensure the job actually executes on the node assigned to NODE_n you must:

• Include a /QUEUE qualifier with the TIME_n symbol that indicates a queue on the node in the OpenVMScluster system, OR
• Do not include the /QUEUE qualifier with the TIME_n symbol and define the queue with the BATN symbol

Specifying more than one node:

To specify more than one node for a NODE_n symbol, the job queued by one of those nodes is picked at random.

You must:

Specifying this node on a standalone system:

Assign the NODE_n symbol the name of the processor. If the processor is not part a network, then leave the NODE_n symbol blank.

Example: Automatic Scheduling Selection

The following example shows triplets defined for performing backups at one of two different times:

$ DAYS_1 :== MONDAY

$ TIME_1 :== 23:00

$ NODE_1 :== MARS

$!

$!

$ DAYS_2 :== MONTH + 1

$ TIME_2 :== 10:00

$ NODE_2 :== MARS

In this example:

• When the current day is Monday, then the system backup operation is submitted on MARS at 23:00.
• When the current day is not Monday, but is the first day of the month, then the system backup operation is submitted at 10:00 on MARS.

Skipping an Automatically Scheduled System Backup Operation

The following example shows how to skip an automatically scheduled backup operation. Assign an automatic scheduling triplet:

$ DAYS_1 :== MONTH -1

$ TIME_1 :==

$ NODE_1 :==

$!

$!

$ DAYS_2 :== WEDNESDAY

$ DAYS_2 :== 17:00

$ NODE_2 :== VOLKS

In this example:

• If the current day is the last day of the month, then the system backup operation is not performed as specified in the *_SBK.COM file.
• If the current day is not the last day of the month, but is Wednesday, then the system backup operation is submitted at 17:00 on node VOLKS.

HOLIDAYS.DAT Record Format

The format for each record in HOLIDAYS.DAT file is:

dd-mmm-yyyy,xxxxxxxxxxx

Where:

dd-is the day

mmm-is the first three letters of the month

yyyy-is the year

xxxxxxxx-is the name of the holiday

Example: HOLIDAYS.DAT File

The following example shows the contents of a HOLIDAYS.DAT file for the year 1991.

04-JUL-1991,Independence Day

02-SEP-1991,Labor Day

28-NOV-1991,Thanksgiving

25-DEC-1991,Christmas

Execution Sequence for Preprocessing and Post-Processing Symbols

See Execution Sequence for Pre- and Post-Processing Symbols shows the execution sequence of the preprocessing and post-processing symbols and shows the corresponding symbols.

Symbols Enabled for Preprocessing and Post-Processing

Because pre- and post-processing operations are performed in the context of the system backup operation, certain symbols are available for the processes.

See Symbols Enabled for Pre- and Post-Processing lists the symbols that are defined and available for pre- and post-processing system backup operations and a description of the assignments.

Executing Another SBK Batch Job After the Backup Operation

The NEXT_JOB symbol is useful to perform an identical save operation of the disk or disks saved by the current job, or to execute a second batch job for another drive or set of drives.

Assign to the NEXT_JOB symbol the name of a batch job to be submitted. Qualifiers to the DCL SUBMIT command (such as /QUEUE) are allowed.

Example:

If you want to execute the job named INCREMENTAL immediately after this job, assign the following:

$ NEXT_JOB :== INCREMENTAL_SBK

Assignments to FILES_n

To select the files to be saved, assign the file name or disk name to the FILES_n symbol. To make the correct assignment, follow these rules:

• FILES_n symbols are sequentially numbered beginning with the number one, continuing with the number two, and so on.
• The numbers cannot contain leading zeros.
• The sequence cannot skip a number.
• The trailing colon must be included after the device name in each assignment.
• You may define as many FILES_n symbols as you need.

For an image backup operation:

Specify only the device name. The contents of the entire disk will be saved.

Assignments to QUALIFIERS and QUALIFIERS_n

The QUALIFIERS or QUALIFIERS_n symbol assignments are the same assignments used with the DCL BACKUP command and correspond to the FILES_n symbol:

• QUALIFIERS

The default BACKUP qualifiers assigned to FILES_n.

Restriction:

The QUALIFIERS symbol should not be changed in a system backup operation's preprocessing procedures.

Example:

$ FILES_1 :== DISK$USERDATA:

$ FILES_2 :== DISK$TESTDATA:

$ QUALIFIERS :== /IMAGE/VERIFY

• QUALIFIERS_n

The BACKUP qualifiers associated with a corresponding FILES_n, where "n" is the same value.

Example:

$ FILES_1 :== DISK$USERDATA:

$ QUALIFIERS_1 :== /IMAGE/VERIFY/RECORD

$ FILES_2 :== DISK$TESTDATA:

$ QUALIFIERS_2 :== /IMAGE/VERIFY

Deciding When to Use QUALIFIERS or QUALIFIERS_n:

See When to use QUALIFIERS or QUALIFIERS_n describes deciding when to use either QUALIFIERS or the QUALIFIERS_n symbols.

Defining the Backup Privilege

The privileges assigned to the PRIVS symbol determine if SLS software can access files that are to be saved, regardless of the file's individual protection. This assignment is equivalent to a VMS privilege assignment that is necessary to run a system backup operation.

Default:

The default assignment is BYPASS. This allows SLS to bypass individual file protection and save or restore any files on the device.

Caution: READALL privilege:

Users with the READALL privilege have access to file headers which enables them to modify files.

Assignments to MNTFLAGS

Assignments to the MNTFLAGS symbol specify the MOUNT qualifiers to use for the system backup operation. More than one assignment may be specified as a logical OR operation on the allowable assignments.

Caution:

Do not modify @SLS$DATAC:MNTDEF (located immediately before the MNTFLAGS symbol in the SYSBAK.TEMPLATE file.

Assigning Additional Mount Actions

See Mount Action Symbol Assignments lists actions that can be enabled when the volume is mounted for the system backup operation, and the corresponding assignment for the MNTFLAGS symbol.

Mount Action Symbol Assignments

IF you want to...	THEN assign...
Perform readcheck	$ MNTFLAGS == MNT$M_READCHECK
Place a message in the log for each volume mounted	$ MNTFLAGS == MNT$M_MESSAGE
Perform writecheck	$ MNTFLAGS == MNT$M_WRITECHECK
Enable the tape controller's write cache (if supported by_hardware)	$ MNTFLAGS == MNT$M_TAPE_DATA_WRITE

Ensure that you understand the behavior enabled by assignments made to the MNTFLAGS symbol. Some assignments may cause a longer time than necessary to complete a backup operation.

Save Set Name Symbol Descriptions

The string assignments made to the SAVESET_GEN symbol translates into the string used to generate save set names. The SAVESET_GEN symbol allows you to specify the format of the save set names that are written to tape.

The SLS software provides many symbol name string assignments that define the SAVESET_GEN symbol. They are grouped into the following classes:

1. File and device
2. Time and sequence
3. Any symbol assignment in the *_SBK.COM file

See Values for SAVESET_GEN lists and describes the symbol assignments for the SAVESET_GEN symbol, describing both the file and device assignments, as well as time and sequence assignments.

Generating Save Set Names

Follow the procedure in See How to Generate Save Set Names to generate save set names from the assignments made to the SAVESET_GEN symbol.

Assigning the PROTECTION Symbols

You need to assign volume protection to the volumes where SLS will write the save sets. Assign the PROTECTION symbol the same assignments you would make for the DCL SET FILE /PROTECTION command.

Example:

If the volume needs read and write protection only for system, owner, group, and world, then assign:

$ PROTECTION :== S:RW,O:RW,G:RW,W:RW

Indicating the Type of Media Used for the Backup Operation

Make an assignment to the MEDIA_TYPE symbol that is the type of media to be used for the system backup operation.

Requirement:

You must use one of the media type (MTYPE_n) definitions from the SYS$MANAGER:TAPESTART.COM file.

Example:

If you want to write the save set to a 9-track magnetic tape and have an MTYPE_n definition of 9TRACK, you would make the following assignment:

$ MEDIA_TYPE :== 9TRACK

Assigning the Volume Pool for the Backup Operation

Assign the volume pool name to the TAPE_POOL symbol. This name is the pools of volumes from where the volume for the system backup operation will be selected.

Example:

A volume pool named MONTH_IMAGE is used for monthly image backup operations. Assign the following:

$ TAPE_POOL :== MONTH_IMAGE

When to use this symbol:

This symbol is valid only when the PREALLOC or AUTOSEL symbols are also used.

Assigning Backup Volume Density

Assign the volume recording density value to the DENSITY symbol.

Example:

The volumes for the backup operation are magnetic tape with a density of 6250 bpi (bits per inch). Assign the following:

$ DENSITY :== 6250

Requirement:

Your site must have, at minimum, the amount of tape devices that support the density value assigned to the N_DRIVES symbol.

Assigning the Backup Volume Size

Assign the REEL_SIZE symbol a value of the size of the volumes in the specified volume pool.

Example:

If the reels are to be allocated from the specified volume pool are 2400 feet, then assign:

$ REEL_SIZE :== 2400

When to use this symbol:

This symbol is valid only when the PREALLOC or AUTOSEL symbols are also used.

Example: Attended System Backup Assignments with Restrictions

The following example shows assignments that could be used to control a system backup with a policy of operator intervention, restricting the operator's decisions.

Example: Attended System Backup Assignments with Without Restrictions

Backup policy might require the operator to make various decisions about the system backup operation. The following example shows assignments that would allow the operator to respond to these decisions:

Example: Unattended System Backup Assignments

The following example shows assignments that could be used to control an unattended system backup operation on a gravity-driven loader device (stacker). For more information about running unattended backup operations, see See Performing Unattended Backup Operations.

 

$ QUICKLOAD == 1	!SLS software mounts loaded volume
$ QUICKLOAD_RETRIES == 80	!Length of time a volume mount is retried
$ PREALLOC == 0	!No volumes preallocated for the job
$ AUTOSEL == 0	!Additional volumes are not selected by SLS
$ CONTLOADOPT == 2	!SLS reinitializes volumes as needed
$ UNATTENDED_BACKUPS == 1	!Does not requires operator intervention

During unattended backup operations, SLS retains the volume labels of any initialized volumes that it uses. Volumes that are not initialized are rejected.

Acknowledging Loaded Volumes

Use the following options for acknowledging loaded volumes before they are mounted:

• If you want the operator to acknowledge a loaded volume before it is mounted, assign $ QUICKLOAD == 0.
• If you want SLS software to mount a loaded volume without seeking acknowledgment, assign $ QUICKLOAD == 1.

Allocating Volumes Prior to Running the System Backup Operation

Assign the number of reels to be allocated to the PREALLOC symbol. This allocation occurs before midnight on the day before the system backup operation is to be executed.

Doing this generates a printout of volumes allocated for the next day's backup operations. This allows the operator to prepare for the next day's system backup operations by gathering the allocated volumes.

Example:

If you want to allocate five reels of tape on the midnight before the backup is run, you would use this assignment:

$ PREALLOC :== 5

Assign this value (number of reels) to zero if there are no volumes to be allocated ahead of time.

For manual backups:

This symbol is ignored if the system backup operation is manually executed.

Enabling SLS Software to Automatically Select Volumes

The AUTOSEL symbol is used by SLS when the system backup operation runs out of preallocated volumes. When appropriately assigned, this symbol enables SLS software to search the SLS volume database for volumes in the free state. Depending upon the assigned value, SLS will either prompt the operator to load these volumes, or automatically load them.

SLS searches for free volumes in the pool name assigned to the TAPE_POOL symbol.

Allowable Values for AUTOSEL

There are two allowable values for AUTOSEL. See Values for AUTOSEL list these possible values and corresponding descriptions.

Recommended Procedure for Handling Volumes

See How to Handle System Backup Volumes describes how to handle additional volumes that might be needed if all preallocated volumes are used before a backup job completes.

Handling Volume Label Mismatches During the System Backup Operation

The CONTLOADOPT symbol specifies the action to take when a label mismatch occurs while loading a volume. Depending on the value assigned to CONTLOADOPT, the operator is prompted when a label mismatch occurs, to which the operator must reply CONT.

Allowable CONTLOADOPT Values

See Values for CONTLOADOPT describes the volume label processing criteria, the conditions for accepting or rejecting the volume, and the related CONTLOADOPT assignment.

Considerations for More Than One Save Set on One Volume

If you want to write more than one save set to a single set of volumes, assign a string of at least one character to the CONTINUE symbol.

If you do not want to write more than one save set to a volume, assign a null string to the CONTINUE symbol.

Assigning Strings to the CONTINUE Symbol

The string assigned to CONTINUE is used by SLS as a file name without device, directory, file type, or version number. Therefore, this assignment must be compatible with VMS file naming conventions.

If the string assigned to the CONTINUE symbol in a specific _SBK.COM file is unique from all other strings in other _SBK.COM files, save sets generated by this _SBK.COM will be written on volumes or volume sets distinct from those volume or volume sets used by the other _SBK.COM files.

If more than one _SBK.COM file shares the same CONTINUE

symbol string, then the save sets created by those _SBK.COM files are written on the same volume or volume sets.

Example:

Two system backup operations run at different times on the same evening: