Technical Questions & Answers

We've summarized here some of the most common technical questions that have been registered with the HelpDesk in recent years, and we would hope that they're useful in helping you solve any of your installation and or customization problems that you might experience.

Can XPFC co-exist with other JES2 Exit code supplied by 3rd party software suppliers or user developed code?

Yes.

XPFC JES2 Exits obey the required JES2 conventions for User Exits and always return to JES2 with Return Code of zero. The fact that XPFC is called does not pre-empt other JES2 User Exits from being called in addition.

To give an example, consider the following JES2 Initialisation Statement for JES2 EXIT1;

EXIT1 ROUTINE=(XPFCE1,BANNER),ENABLE

At Start-of-Job, the JES2 Print/Punch Task calls User Exit "XPFCE1"(XPFC EXIT 1 code) which will check if it is to intervene on the output destined to the active printer and if so, generate cover sheets and/or DJDE packets as specified by the Configurator File.

XPFC then returns to the JES2 Print/Punch Task and User Exit "BANNER" will then be called, which may then, for instance, generate a Cover Sheet for the Job being printed.

XPFC does modify two user areas in the PCE control block (PCEUSER0 & PCEUSER1) - if the User Exit "BANNER" uses these fields for processing then XPFC must be customized to use different fields for it's processing requirements in order to avoid clashes and subsequent unpredictable results !

For XPFC Version 3 Release 2 set Column 10 of **OPTIONS to a "Y", for Version 3 Release 3 code the keyword "USEDCT" under **OPTIONS. This will tell XPFC to use words "DCTUSER0" and "DCTUSER1" instead of the PCE User fields.

In addition, XPFC uses the $USER1 field of the HCT control block - if the User Exit "BANNER" uses this field for processing as well, then XPFC must be customized to use a different field.

For XPFC Version 3 Release 2 set Column 13 of **OPTIONS to a "Y", for Version 3 Release 3 code the keyword "USEHCCT" under **OPTIONS. This will tell XPFC to use word "CCTUSER1" of the HCCT instead of the HCT $USER1 User field.

If you are unsure of the situation please call the Xerox HelpDesk for future advice and assistance.

What do I need to specify on the JES2 Printer Definition?

The major JES2 Initialisation Parms on the PRT(n) statement are as follows;

Q=Class List

This specifies the output Class(es) that are eligible for the printer - these should normally match the Classes specified in the **CLASS Section of the Configurator File.

SETUP=NOHALT

It is strongly recommended that this parameter be entered to ensure that JES2 will not halt and prompt the MVS Operator for changes for which manual intervention on the printer would normally be involved, such as for change of Forms.

For a Xerox printer, ALL Forms changes will be tracked by XPFC and relevant messages issued on the Printer Console for any required Printer Operator intervention (See **MSG Configurator File Section).

Confused with the use of **OPTIONS Keywords ONLYFIRST/SINGLECOVER ?

Specifying the keyword "ONLYFIRST" or "SINGLECOVER", under **OPTIONS, suppresses the insertion of the selected **DATASET and **PREFILE Configurator File entries into the output datastream.

This option is intended for users who wish to generate Job Cover Sheet(s) only at Start-of-Dataset using the **DATASET and/or **PREFILE entry.

Cover Sheets are NOT specified for Start-of-Job from the **JOB Configurator File Section ....... the Cover Sheet(s) specified in the selected **DATASET and or **PREFILE entry(ies) are only output for the FIRST SYSOUT Dataset for the Job.

