cDSCHEDULE Automated Job Submission System Guide and Reference �ManualD

SCHEDULE
Automated Job Submission System
Guide and Reference Manual



 o T Y  
PreviousContentsIndex



0To create a new group 1, use the below commands.

 

"
 ,$ @SYS$MANAGER:SCHEDULE_STARTUP NEW_GROUP 1    DThe following command should be issued on all nodes of the cluster:   '$ @SYS$MANAGER:SCHEDULE_STARTUP BOOT 1    




DTo enter the standard definitions into this new group use the below commands.

 

"
 !$ DEFINE SCHEDULE_GROUP_NUMBER 1   ,$ @SCHEDULE_LIBRARY:SCHEDULE_STANDARD_PROCS    




CWhen a new version of the software has been received to update the #group files use the below commands.

 

"
 /$ @SYS$MANAGER:SCHEDULE_STARTUP UPDATE_GROUP 1   DThe following command should be issued on all nodes of the cluster:  -$ @SYS$MANAGER:SCHEDULE_STARTUP NEWVERSION 1    




GThe logical SCHEDULE_GROUP_NUMBER is used to define which server group Fto communicate with. If a different group number is desired it can be Ddefined system wide for a default database. To override the default Bdefine the logical process wide and re-execute SCHEDULE_LOGIN.COM.

EAfter creating the new group, run SCHEDULE_STANDARD_PROCS.COM to put /default jobs and calendars in the new database.6

2.4.2 Server functions



EThe SCHEDULE System is design as a client/server processing Gpair. All the foreground user interfaces connect to the server process Fto perform all primary functions. The foreground clients are the user =interface programs. Currently there are three styles of user Cinterfaces. 1) DCL commands and qualifiers. 2) MCL menus and forms ?interface. 3) MOTIF interface. These foreground processes just Ecommunicate with the user and then request the server to perform all activities.

FThe server process performs all database I/O, network communications, >scheduling state changes, batch job submissions, and activity Emonitoring. If a foreground process makes a request that refers to a Gremote node then the server will route that request across the network %to the designated node. 12<

2.4.3 Net proxy requirements



EAll network communications are done by sending a request packet from 0one server process on a node to a server processHon another node. The SCHEDULE server declares itself a network object. 13

?No proxy logins are used to implement this communications link.

HOnce an incoming request has been received by the server process from a +remote node a check is made to determine ifFthe user on that remote node has the needed privileges to perform the Arequested function. This check is done using the following steps.

    H
  1. The remote user is equated to a local user name by searching the C NETPROXY.DAT file. This file is maintained and can be viewed and 2 modified by the AUTHORIZE Utility. 14J
  2. Use the access rights of the local user and compare those with the J protection settings of the object that is being accessed. If the access % is refused then reject the request.


DThe parameter NETPROXY_DEFAULT_USER can be set to establish a local Euser name to be used in the event that a search through the NETPROXY 'file does not turn up any equivalences.

HIt is important in a Peer-to-Peer or Satellite-Central configuration to Fbe sure to set up proxy equivalences for all users 15 that 'will be communicating over the network.



/   
N
Note

 P

12 The server interface is composed of N two executable images. SCHEDULESHR contains all the routines that are O called by the foreground applications. These routines then communicate : with SCH0_SERVER which is the server process.

J

13 The NCP object number used is  0.

D

14 Please refer to the VMS O documentation for a full description of the VMS AUTHORIZE Utility.

D

15 When a job has a remote N prerequisite or initiate it is the user name of job that matters. For K interactive use it is the user name of the person logged in on the  terminal.








 o V T Y  
PreviousNextContentsIndex