Paul Gilmartin wrote:
Hmmm. A colleague eschews DSN=NULLFILE because he believes
that the initiator issues an ENQ for NULLFILE. Is that also
in the statement used to be true category?
I ran some tests, and on the earliest system I could get my
hands on, MVS 3.8, DSN=NULLFILE is sufficient
On Tue, 11 Nov 2008 19:17:08 +, john gilmore wrote:
//LIB1 DD DSN=A.B.C,DISP=SHR
//DD DSN=A.B.C,DISP=SHR
is licit. One may, that is, concatenate a library with itself; and the
only penalty incurred by doing so is a small amount of sometimes
gratuitous overhead.
That said, why
Tom Marchant has made another of his characteristic contributions---They are
comprised of much rhetoric sprinkled with elements of correct but irrelevant
information---to this thread. My post addressed the problem of providing a
placeholder for a sometimes but not always required DD statement
On Wed, 12 Nov 2008 20:06:42 +, john gilmore wrote:
Tom Marchant has made another of his characteristic contributions...
Thank you. And Mr. Gilmore has once again failed to shed any light.
Mr. Marchant reminded me that an entire DD DUMMY statement
can also be overridden. This is true,
On Mon, 10 Nov 2008 18:31:40 -0600, Paul Gilmartin
[EMAIL PROTECTED] wrote:
On Mon, 10 Nov 2008 15:35:26 -0800, Raymond Noal wrote:
If you want a private PDS/Copybook to precede your production COBOL
copy book PDS and have it unique to each user, how about this -
//syslib dd
On Wed, Nov 12, 2008 at 6:30 PM, Frank Swarbrick [EMAIL PROTECTED] wrote:
Does anyone out there actually use the ISPF supplied compile screen?
Before I got involved with the z/OS stuff a co-worker had already
written a REXX panel for our compiles for us to use, so I haven't much
looked at the
On Wed, 12 Nov 2008 17:30:31 -0600, Frank Swarbrick wrote:
And the JCL to execute the proc would be this:
//COMPILE EXEC PROC=IGYWC,LNGPRFX=IGY,
// CLIB1='FJS.PDSE.COBOL'
Or, the user could supply overrides.
I'm not sure what you mean here. That is an example of a user override.
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3)
[EMAIL PROTECTED] wrote:
Try this:
//IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K
//STEPLIB DD DSNAME=LNGPRFX..SIGYCOMP,
// DISP=SHR
//*
//SYSLIBDD DDNAME=OWNSYSLB
//
Tom Marchant wrote:
Mr. Gilmore has repeatedly asserted that DUMMY is different from
NULLFILE, as for example,
That statement used to be true, though not for the reasons Mr.
Gilmore cited. For OS/MVT (and possibly MFT), a DSN=NULLFILE
would fail unless it also carried a UNIT and VOL
On Wed, 12 Nov 2008 20:03:03 -0500, Gerhard Postpischil wrote:
Tom Marchant wrote:
Mr. Gilmore has repeatedly asserted that DUMMY is different from
NULLFILE, as for example,
That statement used to be true, though not for the reasons Mr.
Gilmore cited. For OS/MVT (and possibly MFT), a
At 16:41 +0100 on 11/11/2008, Hunkeler Peter (KIUK 3) wrote about Re:
procs and concatenations:
For exactly the same reason you mention I did not want
to write DELETE (or let it default), but the usual PASS
escaped me when writing the post. I'm not exempt from getting
older, it seems.
Coding
//OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB,
// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760
//*
I don't know about KEEP on a temporary DSN; I'd be more
comfortable with PASS. But I'm very uncomfortable with
DELETE in a PROC. It has bad effects when I override with
a catalogued data set
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote:
Try this:
//SYSLIBDD DDNAME=OWNSYSLB
// DD DISP=SHR,DSN=APPL.PROD.COPYLIB
//*
//OWNSYSLB DD
On Tue, 11 Nov 2008 09:27:09 -0600, Staller, Allan wrote:
It is, but it fools the converter/interperter into thinking there really
is a dataset there and allows the concatenation to proceed, as opposed
to DD DUMMY which truncates the concatenation.
I remain open to persuasion, although John G.
Historically the linking of PL/I programs was slightly complicated because
there were two versions of certain library routines, one for COBOL-like
single-task applications and another for multitasking ones. These routines,
located in two different libraries, had the same names.
The scheme
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote:
Try this:
//SYSLIBDD DDNAME=OWNSYSLB
// DD DISP=SHR,DSN=APPL.PROD.COPYLIB
//*
//OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB,
// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760
I sure wish DUMMY didn't truncate the
On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote:
Try DSN=NULLFILE. See the JCL manuals...
We had this discussion about a year ago. At that time everyone
except John Gilmore agreed that both according to the JCL
manuals and empirically DSN=NULLFILE is quite indistinguishable
from DUMMY.
It is, but it fools the converter/interperter into thinking there really
is a dataset there and allows the concatenation to proceed, as opposed
to DD DUMMY which truncates the concatenation.
Agreed, the effect at execution time is the same.
snipTry DSN=NULLFILE. See the JCL manuals...
We had
In most every shop I've worked in, we created some form of SYSx.NULLFILE
and/or SYSx.NULLPDS. So I agree, it would be nice if z/OS supplied them.
For over 30 years I thought that a DD DUMMY in a PDS concatenation should
act as a empty PDS and not a EOF, but IBM did not ask me. I have never
On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote:
Try DSN=NULLFILE. See the JCL manuals...
//TEST EXEC PGM=IEFBR14
//STEPLIB DD DSN=NULLFILE
// DD DISP=SHR,DSN=SYS1.LINKLIB
results in
IEC141I 013-64,IFG0196J,PMITCM0L,TEST,STEPLIB,,,NULLFILE
An OPEN macro instruction
On Tue, 11 Nov 2008 11:08:32 -0600, Tom Marchant wrote:
On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote:
Try DSN=NULLFILE. See the JCL manuals...
//TEST EXEC PGM=IEFBR14
//STEPLIB DD DSN=NULLFILE
// DD DISP=SHR,DSN=SYS1.LINKLIB
results in
IEC141I
Try DSN=NULLFILE. See the JCL manuals...
snip
I sure wish DUMMY didn't truncate the concatenation, but
were treated as an empty directory (DSORG=PO), or data set
(DSORG=PS), allowing subsequent catenands to be searched
or read.
Or that there were an alternative keword (DD EMPTY) with that
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote:
Try this:
//SYSLIBDD DDNAME=OWNSYSLB
// DD DISP=SHR,DSN=APPL.PROD.COPYLIB
//*
//OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB,
// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760
//*
I don't know about KEEP on a
This is my idea, for whatever it may be worth. I would create a proc with
something like:
//SYSLIB DD DISP=SHR,DSN=some.empty.pds
// INCLUDE MEMBER=prelibs
// DD DISP=SHR,DSN=first.standard.library
// DD DISP=SHR,DSN=second.standard.library
//* OTHER STANDARD
Argh, I forgot to describe something else I tried that did not work:
In the proc:
//SYSLIBDD DISP=SHR,DSN=APPL.PROD.COPYLIB
// DD DDNAME=COPYLIB2
// DD DDNAME=COPYLIB3
In the JCL
//STEP01EXEC IGYWG ...
//COBOL.COPYLIB2 DD DSN=FJS.PDSE.COBOL,DISP=SHR
This works
Frank,
If you want a private PDS/Copybook to precede your production COBOL copy book
PDS and have it unique to each user, how about this -
//syslib dd dsn=sysuid..pvtcobol.copylib
//dd dsn=appl.prod.copylib
HITACHI
DATA SYSTEMS
Raymond E. Noal
Senior Technical Engineer
On Mon, 10 Nov 2008 15:35:26 -0800, Raymond Noal wrote:
If you want a private PDS/Copybook to precede your production COBOL copy book
PDS and have it unique to each user, how about this -
//syslib dd dsn=sysuid..pvtcobol.copylib
//dd dsn=appl.prod.copylib
Then each user must
members with what you want to use.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Monday, November 10, 2008 7:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: procs and concatenations
On Mon, 10 Nov 2008 15:35
Nice idea. Though it doesn't address:
1) Wanting to include from someone else's private library as well as or instead
of your own.
2) Not wanting to include from anyone's private library (sometimes I have the
new copybook in my private library but want a compile to pick up only the
production
That seems like it may work. I'm heading home now, but I will try it on
Wednesday (holiday tomorrow!). Probably I would have an empty library as
the first one, so I could always include it but not have to have the main
production library as the first concatentation.
Thanks for the idea!!
Try this:
//IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K
//STEPLIB DD DSNAME=LNGPRFX..SIGYCOMP,
// DISP=SHR
//*
//SYSLIBDD DDNAME=OWNSYSLB
// DD DISP=SHR,DSN=APPL.PROD.COPYLIB
//*
31 matches
Mail list logo
