Appendix B Summary of New and Changed Facilities

This Appendix lists facilities which are new or changed between PXS 254 and PXS 200. Full details can be found in the manual. For PXS251, PXS252 and PXS253 users there is a summary of changes since each version at the end of this appendix.

B.1. Major Changes

PXS254 introduces several major new facilities. These are summarised below and described fully in the manual.

B.1.1. PXS_PATHWAY

PXS_PATHWAY is a screen based system in the style of the PXS200 PXS_ADMIN, (which it includes). The new PATHWAY facilities are:

• Screen based invoke and sub-invoke with option and parameter prompting.
• Screen based SET parameters, with prompting.
• A facility to control and monitor work in the scheduler and the scheduler itself (subject to permissions).
• Control subset allows simple viewing of work in particular states, i.e. Running, Error, Actions, Sets, Invokes.
• Screen mode SET, TELL and SHOW for controlled work.
• Privacy checked TELL to whole scheduler from MAC.
• Background monitor mode for continuously updated information with subsets as above.
• Full menu and help system together with fast action key switching for experienced users.
• Can be customised for packaged MAC services with facility selection and facility restriction if required.

ADMIN facilities are now included as part of PXS_PATHWAY. The command PXS_ADMIN is retained for comparability.

B.1.2. PXS archive and copy facilities

Four new PXS commands allow suite and job definitions to be copied either singly or in groups. They are: PXS_COPY Copies work definitions to other work definitions. PXS_BACKUP Copies work definitions to an archive file. PXS_RESTORE Restores work definitions copied by PXS_BACKUP. PXS_DELETE Deletes Definitions These commands have similar parameters and facilities as follows:

• Many definitions can be copied, archived or deleted in one call from one definition to all PXS work in a system under all users.
• Selection of work by name, name range or "wildcard".
• Easily specified automatic generation of new names for COPY and RESTORE destinations.
• Selection of suites only, jobs only, or both. Option to include work called from suites.
• ADJUST option to copy suites and work called by them and then to adjust internal suite CALLs and AFTERs to the new names.
• ADJUSTALL option to adjust all CALLS and AFTERS during copy.
• PREVIEW option to pre-validate calls.
• Full privacy checking on all functions.
• Archive files which can be transferred between systems by tape or FTF.

Full details are in the manual.

B.1.3. PXS_MAINTAIN

PXS_MAINTAIN allows PXS software options to be edited using a screen mode system similar to PXS_PATHWAY. The options which can be edited are described in an appendix of the manual. All options which were implemented by repair at PXS200 are now part of the options system. PXS_MAINTAIN is also used to update the JXS task with the required hook information for various PXS releases.

B.1.4. PXS_NETWORK option, ("Distributed PXS")

The PXS Network option allows PXS to communicate with PXS in other VME systems. The major features are:

• Work is defined and invoked normally on the initiator system.
• The job definition attribute RUN_LOCATION specifies the system on which the work executes.
• Full definition compatibility with central or distributed definitions.
• Definitions can be down loaded to distributed systems under PXS control.
• All PXS job facilities are available to distributed work.
• All PXS job commands can be used from distributed work.
• Almost identical control and operator image for local and distributed work. All commands supported on distributed work.
• FTF_WAIT option to allow FTF and job execution to be synchronised.
• Distributed jobs can call PXS_INVOKE in the server machine allowing distributed control of server workloads.
• Distributed jobs can call PXS_INVOKE with themselves as owner, allowing distributed suites with full synchronisation.
• PXS can initiate and synchronise with work run on non VME systems which support IPA. Validated for UNIX, ME29 and CDOS.
• Permissions to remotely initiated jobs can be controlled using *ALLWORK in PXS_CHANGE_PERMISSIONS.

A full description of PXS_NETWORK can be found in the PXS254 Manual.

B.1.5. Retro Invoke option, (253+)

