Joel, This. Is
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idau100%2Fu1245.htm Works fine with ddname list as explained to me from IBM 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
