U04 End of Period Overview
LeasePak Documentation Suite NETSOL website
Home Search Help
U04 End of Period Overview

End of Period symbol U04 End of Period

Overview

Overview symbol This is the overview document for U04 End of Period.

Refer to the U04 End of Period Directory for a table of contents organized by category (Interactive, Sequential Updates, etc.), listing items alphabetically within each category.

Refer to the U04 End of Period Numerical Listing for a table of contents of all U04-numbered updates and reports in numerical order.

 

Introduction

EOP is a group of updates and reports, executed automatically in a batch (non-interactive) environment. EOP is executed separately for each portfolio. All interactive updating (for example, manual data entry) for the portfolio is locked while EOP is processing for that portfolio.

A normal EOP process is composed of several steps:

  1. EOP is submitted to a batch queue for later execution by a designated LeasePak operator at the close of the day, month, or year, using U0401 Submit
  2. Data files and other applicable files are backed up by a system operator or automated procedure.
  3. The administrator will usually have set EOP to begin processing after backups are completed. EOP automatically submits a batch job for each of the EOP update or report modules scheduled to perform. Batch jobs to be run by Sequential Updates may be executed in parallel to better use system resources

    Data file backups must be synchronized to be performed only when daily updating for all portfolios is complete

Reports are created separately for each portfolio. Completion of the entire EOP process is not dependent on other portfolios (meaning if EOP terminates abnormally for one portfolio, others may complete successfully, assuming the same problem does not exist in other portfolios).

The elapsed execution time of all EOP processes for the entire database may decrease if each portfolio is assigned a separate EOP batch queue, thus allowing each portfolio to execute its EOP processes in parallel with other portfolios.

 

End of Period Categories

Interactive/Administrative

This category includes the group of interactive tools used to submit, monitor, manage, and report on End of Period processing. They are accessed through the LeasePak client menu, Updates→U04 End of Period.

End of Period Start, End of Period End

U0410 End of Period Start initializes processing, while U0499 End of Period End finalizes it and releases/unlocks the portfolio after processing is complete.

Sequential Updates

U0411 Sequential Updates processes a group of EOP modules collectively, those that require sequential access to the rls Lease and req Asset table records. Parallel processing can be set up for Sequential Updates to lessen the time needed to go through these typically very large tables. U0412 Sequential Updates Post-Processor and U0413 Seguential Updates Post-Merge handle consolidation of records processed in parallel.

End of Day

This category includes updates that run as part of EOP End of Day (EOD) but are not run as part of Sequential Updates.

End of Month

This category includes updates that run as part of EOP End of Month (EOM) but are not run as part of Sequential Updates. Several of these are month-end consolidation and clearing updates.

End of Year

This category includes updates that run as part of EOP End of Year (EOY) but are not run as part of Sequential Updates. These are year-end consolidation and clearing updates.

Non-updating Reports

This category includes reports that can be run as part of EOD, EOM, or EOY but do not make any changes to the database. In general, the day-end reports are identical to their interactive counterparts, while the month-end and year-end reports run with specific parameters to show EOM and EOY closing values.

 

Batch Jobs

Each module of EOP (for example, U0415 Batch Payments) is its own batch job. Therefore, a large number of batch jobs is produced and queued to the specified EOP batch queue. For this reason, a batch queue separate from the system batch queue SYS$BATCH should be set up for each portfolio's EOP process. This avoids clogging the system batch queue with EOP jobs.

 

Dependencies

There is a precise order in which each EOP module is executed. All General Ledger updating, for example, must be performed before R0405 Daily Transaction Journal is created, so that the transaction journal for the day will be complete.

Several modules may be executed in parallel if they are not dependent on any other modules which are currently executing or are waiting to be executed. Executing in parallel means that several modules may execute at the same time, thereby more effectively using system resources. Dependencies refer to relationships between modules. For example, a module is dependent on another module if it must use data that the other is generating or, conversely, if it must clear or delete data that the other is using. In the previous example, R0405 Daily Transaction Journal is dependent on programs which update the General Ledger (for example, U0301 Accrual).

Dependent relationships determine the modules which may be executed in parallel. Again using the above example, the Accrual update and the Maintenance report, which do not depend on each other, may execute at the same time, while the Daily Transaction Journal must wait for the Accrual update to complete before it may begin.

EOP determines the dependent relationships between all modules and automatically determines which modules may execute and which modules must wait. For the modules which must wait, EOP automatically monitors them and starts them when their prerequisite modules are complete.

 

Parallel Processing

In certain cases, it may be beneficial to split the processing of updates into multiple processes. That is, instead of executing an update once for the portfolio, it may be slated to execute several times, each time processing a different set of leases in the portfolio. These separate jobs may then execute in parallel, thereby more fully using system capabilities. Parallel processing is available only for the U0411 Sequential Updates portion of EOP. U0412 Sequential Updates Post Processor and U0413 Sequential Updates Post Merge consolidate results of parallel processing.

