There could be any reason why any software would abort. There are times even when error messages are clear, the trigger of the issue is still hard to determine. To know where to troubleshoot the problem, one should know the details on how the software works. The process flow will tell the story of why it aborts. Understanding how P/I Output Manager works is a good foundation and a good start to troubleshooting a problem.
This is how P/I Output Manager works
- P/I Output Manager's main function is to transform print files to the format for the chosen output device.
- One of the features in this product is to be able to dynamically change this print file base on criteria define in P/I Output Enhancement (an add-on to P/I Output Manager).
- MGR (P/I Output Manager) receives the job via Connect.
- MGR component VIPEXEC receives information from Connect, that this is happening. As part of its function, VIPEXEC creates registration entries about the job in accounting. Some information are displayed by GUI. VIPEXEC also creates the modifier file and job ticket for every input job received, while it updates the system.log with logs of activities.
- After completing receiving the the input file/job, process exits Connect and VIPEXEC submit it to the next stage, which will be handled by the Input client.
- Input client read and parse the file to create virtual files equivalent of it. Virtual files are the native format of MGR.
- Output Client picks up the Virtual and creates the format for the device destination defined by a user or operator.
- P/I Output Manager always logged activities applied on a job in system.log.
- System.log is populated with more information when LOGLEVEL is added in the profile with a value higher than 0.
- (Note: A higher LOGLEVEL value can slow the process of MGR.).
- System*.log files will have the story on jobs as far as MGR is concerned. It is a very a text file that gives information on history of Jobs received by P/I Output Manager.
An example of what a system.log could contain:
18/01/16 - 06:22:43 D000000 VIPEXEC - Config handle structure increased to 64256 entries
18/01/16 - 06:22:44 D000000 VIPEXEC - Config handle structure increased to 64512 entries
18/01/16 - 06:22:45 D000000 VIPEXEC - Config handle structure increased to 64768 entries
18/01/16 - 06:22:47 D000000 VIPEXEC - Config handle structure increased to 65024 entries
18/01/16 - 06:22:48 D000000 VIPEXEC - Config handle structure increased to 65280 entries
18/01/16 - 06:22:50 D000000 VIPEXEC - Config handle structure increased to 0 entries
18/01/16 - 06:22:50 E000002 VIPEXEC - FATAL - program logic - line 3899 - file config.c
18/01/16 - 06:22:50 E000012 VIPEXEC - Unrecoverable error - process terminated
18/01/16 - 06:22:50 D000000 VIPEXEC - IpcAcceptConnection_S: accept call failed: error 10004
18/01/16 - 06:22:50 E047065 VIPEXEC - Call to IPC function IpcAcceptConnection failed. err 10004
The errors in the example registered by VIPEXEC are about processes happened before it could even call the Input Client. What if issues encountered when job was received and being processed?When processing a job, there are other files updated and created. These would have the information of the job in process. These are additional information that Technical Support would request to troubleshooting issues.
Therefore, issues occurred when jobs are being received. These logs is an example that MGR is the recipient of the job. In troubleshooting it is worth looking what happens when the job is sent by what PC and software.
- Versions.log (the versions of each MGR component).
- IPDS trace (Can be created from using IPDSTRACENAME. More information about this command can be found in VDD2IPDS Command Guide)
- .VRF logs (Can be created when using an output device like IPDS printer)
- \system\JTICKET\*.TKT (File created for every input job. This will have commands from the profile, set file and modifier.)
- \system\JOBnnnnn\*.MOD (File created for every input job. This will have commands from connect spool.)
At the early part of this article, P/I Output Enhancement was define as an add on to P/I Output Manager. When MGR aborts with VDE processing, it is a must to distinguish that "the aborting" happens in MGR or VDE. To do this one must know how P/I Output Enhancement work on P/I Output Manager.
This is how P/I Output Manager and P/I Output Enhancement (VDE) works.
- Input Client takes the input job and parsed to create its virtual file version, and stores it as temporary virtuals in job folder.
- PI Output Enhancement (VDE) accessed these temp virtual files; and it makes updates, amendments and create indices, as specified by VDE Input Script, saving the final virtual file version of the job in folder define by VDDP command in set folder.
- So these final virtual file will be ready for the VDE Output Script to accesss. The amended version will be in new temporary vituals in the job folder for the Output Client to access.
- The final stage, Output client convert the current virtuals to format the output device will accept.
- Any reprint, will have to repeat the process from #3.
Knowing the workflow of VDE on MGR, could help in resolving issues like VDETEMP missing. This problem is reported happening when Output Client is applying VDE define in a DEFAULT_PROFILE in the Output Client config. Here is a sample of the error message:
30/03/15 - 23:31:54 E028001 IPDS-OUTSIM - C:\VIPUSER\VDD\VDETEMP\JOB60337\IPDS-OUTSIManyjob_60337.1 cannot be found - rc 2
Looking at the system.log, before this issue occurred, the VDDs (virtual files) were deleted.
The log states that VIPEXEC is doing is on purpose, or other words base on setup.
13/04/16 - 16:11:34 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.123
13/04/16 - 16:11:38 D000000 IPDS-VSOCE - Issuing checkpoint for Job 20161 - File id 131 (Side 4175)
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.124
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.125
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.126
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.127
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.128
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.129
13/04/16 - 16:11:38 D000000 VIPEXEC - Deleting VDD file C:\VIPUSER\VDD\anyjob_20161.130
13/04/16 - 16:11:39 E028001 IPDS-VSOCE (VDE) - C:\VIPUSER\VDD\anyjob_20161.123 cannot be found - rc 2
13/04/16 - 16:11:39 W029270 VIPEXEC - Abort message: "IPDS-VSOCE (VDE) - C:\VIPUSER\VDD\anyjob_20161.123 cannot be found - rc 2" for job 20161 sent to ZOB by IPDS-VSOCE (VDE)
13/04/16 - 16:11:39 D000000 IPDS-VSOCE (VDE) - Process suspended - awaiting abort
The logs implied that VDDs of the job in folder define by VDDP in set folder are deleted.
This would be sure behaviour if HOLDVDD=NO in the default profile (called in generic.cfg) or profile; or the absence of HOLDVDD command for its default value is NO. The Output Client deletes the virtuals after it converted it to the format for the output device, this an automated practice to save disk space. Since VDE script is invoke by the output config via a call to a default profile (and not the ideal of calling the VDE output script via job profile), virtuals are deleted first before this script it applied.
To have HOLDVDD=YES in the profile, resolves this issue.
To manage disk space with HOLDVDD=YES, please refer to User Guide for the following commands related to managing the virtuals, under Life-cycle of VDD files.
UPDATED: August 08, 2017