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
