He couldn't get EZACFSM1 to write to SYSOUT. Neither could I...if it were defined as SYSOUT=(*,INTRDR). Anything else, no problem. However, the following JCL did achieve the desired effect:
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Hmmm, now that you mention the subject, wouldn't the DCB for a file defined as SYSOUT=* be RECFM=FBA,LRECL=133? That might cause INTRDR to choke, perhaps?
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Anuj Dhawan wrote:
ok, I tried with with/without DCB parametes - both work for me. However, when you say
Quote:
He couldn't get EZACFSM1 to write to SYSOUT. Neither could I...if it were defined as SYSOUT=(*,INTRDR).
what exactly happend?
As far as I could tell, nothing. The JCL was not submitted, and there were no EXCPs for SYSOUT in the system messages. To the left, when I defined the DD as SYSOUT=* or as DSN=..., the JCL appeared in sysout or the data set, and there were two EXCPs to SYSOUT.
enrico-sorichetti wrote:
the traditional class for <punched> things is B
but there would be the need of some testing to find out|
I'll have to review the standard sysout class documentation when my office opens up in a couple of hours, but I'm 99% sure that sysout class B has been redefined to mean some sort of letterhead.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
expat wrote:
What about RACF or system exits to deny the use of using INTRDR ?
That was what I was thinking, although I was not sure if they could detect that the write to INTRDR was coming from EZACFSM1 vs. IEBGENER, which would be necessary for the situation to have been true.
===
I think that the responses from various members that the original JCL does/does not work for them without DCB parameters indicates that there is enough variation in installations that this behavior, although surprising, should not be wholly unexpected. Thank you all for your efforts in this matter.