Called in LE Cobol ..works fine 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:56 PM, Scott Ford <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