A new custom facility, called "retro-invoking", allows JOB and RUNJOB requests to acquire selected PXS features and so run as if invoked by PXS_INVOKE. This option is intended as a transition aid for sites with unusual existing job systems. Since these vary considerably, the Retro Invoke option is offered as a service package including implementation and transition support. Retro invokes are implemented by site dependent code inserted as a "message handler" profile hook. Such code uses PXS_RETRO_INVOKE to add PXS details, as required, to existing RUNJOB data. The facilities of PXS_RETRO_INVOKE with this first release are:

• Optional BASE_NAME parameter allows PXS job attributes to be read from an existing defined job or defaulted.
• Privacy checking on use of base definition.
• OWNER, INVOKE_ID, AFTERS, CONDITION and OPTIONS parameters as for PXS_INVOKE.
• JOB_OPTIONS parameter to allow override job options.
• A special AFTER value of *LAST to allow simple chaining of retro invokes under the owner.
• Support of some NETWORK facilities such as run location and FTF wait.
• Transparency to normal invokes allows profiles to be used for either normal invokes or retro invokes.
• CHECKED_JOB = NO on retro invokes allows job failure to be handled in the same way as normal RUNJOB jobs.

B.1.6. Support for VME High Security Options, HSO, (253+)

From PXS253 the VME HSO is formally supported by PXS and all security attributes are maintained by work run under PXS. PXS permissions themselves can be controlled by HSO policies using standard VME facilities. The following facilities can be used to restrict the visibility of users work from other users but do not affect the access via defined permissions.

• The system option SUBSET USER specifies that by default, other users work is not visible from PXS_PATHWAY.
• The CHECK ACCESS option enforces the user's view by requiring at least RJ access before work is visible, even in summary.
• The system option OCF BROWSE LEVEL prevents some or all OCFs from being inspected.

B.2. Other Changes

The following is a simple list of significant changes between PXS200 and PXS254. Cosmetic or minor changes are not mentioned. For details of the releases from which these changes apply, see the later sections of this Appendix.

B.2.1. Packaging changes to the release

• Source clearance of all bugs found in earlier versions.
• ACR9 and ACR10 code split into two products. ACR9 code can run with several versions, including PXS200, in one library.
• Options such as the "site id" patch are now implemented by MTM and edited by PXS_MAINTAIN.
• Formal support of demo and test schedulers with products I8LBPD and I8LBPR.
• Re-packaging of demo software for faster loading, module DEMOINSTALL.
• Support of VME releases pre SV290 is withdrawn.
• Network option is now part of the full product.

B.2.2. Performance, resilience and support

• General performance improvement in scheduler by reduced file updating, optimisation of search paths, reduction of number of scheduler interactions in the invoke path, tighter scheduling and improved deferred action calling.
• Code resilience improved by centralised dependencies subsystem, new message subsystem, removal of all fixed size tables and introduction of self-check code.
• Removal of timer tick. PXS now activates only when required or on a slow 'tick', (adjustable by patch if required), of one day.
• Introduction of telediagnostic support and Interactive VM Analysis (IVMA) in system tasks.
• PXS_TRACE command replaces PXAI_TRACE but operates in all non scheduler modes. PXS_TRACE(84/U) traces the same data as PXAI_TRACE.
• The ZUNTRACE scheduler command is replaced by the ZTRACE command which has the same effects and parameters as PXS_TRACE but for the scheduler.
• New ZCLEARQ command allows scheduler to discard existing work on restart.
• New initial and running trace options set by PXS_MAINTAIN.

B.2.3. New definition facilities

• WHILE, UNTIL and SKIP, conditions on calls from suites. Any two of IF, WHEN, WHILE, UNTIL or SKIP can be on one call.
• 'RUNJOB' parameters for jobs can now be supplied on CALLS from suite to job or via PXS_INVOKE. Example:

           SUITE ABC

           STRING RUN_PROFILE 

           CALL JJJ( PROFILE=VAL RUNPROFILE )

  The parameter keywords of the RUNJOB command are now reserved words, (but see the next section). See Appendix C for details.

