Peter, My answers are obviously slanted as I work as a developer for an ISV, however ...
>In practice, is it the case that a debugger typically needs to know "what is >the status of this name/token pair" (does it exist, what is the token) more >than "what are all the name/token pairs that I might have created"? My own personal experience I find that both are equally likely and the ability to see them whilst debugging can be as useful as the ability to see the TCB tree. Currently I am in a suituation where my internal and external customers want the software that I write to be able to show them the list of name/tokens and I have to make a choice between not supplying the functionality or running a few OCO control blocks - so I plump for the latter and wrap the code in a couple of layers of recovery code. Is there a need outside of debugging - maybe not - but does that invalidate the requirement? Funnily enough I considered raising a requirement for this very thing a few years back as I hate having to use reverse-engineered OCO control blocks, but I did not in the end because I could not see any way of convincing IBM of the real "business" benefit. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: 12 September 2008 13:15 To: [email protected] Subject: Re: Name/Tokens I obviously stirred up a hornet's nest. Good. Every post basically said "I don't care what are programming interfaces, I am going to use whatever I feel like using". A customer will have very little sympathy with that approach if his system stops working because of it. Not one addressed my point of why you would design an approach that relies on using something that does not exist and forces you to use non-interfaces when other alternatives are available. Dave Cole at least has a different need than most in that he is trying to surface "everything" to his users. In practice, is it the case that a debugger typically needs to know "what is the status of this name/token pair" (does it exist, what is the token) more than "what are all the name/token pairs that I might have created"? Bob Shannon wrote >It seems to me that people wouldn't have gone through the effort of >writing code to list name/tokens if there was an easier way to >accomplish what they needed. Is that a valid assumption? I think not. Especially for the cases that have been mentioned so far. Just because you used one approach with ENQ and GQSCAN does not mean that it is appropriate for you to use the same approach with the names of a name/token pair. Dave Cole write >Several of us have documented our >need for a name/token list/search service, I have seen nothing in what has been posted to far that would constitute such documentation. >If you feel that we are not competent enough to correctly determine our >own needs, then why are you even talking to us? If you need it so strongly, why haven't you asked for it properly/formally? A discussion in IBM-MAIN hardly constitutes submission of a requirement. I might have missed it in the 10+ years that I have been monitoring customer submissions of requirements to the base control program, but I do not recall ever seeing a submitted requirement for such a function, either by an individual or SHARE. It might be the case that even if you ask for something you won't get it. But you're certainly more likely to get it if you ask than if you don't. Again, I understand the desire (OK, need, if you want) for a way to list things For Debugging. That does not mean that there is a need outside of that. Make your case. Present your requirement. It certainly does not mean that you should be designing applications in a way that requires you to violate the rules and possibly puts customers at risk. That last sentence doesn't really apply to Dave, but rather to someone who is trying to shoe-horn the ENQ/GQSCAN approach into name/token with roll-your-own list. Pat O'Keefe wrote >Reading between the lines I see you saying "Submit a Requirement and >justify it." Maybe that requirement should come from users of >the tools that currently use the unsupported techniques. They >would be the ones hurt when the unsupported techniques fail. I probably wasn't direct enough that you had to "read between the lines". Yes, exactly. Actually, it's the customers who are hurt. 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 ---------------------------------------------------------------------- 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
