In this tutorial we shall talk exclusively about non persistent CGI. Traditionally, CGI programs are not persistent, that is, a CGI program, the next time it is called, does not remember (or, better, must not remember - as no guarantee exists that it is called by the same client as before) what values where left in its variables, and where files are positioned. This fact of course has a relevant impact in program design, because the values of the variables which are important for a program at the time it is invoked must be saved in the previous response HTML (usually as hidden fields) and sent with the program invocation request.

Since V4R3, however, persistent CGI have been implemented for OS/400 HTTP.
A persistent ILE-COBOL CGI ends with "exit program and continue run unit", that is, the next time it is called, it finds its status as it was left.
The obvious problem with persistent CGI, is that for a given program there are potentially several copies waiting to be called back, and each copy is related to a different user. You would not like to have such responsibilities be randomly mixed up. To solve this problem, it is a program responsibility to give a "ticket" (technically speaking, a "handle") to each next program invocation.
The next problem is that a persistent CGI cannot wait forever to be called back. An HTTP controlled timeout will kill any persistent CGI session waiting over a given number of seconds. At this point, the user may need to re-start his transaction cycle from the beginning.

Because of this second problem, the implementation of persistent CGI is not very frequent and left to cases where a COMMIT technique is mandatory.

Our recommendation is not to use persistent CGI, unless strictly necessary. Persistent CGI

• do not perform faster than non-persistent CGI
• require much more skill and testing
• may not provide a user-friendly solution

However, should you like to know more on this subject, this what we wrote for ILE-RPG CGI, which also fully applies to ILE-COBOL CGI.