The System360 Model 20 Wasn't As Bad As All That 3871

360-67 had high resolution time so that the low-order bit tic'ed at about 300*256 times-sec, approx every 13mics ... as opposed to tic'ing one of the higher order bits at lower resulution. the period of the 32bit location 80 timer stayed the same (approx 15.5hrs).

there were other ways that they gamed the system ... but i closed just about all of them ... initially with cp67 infrastructure rewrite i did as an undergraduate ... recent comment in this thread:

and then later (when most of it was dropped in the cp67 to vm370 morph), re-introduced it for vm370 as the resource manager (11may76) ... recent 11may76 reference (dated 10may06):

part of the infrastructure change (both cp67 and vm370) was tracking process recent resource consumption rate (as opposed to straight resource consumption) and adjusting end order based on process resource consumption rate compared to the process's target resource consumption rate (with some finagling to handle edge conditions) ... with fair share being the default target resource consumption rate

for a little drift when I got into doing high-speed data transport project (hsdt)

i also did a rate-based implementation. my buttertion has been that the reason that window-based network implementations being much more prevalent was because most of the platforms from that period had such deplorable timer facilities. recent post that strayed into network rate-based control

quick & dirty conversion of ios3270 greencard to html has details on the 370 64bit clock-timer. the 360 "low-resolution" location 80 timer was initially carried forward into 370 (but later dropped) ... but if you wanted higher resolution, you had to use the new 370 64bit clock and time facilities.

the 360 32bit timer was defined at storage location 80 (x'50'), location x'54' and location x'4C' were "undefined". cp67 (to avoid "loosing" tics) ... saved current value at location x'54', stored a new value at location x'54' and then did an "overlapping" move instruction:

mvc x'4C'(8),x'50'

which moved the eight bytes starting at location x'50' to location x'4C', i.e. the current timer value at x'50' was moved to x'4C' and the new timer value at x'54' was moved to x'50', in one instruction w-o loosing a timer tic. then the difference was calculated between the value just moved into x'4C' and the value just previously saved from x'54' (which would have been the previous initial timer setting) ... before overlaying x'54' with the new timer value.

In the morph from cp67 to vm370 to use the higher resolution timers (effectively in timer registers ... not storage addressable), there was the possibility of loosing a timer tic ... since two separate instructions were required to save current value and then load new value; first doing a STPT lovexx

to save the current interval timer, followed by a SPT yyyyy

to load the new value.

More detailed discussion of timers from esa-390 principles of operation:

STPT, store cpu timer

SPT, set cpu timer: