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
Re: Name/Tokens
Peter Relson of the IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/12/2008 07:14:39 AM: I obviously stirred up a hornet's nest. Good. What about the scenario of you quitting IBM and going to work for Dave Cole? Regards, John K -- 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: Name/Tokens
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: IBM-MAIN@BAMA.UA.EDU 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
Re: Name/Tokens
On Fri, 12 Sep 2008 09:48:16 -0400, Rob Scott [EMAIL PROTECTED] wrote: ... 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. ... Sometimes there are very unusual situations like a debugging tool so useful that IBM makes arrangements to OEM it, but finds that the tool uses unsupported interfaces. One part of IBM can't use the tool (without some major rewriting it wants to avoid) because another part of IBM didn't provide an official interface. So IBM avoids the whole problem by purchasing another vendor of tools. Now, that might be apocryphal, and NDAs prevent me from being more specific, but I suspect some readers of this list know the detals a lot better than I do. And no, I don't really think that IBM bought Candle just to get around rewriting a tool that used unsupported interfaces. In any case, useful tools will be written to display useful information whether or not supported interfaces are available to gather the data. And whether or not access to that information ever reaches the level of need. And even IBM can suffer from the lack of those supported interfaces. Pat O'Keefe -- 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: Name/tokens
Every response to my query seems to have missed the point and put the cart before the horse. I don't disagree that it is desirable to have a list service for name/tokens. What I question is the need. Since a list service does not exist, it seems pretty clear to me that you should not take an approach that requires such a service. You are welcome of course to ask for such a service and, after/if it is made available, exploit it. 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
Re: Name/tokens
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. If vendors waited for IBM to produce GUPI interfaces for everything they need, there would be no vendor code. 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: Name/tokens
This is a bizarre response, Peter. Several of us have documented our need for a name/token list/search service, a need that we've felt strongly enough about to actually go to the trouble of writing complicated workarounds to your failure to fulfill that need. What more do you want by way of demonstrating a need? it seems pretty clear to me that you should not take an approach that requires such a service. Our needs dictate our approaches, Peter. If you feel that my product does not need a list/search service, then feel free to quit IBM and come work for me and find a better way to code to my product's needs. If you feel that we are not competent enough to correctly determine our own needs, then why are you even talking to us? David Cole At 9/11/2008 07:28 AM, Peter Relson wrote: Every response to my query seems to have missed the point and put the cart before the horse. I don't disagree that it is desirable to have a list service for name/tokens. What I question is the need. Since a list service does not exist, it seems pretty clear to me that you should not take an approach that requires such a service. You are welcome of course to ask for such a service and, after/if it is made available, exploit it. 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
Re: Name/tokens
On Thu, 11 Sep 2008 07:28:24 -0400, Peter Relson [EMAIL PROTECTED] wrote: ... I don't disagree that it is desirable to have a list service for name/tokens. What I question is the need. Since a list service does not exist, it seems pretty clear to me that you should not take an approach that requires such a service. You are welcome of course to ask for such a service and, after/if it is made available, exploit it. ... But with that logic it is very tough to justify an assembler (let alone a high level language) or just about any utility ever created. There is always another, lower level technique for doing anything so there is no need for a better tool. If people have written their own tools they must have felt some need (even if it was just a need to experimment). If they made it available to others they must have felt that others also had the need. 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. Pat O'Keefe -- 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: Name/tokens
On Thu, 11 Sep 2008, Patrick 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. Pat O'Keefe I agree with you on that. However, being the SOB (Swell Ol' Boy) that I am, I wonder how well IBM's S/360 MVT would have faired against the other vendors' hardware and software if IBM had started OS/360 as closed source and had the attitude of if you need something, ask us and if you make a good enough economic argument about how __we__ will make some money off of it, we'll look at putting in an interface to do that. Of course, back then it was all about selling the hardware. Software was an after thought, so to speak. Today, it is about selling services and software with the hardware just along for the ride (more or less). I know, different times, different techniques. This is why I'm a Linux bigot now. The source is available. Thanks to the GPL, it will always be available. You want to modify the kernel? Fine, feel free. You break it, you bought it! BTW - to the person who said that eventually the System z software stack will likely be on Intel - I doubt it. But, on Power? That might be nice! A single box, running a hypervisor, and running all the iSeries, pSeries, and zSeries software on it. drool. After, the iSeries runs on Power via a sort of emulation. If I had an AIX box available to me, I'd love to see how Hercules/390 (not an optimally performing emulation) runs on it. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- 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: Name/tokens
I have a need to traverse all system level name/tokens on an lpar. Care to enlighten the group why such a need exists? 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
Re: Name/tokens
Peter, In the past, I have seen software that uses part of the name as a constant prefix and then places variable information in the later part of the name (maybe ASID, TCB or subsystem instance or whatever the developer wanted) - I imagine this can happen when the token part is already full. In this case the ability to list the name/tokens for search purposes would be desirable. From a purely generic perspective, if there is a service to create and delete a thing - the ability to list all things seems to me to be a fundamental function. 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: 10 September 2008 12:20 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens I have a need to traverse all system level name/tokens on an lpar. Care to enlighten the group why such a need exists? 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
Re: Name/tokens
Rob Scott wrote: From a purely generic perspective, if there is a service to create and delete a thing - the ability to list all things seems to me to be a fundamental function. Agreed. For example, when you acquire storage areas using the STORAGE macro, you can list them using VSMLIST. When you acquire storage objects using IARV64, you can list them using IARV64. VSMLIST appeared only after people realized the need to list memory areas existed. The developers of IARV64 learned the lesson well. Similar story for GQSCAN/ISGQUERY to list ENQs, CSVQUERY to list LOADed modules, and many others. There ought to be a way to list name/tokens. Several popular programs do it without a service. This has been discussed before. -- 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: Name/tokens
At 9/10/2008 09:50 AM, Rob Scott wrote on IBM-MAIN: Peter, In the past, I have seen software that uses part of the name as a constant prefix and then places variable information in the later part of the name (maybe ASID, TCB or subsystem instance or whatever the developer wanted) - I imagine this can happen when the token part is already full. In this case the ability to list the name/tokens for search purposes would be desirable. Ditto. z/XDC used to keep track of certain control data via ENQs. The RNAMEs all were control data that started with an identifying keyword followed by specific data. I could then use GQSCAN to search for and return all instances of a desired control data type simply by specifying a GENERIC scan for the first n bytes of the RNAME. Some 6 or 8 years ago, I had reason to switch from using enqueues and GQSCAN to using name/token services. What should have been a rather straightforwards conversion turned out to be immensely complicated by the fact that name/token services did not in any way support generic searches! It was a major P.I.T.A.! That's my nickel's worth. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: Name/tokens
David Cole wrote: z/XDC used to keep track of certain control data via ENQs. The RNAMEs all were control data that started with an identifying keyword followed by specific data. I could then use GQSCAN to search for and return all instances of a desired control data type simply by specifying a GENERIC scan for the first n bytes of the RNAME. We still have software that does this. It's immensely useful to be able to list objects that have been created for your task, address space, system, or sysplex. ENQ/GQSCAN/ISGQUERY does this nicely. Name/Token? Not so much (or at all). -- 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: Name/tokens
Maybe this affects us more than 'real' z/OS users because we are all in development. From my local experience in Rocket, I know that Name/Token is very popular in a lot of software that we write - and the MXI command NTOK that displays the system-level ones is used a lot - so much so that in the next version of MXI I have changed the collector to be an SRB so that it can show ASID/TCB level tokens from any address space as well. A supported callable service to do this would be preferable to the non-GUPI control block chasing that I currently have to do... 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 Edward Jaffe Sent: 10 September 2008 18:00 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens David Cole wrote: z/XDC used to keep track of certain control data via ENQs. The RNAMEs all were control data that started with an identifying keyword followed by specific data. I could then use GQSCAN to search for and return all instances of a desired control data type simply by specifying a GENERIC scan for the first n bytes of the RNAME. We still have software that does this. It's immensely useful to be able to list objects that have been created for your task, address space, system, or sysplex. ENQ/GQSCAN/ISGQUERY does this nicely. Name/Token? Not so much (or at all). -- 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 -- 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: Name/tokens
From a purely generic perspective, if there is a service to create and delete a thing - the ability to list all things seems to me to be a fundamental function. agree. It's immensely useful to be able to list objects that have been created I have always been one to poke around in the system. You find out how stuff works; every bit of knowledge is useful. But in this case, I am not sure what I would learn by knowing the name/tokens. How would I use the information? More interesting to me might be who created what name/tokens (even then, the benefit of knowing it is hazy). Is ownership kept in the control blocks? Pedro Vera -- 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: Name/tokens
Rob Scott wrote: Maybe this affects us more than 'real' z/OS users because we are all in development. Ummm. That's true of *all* programming services provided by the operating system. We use them every day. Average users do not. -- 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: Name/tokens
A small amount of ownership info is kept in the control block that describes the name/token entry - for example it contains the ASID and TCB. However, I would *love* to see the following information added : JOBNAME of creator STOKEN of creator STCK of creation The usefullness of seeing the tokens is proportional to your knowledge of what either/both the name and token refer to. I find that displaying the name/tokens help during interactive debug sessions of my own code as I use them to anchor each task and its associated end-of-task exit routine. 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 Pedro Vera Sent: 10 September 2008 18:15 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens From a purely generic perspective, if there is a service to create and delete a thing - the ability to list all things seems to me to be a fundamental function. agree. It's immensely useful to be able to list objects that have been created I have always been one to poke around in the system. You find out how stuff works; every bit of knowledge is useful. But in this case, I am not sure what I would learn by knowing the name/tokens. How would I use the information? More interesting to me might be who created what name/tokens (even then, the benefit of knowing it is hazy). Is ownership kept in the control blocks? Pedro Vera -- 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
Re: Name/tokens
Ooops, just answered my own question. It's a pointer off the ECVT. Sorry. /re - Original Message - From: Rolf Ernst [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, September 9, 2008 8:50:39 AM GMT -06:00 US/Canada Central Subject: Name/tokens Hi, I have a need to traverse all system level name/tokens on an lpar. I vaguely recall that this can be done but for the life of me cannot remember. Does anybody know which chain to follow? /re -- 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
Re: Name/tokens
On Tue, 9 Sep 2008 09:04:03 -0500, Rolf Ernst wrote: just answered my own question. It's a pointer off the ECVT. Sorry. But be careful; that list is updated dynamically with no standard serialization. By following pointers at the wrong time you might find yourself traversing the free list. IBM's token retrieval service knows how to detect an invalid outcome and retry, but it's tricky. I have a need to traverse all system level name/tokens on an lpar. I vaguely recall that this can be done but for the life of me cannot remember. Does anybody know which chain to follow? -- gil -- 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: Name/tokens
On Tue, 9 Sep 2008 09:04:03 -0500, Rolf Ernst [EMAIL PROTECTED] wrote: Ooops, just answered my own question. It's a pointer off the ECVT. Sorry. But note that ECVTNTTP is not an intended programming interface, and you use it at your own risk. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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
Re: Name/tokens
I understand. It's not for use in a production environment. Just a quick and dirty check. /re - Original Message - From: Walt Farrell [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, September 9, 2008 11:34:30 AM GMT -06:00 US/Canada Central Subject: Re: Name/tokens On Tue, 9 Sep 2008 09:04:03 -0500, Rolf Ernst [EMAIL PROTECTED] wrote: Ooops, just answered my own question. It's a pointer off the ECVT. Sorry. But note that ECVTNTTP is not an intended programming interface, and you use it at your own risk. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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
Re: Name/tokens
Walt Farrell wrote: But note that ECVTNTTP is not an intended programming interface, and you use it at your own risk. IBM never provided an intended interface. :-( -- 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: Name/tokens
On Tue, 9 Sep 2008 09:57:41 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Walt Farrell wrote: But note that ECVTNTTP is not an intended programming interface, and you use it at your own risk. IBM never provided an intended interface. :-( Not true, Ed. We have lots of them, and they're all documented as being interfaces. We also have a bunch of things that we do not intend others to use, but people do anyway. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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
Re: Name/tokens
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Tuesday, September 09, 2008 12:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens On Tue, 9 Sep 2008 09:57:41 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Walt Farrell wrote: SNIP IBM never provided an intended interface. :-( Not true, Ed. We have lots of them, and they're all documented as being interfaces. We also have a bunch of things that we do not intend others to use, but people do anyway. SNIP How soon will this INTENDED clause get implemented in COBOL? ;-) Regards, Steve Thompson -- Opinions expressed by the poster are not necessarily those of poster's employer. Any attempt to take this as advice, legal, financial or otherwise, makes this posting null and void. Any attempt to read this without gas will cause carburetion starvation and engine failure may result -- -- 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: Name/tokens
AFAIR the create/delete/retrieve works fine in Cobol. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Tuesday, September 09, 2008 12:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens On Tue, 9 Sep 2008 09:57:41 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Walt Farrell wrote: SNIP IBM never provided an intended interface. :-( Not true, Ed. We have lots of them, and they're all documented as being interfaces. We also have a bunch of things that we do not intend others to use, but people do anyway. SNIP How soon will this INTENDED clause get implemented in COBOL? ;-) Regards, 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: Name/tokens
Walt Farrell wrote: On Tue, 9 Sep 2008 09:57:41 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Walt Farrell wrote: But note that ECVTNTTP is not an intended programming interface, and you use it at your own risk. IBM never provided an intended interface. :-( Not true, Ed. We have lots of them, and they're all documented as being interfaces. We also have a bunch of things that we do not intend others to use, but people do anyway. What are you talking about, Walt???! It should be obvious that I'm not asserting that IBM has never written an intended interface. I'm saying that IBM never provided a Name/Token service to allow you to list/search them. The only way to achieve this is a roll-your-own approach. And, as Paul G. points out, you need to be aware of the serialization (or lack thereof) issues. Jeez! -- 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: Name/tokens
On Tue, 9 Sep 2008 12:32:23 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: What are you talking about, Walt???! It should be obvious that I'm not asserting that IBM has never written an intended interface. I'm saying that IBM never provided a Name/Token service to allow you to list/search them. The only way to achieve this is a roll-your-own approach. And, as Paul G. points out, you need to be aware of the serialization (or lack thereof) issues. Jeez! Sorry, Ed, but I did not interpret your message in that context at all. It seemed like a general snipe at IBM (which, after all, does happen on this list with some regularity when the topic of interface vs non-interface comes up) rather than something related to the OP's question about scanning defined name/token pairs. My apologies. -- Walt Farrell, CISSP IBM STSM, z/OS Security 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
Re: Name/tokens -- Joke reference
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Roland Schiradin Sent: Tuesday, September 09, 2008 2:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens AFAIR the create/delete/retrieve works fine in Cobol. Roland SNIP ID DIVISION : : : : PERFORM ABC-PARAGRAPH WITH INTENDED TO PRODUCE PAYROLL REGISTER : STOP RUN WITH INTENDED TO GOBACK, RETURN, ESW. : This was a LONNNG running joke from back about 1977 when I first heard it. COBOL needs to have an INTENDED clause. Later, Steve Thompson -- Opinions expressed by the poster are not necessarily those of poster's employer. -- -- 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: Name/tokens -- Joke reference
Ok got it. You're welcome -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Roland Schiradin Sent: Tuesday, September 09, 2008 2:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/tokens AFAIR the create/delete/retrieve works fine in Cobol. Roland SNIP ID DIVISION : : : : PERFORM ABC-PARAGRAPH WITH INTENDED TO PRODUCE PAYROLL REGISTER : STOP RUN WITH INTENDED TO GOBACK, RETURN, ESW. : This was a LONNNG running joke from back about 1977 when I first heard it. COBOL needs to have an INTENDED clause. -- 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: Name/tokens -- Joke reference
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Thompson, Steve SNIP ID DIVISION : : : : PERFORM ABC-PARAGRAPH WITH INTENDED TO PRODUCE PAYROLL REGISTER : STOP RUN WITH INTENDED TO GOBACK, RETURN, ESW. : This was a LONNNG running joke from back about 1977 when I first heard it. COBOL needs to have an INTENDED clause. Aren't they waiting for somebody to complete the DWIM macro?? :-) -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: Name/tokens -- Joke reference
On Tue, 9 Sep 2008 15:21:07 -0500, Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Thompson, Steve SNIP ID DIVISION : : : : PERFORM ABC-PARAGRAPH WITH INTENDED TO PRODUCE PAYROLL REGISTER : STOP RUN WITH INTENDED TO GOBACK, RETURN, ESW. : This was a LONNNG running joke from back about 1977 when I first heard it. COBOL needs to have an INTENDED clause. Aren't they waiting for somebody to complete the DWIM macro?? :-) That is next in line after they finish getting the GF button on the processor to work. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
