Your browser does not allow storing cookies. We recommend enabling them.


Restoring Archived Data Sets

Storage management software, such as data facility hierarchical storage manager (DFHSM), can migrate needless data sets by storing them out of the normal data file system to a tape or some other storage medium. These data sets are listed in the catalog with a special volume serial number, normally MIGRAT, but some configurations or products may use different identifiers. A migrated data set is recalled by mounting the offline storage medium on which it is stored and copying it back to an online medium. This process can happen automatically under the storage manager's control, or it may be explicitly requested. There will usually be some delay while recall occurs.

From an SFTP user point of view, it may be desirable to have migrated data sets automatically recalled, or it may be preferred not to do so and ignore them if they would be selected by a globbing pattern. This behavior can be controlled via the automount and autorecall extended file attributes. See Tectia Server for IBM z/OS User Manual for further details.

When allocating a migrated data set, the SFTP subsystem recognizes that the volume serial number MIGRAT is purely symbolic and does not use it to specify the volume, allowing the storage manager to do so. In the case where the special volume serial number for a migrated data set is other than MIGRAT, it is necessary to inform the SFTP subsystem that this is the case. The environment variable SSH_SFT_PSEUDOVOLUME_VOLSERS is provided for this purpose. It may be set to a comma-separated list of one or more pseudo-volume serial numbers, each of which is a string. If the volume serial number of a migrated data set matches one of these, the subsystem will treat the data set exactly as if it had contained MIGRAT, that is, it will not specify a volume when attempting to allocate the data set. Note that this is the sole effect of this environment variable: it does not cause migration or recall to happen, or modify the process in any other way. Supply the setting SSH_SFT_PSEUDOVOLUME_VOLSERS=<volser_list> (where <volser_list> is a comma-separated list of pseudo-volume serial numbers) as appropriate in any of /etc/environment, the user's logon profile or rc script, ~/.ssh2/environment, or the data set allocated to STDENV DD for a batch job.

For recall of migrated data sets to happen when they are requested via SFTP, the following conditions are required:

  • The user ID under which SFTP is running must be permitted to recall migrated data sets. If the RACF facility SSZ.MOUNT is defined, the user must have read access.

  • The extended file attribute automount must be set to yes or immed via site command or configuration.

  • The autorecall extended file attribute must be set or allowed to default to yes.

To avoid unintentionally recalling data sets when it is not desired to do so, set the extended file attribute autorecall to no. If the special volume serial number for migrated data sets is anything other than MIGRAT, define the special volume serial number(s) in use via the SSH_SFT_PSEUDOVOLUME_VOLSERS environment variable.


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more