On 11 Aug 2007 09:19:38 -0700, in bit.listserv.ibm-main you wrote: >-------------------------------<snip>---------------------- >Does anybody know why the people who designed SMF decided to encode the >date and time as FL4'hundredths of seconds after midnight' plus >PL4'0cyyddd'? Why not just put in the STCK value? STCK is guaranteed to >be unique on a system (and on a sysplex). I ask because I want to relate >all the SMF records generated by a specific job together. Unfortunately, >I have some people who submit 4 or 5 jobs with the same name which end >up with the same SMF "joblog" value (they are basically IEFBR14 jobs). >If SMF used STCK, then the STCK value alone could be used to guarantee >uniqueness. >-----------------------------<unsnip>----------------------- >I can think of two reasons: > >1. STCK instruction didn't exist when SMF was designed. All we had was >the interval timer and the TIME macro only returned DEC, TU and BIN >values. (IIRC a TU value was timer units and a timer unit was between 26 >and 27 microseconds.) > >2. I know of NO guarantee that TOD values are unique across ANY LPAR or >CEC boundaries. To assure uniqueness across those boundaries, AFAIK, >you'll have to program some value into the programmable field of the >ETOD, and use THAT value. Are you prepared to rewrite SMF and related >system processing? Not to mention all the hundreds of thousands of >programs designed to gather, consolidate and report on SMF data?
This brings up a very interesting question, how much of z/OS is now constrained to very low limits for historical reasons and the difficulty of change. 8 character ids (job, user, etc.), 2 levels of stepname, 44 character datanames and 8 character member name come to mind. The increased size of a time stamp has some value and at some point, it should be worth while to increase all of the limits for at least "new" style entities such as VSAM related data names (should we allow GDGs for KSDSs?), whatever will supplant jobs as we move to a more capable batch system, and so forth. Managing transitions is never easy and I hope someone has been looking at this and not taking the shortsighted view that was done with regard to FBA. There are many limitations in z/OS that make it look antiquated and ill thought when compared to other platforms. Limitations that made sense on 2314s and 256K OS360 are increasingly archaic. Yes some very large number of SMF programs will be affected as will the guts of many of the system services by field expansion. It may be better to provide old facility and new facility over some period of time. I just hope that the solution isn't a kludge. > >> rest snipped ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
