The STCKE value is guaranteed to be unique with the bounds of a sysplex (as long as you don't shrink the significant number of bits).
Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joel C. Ewing Sent: 08 September 2010 14:26 To: IBM-MAIN@bama.ua.edu Subject: Re: Need a simple counter On 09/08/2010 02:35 AM, Rob Scott wrote: > Miklos, > > Generating a sysplex-wide "token" value is a very simple process - but having > a counter that is only updated (or reset) by permitted tasks on each system > presents much more of a programming challenge and would in turn require some > sort of runtime options to dictate how the "counter" is handled in normal and > abnormal circumstances (for example, what to do if the creating > TCB/ASID/SYSTEM goes away unexpectedly). > > If you do not care about the counter contents and just want some sort of > permanently increasing value then you might get some usage from the > STCK/STCKE instruction. > > Rob Scott > Lead Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of Miklos Szigetvari > Sent: 08 September 2010 07:37 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Need a simple counter > > Hi > > I understand "not so simple", but the problem is why not , at last in > processor level > If you compare the effort to get a unique key with the large number of > new, sometimes "exotic" , machine instructions > you can ask Why it is so. Why don't get a counter from the CPU or with > some simple system call ? > > On 9/7/2010 10:29 PM, john gilmore wrote: >> The OP asked for a perhaps SYSPLEX-wide facility. The CF-based approach I >> suggested is probably a minimal way to meet this requirement. >> >> For those of you who have not looked at such problems in any detail itr is >> perhaps appropriate to recall that SYSPLEX-wide data sharing poses >> significant, non-trivial problems. >> >> It is not neurosurgery, but It certainly cannot be done in COBOL, which, >> whatever its other merits, is not a systems-implementation language. >> >> You must write authorized code; and you need the appropriate design and >> testing skills, as I made clear in my original post. If you don't have them >> you should think about getting an ISV who does to do the job for you. >> >> John Gilmore Ashland, MA 01721-1817 USA >> ... Rob, When using any technique other than a unique counter you have to beware of unexpected effects caused by a change in hardware or a change in transaction volume. We have had cases in the past of CICS transactions using a unique value derived from TOD value (they always want a unique value with fewer bits than TOD) suddenly consuming ten times the expected CPU resource on a new box. The application had a spin loop retrying when a non unique value was found which could be executed many more times on the faster processor before the least significant bit they were using changed. We have also had cases where a quasi-pseudo random value was generated (I call it "quasi" because I'm sure no formal attempt was made to see if it passed any of the customary randomness tests) and used as a "unique" key, retrying if the key was already in use. This worked fine as long key range was very large compared to the number of entries, but you can guess what happened to performance when the number of records increased greatly over time and an attempt to reuse a "unique" key became a common rather than a rare event. A counter is the only way to guarantee uniqueness with the fewest number of bits. And in both the examples referenced above the transaction rate was way too high to consider maintaining a counter value in some external file. -- Joel C. Ewing, Fort Smith, AR jcew...@acm.org ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
