In [EMAIL PROTECTED], on 01/05/2008
at 02:21 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Do you consider the following IEBGENER step to verify the difference in
behavior:
Yes. Did you create an ETR?
... ? Note that the line after /./dev/null is displayed, but the line
after /dev/null is not
On Wed, 2 Jan 2008 21:06:54 -0500, Shmuel Metz (Seymour J.) wrote:
Off the top of my head, I'd say that it's broken as designed. Another case
of IBM's MVS, OMVS and Unix people not talking to each other, assuming
that you have verified the difference in behavior.
Do you consider the following
In [EMAIL PROTECTED], on 01/02/2008
at 04:43 PM, Paul Gilmartin [EMAIL PROTECTED] said:
One might make the same argument about DSNAMEs
And I wouldn't argue with it.
either way. NULLFILE could have been catalogued on an imaginary UNIT
Given that there's a device type for DUMMY, that would
In [EMAIL PROTECTED], on
01/02/2008
at 04:56 PM, Skip Robinson [EMAIL PROTECTED] said:
The 'equivalent' examples quoted from the manual differ greatly in coding
JCL statements in a cataloged procedure: DSNAME can be represented as a
symbolic variable but DDNAME cannot.
The DDNAME keyword
In [EMAIL PROTECTED], on 12/31/2007
at 03:11 PM, Paul Gilmartin [EMAIL PROTECTED] said:
I'll retract grievous.
But see below.
If the argument of PATH is anything other than '/dev/null'
(or '//dev/null'), the file is allocated as a UNIX file and can be
processed as a UNIX file. If it is
On Wed, 2 Jan 2008 14:20:04 -0500, Shmuel Metz (Seymour J.) wrote:
I'll retract grievous.
But see below.
Thanks for seeing past my bombast.
If the argument of PATH is anything other than '/dev/null'
(or '//dev/null'), the file is allocated as a UNIX file and can be
processed as a UNIX file.
cc
Discussion List
[EMAIL PROTECTED] Subject
.EDU Re: Curiousity question: the
processing
On Wed, 2 Jan 2008 16:56:19 -0800, Skip Robinson wrote:
I've never questioned the path length or development costs to support both
DDNAME and DSNAME options for a null file, i.e. DD DUMMY and DSN=NULLFILE,
but as pointed out earlier in this thread, they are both ancient. The
virtue of having both
On Sun, 30 Dec 2007 19:11:46 -0500, Shmuel Metz (Seymour J.) wrote:
Which was a grievous and irresponsible and unnecessary design blunder.
No.
I'll retract grievous. Why was it necessary, or even
beneficial? Adding complexity and code with no benefit
is a blunder.
Who benefits from this
: the processing of DD DUMMY.
To: IBM-MAIN@BAMA.UA.EDU
Got stuck in a situation where senior management kept appropriating the
prefix for other uses. At one point, I was changing the prefix weekly.
In spite of all my efforts to explain this to senior management, they
remained clueless. I
---snip---
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now we also have PATH=/dev/null.
In [EMAIL PROTECTED], on 12/28/2007
at 06:52 AM, Barbara Nitz [EMAIL PROTECTED] said:
Actually, I just had a bloody row about a DD dummy statement in the JCL
for a new release of a vendor product. It appears that a dd dummy
generates a dsn of NULLFILE in the JFCB
DSN=NULLFILE has been
In [EMAIL PROTECTED], on 12/28/2007
at 03:55 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Which was a grievous and irresponsible and unnecessary design blunder.
No.
Who benefits from this special treatment of PATH=/dev/null?
What special treatment?
It only adds confusion by making the
-snip---
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now we also have PATH=/dev/null.
--snip
Works for me!!! But I HATE to use the RACF prefix capability. Just a
feeling, probably senseless.
I'm not sure why you feel that way, but you could always define the prefix
as John showed, and a GLOBAL DATASET member to allow prefix.NULLFILE, and
then
On Sat, 29 Dec 2007 10:48:30 -0600, Rick Fochtman wrote:
-snip---
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now we also have PATH=/dev/null.
On Dec 29, 2007, at 11:02 AM, Rick Fochtman wrote:
---SNIP-
unsnip
Got stuck in a situation where senior management kept appropriating
the prefix for other uses. At one point, I was changing the prefix
weekly. In
--snip---
Actually, I just had a bloody row about a DD dummy statement in the JCL for a
new release of a vendor product. It appears that a dd dummy generates a dsn of
NULLFILE in the JFCB (that would explain why I see dsn=nullfile quite a bit in
our productive
On Fri, 28 Dec 2007 10:36:49 -0600, Rick Fochtman wrote:
Suggestion: instead of DD DUMMY, try using DD
DSN=SYS1.NULLFILE,DISP=SHR
and define a RACF profile for SYS1.NULLFILE with a UAC of ALTER.
Will that work? From the JCL Reference:
NULLFILE
Specifies a dummy data set. NULLFILE has the
case of NULLFILE.
Date: Fri, 28 Dec 2007 10:36:49 -0600
From: [EMAIL PROTECTED]
Subject: Re: Curiousity question: the processing of DD DUMMY.
To: IBM-MAIN@BAMA.UA.EDU
Barb, it sounds to me like maybe it's time to re-evaluate the value of
the product vs. other offering by other
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of J R
Sent: Friday, December 28, 2007 11:53 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Curiousity question: the processing of DD DUMMY.
Suggestion: instead of DD DUMMY, try using DD
DSN
-snip--
Using RACF, it is possible to set up a SETROPTS which will prefix all
single level dataset names with a given high level qualifer. If this
is done, it would be possible to create a RACF rule for hlq.NULLFILE
with a UACC of ALTER. I would likely do
---snip-
Suggestion: instead of DD DUMMY, try using DD DSN=SYS1.NULLFILE,DISP=SHR
and define a RACF profile for SYS1.NULLFILE with a UAC of ALTER.
But that won't have the intended effect of DD DUMMY.
If the vendor code really needs to check the
On Fri, 28 Dec 2007 13:12:24 -0600, Rick Fochtman wrote:
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now we also have PATH=/dev/null.
--
Tom Marchant
On Fri, 28 Dec 2007 13:50:54 -0600, Tom Marchant wrote:
On Fri, 28 Dec 2007 13:12:24 -0600, Rick Fochtman wrote:
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now we also have
: the processing of DD DUMMY.
On Fri, 28 Dec 2007 13:50:54 -0600, Tom Marchant wrote:
On Fri, 28 Dec 2007 13:12:24 -0600, Rick Fochtman wrote:
IIRC, SYS1.NULLFILE was recognized by the system as a special case of
DUMMY. But it filled in the DSNAME field of the JFCB.
You are thinking of DSN=NULLFILE. Now
On Fri, 28 Dec 2007 15:55:38 -0600, Paul Gilmartin [EMAIL PROTECTED]
wrote:
Will RACF deal with single-level DSNAMEs? The system ought by
default be configured to give UACC=ALL to NULLFILE.
As John mentioned, yes, RACF can deal with single-level names, if you
configure it to do so via SETROPTS
On Fri, 28 Dec 2007 13:10:09 -0600, Rick Fochtman [EMAIL PROTECTED] wrote:
Works for me!!! But I HATE to use the RACF prefix capability. Just a
feeling, probably senseless.
I'm not sure why you feel that way, but you could always define the prefix
as John showed, and a GLOBAL DATASET member to
I'm curious if anybody knows how z/OS actually processes the OPEN for a
DUMMY DD statement. I know that basically output is ignored and input
causes an immediate EOF. But I wondering if OPEN is smart enough that if
a file is opened for OUTPUT, the address in the DCB is simply to a
IEFBR14 type
On Thu, 27 Dec 2007 12:39:31 -0600 McKown, John
[EMAIL PROTECTED] wrote:
:I'm curious if anybody knows how z/OS actually processes the OPEN for a
:DUMMY DD statement. I know that basically output is ignored and input
:causes an immediate EOF. But I wondering if OPEN is smart enough that if
:a
McKown, John wrote:
I'm curious if anybody knows how z/OS actually processes the OPEN for a
DUMMY DD statement. I know that basically output is ignored and input
causes an immediate EOF. But I wondering if OPEN is smart enough that if
a file is opened for OUTPUT, the address in the DCB is simply
On Thu, 27 Dec 2007 12:39:31 -0600, McKown, John wrote:
I'm curious if anybody knows how z/OS actually processes the OPEN for a
DUMMY DD statement wondering if OPEN is smart enough that if
a file is opened for OUTPUT, the address in the DCB is simply to a
IEFBR14 type module, or is it more
Because the application may not check to determine if it is a dummy file.
The application may require the data from the JFCB
Actually, I just had a bloody row about a DD dummy statement in the JCL for a
new release of a vendor product. It appears that a dd dummy generates a dsn of
NULLFILE in
33 matches
Mail list logo