• A new option "RJ PREFIX" alters the way in which `RUNJOB` parameters are set by prefixing them with RJ when used in PXS_INVOKE of via PXS_CALLS. The example above would then become: CALL JJJ( RJPROFILE=VAL RUNPROFILE ). This can be used where existing PXS200 work uses the names of the parameters of runjob, as PXS variable names.
• CONDITION parameter to PXS_INVOKE allows one condition of any type to be applied to the invoked call.
• AFTER parameters to PXS_INVOKE allow Sub-invoked suites to be dependent on previously invoked work.
• *LAST after value, (for invoke only), allows simple chaining of sub invokes.
• MORE option to PXS_INVOKE, ("Part Invoke"), allows work to be invoked in more than one call of PXS_INVOKE. Example:

            PXS_INVOKE( S1, OPT = MORE) 

            PXS_INVOKE( J1, OPT = MORE, OWNER = S1)

            PXS_INVOKE( J2, OWNER = S1, AFTER = J1, COND = "WHEN START")

• Two new options for part invokes. ABORT cancels a failed part invoke while DEFINE completes one.
• Job cloning. The following generates two identical jobs under S1 from the same definition, but called JOBX1 and JOBX2.

            PXS_INVOKE(J1, OPT=M, OWN=S1, PAR = NAME / JOBX1)

            PXS_INVOKE(J1, OPT=M, OWN=S1, PAR = NAME / JOBX2)

• Profile now defaults to BATCH on invoke if blank in admin.
• When using a test scheduler the scheduler tag is prefixed to the profile. Definitions specifying BATCH will then use (e.g.) PXSBATCH, and need not be altered for testing.
• Three new suite/invoke options:
  1. NOPROMPT is provided to allow work to be tested or run without generating prompts. CONTROL displays will still show the prompt details.
  2. JOBID adds the invoke id to the running job name, so that it can be seen in VME OCFs and in the journal. The system option of the same names now provides the default.
  3. UNIQUE allows a name/id combination to be unique in the scheduler. A system option allows this to be requested for all work.
• Jobs can now be created from Suite definitions and vice versa.
• INVOKEID can now be used as a name in PXS conditions.
• INVOKEID can now be forced to be alphanumeric using the INVOKE ID ALPHANUMERIC option. This is the issued default at PXS254 and later and is strongly recommended.
• New default account facilities. The default when the ACCOUNT in a job definition is blank at invoke time can now be the account of the job's owning user. This is controlled by a system option.
• Better facilities when defining work owned by other usernames. If a user amends a suite owned by another user, then calls from that suite will default to the suite-owning user's name, unless explicitly defined. Permissions to called work are also checked in context of the called username.

B.2.4. Parameters and resources

• ALL value for resource. A resource can be declared as NAME=ALL. At run time this will then seek ALL the resource from the fixed-to resource.
• Full support for 16 variables and at least six resources or twelve resources and at least twelve variables.
• Only variables which are required for a condition need be set before it can be checked. (An option can override this).
• SET for resources now fully supported for Top level resources and resources not yet acquired.
• RJ parameters, such as PROFILE and CLASS are now reserved words. Variables cannot be declared with these names. See Appendix C for a discussion of compatibility.

B.2.5. Listing, display and permissions facilities

• LIST_TO and LIST_LEVEL on PXS_INVOKE in the same way as the D_x_Details commands, LEVEL specifies the level of detail required.
• Component EVERYTHING now supported with X option to suppress, e.g. EVERYTHING & XBASIC.
• INVOKE can be called with option=DISPLAY. This will invoke and list the invoke but will not send it to the scheduler. This allows listings of an 'as invoked' suite to be produced.
• LISTTO=<file> will now create a file by default unless an existing file is specified by generation, (not local name).
• *STDI on LISTTO suppressed for OPER mode.
• Resource display includes FROM reference.
• PXS_SHOW display now modified and fully supports maximum number of parameters and resources.
• PXS_DISPLAY_USER_DETAILS can now be subset using a "wildcard" for START_FROM, e.g. ABC*.
• ALLWORK in PXS_CHANGE_PERMISSIONS is now *ALLWORK.
• *ALLWORK permissions now apply even to work known to the scheduler but without work definitions. This includes Network jobs and Retro invoked jobs.
• A new line in the PXS_SHOW and PXS(CONTROL) VIEW screens indicates the reason why work is not proceeding.
• Expanded error messages in run time Built In Functions.
• A new PXS LOG and OCF browser is available from PXS_PATHWAY. The availability of certain OCFS can be restricted by a system option.
• Pathway information can be subset by user. This can be forced by a system option.
• RJ access can be required even to see a summary line for work on PXS_PATHWAY. This option is expensive and should not be used lightly.

