I agree. The IBM developer who's on this listserv gave me the code for IDCAMs and saved me a lot of effort. The other program I tested in our z/os 1.12 environment and works with a ddname last override which was a big surprise. My problem is I have a customer who tried this and it S0C4-11 . I saw abendaid causing a u4039-8 abend twice and LE CEEHSRP , the resume point module get involved.
I wondered if the customers didn't have the right security permissions, in this case ACF2 in place and we opened the file then a read and 0C4ed ... Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Feb 9, 2013, at 2:12 PM, "Joel C. Ewing" <[email protected]> wrote: > So this is indeed now the behavior documented for the 14 specific IBM > utilities in z/OS V1R12.0 DFSMSdfp Utilities, which means those 14 programs > have now all been modified to accept a ddname list, and apparently IDCAMS > plays by same game (separately documented, I believe). I wasn't aware that > all of these had been enhanced. From your first remarks it sounded like you > were talking about an arbitrary program, for which one couldn't make > assumptions, rather than ones for which this behavior was explicitly > documented. > > At least a quick scan of the exits section of the same referenced manual > shows no relevant exits to in for the utilities in that manual. Presumably > one would have to look in the manuals specific to each utility for those > utilities that are documented separately. I would be a little surprised to > see such an exit, as I could see IBM dismissing as marginally useful an exit > to allow manipulation of parameters in an programming interface that was > already totally controlled external to the utility. > Joel C Ewing > > On 02/09/2013 12:03 PM, Scott Ford wrote: >> Also that wasn't what I was asking ...I was asking about dfsmsdfp exits that >> could intercept the new ddnames .....li understand that utilities have their >> address list passed to them. >> >> Scott ford >> www.identityforge.com >> >> Tell me and I'll forget; show me and I may remember; involve me and I'll >> understand. - Chinese Proverb >> >> >> On Feb 9, 2013, at 12:46 PM, "Joel C. Ewing" <[email protected]> wrote: >> >>> If you are saying you expect alternate DDNAME parameters to work with other >>> utility programs or some previously written program for which this feature >>> is not documented because it works with IDCAMS, that is unreasonable. >>> Standard MVS calling linkage conventions only define how to pass >>> parameters. The meaning attached to those parameters is totally up to the >>> called program and undocumented behavior should not be expected. In the >>> standard MVS program environment, unlike UNIX environments, there is no >>> concept of a STDIN/STDOUT/STDERR that is always available to a program and >>> always externally changeable. >>> >>> If you are saying you are attempting to pass alternative DDNAME parameters >>> to a program of your own design and it's not working, then you would need >>> to confirm that the DDNAMEs are allocated with attributes consistent with >>> the called program's requirements (either statically via DD statements or >>> dynamically by either the caller or callee program) and that the called >>> program is designed to properly extract the passed DDNAMEs from the >>> parameter list and plug those names into the appropriate intended DCB >>> control blocks within the called program prior to OPEN time. >>> >>> A utility that has a documented parameter list that includes alternate >>> DDNAMEs could of course conceivably have an exit specific to that utility >>> that could modify a passed parameter list, but as Paul has already remarked >>> there wouldn't be any generic DFSMS exit that would do this, as the meaning >>> and structures associated with the list of addresses passed in a parameter >>> list is not restricted and potentially unique for each unique called >>> program. >>> Joel C Ewing >>> >>> On 02/09/2013 10:27 AM, Scott Ford wrote: >>>> Gil, >>>> >>>> You can rant but it works in a call also for IDCAMs, I prefer the attach >>>> but I am dealing with a single thread application of not my design .. >>>> >>>> Scott ford >>>> www.identityforge.com >>>> >>>> Tell me and I'll forget; show me and I may remember; involve me and I'll >>>> understand. - Chinese Proverb >>>> >>>> >>>> On Feb 9, 2013, at 9:36 AM, Paul Gilmartin <[email protected]> wrote: >>>> >>>>> On Fri, 8 Feb 2013 20:40:27 -0500, Scott Ford wrote: >>>>>> I am calling a program passing an alternate ddname list for >>>>>> sysin/sysprint. Are there dfsms exits that will prevent me from doing >>>>>> this ? >>>>> Seems unlikely, since the alternate DDNAME list is merely a >>>>> second PARM (out of possibly many) that may be passed to >>>>> any program. An exit would need to know the characterists >>>>> of the CALLed (LINKed, ATTACHed) program to know whether >>>>> a PARM is in fact a ddname list and whether to intervene. >>>>> Does any exit even get control at a CALL? >>>>> >>>>> However, it's prerogative the called program to decide how >>>>> or whether to process a second PARM as an alternate ddname >>>>> list. Typically, z/OS utilities do this; many application programs >>>>> might not. >>>>> >>>>> <RANT> >>>>> This design is wrong! The alternate DDNAME list should be a >>>>> parameter to ATTACH, not passed to the ATTACHED program, >>>>> to which the remapping of DDNAMEs should be transparent; >>>>> invisible. And such DDNAME mapping should apply to all >>>>> ATTACHED programs, not only those that choose to implement >>>>> the support. Someone here once said he had achieved much >>>>> (not all) of this effect with SVC screening. >>>>> </RANT> >>>>> >>>>> -- gil >>>>> >>>>> - >>> >>> -- >>> Joel C. Ewing, Bentonville, AR [email protected] > > > -- > Joel C. Ewing, Bentonville, AR [email protected] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