For ALL subsequent SYSOUT Datasets for the Job, the **DATSET/**PREFILE insertion is suppressed.

A "SIDE=NUFRONT" DJDE packet is inserted in to the print datastream before each subsequent SYSOUT dataset automatically. This ensures that each SYSOUT print report starts on a new physical page if printing in duplex mode. The DJDE IDEN is taken from the **DJDE specification in the Configurator File.

Great care should be taken if using this option. The automatic suppression of DJDE packets otherwise generated from **DATASET and/or **PREFILE entries may cause some output to print in a different layout than originally intended.

The effect depends heavily upon the JCL mapping scheme used to control output style. If output style (such as ..... Simplex/Duplex FORMS etc) is controlled by Output Class or FORM Id, then suppression of subsequent **DATASET/**PREFILE actions is probably safe as each Print Job will consist of SYSOUT whose output Class, Form-ID and Flash etc.. have matching characteristics.

If a PAGEDEF or FORMDEF is used to control output style, a print Job on the JES2 output queue may consist of SYSOUT datasets with differing PAGEDEF/FORMDEF values, so suppression of **DATASET/*PREFILE insertion would be highly dangerous !

Why is *HOF coded in certain Sections within the Configurator File?

*HOF directs XPFC to insert a record containing a Skip-to-HOF immediate PCC byte in the output stream to the printer.

This is necessary to ensure the following;

Cover Sheets are contained on a separate page

and or,

DJDE Packets generated by XPFC are applied by the Xerox printer at the next page boundary.

MUST a *HOF be coded for certain situations?

In many cases, a *HOF is coded just to make sure that a Skip-to-HOF immediate PCC byte WILL be output immediately before a SYSOUT dataset is sent to the printer.

For cases where there is NO XPFC Cover Sheet to be output at Start-of-Dataset..... such as ..... only a DJDE Packet is output to specify the output style of the following SYSOUT...... then a subsequent *HOF is not necessary. JES2 will generate an output line with a Skip-to-HOF immediate PCC byte if the first line in the SYSOUT dataset does NOT specify one.

For example, the JES2 JCL Image File and System Messages, asssociated with a job's JCL and execution do NOT contain such HOF skips.

For these SYSOUT datasets, and ANY other SYSOUT datasets generated by applications with no starting HOF skip, if XPFC is to produce a Start-of-Dataset Cover Sheet AND a DJDE Packet specifying the output style of the following SYSOUT, a *HOF AFTER the DJDE Packet line MUST be coded to ensure that the necessary Skip-to-HOF immediate PCC byte is generated BEFORE the SYSOUT dataset lines are sent to the printer.

This is because JES2 will NOT automatically generate an output line with a Skip-to-HOF immediate PCC byte BEFORE the SYSOUT dataset is sent to the printer ! JES2 detects that this has already been done by the *HOF specified before the XPFC Cover Sheet was sent to the printer.

For safety, the latest QuickStart XPFC Configurator Files supplied on the Install Tape specifies *HOF immediately after EVERY DJDE packet for ALL **DATASET Configurator File sections.

Some earlier QuickStart XPFC Configurator Files may miss some *HOF lines in certain **DATASET Configurator File sections. For safety, they should be inserted into your Production Configurator File. For example.......

I already have output on the JES2 Spool generated by existing applications which contain DJDE records to format the output .......... Can I customize XPFC so that this output is still printed in the same way with no application/JCL changes?

Yes. All that is necessary is to customize XPFC in the following way;

	Ensure that XPFC does not insert cover sheet information and DJDE Packets for this output by reserving a discrete Output Class for this type of output which is specified on the Class list in the JES2 Printer Definition but excluded from the Output Class list in the **CLASS Section of the Configurator File.
	Modify the DJDE identifier string used in the XPFC QuickStart Configurator File and printer JSL to match that already used by the application so that the existing JSL on the printer can be merged in with the XPFC QuickStart JSL. XPFC is already compatible with most Xerox supplied packages ...... the Xerox host product XPPI uses the string $DJDE$ which is already used in the XPFC QuickStart Pack.

I have followed the advice for the previous question ....... and the output from my application still works fine and XPFC controls new output.

But .......... my old application relies on JES2 to produce a cover sheet - I would like to use the one created by XPFC as it looks better and I can customize it to my exact requirements.

Can XPFC provide just cover sheet information and leave the application's DJDE's to format the output?

Yes, it can.

In the example, XPPI DJDE packets in the output actually override XPFC DJDE formatting for the actual printed output, so merely include the Output Class of XPPI output in the Output Class list in the **CLASS Section of the Configurator File ......... and XPFC will provide the necessary Cover Sheets and the XPPI DJDE Packet will format the output correctly !

However, if your application is sensitive to DJDE Packets from XPFC, then you can still get XPFC to intervene by added the output Class to the **CLASS list in the Configurator File and prevent unwanted DJDE insertion at Start-of-Dataset by using one of the "FORCE"ing features of XPFC.

This is achieved by coding entries in the Configurator File in a manner similar to the following;

Insert a separate "**DATASET name" definition with no subsequent entries following it like this; **DATASET XPPI

	Insert a **INTERVENE Section to 'FORCE' selection of the above "**DATASET name" entry based on certain criteria like this; **INTERVENE XPPI,XPPI.*.SYSPRINT
	Turn on **INTERVENE processing. This is achieved by setting Column 29 of **OPTIONS to a "Y", or by coding the keyword "USEINTERVENE" under **OPTIONS.

The aim here is to 'FORCE' XPFC to select a certain **DATASET entry when processing the output for which NO DJDE insertion (for print layout/formatting) required.

In the above example, ALL Jobs having a Proc-Stepname of "XPPI" using DDNAME SYSPRINT are forced to use a **DATASET entry of "XPPI".

When this entry is selected, because there are no lines following it in the Configurator File, NO DJDE packets are inserted when the output is sent to the printer - only the XPFC Start-of-Job Cover Sheet is sent at the start of the print job !

Must I use Start-of-Dataset Cover Sheets?

No.

They are included in the QuickStart Configurator Files to highlight their presence and be of use when installing and testing XPFC. The IVP uses them to display all XPFC run-time parameter values for some SYSOUT reports

The XPFC Configurator File pre-processing program requires that at least ONE Start-of-Dataset entry (ie **DATASET definition) is coded. This is the default entry to by used for every Start-of-Dataset call from JES2 when printing output.

If cover sheets are not required, then edit the default **DATASET entry in the Configurator File and remove the first DJDE and Cover Sheet information lines, but leave the final DJDE line and *HOF Line because they provide information to the Xerox printer as to how the actual print output is to be formatted.

Remove ALL other **DATASET entries and their respective lines of cover sheet and DJDE packet information ............ all output will then be printed with WITHOUT Start-of-Dataset cover sheets.

I have coded **FORMS and/or **FLASH entries with a list of valid values in the Configurator File but XPFC is not performing any validity checking on the JCL value picked up when output is printed.

Remember that just coding a validation or translation list section is not enough to get XPFC to perform the desired operation.

You must also code the necessary entry(ies) under the **OPTIONS Section to invoke the control feature.

For XPFC Version 3 Release 2 column 23 must be set to "Y" for **FLASH processing to be active and Column 26 must be set to "Y" for **FORMS processing to be active.

For XPFC Version 3 Release 3 code the keyword "USEFLASH" for **FLASH processing to be active and code the keyword "USEFORMS" for **FORMS processing to be active.

I am mapping the JCL FORMS value to a JDE call on the Xerox printer.

Must I use the **FORMS validation list checking?

How does it help?

Each time I add a new FORM (ie "Print Style") I must add the new JDE entry in the Xerox printer JSL and re-compile, then update my Configurator File, run the "Configurate" batch job and wait for a warm start of JES2.

It is not strictly necessary to perform the **FORMS validation check.

However, if a job is printed that specifies a FORMS JCL value other than expected, this will cause a DJDE processing error on the Xerox printer which will then cause the printer to halt until the LPS Operator specifies "Continue".

By coding **FORMS entries for each valid FORMS JCL value and turning the XPFC FORMS validation feature on, if an invalid value is encountered, XPFC will provide a default (the first entry in **FORMS section) chosen by the user which will ensure that the printer will not halt until the Operator decides how to handle the error.

You might even like to consider adopting a standard whereby you have a "default cover sheet" which could perhaps include the text;

Wrong FORMS value requested - Please report to Xerox Printing Support.

........ Well ?

If updates are regularly being made to the Production Configurator File, use the InFlight Reloader feature of XPFC - there's information about this useful feature on a separate page on this Web site.

This allows new Configurator Files to be prepared and introduced without a warm start of JES2.

The QuickStart Configurator File codes **FORMS and **FLASH have a single entry and the relevant columns of **OPTIONS have not been set to "Y" to turn on validation - Do these entries provide anything?

Yes.

If a validation/translation type section such as **FORMS has been coded with a single entry, this value is used as a default if NO JCL value has been coded irrespective of whether the processing options in **OPTIONS have been turned on or off.

This allows the user to provide a sensible default for a range of JCL values where nothing will have been coded in the JCL.

I wish to "FORCE" a different cover sheet on all JES2 output - such as ....... Job Log, JCL images and System Messages.

What DSname value do I code in the **INTERVENE section entries?

If you wish to affect output for ALL Jobs then just specify the DDname by itself.

The DDname is made up by JES2 and may vary according to the version of JES2 installed.

To obtain the correct value, select the Held Output Queue on SDSF and place a "?" in the command field against any one of the Jobs shown ........ the resulting display will show the Jobname, Proc-stepname , stepname and DDname.

The **INTERVENE Section may then be coded as follows;

**INTERVENE JCL,JES*

In this example, JES2 at this installation identifies the DDnames of its sub-system datasets as "JESSYLOG", "JESJCL" and "JESSYMSG", so a single generic entry of JES* would force XPFC to use a value of "JCL" for the &F runtime parameter and thus select an appropriate **DATASET entry if one was present.

I have coded **FORCEFORM entries which I believe to be correct and set the relevant **OPTIONS column to a 'Y'.

But when I test the results, none of the entries coded seem to cause the desired "FORCE"d Form to be applied ........ What is the problem?

First, verify the SYSOUT Dataset name (ie Jobname,Proc-Stepname, Stepname and DDname) by using SDSF in the way described previously.

When specifying the DSNAME on the **FORCEFORM entries, remember that it is right justified if any levels are missed off ........ specifying an entry coded "SALES*.SYSPRINT" effectively means "*.*.SALES*.SYSPRINT" ......... ie ANY Jobname, ANY Proc-stepname with Stepname beginning "SALES", and DDname explicitly of "SYSPRINT".

Also ....... using "?" means any SINGLE character in that position so "SALES?" is not the same as "SALES*" for every possible Stepname ........ it would match on a value of "SALES1" but NOT "SALES01".

Even if a value is "FORCE"d by correct matching of the current output (Synthesised) SYSOUT Dataset Name, XPFC may still set the run-time parameter to a different value later on during validation processing.

Is there a list of Forms in a **FORMS section with column 26 of the **OPTIONS flags set to "Y"?

If so, is the "FORCE"d Form value specified?

If not, the "FORCE"d value will be rejected as invalid and the first entry in the list would be applied as the default !

XPFC derives the value for the FORMS and FLASH run-time parameters in the following manner:-

	Obtain the value coded (or system default used) from the job's JCL
	Process any "FORCE"d sections in the Configurator File if turned on in the relevant **OPTIONS flags ........ this may cause the runtime parameter taken from the JCL to be altered.
	Process the **FORMS/**FLASH validation list is specified in the Configurator File. This may again cause the current value of the run-time parameter to be altered.

Are any of the **OPTIONS flags mutually inclusive or exclusive?

For example ....... If a particular column is set to 'Y' must another value be set to 'Y' or 'N' as well?

No.

Each **OPTIONS flag controls a specific processing feature. They are additive and there are no restrictions on specific settings or combinations of settings unless the documentation recommends a particular value for a specific column.