
Classic Goof-Ups & Silly Problems
Here is a short summary of some of those XPFC "problems"
that really weren't problems at all !
It's only with considerable experience ( and hindsight !)
that it's possible to spot the root cause of these "problems" ....... we can
appreciate that when you're stuck on one of these "gems", it's far from simple,
and even further from the "obvious" !
We hope you find these helpful !


External Writer suffers various Abends when running; 806, 106 etc
.... NO output is
created on the tape and the XPFC Load Module Library is now corrupt; it contains NO
runtime XPFC load modules.

The XPFC External Writer, in common with the standard IBM External Writer, uses the
dataset named in the FIRST DD statement of the External Writer Step as the output
file, regardless of the actual DDname.
If this is the STEPLIB DD defining the Load Library from where the
XPFC runtime code is loaded, the initial XPFC External Writer module will be loaded and
execution will commence, causing this dataset to be opened for output as a sequential
dataset, thus corrupting the Load Library immediately !
Once this occurs, OFFLINE XPFC must be re-installed !
The supplied XPFC External Writer procedure includes a STEPLIB DD
statement to define the Load Library from where the XPFC runtime code is loaded as the LAST
statement within the step. The FIRST DD statement, named IEFRDER, defines the
output tape/cartridge where the XPFC conditioned output datastream is to be written.
If any modifications are made to the supplied XPFC External Writer
code, great care MUST be taken to ensure that the FIRST DD card is used as
supplied ......... it defines a dataset on tape/cartridge where the XPFC conditioned
output datastream is to be written !


Print data greater than 150 chars is truncated when printing on Xerox printer

Specify a value of ;
DATA=(0,255)
in the LINE statement on the Xerox printer JSL
...... not forgetting to re-compile the JSL !


Print data greater than 132 chars is truncated when printing on Xerox printers ........ or
that the previous suggested change to JSL did not make any difference.

Check out the way that the printer is defined to JES2.
If a Local Printer, JES2 will not truncate the line.
The only way the line length can be affected is on the LINE
statement in the JSL.
If the printer is defined a Remote Device (JES2 RJE, probably SNA)
then the Remote Printer definition can affect the length of the Line transmitted.
Look at the Remote Printer definition statement in the JES2
Initialisation Parameters and check the specification of the LRECL or PRWIDTH parameter
........ this should set to 255 to ensure that JES2 will not truncate any lines.


**INTERVENE, **FORCEFORM or **FLSHFORCE not working as expected.

User finds that even though the necessary entries have been coded in the XPFC Configurator
File, the desired "FORCE"d action does not take place yet the records appear to
be syntactically correct.
This problem only occurs for the JES2 SubSystem datasets - such as
JCL Images, Message Log and System Messages.
Look at the DDnames that have been specified in the entries - they
should look something like "£JCLIMG" for the JES2 JCL Images Sub-system
Dataset.
It may be that this is wrong for the Version/Release of JES2 being
run ....... JES2 itself generates the required DDnames for these SubSystem
Datasets.
You can view the actual DDnames by using SDSF, selecting the Held
Output Display Panel (Option H) or Output Display Panel (Option O) and place an
"?" in the command field against any Job.
The DDnames of all the SubSystem Datasets should appear to the left
of the display area.


Font Indexing working correctly ONLINE, but OFFLINE printing produces no
change in fonts in desired positions, and output may even be shifted over to the right on
the page.

Check the contents of the Configurator File.
This is one exception where a separate Configurator File may be
needed for Online and Offline modes of printer operation.
If the DJDE Packets contain FONTINDEX statements, there is an
important difference between Online and Offline Operation .......... You REALLY must
read the Xerox documentation on this tricky subject !


External Writer Abends 002-18 ......... and output for the XPFC External Writer Class(es)
is left on the JES2 output queue.

Inspect the first SYSOUT Dataset on the JES2 output queue for the XPFC External Writer
using SDSF option "O" or equivalent.
Browse the output scrolling right (PF11) to determine the maximum
width of the output lines ...... there may be only one line that is much longer than the
others.
Note this maximum line width and then check against the LRECL value
coded in the DCB for the IEFRDER DD card in the XPFC External Writer Procedure.
The value coded should be at least 4 greater than the maximum line
width of any SYSOUT Dataset destined for the XPFC External Writer.
For example, for a SYSOUT Dataset with a maximum line width of 201
characters including the PCC byte (Printer Control Character - the
first byte before any actual data), code an LRECL of 205.
Ideally, the XPFC External Writer Procedure should have an LRECL
value of 255 specified to cater for ANY possible SYSOUT line width up to the
maximum.


XPFC's Configurator File changed OK, but it can't be brought into live service

The Configurator File has been updated OK with the desired changes, the batch
"Configurate" job has run OK to create an InFlight Reloader style Configurator
Load Module .......... but it cannot be loaded using the XPFC InFlight Reloader command
"$TXPFC,M=CONFIGxx".
Look at the message from the XPFC InFlight Reloader command to
determine why the Configurator Load Module cannot be loaded.
If the message text reads "$XPFC Configurator Module not
found", then check that the name "CONFIGxx" matched the name given when
running the "Configurate" batch job.
If it is, did you remember to "Refresh" the MVS
Linklist Lookaside Address Space ?
This must be done before any XPFC InFlight Reloader command is
issued if the XPFC Configurator Module resides in an MVS Linklist Library.
If the message text reads "$XPFC Configurator Module
CONFIGxx invalid eye-catcher", then check that the "Configurate" batch
job ran correctly with a Return Code of zero for ALL three steps.
If the first step generated a Return Code greater than zero and the
Assembly and Link-edit steps still ran, the XPFC Configurate program in the first step
will deliberately adjust the eye-catcher at the start of the Configurator Module so that
an invalid one cannot be inadvertently loaded ........... Correct the Configurator File
errors and resubmit the "Configurate" batch job.
If the message text reads "$XPFC Configurator Module
CONFIGxx Load failed xxx/yy", then determine why the load failed by checking the
Abend and Reason codes given (xxx/yyy respectively) as documented in the relevant IBM
System Messages and Codes Manual.
A common problem is that the Library where the XPFC run-time and
Configurator modules reside are allowed to run into secondary extents.
If the Configurator Module is contained in such an extent, it cannot
be loaded by MVS until the Library is compressed so that the load module is contained only
within the original primary extent and the Linklist Lookaside then refreshed.
|