Mainframe > Administrator > Migration

How JES2 Manages a Smoother Spool Migration

Editor’s note: This is the second of a four-part series on Job Entry Subsystem 2 (JES2) spool migration, which was included in z/OS release 13. This article provides insights into how JES2 manages the migration among multi-access spool (MAS) members and also migrator communications with runtime applications during the copy and catch-up phases.

Before delving further into this topic, the first order of business is to define key terms:

Spool migration: The process of moving data off of one volume and placing it onto another. As in the first article, the source and target volumes will be referred to as SPOOL2 and SPOOL5, respectively. This and follow-up articles will detail the setup phase and the algorithm to assure migration is handled in a non-disruptive manner.

Migrator: A subtask running in the JES2 address space responsible for coordinating a migration. The migrator coordinates all phases of the migration among all MAS members. Each migrator represents just one migration. At most, five active migrations can take place per MAS at a given time.

Runtime: Address spaces running user applications and performing I/O to source spool volumes. JES2 incorporates a low-level interface, which enables runtime to communicate with the migrator task via cross-coupling facility (XCF) messaging. Once a migration is started, runtime reports into the migrator before performing any I/O on the source volume during copy and catch-up phases. Migrator provides necessary instructions back to runtime via message response. Actual I/O is performed by the runtime.

Migration assistant: A subtask running in each JES2 address space that works in concert with the migrator to coordinate migration phase transitions on a per member basis. A single assistant will handle all active migrations.

Bitmaps used in migration:

• Track level. Created in setup phase, it represents the tracks that must be migrated from source to target. It’s used by migrator during copy phase.
• Runtime. Also having track-level granularity and managed by assistants under direction of the migrator, this bitmap informs runtime on a per-track basis, whether communication is required with migrator before performing I/O to the source volume SPOOL2.
• Re-migrate. During the copy phase, the migrator, in concert with runtime, tallies which tracks might need to be re-migrated during catch-up phase. This bitmap also provides migrator restart and takeover capabilities on any system within MAS should the migrator go down. This is written to the target spool volume.

I/O permission request: A XCF request/response message sent from runtime to the migrator during copy and catch-up migration phases. The migrator is the ringmaster and uses this message to direct runtime to access source or target volumes under a set of rules explained below.

Tweet