The first example of section may help to clarify what is going on. When PY2ENT is called to generate a pair, the quarks are stored in lines 1 and 2 of the event record, respectively. Colour information is set to show that they belong together as a colour singlet. The counter N is also updated to the value of 2. At no stage is a previously generated event removed. Lines 1 and 2 are overwritten, but lines 3 onwards still contain whatever may have been there before. This does not matter, since N indicates where the `real' record ends.
As PYEXEC is called, explicitly by you or indirectly by PY2ENT, the first entry is considered and found to be the first parton of a system. Therefore the second entry is also found, and these two together form a colour singlet parton system, which may be allowed to fragment. The `string' that fragments is put in line 3 and the fragmentation products in lines 4 through 10 (in this particular case). At the same time, the and in the first two lines are marked as having fragmented, and the same for the string. At this stage, N is 10. Internally in PYEXEC there is another counter with the value 2, which indicates how far down in the record the event has been studied.
This second counter is gradually increased by one. If the entry in the corresponding line can fragment or decay, then fragmentation or decay is performed. The fragmentation/decay products are added at the end of the event record, and N is updated accordingly. The entry is then also marked as having been treated. For instance, when line 3 is considered, the `string' entry of this line is seen to have been fragmented, and no action is taken. Line 4, a , is allowed to decay to ; the decay products are stored in lines 11 and 12, and line 4 is marked as having decayed. Next, entry 5 is allowed to decay. The entry in line 6, , is a stable particle (by default) and is therefore passed by without any action being taken.
In the beginning of the process, entries are usually unstable, and N grows faster than the second counter of treated entries. Later on, an increasing fraction of the entries are stable end products, and the rôles are now reversed, with the second counter growing faster. When the two coincide, the end of the record has been reached, and the process can be stopped. All unstable objects have now been allowed to fragment or decay. They are still present in the record, so as to simplify the tracing of the history.
Notice that PYEXEC could well be called a second time. The second counter would then start all over from the beginning, but slide through until the end without causing any action, since all objects that can be treated already have been. Unless some of the relevant switches were changed meanwhile, that is. For instance, if decays were switched off the first time around but on the second, all the 's found in the record would be allowed to decay in the second call. A particle once decayed is not `undecayed', however, so if the is put back stable and PYEXEC is called a third time, nothing will happen.