Monthly log file

For large size installations where various batch jobs are submitted potentially leading to thousands over thousands of PDF created, FPDF4ZOS engine provides an interesting feature whereas all calls are traced into a monthly log file. The name of that file contains a root string defined in configuration file (Key=JRNL.DIR), which is read upon calling NewPdfy() function, to which a suffix Lyyyymm is automatically appended; yyyymm being a six characters string containing current year and month when FPDF4ZOS is invoked.

This log file has a format close to CSV which means fields are separated from each other by a semi-colon. The image below gives an idea about what this log file looks like.

Monthly log file example

The list below details the meaning of each and every field which appears in this CSV/ LOG file:

Field #1Date and hour at which FPDF4ZOS processing has completed.
Field #2An 8 characters string which is supposed to identify a customer for multi customers installations. In fact, it is the third parameter string given in function FlushPdf(). If the length of this third parameter is lower than 3, this string is forced to “??????“.
Field #3An 8 characters string which is supposed to identify a program for multi programs installations. In fact, it is the fourth parameter string given in function FlushPdf(). If the length of this fourth parameter is lower than 3, this string is forced to “??????“.
Field #4A single character string indicates whether PDF built was compressed (=Z) or not (=N). NB: in most cases of production instalations, this field will be almost always equal to Z.
Field #5This is the number of PDF files produced by FPDF4ZOS when invoked. It is recalled that this tool has the capability to produce a great number of PDF files with a single call, thanks to a specific FlushPdf() feature. This feature enables a program to call intialisation function NewPdfy() only once and to produce multiple PDF while keeping context and resources in memory. In that case, this number of PDF files produced will be greater than 1. Otherwise, in more classical usages, this number will be 1.
Field #6This is the overall number of PDF pages produced by FPDF4ZOS when invoked. If multiple PDF files are created in a row, this number will be the cumulated sum of all pages across all the PDF files built.
Field #7This is the overall volume in bytes produced by FPDF4ZOS when invoked. If multiple PDF files are created in a row, this number will be the cumulated sum of sizes of all the PDF files built.
Field #8This is the name of the file produced by FPDF4ZOS when invoked. If multiple PDF files are created in a row, this will be the name of the last PDF file created.
Field #9For z/OS environments, this will be the JobName from which FPDF4ZOS was invoked. For Windows and Linux environments, this will be Machine name from which FPDF4ZOS was invoked.
Field #10For z/OS environments, this will be the JobNumber from which FPDF4ZOS was invoked. For Windows and Linux environments, this will be the process ID from which FPDF4ZOS was invoked.
Field #11In a given installation, there might be several instances which simultaneously produce PDF files. In that case, it may happen that contentions occur when one process attempts to write a line in target Log File. If that is the case, FPDF4ZOS engine waits a random number of ms before retrying to write in log file. If retries fail 10 successive times, processing completes without any line being written in log file. This field indicates the number of retries attempted in case of such contentions, when retry number has been lower than 10. Most of the time, this number is 0.
Field #12Number of CPU milliseconds which have been required to complete processing of building that PDF, or that set of PDFs. Note that this time is the sum of CPU time spent by the engine itself AND the calling program.
Field #13Elapse time in seconds it took to both the program and FPDF4ZOS core engine to complete processing of building PDF(s).
Field #14User ID on behalf of which processing has completed. For z/OS environments, this is the user ID under which authority the job has been submitted. For Linux environment, it is the login name under which processing has been started. For Windows environment, this the owner of the session.