Re: ISV Anchor Table
At 08:55 -0400 on 08/31/2006, Bob Shannon wrote about Re: ISV Anchor Table: If I were doing it, I'd allocate a reasonable size table with room for expansion (ie: Empty Slots past the currently assigned slot number). A 4K table, has room for 1024 Slots/ISVs. Even a 1K table has room for 256 slots. Either 1K or 2K should be more than enough for the foreseeable future needs based on the 1 Slot per ISV method without the need to expand it via maintenance. Why do you think IBM did anything other than that? Bob Shannon Rocket Software I never said (or intended to imply) that IBM did not wildly over-allocate the table size (since the extra space is insignificant as I indicated) to avoid the running out of slots that the original querent asked about (ie: [paraphrasing] What will happen if IBM runs out of slots to assign and a PTF to expand the table size needed to be issued?). I was just responding to say what I would do and neglected to qualify it with something on the order of and I assume that IBM did something on this order. -- 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
Re: ISV Anchor Table
If I were doing it, I'd allocate a reasonable size table with room for expansion (ie: Empty Slots past the currently assigned slot number). A 4K table, has room for 1024 Slots/ISVs. Even a 1K table has room for 256 slots. Either 1K or 2K should be more than enough for the foreseeable future needs based on the 1 Slot per ISV method without the need to expand it via maintenance. Why do you think IBM did anything other than that? Bob Shannon Rocket Software -- 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
Re: ISV Anchor Table
On Fri, 25 Aug 2006 17:43:54 -0400, Craddock, Chris [EMAIL PROTECTED] wrote: Peter Relson doles out anchor table slots on request (one per vendor). As an employee of an ISV who'se product could make good use of this feature, I've some questions that perhaps Peter could answer. Q1) What are the criteria for being allocated an ISV Anchor Table slot? Presumably it's more than just ask and you'll get one. Q2) Assuming we meet the criteria what is the process for getting one? Q3) Assuming a slot was allocated would it be in z/OS 1.8 and above or could it be retro fitted to earlier supported levels? If this is all documented somewhere perhaps you could point me at the doc. Regards, Ron MacRae. -- 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
Re: ISV Anchor Table
Ron MacRae asks Craddock, Chris wrote: Peter Relson doles out anchor table slots on request (one per vendor). As an employee of an ISV who'se product could make good use of this feature, I've some questions that perhaps Peter could answer. Q1) What are the criteria for being allocated an ISV Anchor Table slot? Presumably it's more than just ask and you'll get one. I am not aware of any specific criteria, but I would assume that a Partnerworld membership ought to be sufficient. In theory vendors get exactly one slot in the table, but a few have ended up with more as a result of MA. but realistically you only need one. Q2) Assuming we meet the criteria what is the process for getting one? Send an email to Peter Relson and ask politely. (Yeah, its that formal :) Q3) Assuming a slot was allocated would it be in z/OS 1.8 and above or could it be retro fitted to earlier supported levels? The table is just a contiguous block of SQA allocated during IPL and is (as far as I know) more than enough to accommodate all of the current users. If the table needed to expand, I imagine IBM would deliver service to do that and you might get involved in notifying your customers that they need to apply said maintenance before running your product. I've never seen it expand (yet) but I can't say for sure it won't. If this is all documented somewhere perhaps you could point me at the doc. Oh surely you jest. This is tribal knowledge. There is no doc. CC -- 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
Re: ISV Anchor Table
Ron MacRae wrote: On Fri, 25 Aug 2006 17:43:54 -0400, Craddock, Chris [EMAIL PROTECTED] wrote: Peter Relson doles out anchor table slots on request (one per vendor). As an employee of an ISV who'se product could make good use of this feature, I've some questions that perhaps Peter could answer. Q1) What are the criteria for being allocated an ISV Anchor Table slot? Presumably it's more than just ask and you'll get one. Q2) Assuming we meet the criteria what is the process for getting one? Q3) Assuming a slot was allocated would it be in z/OS 1.8 and above or could it be retro fitted to earlier supported levels? If this is all documented somewhere perhaps you could point me at the doc. If you know Peter -- and he knows you -- you can probably just ask. But, I suspect the expected procedure is that you go through your normal PWD contacts just like you do for everything else. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: ISV Anchor Table
At 09:29 -0400 on 08/30/2006, Craddock, Chris wrote about Re: ISV Anchor Table: The table is just a contiguous block of SQA allocated during IPL and is (as far as I know) more than enough to accommodate all of the current users. If the table needed to expand, I imagine IBM would deliver service to do that and you might get involved in notifying your customers that they need to apply said maintenance before running your product. I've never seen it expand (yet) but I can't say for sure it won't. If I were doing it, I'd allocate a reasonable size table with room for expansion (ie: Empty Slots past the currently assigned slot number). A 4K table, has room for 1024 Slots/ISVs. Even a 1K table has room for 256 slots. Either 1K or 2K should be more than enough for the foreseeable future needs based on the 1 Slot per ISV method without the need to expand it via maintenance. -- 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
Re: ISV Anchor Table
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Craddock, Chris [ snip ] You build your own stuff in a block of common storage (typically ECSA or ESQA) and place its address in your designated slot. Once its there you can access your own stuff from any address space by a sequence of 4 loads. That has the advantages of being blindingly fast and about as complicated as a bowling ball. Even at that, there are still some folks who can f%%% up an anvil with a rock. -jc- -- 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
Re: ISV Anchor Table
I don't know of any IBM recommended prefixing for the name:token. As with almost anything, IBM recommends that you begin the name with some 3-character prefix owned by your company/product. And that usually means to stay away from A-I or SYS (with exceptions of course for prefixes within A-I owned by other companies. Peter Relson z/OS Core Technology Design -- 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
ISV Anchor Table
Does anyone know anything about this? A table that is pointed to off the CVT/ECVT that contains pointers for ISVs to anchor things? I'd heard something about this in the mid-90s and I've drunk a few beers since then. Later, Steve Thompson -- 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
Re: ISV Anchor Table
It's called the Customer Anchor Table and it's hung off the ECVT. Any vendor that requests a slot (FW) can get one. Bob Shannon -- 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
Re: ISV Anchor Table
In a message dated 8/25/2006 1:30:49 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Does anyone know anything about this? A table that is pointed to off the CVT/ECVT that contains pointers for ISVs to anchor things? Check the IBM-MAIN archives. Many older posts. Bill Fairchild -- 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
Re: ISV Anchor Table
Peter Relson manages the allocation of ISV slots in table. You only get a fullword slot, so use it wisely. Be sure all of your products have a common protocol for managing it. ECVTCTBL points to the array of customer anchors. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon Sent: Friday, August 25, 2006 12:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ISV Anchor Table It's called the Customer Anchor Table and it's hung off the ECVT. Any vendor that requests a slot (FW) can get one. Bob Shannon /snip/ -- 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
Re: ISV Anchor Table
Thanx to all who answered this. I'm having a Senior Week. Ok, since I originally did work with this when it was first announced I've had a few beers to drink. And I just couldn't remember clearly. [And they want to blame it on us guys/gals being older than 40!] Later, Steve Thompson -- 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
Re: ISV Anchor Table
At 12:38 -0600 on 08/25/2006, Jeffrey D. Smith wrote about Re: ISV Anchor Table: Peter Relson manages the allocation of ISV slots in table. You only get a fullword slot, so use it wisely. Which is all you need until you want your table to be in 64-bit addressable storage (at which point you just point your fullword to a doubleword with the real anchor address). -- 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
Re: ISV Anchor Table
In a recent note, Jeffrey D. Smith said: Date: Fri, 25 Aug 2006 12:38:30 -0600 Peter Relson manages the allocation of ISV slots in table. You only get a fullword slot, so use it wisely. Be sure all of your products have a common protocol for managing it. ECVTCTBL points to the array of customer anchors. When is this preferable to name/token services? When is name/token services preferable? Is there any protocol such as prefix registration to prevent collisions in name/token services? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: ISV Anchor Table
ECVTCTBL points to the array of customer anchors. When is this preferable to name/token services? When is name/token services preferable? Is there any protocol such as prefix registration to prevent collisions in name/token services? Peter Relson doles out anchor table slots on request (one per vendor). The implied purpose of the customer anchor table is to allow each vendor to have a global skyhook. It basically amounts to a CVT for your own products. You build your own stuff in a block of common storage (typically ECSA or ESQA) and place its address in your designated slot. Once its there you can access your own stuff from any address space by a sequence of 4 loads. That has the advantages of being blindingly fast and about as complicated as a bowling ball. There is no serialization protocol that I am aware of and (based on personal experience) only a handful of vendors actually exploit it anyway. I can't imagine NOT using it. CC -- 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
Re: ISV Anchor Table
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, August 25, 2006 3:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ISV Anchor Table In a recent note, Jeffrey D. Smith said: Date: Fri, 25 Aug 2006 12:38:30 -0600 Peter Relson manages the allocation of ISV slots in table. You only get a fullword slot, so use it wisely. Be sure all of your products have a common protocol for managing it. ECVTCTBL points to the array of customer anchors. When is this preferable to name/token services? When is name/token services preferable? Is there any protocol such as prefix registration to prevent collisions in name/token services? -- gil /snip/ CTBL is useful for referencing common area control blocks. The name:token service has system-level, primary-space-level, home-space-level, and task-level scopes for the names. The system-level is visible by all address spaces, so you must be careful to avoid name collisions. The primary-space-level and home-space-level are visible only within the particular address space. The name won't collide with an unrelated address space. The task-level is visible only to the task that defines the name. The name won't collide with names used by other tasks or with address space level names or system-level names. I use both name:token services and the CTBL thing. I don't know of any IBM recommended prefixing for the name:token. What I DO know is that I can find my cryptographic global control block with 5 load instructions using CTBL, or an unknown number of instructions using name:token services. So, I think the CTBL thing is always faster than name:token services, and I don't have to worry about naming conventions. Currently, I must sniff the retrieved token to see if it looks like what I expect, to avoid a possible collision with someone else who happens to be using the same name (unlikely -- but I must verify it). My CTBL chaining is designed for backward compatibility. I can grow my pointer vectors in any direction for multiple products and still be compatible with my older software that doesn't know about the new stuff. I don't need working storage for looking at CTBL. I do need working storage for name:token services. I will probably continue to use name:token services in addition to the CTBL. CTBL seems to be more efficient and easier to use. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ -- 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
Re: ISV Anchor Table
Based on the inof I got this is the list I build into SHOWzOS (Remember I start with SLOT 1) ISVNAMES TABLE 9,'BMC Mainview' TABLE 12,'Computer Associates' TABLE 21,'BMC Mainview' TABLE 25,'MVS Solutions ThruPut Manager'RS1205 TABLE 31,'Compuware Strobe' TABLE 34,'Computer Associates (Sterling)' TABLE 36,'Syncsort' TABLE 44,'BMC Control-O' TABLE 46,'IBM IMS Connect' TABLE 58,'ASG TMON' TABLE 61,'DKL tableBASE' Gary Weinhold TABLE 75,'Cole Software XDC' TABLE 76,'IBM Healthchecker' Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Friday, August 25, 2006 11:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ISV Anchor Table ECVTCTBL points to the array of customer anchors. When is this preferable to name/token services? When is name/token services preferable? Is there any protocol such as prefix registration to prevent collisions in name/token services? Peter Relson doles out anchor table slots on request (one per vendor). The implied purpose of the customer anchor table is to allow each vendor to have a global skyhook. It basically amounts to a CVT for your own products. You build your own stuff in a block of common storage (typically ECSA or ESQA) and place its address in your designated slot. Once its there you can access your own stuff from any address space by a sequence of 4 loads. That has the advantages of being blindingly fast and about as complicated as a bowling ball. There is no serialization protocol that I am aware of and (based on personal experience) only a handful of vendors actually exploit it anyway. I can't imagine NOT using it. CC -- 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 -- 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
