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 Wed, Nov 12, 2008 at 6:56 PM, Dave Salt <[EMAIL PROTECTED]> wrote:
>
> I haven't used the ISPF compile panels for a long time. When I'm in a member
> list I enter '1' next to any members I want to compile, or I enter '1
> pattern' on the command line to select all members that match a pattern
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.
C
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 DS
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 specific
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
>/
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
> On Wed, Nov 12, 2008 at 6:30 PM, Frank Swarbrick 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 ISPF
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 a
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 dsn=&
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,
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 wi
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 s
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 use
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 seen
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 013-64,IFG0
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 w
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
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 LIBRA
> -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 DISP
>>//OWNSYSLB DD DISP=(NEW,KEEP),DSN=&&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 d
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.
>Try DSN=NULLFILE. See the JCL manuals...
>
We had th
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
Try DSN=NULLFILE. See the JCL manuals...
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
behavior.
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=&&OWNSYSLB,
>// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760
>
I sure wish DUMMY didn't truncat
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=&&OWNSYSLB,
>// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760
>//*
I don't know about KEEP on a
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
//*
//OW
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!!
Fra
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 v
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: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
neer
Office: (408) 970 - 7978
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Frank Swarbrick
Sent: Monday, November 10, 2008 3:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: procs and concatenations
I have a question that is going to keep bugging me unt
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 if
I have a question that is going to keep bugging me until I ask it, even though
I'm fairly certain I will not be happy with the answer...
The following is the system supplied Cobol compile procedure, IGYWC:
//IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K
34 matches
Mail list logo
