On Thu, 17 Mar 2011 19:03:43 -0400, Shmuel Metz (Seymour J.) wrote:
>In <listserv%[email protected]>, on 03/17/2011
> at 07:24 AM, Paul Gilmartin said:
>
>>Not really. It's application dependent and wretchedly inconsistent.
>
>What is "it"? If you mean Unix System Services, then the details you
>give don't make much sense.
>
My intent was to contrast UNIX (generally, not just z/OS Unix),
which has a clear separation of primary output stream from
message output stream with MVS, where things are less regular.
>>I see:
>
>Could you give the key to your chart?
>
System or primary message
program output output
stream stream
>>UNIX stdout stderr
>
>Well, it uses stdin, stdout and stderr, none of which are ddnames.
>
DDNAME, descriptor, stream, whatever. What's in a name? The
concept is similar.
>>Assembler SYSPRINT SYSTERM
>
>Do you mean HLA or programs written in HLA? The latter use whatever
>ddnames the programmer wants?
>
The former, as you pretty much guessed.
>>IEBGENER SYSUT1 SYSPRINT
>
>SYSUT1 is an input, not an output.
>
Lapsus mentis. SYSUT2. I stand corrected.
>>Batch TMP SYSTSPRT
>
>For the output of PUTLINE and PUTGET. Programs that use, e.g.,
>SYSPRINT, SYSTERM, in foreground TSO continue to use them in
>background TSO.
>
>>TSO Terminal
>
>Only for TPUT. Other output goes wherever the allocation points, which
>might be the terminal or might be something else.
>
The dichotomy is more harmful than useful.
>>It's a real shame that:
>>o TSO didn't originally read from/write to DDNAMES rather
>> than inventing the idiosyncratic TGET/TPUT
>
>Only if they could do that without losing functionality. From what
>I've seen it was the right decision.
>
I have preferred to see the needed functionality (handling
of 3270 data streams, and of ATTN interrupts) added to
QSAM, rather than QSAM discarded an a competing facility
invented. But, Conway's Law ...
>>o DDNAME redirection wasn't made a basic capability of
>> data management rather than implemented sporadically by
>> various applications, often by positional entries in a
>> second PARM.
>
>Agreed, and not just for TSO.
>
Especially in TSO. The dichotomy between TPUT and PUTLINE
should never have been allowed to happen. There should have
been a consistent I/O technique which could be redirected
or trapped with OUTTRAP.
>>o Rexx, which internally has separate interfaces for data
>> output and message output, has no provision for externally
>> directing them to different DDNAMEs/descriptors.
>
>Do you mean that you would like the output of the say statement to go
>to a different location from where REXX messages go? That could make
>debugging more difficult. ...
>
Suppose that if both SYSTSPRT and SYSTSMSG were allocated, "say"
goes to the former; messages to the latter. If only SYSTSPRT
were allocated, both streams go there. In UNIX, these should
be stdout and stderr respectively. Conventionally, both are
directed to the terminal, so debugging needn't be more difficult.
My frustration is that if I have a Rexx EXEC that writes data
to stdout with "say", I can redirect that to a file. But
if I enable tracing, I'd much prefer to see the trace output
(and messages) go to stderr (the terminal), as sh directs it,
not to my file. That's why IEBGENER separates SYSUT2 from
SYSPRINT.
> ... What I consider a shame is that they haven't
>added the features from ANSI REXX.
>
CHARIN, CHAROUT, ...?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
