Designing Functions to Work With and Without Tasks

DEVELOPER

Trail: PROIV Documentation > Developer > PROIV Bus and Tasks > Designing Functions to Work With and Without Tasks

Currently, the TGDA is available only if you are calling a Task from the Bus; indeed, this is the only way of executing a Task (with one exception in a non-mainframe environment – see Logon Link to Function as a Task). But there is a way of taking advantage of the TGDA with a function that can be run in both standard and component mode.

There are three important things to note, all of which can help you in writing such a function.

1. If you define a function parameter and you run the function in standard mode, the parameter will be treated like a local variable. Even if the function is executing in component mode, and the function parameter is mapped to a variable name that does not exist in the TGDA, the parameter will be treated as if it was not a parameter. So you can run the same function in component and standard mode.

2.  You can use system COMM variables as function parameters, the traditional way to pass data between linked functions, and map them to TGDEs.
   As an example to explain how to handle this, suppose you have a set of functions that do the following:

Example of Linked Functions

Suppose FUNCT2 and FUNCT3 are the functions that are doing all the work, and that FUNCT1 just sets up the data. You would like to pass the data into a Task that executes FUNCT2 and FUNCT3. This can be achieved in at least three ways:

-      Write a new Task start function, TSK_START, whose job it is to read the Task parameters (T_ALPHA and T_NUMBER) and write them to the system COMM variables. So TSK_START needs (at least) two parameters, one (called, say, P_ALF1) mapped to T_ALPHA and the other (called, say, P_NUM1) mapped to T_NUMBER. Then TSK_START writes P_ALF1 to $COM1 and P_NUM1 to #COM2, followed by a link to FUNCT2.

-      Write TSK_START, but map $COM1 directly to T_ALPHA, and #COM2 to T_NUMBER. There is no need to actually assign $COM1 or #COM2.

-      Do not use TSK_START, instead modify FUNCT2 by mapping $COM1 and #COM2 to T_ALPHA and T_NUMBER respectively. The function is already using those two COMM variables, and no other changes are necessary. FUNCT2 will work properly when you link from FUNCT1 in standard mode, or execute it in component mode.

Whether or not you create TSK_START or use FUNCT2 to read the Task parameters depends on what other things you need to do before executing FUNCT2.

3. Pre-load fields (not available under the S/390 product) are also a useful feature for designing functions that operate in both modes. In FUNCT1 you want to read in the data from the Task if the function is executing in component mode, or get the data from the user in standard mode. By defining and mapping the parameters, and marking the fields as pre-load, that will happen automatically. In standard mode, the fields will be empty and the user is allowed to enter data. In component mode (with values in the parameters), the user will not be allowed to enter data into those fields; the data from the Task will be used instead.

Retrofitting exiting functions into Task can also benefit for the same approaches. Analyze where data is coming from and what needs to be set up before executing the functions that do the actual work. If you are driving your modules from a menu, you may want to replace the menu when you are working in component mode. Each menu choice can become a Task, with its own start function. In each start function, data should be set up so that the interface is the same as the interface from the menu. Alternatively, you can modify the first function linked-to from the original menu choice in a similar way to changing FUNCT2 in the example above.

Comment on this topic

Topic ID: 540041