On Thu, 7 Nov 2013 13:37:54 -0500, Tony Harminc wrote:
>
>Taking that to the extreme one could say that nothing should be coded
>on DD statements, i.e. that programs should deal with DSNAMEs rather
>then the intermediary of DDNAMEs. Which is indeed how most non-z/OS
>systems work.
>
In UNIX, I see the analogue of DDNAME as the descriptor.  If a program
insists on writing to stdout (descriptor 1, analogous to SYSTERM), I can
redirect with:

    program 1>logfile

And, this handled correctly (IMO) by the kernel.  The subject program
needn't process, nor even be aware of, the redirection, in sharp contrast
to the handling of the alternate DDNAME list in OS.  So, I'll take the
view quite opposite to yours.  If the program looks for copybooks
in SYS1.MACLIB, that's an undesirable early binding; if it looks in SYSLIB
that's a preferable late binding that can be deferred until the programmer
codes the JCL.

When I said a couple weeks ago that alternate DDNAMES should be
handled by ATTACH, transparent to the application, someone asked,
"What about programs that scan the TIOT for specific DDNAMEs?"
Alas, that's a relic of the early resource-constrained implementation
of OS.  The requirement for applications to access system control
blocks should be minimized in favor of APIs to obtain their content.
If this had been done, moving the TIOT above the bar (very hypothetical
example) would not impact existing application programs.

>... The late binding provided by DD statements is one of the
>strongest, if clumsiest, things about OS/360 and its descendants. Why
>should this not apply to LRECL, RECFM, and the other DCB parameters as
>much as anything else?
>
Some HLL runtime libraries can readily deal with diverse RECFMs for a
given DDNAME, even transparently to the application code.  Most
assembler programs are not coded that way.  (Ed J. might jump in
with exceptions.)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to