B.2.6. Built In Functions

• New time formats for time based functions. The possible format are now: n_units, hh:mm, yyyy/mm/dd__hh:mm, mm/dd, day of week, day of month and some special names. For example TIME_AFTER(MONDAY).
• PERIOD parameter to TIME_AFTER, TIME_BEFORE and TIME_BETWEEN now defaults to select a period appropriate to the TIME. For example TIME_AFTER(10:00) will assume DAY. TIME_BEFORE(23RD) will assume MONTH.
• A new Built In Function TIME_IN is introduced to replace many uses of TIME_BETWEEN. TIME_IN can use all the new time formats and has TIME and ENDTIME parameters not INTERVAL. Example TIME_IN(10:00,15:00) is true between 10 a.m. and 3 p.m. on each day.
• A new Built In Function WAIT_UNTIL replaces many uses of WAIT. This function has a single ENDTIME parameter and waits for a specific time relative to the last state change. For example:

            CALL DAILY_JOB WHILE WAIT_UNTIL(10:00)

  This call will wait until 10:00, execute, return to "waiting" and then wait until 10:00 the next day.

• PXSF_ERROR and PXSF_VALIDATE can be called in MAC, (though they will perform only dummy functions). This facilitates testing of user written Built In Functions.
• New support procedure PXSF_USER_CONTEXT allows user defined BIF writers to switch to the user of the suite calling the condition. This allows VME objects to be selected without using explicit usernames.
• DAY_IS permits invalid or unset values in ADMIN mode to allow e.g. DAY_IS(VAL DAY)
• New Built In Function FILE_EXISTS.
• Some functions can return UNDEFINED, TRUE or FALSE. For example FAILED is UNDEFINED until a job has run and then TRUE or FALSE depending on outcome. This forces IF, WHILE, UNTIL and SKIP conditions to defer their evaluation.
• New function PXSF_UNDEFINED to allow SCL writers for BIFs to force UNDEFINED outcome.
• New facility for user written Built In Functions PXSF_WAIT_FOR_NAME. This causes work to be re-checked each time new work is declared to the scheduler.
• FAILED Built In Function. This returns TRUE if the named work is Finished, FALSE if it is in Error state and UNDEFINED otherwise. Example:

  CALL JOB1

  CALL JOB2 WHILE FAILED(JOB1)

  If JOB2 includes a PXS_TELL(JOB1,FIX) then JOB2 will run after JOB1 has failed and then, since while JOB1 is running FAILED is UNDEFINED, waits until JOB1 finishes again. The jobs will run alternately until JOB1 works.

• FINISHED now checks AFTERS if the target work is Omitted.

B.2.7. Operational and run-time

