The following restrictions apply to a remote process that is not a WFL job:
-
The remote process must be an external process whose object code file is stored on the remote host.
-
The remote process can be passed no more than one parameter. The parameter must be a real array of one dimension. The actual parameter must have a zero lower bound. The system automatically chooses a passing mode of call-by-value for the parameter.
-
The WFL COMPILE statement cannot cause the resulting object code file to be executed as a remote process. For example, suppose the compiler equation COMPILER HOSTNAME = SFA15C is used. The compilation will run successfully on the foreign host with a disposition of LIBRARY or SYNTAX, but if the disposition is GO or LIBRARY GO, it is rejected.
If one of the preceding restrictions is violated, the initiating process is discontinued with HISTORYCAUSE = 2 (PROGRAMCAUSEV) and HISTORYREASON = 31 (ILLEGALTASKXFERV). The following error message is displayed:
ILLEGAL HOST-TO-HOST TRANSFER OF TASK
Another restriction is that a WFL job cannot use global file assignments for remote tasks initiated by the job. For example, the following sequence of statements is illegal:
FILE IN(KIND=DISK,TITLE=NEW/INPUT/DATA); RUN OBJECT/UPDATE; HOSTNAME = ALBANY; FILE CARD:= IN;
Global file assignments have no effect when applied to remote tasks initiated from WFL. The remote task executes normally, but the file used by the task does not receive any of the file attributes specified for the global file in the WFL job. When the remote task opens the file, the following nonfatal attribute error message is displayed:
[<hostname>] <mixno> ATTRIBUTE ERROR:<file internal name>.GLOBALFILESIRW
A remote task initiated from a local WFL job cannot read from any data specifications in the WFL job. When the remote task attempts to read from a data specification, it is suspended with a “NO FILE” condition and waits for a card reader file with the requested title to appear. An RSVP message such as the following is routed back to the local host:
[ALBANY] 2079 RSVP (JASMITH)OBJECT/UPDATE ON USERPK. NO FILE CARD (CR)
A coroutine cannot use a continue statement to transfer control to a coroutine on a remote host. By default, the PARTNER task attribute of a remote task is treated as MYSELF and the PARTNEREXISTS task attribute of a remote task returns a value of FALSE. In this case, any continue statement executed by the remote task has no effect. Execution simply proceeds to the next statement in the remote task.
The MYJOB task variable of a remote task is treated as a reference to the DSSSUPPORT library on the remote host. Any references to MYSELF.EXCEPTIONTASK in the remote task are treated as references to TASKING/MESSAGE/HANDLER, a task initiated by DSSSUPPORT on the remote host. TASKING/MESSAGE/HANDLER is discussed under TASKING/MESSAGE/HANDLER and TASKING/STATE/CONTROLLER later in this section. Any references to MYJOB.EXCEPTIONTASK in the remote task are treated as references to the remote task itself.
Any files accessed by a remote process are searched for on the remote host by default. If the remote process uses a file on the local host, the HOSTNAME file attribute must be assigned. For the remote process to open a remote file on the local host, the process must also set its STATION task attribute to zero and assign the desired station name to the FILENAME task attribute. Note that the STATIONNAME task attribute is ignored when the HOSTNAME file attribute is non-null.