There are performance trade-offs when executing multiple processes rather than a single process. Analysis of the portfolio should be performed by a NETSOL representative before using parallel processing.

 

Module Status Definitions

Each EOP module slated to run has a current status defining its stage of execution. The status assists in determining if the EOP process has completed successfully or if some intervention is required in order to allow it to complete.

End of Period module statuses are:

Status Definition
HOLDING ON QUEUE - WAITING BACKUPS All modules are holding, generally waiting for backups to complete before beginning execution. Assigned when U0401 Submit is used to submit the EOP process as a single batch job in a hold state. After backups are completed, the batch job is released from the queue by the system operator. This batch job then branches into multiple batch jobs, each executing an individual function of EOP (for example, Cycle Accruals, Maintenance report, etc.). At this time, the module status changes to another status (for example, PENDING INITIALIZATION, CURRENTLY IN PROGRESS, or PENDING COMPLETION OF PARENT MODULE).
TIMED FOR LATER EXECUTION All modules are waiting until a specific time before beginning execution. Assigned when the U0401 Submit is used to submit the EOP process as a single batch job with an 'A' after time. At the specified time, the batch job begins executing automatically. The batch job branches into multiple batch jobs, each executing an individual function of EOP (for example, Cycle Accruals, Maintenance report, etc.). At this time, the module status changes.
PENDING INITIALIZATION The module is either:
  • Just beginning to execute (that is, it is performing some initializations before starting)
  • May be waiting for a slot in the batch queue.
A module with this status has no parent for which it is waiting. It may begin executing as soon as it is finished with its initializations or as soon as there is room on the queue (for example, if the batch queue has a job limit of 5 and 5 other EOP modules are currently executing, this module must wait for one to complete before it may begin).
PENDING STARTUP OF QUEUE The EOP batch queue is stopped. Starting the queue can be done by a system operator or someone who has access to the operating system. All uncompleted EOP modules automatically begin executing when the queue is re-started.
PENDING COMPLETION OF PARENT MODULE Module is waiting for another module to complete successfully. A parent module is defined as another module which updates the same files required by this module, and which must successfully finish before this module may start. Generally, reports do not have to wait for each other before starting. However, most reports must wait until certain updates are finished before beginning execution.
CURRENTLY IN PROGRESS Module is currently executing.
COMPLETED Module has successfully completed. Other dependent modules, which were waiting for the completion of this module, may now start.
FAILED DUE TO ERROR The error file for this portfolio may be examined to determine the error. Also, a MAIL message is sent to the EOP supervisor indicating that an error has occurred and also detailing the error traceback. However, there may not be an error file entry for this error if the failure was due to a system or power failure. All dependent modules waiting for release of data files by this module which failed are postponed until specific action is taken on this failed module. The user may either restart the module or skip the module altogether for this End of Period. A restart recovers the data files for this module and then begins executing the module again. A skip does not recover the data files. A module should be skipped only after careful analysis of the impact of not completing the module. Refer to U0404 Halt/Restart/Skip and individual EOP module documentation for more information about skipping a particular module. All modules must successfully complete or be skipped before updates are unlocked and data entry may resume for the portfolio.
POSTPONED - PARENT MODULE FAILED Module is postponed until action is taken on its failed parent. Postponed modules no longer appear on the batch queue. A postponed module does not start execution because an update or report for which it was waiting failed. A postponed module may be skipped without requiring data recovery, since it did not start execution. Successful completion or skipping of a failed parent module does not automatically restart postponed modules. Once the parent module is restarted or skipped, postponed modules must also be restarted so that they may be returned to the queue in either a pending state if any parent has yet to complete or a current state if all parent batch jobs are completed or skipped.
HALTED BY SUPERVISOR A halted module no longer appears on the batch queue. Halting a module should be done only in an emergency (for example, End of Month was submitted by mistake). The files are left unrecovered until restart is specified for the module. All dependent modules are also postponed and no longer appear on the batch queue. This action is similar to a FAILED DUE TO ERROR state, except the module is halted by the supervisor rather than due to power or program failure.
POSTPONED - PARENT MODULE HALTED This state is similar to POSTPONED - PARENT MODULE FAILED, except that the parent module is halted by the supervisor. Refer to the POSTPONED - PARENT MODULE FAILED description for required action.
SKIPPED - NOT TO RUN THIS EOP The scheduled module was skipped through U0404 Halt/Restart/Skip. In case of a severe problem, a module may be skipped altogether for this EOP, but only after carefully analyzing the impact of skipping the module. Skipping one module does not automatically skip all modules dependent on the skipped module. If dependent modules should not be executed, then specifically skip those as well through U0404 Halt/Restart/Skip.