APPX Software Library

Section 7: Job Processes

Job Processes

(from SP2 Jobs, Query Functions, and Displayed Disposition Functions)

Item 7.1

Conversion Bug (fixed in V05): In V04 invocation Type is improperly set to DETACHED on SP2 job steps running other jobs. Change this to RELATED in order to share disposition values. (Note: SP2 job steps using SUB JOB are converted properly to RELATED.)

Item 7.2

Bug (FYI): In APPX 2.3, changing the name of a job can sometimes cause the rules of the job to be lost; they come back if the job is changed back to the original name. (This happened once at APPX Software, Inc. when changing the names of several disposition jobs in succession but could not be reproduced at will.) (See item 1.23 for orphan utility and reference to similar type bugs.)

Item 7.3

Bug/Difference (flagged): In APPX 1.8.4 and 2.0, using a job to change companies does not work right when the change is not just for the duration of the job (for instance, the SP2 job includes the predefined input/subroutine SELECT DATABASE followed by MENU job steps or the SP2 job does not change the company back too). APPX does not enforce security for the new company and then can give security violation errors when the operator returns later to the original company. What was found to work properly was to offer a menu pick to change to a specific company, define a MENU process as the menu pick, and set SELECTED DATABASE to the company ID in Pre-Child Invocation. The conversion log flags jobs which are used to change companies. (See items 6.5 and 8.14.)

If the SP2 job is changing the company simply for the duration of the job, change Invocation Type to DETACHED on the job step to be run under the new company. If more than one job step is under the new company (or if the job step has security), create another job containing those job steps and invoke that job as DETACHED. APPX will automatically restore the original company at the completion of the job. (Under APPX 3.0 at Pinellas, where a job step was used to change company and the next job step had security, APPX used the security of the old company whereas SP2 uses the security of the new company. This problem can be avoided by creating another job for the job step.)

Item 7.4

Bug (fixed in APPX 3.0 Beta): In APPX 1.8.4, the predefined subroutine BEGIN LIVE OPERATIONS does not work. This means the jobs to end Recovery Processing or Initial Setup do not work. You must enter System Administration in order to change phase. (See item 7.15.)

Item 7.5

Bug (FYI): In APPX 1.8.4 the Cross Reference Utility may not find jobs run by commands.

Item 7.6

Difference (flagged in V05): The conversion log flags any job using function code for review since many do not convert properly. For instance, SP2 jobs may use function code to determine which of several sorts to use with a given output/update function or to determine which output/update to run following a given sort. In APPX a query does not get executed until a job step is invoked which specifies the query in its Use Query option. Also, SP2 external functions can be defined to set function code from the return code. (See items 7.7, 7.19, & 10.16.)

Item 7.7

Difference (flagged in V05): APPX cannot handle a job with a single query serving the same process twice for different results as in the following SP2 example:

      CSA  INPUT         CUSTOMER ACTIVITY REPORT
      CSA  SORT SETUP    CUSTOMER ACTIVITY REPORT
      CSA  DISPOSITION   STANDARD REPORT
      CSA  SORT          CUSTOMER ACTIVITY REPORT
D     CSA  OUTPUT        CUSTOMER ACTIVITY REPORT
S     CSA  OUTPUT        CUSTOMER ACTIVITY REPORT

This SP2 job uses the same output function to print detail and/or summary versions of the report by keying on the function code. If both versions are requested, the function code is initially set to "D" in the input function and then changed to "S" by commands in the Output End of Function.

This approach will not work in APPX 1.8.4. When a query is reused in a job (i.e., not run again), the shared resources of the original query replace the current values. This means that although the 2nd output job step starts out with a PROCESS CODE of "S", during execution PROCESS CODE reverts back to "D", the value at query runtime. Update Type in the Use Query cannot be set to 2 (Clear) since this will discard any operator changes to record selections or sort order. One work-around is to create a summary version of the output (for example, CUSTOMER ACTIVITY SUMMARY) which does not rely on testing PROCESS CODE within the output and change the job to use the summary version. (See item 10.16 too.)

Item 7.8

Difference (FYI): Certain job steps that are self-explanatory in SP2 have no direct counterpart in APPX and job clarity is lost. For instance, DISPOSITION functions convert to JOB or SUBROUTINE processes in APPX, and certain built-in functions convert to rules on a blank job step. (See items 7.9 & 7.11.)

Item 7.9

Suggestion: To distinguish disposition jobs or subroutines from ordinary ones, use Change All References to rename them to begin with the prefix *DISP* (for example, *DISP* STANDARD LIST). Beware of any cross-application use. Warning: If application JJJ installed, use the procedure in item 7.10 instead.

Item 7.10

Suggestion: Consider installing the APPX Software, Inc. Job/Report Disposition Control System for APPX (application JJJ).

If JJJ installed, perform the following steps for jobs converted from SP2 displayed disposition functions:

  1. Print APPX Tech Doc for 'old' disposition jobs (converted status).
  2. Create new disposition jobs by copying JJJ Job "*DISP*".
  3. Define new disposition jobs in JJJ Disposition Definitions F/M. If background not implemented (on PC?), set background options to "N".
  4. Delete old disposition jobs.
  5. Run Change All References from old disp jobs to new disp jobs.

