【Fujitsu】OSIV/MSP (1997 Enhanced Version)

Amid heightened concerns about disaster preparedness in the wake of the Kobe Earthquake (January 17, 1995), Fujitsu began shipping an enhanced version of its OSIV/MSP operating system (first announced in June 1989) for Fujitsu very-large mainframes in March 1997. The functional enhancements were intended to enable the construction of backup centers for corporate data processing systems.

At the time, Fujitsu switched from introducing operating system enhancements as version-level upgrades. Instead, it provided them along with enhanced software in the same way as function revisions. The reason for this was twofold: to reduce the overhead associated with version-level upgrades and because it was impossible to discuss the functions wanted in mainframe systems without considering the relationship between functional enhancements to the operating system and at the middleware level (software such as Fujitsu AIM).

The main disaster-response function the March 1997 version upgraded was real-time backups. Should a disaster strike an operations center, real-time backups would enable a corporation to quickly resume services using up-to-date or virtually up-to-date data from the backup center. The same functional enhancements were also supplied with Fujitsu’s large mainframe operating system, OSIV/XSP.

Real-time backups depended on Fujitsu’s remote file control unit (FCU). This unit transferred backup data to the remote site almost in real time. The remote FCU’s key function was called a remote file control facility (RFCF). The remote FCU used around March 1997 was the F1710R, but this was replaced later with the F6495, which had the same RFCF function. Next is a description of the real-time backup process, following the figure below.

  • When a database update, for example, is written to the log file, the remote FCU transfers a copy of the written data to the remote site (a backup center, for example).
  • The remote FCU at the remote site writes the received data as a file at the remote site and ensures the two remote FCUs are synchronized. This synchronization allows the original log file and the remote site’s log file to be treated as if they were one virtual log file spanning both sites.
  • At the remote site, the database is periodically updated to reflect the received log data. To implement this function, a logical log*1 function was provided in AIM, which was enhanced at the same time as the operating system.
  • *1. A log that relies entirely on the logic of its data without identifying or specifying the physical location of the database. While the update speed is not as fast as a log that specifies the physical location, the logical log method can offer more flexibility, such as making the remote site’s database more compact.