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