Ted MacNEIL started this latest sub-discussion within this thread with:

> I was one of the ones, in Canada, complaining about the constant
> changes in geometry. 3330->3350->3380->3390 (and don't forget
> 'compatability' mode.

Seymour J. Metz responded to Ted:

> Because you didn't use system services to insulate yourself from
> changes.

Rick Fochtman interjected:

> Most of those geometry-related "System Services" didn't exist!

Paul Gilmartin then asked Rick:

> Not even by the advent of the 3390, the "last ever" conversion?

Seymour J. Metz responded to Paul:

> Not even close. Those services came in decades earlier.

Seymour J. Metz then asked Rick:

> What year are you talking about?

To which Rick Fochtman responded:

> Just about the time the 3390 first hit the street. 
> Don't remember the exact year.

And then Mike Schwab interjected:

> Late 1980s with SMS and the 3380 - 3390 transition.  BLKSIZE=0.

Seymour J. Metz rebutted with this:

> Those services were long in the tooth by then.

Shmuel is correct (although that is, of course, not unusual).
    
The TRKCALC routine, at least [I do not remember if the TRKCALC _macro_
appeared this early or not] -- or (as we knew it then) the STAR (System
Track Algorithm Routine) service -- was first introduced with DF/DS
(concurrently with DF/EF) for MVS/SP R1 [what would eventually come to be
called MVS/SP V1 R1, or SP1.1] and was available in January 1981, although
3380 ESP sites had all three long before then (but that's another story). It
was claimed (but I never bothered to verify) that this routine was actually
available pre-MVS/SP1.1, but was not documented; regardless, POK hid it
neatly inside of the existing, well-known 3330/3350 RPS sector calculation
routine pointed to by the CVT using a non-obvious entry linkage, which
survives to this day.
   
There were other, somewhat ad-hoc sector and/or track balance calculations
spread all over MVS and JES2 [and I'm sure JES3]. TRKCALC was, no doubt, an
attempt to eliminate most of those, so that every component didn't need to
RYO. The advent of the cellular DASD devices, which gave SAS so much trouble
(as has been mentioned in previous posts in this thread), necessitated
significant changes to the sometimes-simplistic (albeit working for 3330 &
3350 devices) algorithms used in these disparate ad-hoc routines inside of
MVS and other IBM products. In fact, many attempted to continue to RYO
(i.e., not use TRKCALC) and they got it wrong in some corner cases. I
suspect they got their hands slapped.
    
--  
WB
 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to