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] > > ---------------------------------------------------------------------- > 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
