| Previous | TContents | YIndex |
H Network communications are involved in several different aspects of the G SCHEDULE system. The two main areas are database locality and job interconnection in a network.
8 There are two ways to inform the system that you wish to ? communicate with a remote node. The first method is to add the H /NODE=NODE_NAME to any command. For example to do a directory operation on a remote node.
|
" $ SCHEDULE DIRECTORY */NODE=ISE |
< The second method entails defining a logical name to contain E the target node. The following commands will give the same result as the above one.
|
" $ $ DEFINE SCHEDULE_DATABASE_NODE ISE $ SCHEDULE DIRECTORY * |
8 2.4.4.1 Database locality
B Usually a single SCHEDULE database is installed inside a @ single VMS management domain (referred to as the SYSTEM in this D documentation). A single management domain includes all VMS systems E clustered together that share such things as the authorization file, B queue file and online disks. Sometimes it is advantages to have a D single SCHEDULE database across all systems in the network 7 even though they are not in the same management domain.
G A Peer-to-peer configuration is where each system has its own D SCHEDULE database and on occasion needs to synchronize jobs F between these systems. This mode allows each system to do most of its F own work without regard to the up/down status of the other members of G the network. A network request will wait for the remote node to become accessible before completing.
H A Satellite-Central configuration is where a system is defined as D the repository of the central SCHEDULE database. All other A nodes in the network indicate 16 that the database is + located on this central node. 17
B In this mode the central system must be up and accessible for any C scheduling activity to be performed on a remote node. This mode is G generally used in an environment with a large central cluster and many D standalone workstations that are connected to a common network. The H workstations are too small to merit a full SCHEDULE set up but : certain jobs need to be periodically run on those systems. : 2.4.4.2 Job interconnections
F There are two methods for interconnecting jobs across a network. Jobs G are interconnected by defining a prerequisite or an initiate condition 2 between any two jobs. A network connection is when C these two jobs are on different nodes in the network. 18
F In a Peer-to-Peer configuration a node name is added to each E entry on the prerequisite or initiate list entry that is on a remote : node. A typical prerequisite list would appear as follows.
|
" . $ SCHEDULE TYPE/PREREQUISITE [DEMO.A]REPORT_3 [DEMO.A]REPORT_3.prerequisite NODE1::UPDATE_A
UPDATE_B NODE2::UPDATE_C |
F In a Satellite-Central configuration a node name is added to F the submit attributes of any job that is to execute on a remote node. @ There is no need to add the remote node name to the initiate or F prerequisite list entry. For example, to mark a job to execute on the / remote system NODE1 use the following commands.
| N » 16 The parameter DATABASE_NODE in the SCH0_PARA in the SCH0_PARAMETER.DAT file indicates on what node the central database resides.17 Typically the central system is a cluster. In this case it is important to specify the cluster alias as the node name. This will allow the remote systems to communicate with any up member of the central cluster.“18 For network operations to work all nodes involved must be running the SCHEDULE System. |
| Previous | VNext | TContents | YIndex |