On Sun, 30 Nov 2025 at 01:25, Brian Westerman < [email protected]> wrote:
> It's not really as much going on as you might think. The counters are for > accounting of automation script related commands, there are 104 discrete > command sets and as each is used the counter for that subset is updated. > Scripts really tend to be pretty small and run in a fraction of a second, > but even on a long running script (something that runs 24x7 for a couple > years), the number of times that any individual command gets processed > tends to be fairly reasonable, but the 7 digits makes sure we won't ever > overrun an individual counter even if they run a continuous looping script > for a few years. For most scripts, the majority of the counters remain > unused, and the 104 ZAP's to initialize them is (mostly) wasted effort. > > The "average" script size is under 25 lines, so the init process is wasted > effort for a great percentage of the 104 fields. > > I'm not sure that I would gain anything from the suggestion of making them > fullword fields. Reducing the limit to a little over 4 billion from 9 > billion is probably not a big deal, but I'm not sure that much is saved > changing the current AP to adding to a Fullword. Am I wrong? > It's not clear to me if you're just incrementing the counters by 1, or if it might be another number. If the increment will always fit in the range -128 -- +127 (i.e. a signed byte) then using either a fullword (ASI) or doubleword (AGSI) instruction would probably be faster than any packed decimal instruction. But that's the incrementing - the initializing could use the same instruction in a loop, or of course MVCL with padding. Tony H.