• Work and scheduler control via the CONTROL facility of PXS_PATHWAY.
• Permissions checking on scheduler commands issued via PATHWAY or PXS_TELL, (via definition file ":MASTER.[scheduler tag]").
• All PXS job level commands, e.g. PXS_END_JOB, when used in MAC now simulate ENDJOB with QUIT_SCL.
• New values for NAME in PXS_SET, PXS_TELL and PXS_INVOKE from PXS controlled jobs. *SELF indicates the current work while *OWNER is the current works owner.
• SKIP now skips to FINISH and bypasses WHILE and UNTIL conditions. Jobs continue to run if active.
• SKIP on a suite now skips all work in the suite even if active or unfinished. The delay on the skip itself is still maintained.
• SKIP, JOBS option allows a skip to be issued on a suite that will skip only the jobs in it. This provides the effect of the "slow" skip at PXS252 and before.
• HOLD and RELEASE options. DOWN for specific hold/release to target and one level down then general below. ONLY for just the target with no general holds below.
• PXS prompts now self-cancel. Critical prompts may no longer be CANCELLED with <enter>, e.g. JOB FAILED.
• Prompts for jobs are now location subset as are the PXS_JOB and PXS_LOG pictures.
• The "User OCF line" on the PXS job picture now gives a better image with consistent descriptions of waits.
• The "User OCF line" is sometimes used by PXS after the RUN phase, e.g. "OK to DELETE?". The user data is restored after the prompt, or whatever, is answered.
• New job status indicators. 'rem' for distributed jobs with 'at' and 'for' descriptions of remote service, 'Udf' for part-defined entries, 'Rpv' for passive and 'Rft' for if waiting for FTF.
• IGNORE, WAIT command. This is the same as IGNORE WHEN plus IGNORE AFTERS.
• IGNORE command with no data now assumes IGNORE, IF in Opt state and IGNORE, WAIT in WAITING state.
• Better support for Jobs to be owners of other work via sub-invokes. In this case the owned work cannot start until the owning job SCL has been executed.

  This facility allows ad-hoc work to be made "between" existing jobs as follows. If JOB2 is after JOB1 and JOBX is invoked under JOB1, then JOBX waits for the SCL component of JOB1 to finish, and JOB2 (still) waits for JOB1 to reach the PXS Finished state, i.e. effectively waits for both.

• A new system option allows suites to be invoked to PXS using a batch service other than BATCH. This can be used where BATCH is not generally available.
• The work visible in the PXS Job Summary OCF can be subset in a similar way to PXS_PATHWAY. This can, for example, make omitted work invisible.
• Two new options can be used to restrict the commands available. The first makes selected commands "privileged" in that they can only be issued by TELL command and not via PXS_TELL or PXS_PATHWAY(CONTROL). The second suppresses commands so that they cannot be issued even via TELL. A corresponding list of override users can also be specified for each list.

B.2.8. PXS_ADMIN and PXS(DEFINE)

• New Index facility to select work from a list. Supports both work selection for NAME fields and multiple Amend/Delete from TOP level menu.
• Call definition now prompts with variable names in calls.
• New call insertion is now by screen overlay.
• Top down suite definition allowed by defining jobs and suites from call summary screen. Up to 10 levels possible.
• Testing of Built In Functions in calls is now in its own inner block. This reduces the chance of clashes with VME names.

B.2.9. New Trace File facilities

From PXS254 the PXS trace file is created by the scheduler itself at load time rather than being placed manually. This is controlled by two new options, TRACE FILE and GENERATIONS.

• TRACE FILE, if set to YES, will place and use a file called "PXSTRACE" in the current journal library, normally the system default journallib. Note that the trace file name has changed so that there is no conflict with the trace files of previous versions.
• GENERATIONS controls the automatic deletion of old trace files. If TRACE is set to yes then a tidy of unwanted generations will take place. This can be inhibited. The issued value is five.
• The trace file is not placed or opened during a checkpoint session, even if requested. This avoids an unwanted file connection which prevents the VM from checkpointing correctly.

Some other minor changes have been made to the trace system.

• As issued the diagnostic OCF is now suppressed, having been replaced for most purposes by the trace file.
• NORMAL is now allowed as a synonym of NORM in PXS_TRACE and ZTRACE.
• A new trace level ACTIONS is provided. This traces Invokes, Deletes, Commands, Sets, Job starts, job ends, job fails and job actions. If combined with 97/D the all prompts will also be traced.
• Message types 10, 12 and 20 are no longer used. Commands are now logged on Message types 30 and 31.