Introduction to Prestart Jobs
Prestart jobs provide improved performance by allowing a job to be started prior to handling a work request and can be reused for multiple requests—but they can be difficult to manage.
I’m sure you have a love/hate relationship with prestart jobs. They provide improved performance by allowing a job to be started prior to handling a work request and can be reused for multiple requests—but they can be difficult to manage. There are many aspects to consider with prestart jobs; this blog post is the first in a series on the topic.
For many of you, this article will reveal nothing new—IBM i has had prestart jobs since the early days of the system. However, I thought it would be good to start from the beginning. After all, there are always people new to the IBM i platform and this starting point may be interesting to those who have limited experience with IBM i.
Prestart jobs have their heritage with legacy communications protocols (APPC/APPN, Async, Bisync, retail/finance, etc..) and were introduced long ago. My memory is fuzzy, but I’m guessing it was around the V2R1 time frame of the AS/400. With the legacy communications protocols, a request for work was called a program start request. When a program start request was received, a job would be started to handle that work request and end when the work was completed. However, job initiation and termination was (and still is) a rather expensive operation, and the overhead of job initiation when a program start request was received resulted in poor performance in establishing the communications connection.
To address the performance of accepting a program start request, prestart jobs were introduced. Initially this support simply started the jobs ahead of time and had them wait for work, ready to handle a program start request when it was received. This moved the cost of job initiation out of the mainline connection establishment path. In this initial support, prestart jobs were never reused. When prestart jobs had been started and were waiting for work, the job’s status was Program Start Request Wait, which was displayed as PSRW. Today, you still see prestart jobs with a status of PSRW, but the definition has been changed to mean Prestart Wait.
Prestart jobs were extended to support client-server communications with the introduction of the host servers; again, my memory is fuzzy, but I think the host servers appeared in V3R1. During this time frame, support was added to allow prestart jobs to be reused.Prestart jobs are used more than ever in today’s application environments. They’re supplied by the operating system for various subsystems, but the ones in QSYSWRK, QUSRWRK, and QSERVER are the most interesting.
Over the next few weeks, I plan to write several more articles covering all aspects of prestart jobs. Hopefully you will come to love them rather than hate them.