Also, perform the following steps for subroutines converted from SP2 non-displayed disposition functions:

  1. Print APPX Tech Doc for disposition subroutines (converted status).
  2. Print APPX X-Ref for disposition subroutines (& compare to SP2 X-Ref).
  3. Create new disposition jobs by copying JJJ Job "*DISP*".

  4. Define new disposition jobs in JJJ Disposition Definitions F/M specifying "N" for display options.

    If background not implemented (on PC?), set background options to "N".

  5. Delete disposition subroutines.
  6. Modify all references to disposition subroutines to call new disposition jobs.

Finally, print APPX Process X-Ref on --- INPUT DISPOSITION to confirm there are no references. There may be references in jobs that used the SP2 built-in disposition function as well as references in inquiry processes on key entry frames (see optional process for the image). These should all be changed to reference JJJ INPUT DISPOSITION instead. Remember any changes made on key entry frames must be reimplemented if key entry frames are rebuilt.

Item 7.11

Suggestion: To provide greater visibility into what a job is doing, consider replacing blank job steps with SUBROUTINE job steps that call self-explanatory or do-nothing subroutines appropriately labelled, such as: (see items 1.4, 7.17, 7.18, & 7.19)

*SET* CANCEL OK
*SET* CANCEL NOT OK
*SET* PROCESS CODE    (do-nothing subroutine)
*GOTO*                (do-nothing subroutine)

For do-nothing subroutines, the rules should still be attached to the job step. Create the self-explanatory subroutine with the appropriate code and create the do-nothing subroutine with a single comment line.

Item 7.12

Suggestion: Consider printing a completion report as the last step in jobs which perform critical updates. Otherwise, if the job is run in background, there will be no visibility that it did not run to completion. For example, an error message does not print if the job is cancelled.

Item 7.13

Note (FYI): APPX handles queries differently than SP2 handles sorts and these differences can cause problems in the way jobs are converted. Background processing is also handled differently (see item 7.21).

Item 7.14

Difference: In SP2 the title of the job appears at the top of screens presented by STATUS and DISPOSITION job steps. In APPX the title of the job does not appear. If desired, review STATUS processes to determine if a warning message naming the job is needed. Check SP2 Status X-Ref for use. (See item 14.1.)

Item 7.15

Conversion Bug (flagged in V05): The SP2 built-in function BEGIN LIVE OPNS is converted to use the predefined subroutine --- BEGIN LIVE OPERATIONS but needs attention in order to call the proper menu. (See item 6.1 for how to handle use directly from menu.)

If used as a step in a job, from the job step change the AA Invocation Type from RELATED to SUBPROCESS (Parent Disposition is NORMAL) and add the following code to Post Invocation:

MENU     aaa                              DETACHED     END? N  FAIL 0

Then, from the menu item optional process for the job, change the AA parent disposition from NORMAL to END AFTER (Invocation Type is DETACHED). This assumes that the menu is only one level deep in the application.

Item 7.16

Note (flagged): The conversion log may generate the message "Revise Use of END APPLICATION on Job Step". Since there is no equivalent of this SP2 built-in function in APPX, delete any remaining references to the job and then delete the job. If the job is associated with menu item 0 in SP2 (as is normally the case) and if the application was converted with the conversion option to delete menu item 0, there may not be any references to the job in APPX. However, change menu text to read "Press END to End Application".

Item 7.17

Note (flagged in V05): In light of the APPX bugs related to CANCEL OK (documented in item 1.4), extra work is needed to protect jobs from being cancelled that used the SP2 built-in function 'CANCEL NOT OK'. Check each process following this job step and set 'User Cancel OK?'="N". Also, insert another job step to set CANCEL OK="N" following any STATUS job step. The conversion log flags any job using CANCEL NOT OK. (See items 1.4 & 7.11).

Item 7.18

Note (flagged in V05): The conversion log flags any job using GOTO since these jobs may not convert properly. If a job loops via GOTO to reuse a query, Update Type in Use Query should be changed to 2 (Clear) so that APPX will not reuse the same query file and so that different user criteria can be applied. Also, once background processing is enabled, it is illegal in APPX to branch to a job step before the job step with 'Separate Task?'="Y". Remember that GOTO is implemented in APPX by setting the NEXT CHILD ID predefined field. (See item 7.11.)

Item 7.19

Difference (flagged in V05): It may be necessary to add an UPDATE or SUBROUTINE job step in APPX to replace any updating performed in the query (including setting PROCESS CODE). (See item 12.11 for details.)

Item 7.20

Difference (flagged in V05): If a job has 2 or more OUTPUT's but only one SORT, confirm that both OUTPUT's are using the sort by checking the APPX job step UQ. If so, there is the potential for bogus blank lines in one of the outputs. (See items 10.16 & 12.16.)

Item 7.21

Bug/Difference (flagged in V05): APPX handles background processing differently than SP2 and provides a new flag 'Separate Task?' defined at the job step level. The conversion log flags any suspect jobs for review (see items 1.32 and 1.33 too):

  1. Any single-step job should have 'Separate Task?'="N".
  2. A multi-step job should have 'Separate Task?'="Y" only on its final job step and then only if the job is not run by another job with 'Separate Task?'="Y".
  3. If a job has more than one job step following its disposition job step, these job steps should be moved to a new job (or jobs if necessary).

For example, to address a job which has both an update and an output following its disposition job step, use Design Transfer to create a new job named the same but ending in "2". In the original job, delete the update and output job steps and add a JOB job step calling the new job as the final job step. Set 'Separate Task?'="Y" only on the new JOB job step. In the new job, delete all job steps except the update and output and set 'Separate Task?'="N" on all job steps.

Note that the disposition job will control whether or not the operator can actually select background processing from the disposition screen.