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
