Fred,
This is NOT a ThruPut Manager problem.
If you bypass ThruPut Manager you will get ...
IEF286I IEFBR14 STEPNAME DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME
ThruPut Manager is simply reporting what IBM would have report.
The 1st step that references that GDG, via the relative generation,
Why not use DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1)?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality
On Tue, 18 Jan 2011 11:29:25 -0600, Fred Kaptein wrote:
is there any way to
completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where
GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00
No.
If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1)
will be GDG.DSNAME.G0002V00
Using DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1) is not valid
on our system, as we use ThruPut Manager.
This JCL results in the following error message
DTMI DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME
--
For
It's unclear to me why you want to use a GDG at all. Or why you bother
deleting and recreating it.
Your step (3) could simply be writing into GDG.NAME(0) with IEBGENER using
DISP=OLD and with SYSUT1 as DD DUMMY and you'd accomplish pretty much the
same thing as a delete/allocate.
But if you
My first thought is why use a gdg at all in this situation? Wouldn't a
plain data set work just as well.
Second is GDG's (relative and absolute) are updated at the END of the job,
NOT the end of each step (as best I remember). Relative (0) will be G0001
throughout the job, so (+1) will be
Or why not just allocate a standard PS file and then clear it when you are
done with it?
*don*
On Tue, Jan 18, 2011 at 12:43 PM, McKown, John
john.mck...@healthmarkets.com wrote:
Why not use DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1)?
--
John McKown
Systems Engineer IV
IT
I don't think you need either the delete or the allocate.
Just use DSN=GDG(0),DISP=OLD for the step that writes data into the GDG.
DISP=OLD and open for output will allow you to rewrite the whole dataset
starting at the beginning.
OTOH if you are truly just appending data (and don't use a
On Tue, 2011-01-18 at 13:27 -0500, Tom Marchant wrote:
If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1)
will be GDG.DSNAME.G0002V00 for any reference in that job.
The GDG name table (GDGNT, mapped by IEFZB429, pointed to from the JCT)
contains a list of GDG base names, and their
There are too many JCL changes in other batch jobs, to change this
to a non-GDG file.
Reusing the same file without deleteing and reallocating the data set is an
option.
Thank you for your responses, we will take them into consideration.
-MAIN@bama.ua.edu
Date: 01/18/2011 03:48 PM
Subject:Re: GDG Question
Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
There are too many JCL changes in other batch jobs, to change this
to a non-GDG file.
Reusing the same file without deleteing and reallocating the data
: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Fred Kaptein
Sent: Tuesday, January 18, 2011 1:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG Question
There are too many JCL changes in other batch jobs, to change this to a
non-GDG file.
Reusing the same file without
WY back when (mid 70s), i can remember doing an UNCATLG,
RENAME, CATLG to convert a Gv00 to G0001v00. Now i see that it may
not have been necessary?
KENNETH E. THOMPSON
Programmer Analyst Sr. Professional
CSC
1222 Spruce Street, Room 7.204, St. Louis, MO 63103
North
WY back when (mid 70s), i can remember doing an UNCATLG, RENAME,
CATLG to convert a Gv00 to G0001v00.
Now i see that it may not have been necessary?
I can't speak to the 1970's, but I never needed it in 1981.
-
Too busy driving to stop for gas!
-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Kenneth E Thompson
Sent: Tuesday, January 27, 2009 8:10 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG question
WY back when (mid 70s), i can remember doing an UNCATLG,
RENAME, CATLG to convert a Gv00
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG question
Actually I think it was way back then. I seem to recall not quite so
far back (early to mid 80s) that when we first installed our 4381 with
XA 2.1.7 that the training I got back then said I needed to perform
unnatural acts when a GDG hit
Based on Ted's comment about not needing to do anything strange with GDG
rolling in 1981, maybe my training course was wrong...
I don't know about that, but I was a JCL Jockey, in production support, in 1981.
And, unless, what I loosely call my mind, has failed completely (possible), we
never
Barry:
Excellent response. I am somewhat perturbed though by IBM's response as being
OCO. IBM, I believe (for a large $$ donation) will give out certain non
disclosure items. Yet I am somewhat mystified as to why IBM needs to classify a
catalog record layout as OCO. We know of at least one
You may have been thinking of the post about GDG 'wrap bit' processing?
http://www-1.ibm.com/support/docview.wss?uid=isg1II07276
Jack Kelly
202-502-2390 (Office)
Jerry Fuchs jerry.fu...@wendysarbys.com
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
01/19/2009 02:16 PM
Please
It seems to me that I saw a thread that stated when you hit GV00 you will
be unable to create (+1).
Is this correct?
No, GDG's have wrapped for aeons.
Even the so-called bad wrapping problem is rare, since the maximum you can have
is 255.
I've never seen the problem, in my almost 30
You may be recalling this incident from 2005:
Change 23.219 The ICF Catalog 05 record variable GATGEN should have
VMAC6156 been input as PIB.2., instead of one byte, and variable
VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005 to mark that this GDG
John Kington wrote:
Are you haevy user of GDGs created *more frequently* than daily?
We run a batch job to copy off smf and ims log data whenever a switch
occurs. Just our kind of normal.
Well... I do use GDG for SMF, but I create one generation a day and use
DISP=MOD for further
Well... I do use GDG for SMF, but I create one generation a day and use
DISP=MOD for further offloads.
Risky choice.
What happens if the offloading job fails for some reason?
You could lose all the accumulated data.
BTW: In your scenario you don't know how old data do you have! The data can be
Ted MacNEIL wrote:
Well... I do use GDG for SMF, but I create one generation a day and use
DISP=MOD for further offloads.
Risky choice.
What happens if the offloading job fails for some reason?
You could lose all the accumulated data.
Why ?
The only problem that can occur is lost record
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Wednesday, January 21, 2009 5:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG
Richards, Robert B. wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
I considered it and said no. There is no good way to avoid duplicate
records during offload.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B.
robert.richa...@opm.gov wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Bob
Won't touch it until the offload support is enhanced with better date
selection options (which it still wasn't even in
Sent: 21 January 2009 13:53
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG Question
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B.
robert.richa...@opm.gov wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Bob
Won't touch it until the offload support
@bama.ua.edu
Subject: Re: GDG Question
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B.
robert.richa...@opm.gov wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Bob
Won't touch it until the offload support is enhanced with better date
selection options
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B.
robert.richa...@opm.gov wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Bob
SMF logstream relates to the MAN dataset logging rather than the
associated DUMP GDG generations, though you may find it
For SMF, the key is actually to switch to logstreams and get rid of the GDGs!
:-)
Right!
And, introduce the duplicate SMF data problem, while I'm at it?
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff
I prefer to order GDGs with odd generations in LIFO order followed by the even
generations in FIFO order - except on the second Tuesday of the month,
when I want to read the data backwards in random file sequence. Why won't
IBM listen to me?
You can't satisfy everyone. I suspect it was a
On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline martin.kl...@yrcw.com wrote:
I prefer to order GDGs with odd generations in LIFO order followed by the even
generations in FIFO order - except on the second Tuesday of the month,
when I want to read the data backwards in random file sequence. Why
On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote:
On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline wrote:
You can't satisfy everyone. I suspect it was a performance choice made many
years ago. For whatever reason, it is what it is. Deal with it or get over it.
Correct. I remember CVOLs.
On Wed, 21 Jan 2009 07:53:00 -0600, Mark Zelden
mark.zel...@zurichna.com wrote:
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B.
robert.richa...@opm.gov wrote:
For SMF, the key is actually to switch to logstreams and get rid of the
GDGs! :-)
Won't touch it until the offload support is
---snip-
The thing that's always bugged me about GDG files is they way they are
selected starting with the highest gen # first down to the lowest if you
specify the GDG-base name on a DD.
Tom Marchant wrote:
I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever
the reason was for concatenating the generation data sets in reverse order,
I don't think it was for performance.
The names were stored in the catalog in inverse order (the
portion was
was *specifically* to achieve the reverse sequence returned in GDGALL.
Date: Wed, 21 Jan 2009 11:53:01 -0600
From: m42tom-ibmm...@yahoo.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote:
On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline
On Wed, 21 Jan 2009 11:53:01 -0600, Tom Marchant m42tom-ibmm...@yahoo.com
wrote:
On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote:
On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline wrote:
You can't satisfy everyone. I suspect it was a performance choice made many
years ago. For whatever
But maybe I was always wrong.
Maybe it was to give a faster path to generation (0) which would probably
be the most oft retrieved generation.
Date: Wed, 21 Jan 2009 13:30:49 -0500
From: jayare...@hotmail.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
I spent a *lot
On Wed, 21 Jan 2009 13:22:42 -0500, Gerhard Postpischil wrote:
Tom Marchant wrote:
I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever
the reason was for concatenating the generation data sets in reverse order,
I don't think it was for performance.
The names were
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant
Sent: Wednesday, January 21, 2009 12:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG Question
On Wed, 21 Jan 2009 13:22:42 -0500, Gerhard Postpischil wrote:
Tom Marchant wrote
On Wed, 21 Jan 2009 12:39:39 -0600, John McKown wrote:
On Wed, 21 Jan 2009 11:53:01 -0600, Tom Marchant wrote:
I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever
the reason was for concatenating the generation data sets in reverse order,
I don't think it was for
Re: GDG Question
01/19/2009 02:41
PM
The V00 part of the GV00 number is used to create the same GDG number
without impacting the GDG numbers.
Say I have G0001V00 and I find that it is incorrect, I then create a
G0001V01. Now let's say the G0001V01 is still the Generation 0 entry in the
GDG. Then when I use DSN(0) it pulls in
Subject
.edu Re: GDG Question
01/20/2009 09:16
As entries are added to a GDG by DSN=...(+1), G0001V00 thru GV00 are
created with the wrap bit OFF (I'll refer to these entries members of group
A). After GV00 exists, the next entries created by DSN=...(+1) are
G0001V00 - G0999V00 with the wrap bit ON (I'll refer to these entries as
David Magee wrote:
[...]
If for some reason an entry in group A does not roll off (i.e., an
expiration date is changed so that the entry doesn't expire in a timely
matter, etc.), group B will not have it's wrap bits turned off. When group
B gets to G0999V00, then next attempt to create an entry
On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote:
Of course it is possible to use GDGs for cyclic jobs running hourly
(still over year) or even more frequently. [...] But I think it is
uncommon.
Commonplace here. We are heavy, regular users of GDGs. Lots and LOTS
of old-master-in,
David Andrews wrote:
On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote:
Of course it is possible to use GDGs for cyclic jobs running hourly
(still over year) or even more frequently. [...] But I think it is
uncommon.
Commonplace here. We are heavy, regular users of GDGs.
Are you haevy user
we certainly create GDG members more frequently than daily - more
importantly (for us) - they are ad hoc - we simply dont know how many
will be generated in a day - until they are generated
(CA-IDMS transaction log and recovery journal offloads)
Chris Hoelscher
Senior IDMS DB2 Database
Why doesn't'GV00 roll over to G0001V01?
Rather than starting over at G0001V00...
Why does it really matter?
You can only have a max of 255 entries.
Just like 640K was enough memory on a PC, 255 entries is enough!
-
Too busy driving to stop for gas!
Are you haevy user of GDGs created *more frequently* than daily?
We run a batch job to copy off smf and ims log data whenever a switch
occurs. Just our kind of normal.
BTW: I think that a reason why IBM didn't increase maximum LIMIT() for
GDG is lack of interest: Those customers who
At 02:36 + on 01/20/2009, Ted MacNEIL wrote about Re: GDG Question:
That is because the GDG is in a VSAM catalog.
ICF catalogue -- different from VSAM.
True. I was using VSAM as the alternative to CVOL catalogs. ICF is
still VSAM but just a new way of handling the Catalog (as opposed
At 09:29 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question:
So what your saying is the the LOCATE/CAMLIST macros (and others I suppose)
never even look at the Vxx part of the DSN.
Your usage of it is interesting, never thought of it myself, but lord knows
I could have used it!
Thank
At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question:
This brings up a question I've had before.
Why is the 'V00' not made use of?
Why doesn't'GV00 roll over to G0001V01?
Rather than starting over at G0001V00...
Just a thought
All automatically created files have
On Tue, 20 Jan 2009, Ted MacNEIL wrote:
Why doesn't'GV00 roll over to G0001V01?
Rather than starting over at G0001V00...
Why does it really matter?
You can only have a max of 255 entries.
Just like 640K was enough memory on a PC, 255 entries is enough!
-
Total agreement! What I
On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote:
What I wish were a possibility would be an totally new
construct with similar semantics to a GDG. But the LLQ would somehow
encode the creation date time (perhaps to the nearest second). No, I
don't know how to encode that into 8 printable
The Vyy is the Version Number ... (allowing you to replace it up to 99
times).
Are you saying that replacement versions may only be created in ascending
sequence?
Date: Tue, 20 Jan 2009 12:15:46 -0500
From: hal9...@panix.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
, 2009 at 12:20 PM, Robert A. Rosenberg hal9...@panix.comwrote:
At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question:
This brings up a question I've had before.
Why is the 'V00' not made use of?
Why doesn't'GV00 roll over to G0001V01?
Rather than starting over at G0001V00
The Version numbers are ascending (00 to 99). I have not known of a case where
you would create a descending version (99 to 00).
Lizette
The Vyy is the Version Number ... (allowing you to replace it up to 99
times).
Are you saying that replacement versions may only be created in
I have always *tried* to avoid GDGs like the plague that they are.
They have their uses, if you understand their quirks.
The biggest thing I used them for was SMF dumps.
At each switch dump to a GDG.
Switch at midnight, consolodate with a simple reference to the base(s).
Delete if successful.
On Tue, 2009-01-20 at 17:49 +0100, R.S. wrote:
Is there any other reason? No one wants 365 generations?
Well... if the system allowed larger limits then we'd probably use them.
GDG catalog processing has always been something of a kludge (my
opinion... sorry if you're lurking, Mark). GDG
:29:56 -0500
From: stars...@mindspring.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
The Version numbers are ascending (00 to 99). I have not known of a case
where you would create a descending version (99 to 00).
Lizette
The Vyy is the Version Number ... (allowing you
On Tue, 2009-01-20 at 12:18 -0600, Tom Marchant wrote:
On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote:
But the LLQ would somehow
encode the creation date time (perhaps to the nearest second).
Dddd.Thhmmss?
One second is not fine enough. In a backup application I use
understanding. Version only
allows you to replace the current Gen Number without losing the oldest GDG (due
to roll off).
Lizette
-Original Message-
From: J R jayare...@hotmail.com
Sent: Jan 20, 2009 1:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG Question
The Version numbers
the current Gen Number without losing the oldest GDG
(due to roll off).
Lizette
-Original Message-
From: J R jayare...@hotmail.com
Sent: Jan 20, 2009 1:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG Question
The Version numbers are ascending (00 to 99). I have not known
of a case where you
Yes, it's understood that there is only one version cataloged at any one time.
The question remains: Must version numbers be assigned incrementally?
Date: Tue, 20 Jan 2009 13:57:44 -0500
From: stars...@mindspring.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
My
-snip
Total agreement! What I wish were a possibility would be an totally new
construct with similar semantics to a GDG. But the LLQ would somehow
encode the creation date time (perhaps to the nearest second). No, I
don't know
--snip--
Well... if the system allowed larger limits then we'd probably use them.
GDG catalog processing has always been something of a kludge (my
opinion... sorry if you're lurking, Mark). GDG sphere records are too
big for their own
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman
You should have seen how they were managed in a CVOL environment!
Chewing gum, bailing wire, spit a and LOT of prayers! . . .
So, does that mean the demise of CVOLs predated the availability of duct
--snip
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman
You should have seen how they were managed in a CVOL environment!
Chewing gum, bailing wire, spit a and LOT of prayers! . . .
So, does that
think that I would be able to catalog non-GDG datasets with the same
prefix as the GDG base.
Have I missed something?
Date: Tue, 20 Jan 2009 14:08:27 -0500
From: jayare...@hotmail.com
Subject: Re: GDG Question
To: IBM-MAIN@bama.ua.edu
Yes, it's understood that there is only one
On Mon, 2009-01-19 at 14:13 -0500, Jerry Fuchs wrote:
It seems to me that I saw a thread that stated when you hit GV00 you
will be unable to create (+1).
You're mistaken. It rolls over, just as you think it should. Easy
enough to verify: create a GV00 in a test GDG, then a +1 and see
-MAIN@bama.ua.edu
cc
Subject
Re: GDG Question
On Mon, 2009-01-19 at 14:13 -0500, Jerry Fuchs wrote:
It seems to me that I saw a thread that stated when you hit GV00 you
will be unable to create (+1).
You're mistaken. It rolls over, just as you think it should. Easy
enough to verify
On Mon, 19 Jan 2009 14:13:34 -0500, Jerry Fuchs
jerry.fu...@wendysarbys.com wrote:
It seems to me that I saw a thread that stated when you hit GV00 you
will be unable to create (+1).
Is this correct?
How did you handle this situation? Just delete all generations or create a
new GDG?
THI
At 13:41 -0600 on 01/19/2009, Scott Barry wrote about Re: GDG Question:
The GDG assignment rolls from GV00 to **.G0001V00 on this condition.
That is because the GDG is in a VSAM catalog. In the past when CVOL
catalogs were used I think you were SOL since there was no rollover
ability
That is because the GDG is in a VSAM catalog.
ICF catalogue -- different from VSAM.
In the past when CVOL catalogs were used I think you were SOL since there was
no rollover
ability.
I don't recall it ever being a problem, even with CVOLs.
I started this business as a JCL jockey in Production
, 2008 3:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: GDG QUESTION
Hi Howard,
I noted that Linda supplied the required answer to your query about:
The executing job has the following DD in the JCL:
DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR
and the resulting error is:
IEF212I E18823X
sequence.
Date: Sat, 15 Nov 2008 08:34:42 +
From: [EMAIL PROTECTED]
Subject: Re: GDG QUESTION
To: IBM-MAIN@BAMA.UA.EDU
Hi Howard,
I noted that Linda supplied the required answer to your query about:
The executing job has the following DD in the JCL:
DUMPIN DD DISP=SHR,DSN
Hi Howard,
I noted that Linda supplied the required answer to your query about:
The executing job has the following DD in the JCL:
DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR
and the resulting error is:
IEF212I E18823X PST0010 STEP01 DUMPIN - DATA SET NOT FOUND
Can some one tell me what
Sorry for the typo, this should have been:
DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR NOT TMVS01
Howard Rifkind [EMAIL PROTECTED] 11/14/2008 5:42 PM
Hello all,
I'm having problems with a GDG definition/datasets.
I use the following JCL to set the GDG up:
//DEFGDG EXEC PGM=IDCAMS
That's just the base entry.
Do you have any actual datasets... ie... (-0)... (-1) ?
Jay Campbell
IBM OS Support Section
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Rifkind
Sent: Friday, November 14, 2008 5:43 PM
To:
Hi Howard,
The JCL you ran defined the GDG and the 3.4 display is what I would expect to
see for the catalogued GSG base. You can create 5 generations and the 6th will
cause the oldest to roll off the catalogue and be scratched. The GDG base is
not a dataset, it is a catalogue entry only, a
No, and I think you got it.
Thanks
Campbell Jay [EMAIL PROTECTED] 11/14/2008 5:47 PM
That's just the base entry.
Do you have any actual datasets... ie... (-0)... (-1) ?
Jay Campbell
IBM OS Support Section
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL
On Wed, 15 Aug 2007 11:10:54 -0400 Hare, Tim [EMAIL PROTECTED]
wrote:
:I need to move some existing GDG datasets from tape to disk. Normally, I
would create a new version of each generation (V00 to V01, etc.), however these
are created by a product which records the dataset name when they are
Thanks for sharing the info on this Bruce:
snip
Remember that it is true that a SYSDSN ENQ is held until the end of last
step that references the dataset. this is also true for GDG bases. My
test showed that this is true, both ENQs were released at the end of the
first step. But if you have
did not realize that referencing the new GDG entry in a subsequent step would
retain the original ENQ EXCLUSIVE.
You'll find ENQ's promoted, but never demoted.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe /
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Barkow, Eileen
Sent: Wednesday, April 11, 2007 12:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: gdg question
can one of you gurus out there please shed some light on this, since i
am not sure
Eileen,
If I understand correctly, The GDG BASE is being ENQUEUED.
Kevin (not a guru) Clark
3. JOBA remains on the execution queue waiting for the dataset:
IEF863I DSN = .PTNT.SASFILE.NEW JOBA
IEF099I JOB TBCDAILY WAITING FOR DATA SETS
now, why is the IEF863I msg
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Barkow, Eileen
Sent: Wednesday, April 11, 2007 12:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: gdg question
can one of you gurus out there please shed some light on this, since i
am not sure what the
I'm no guru but I would say that the JOBB has and ENQUE on the base because
you said DISP=OLD with a releative #. If you specified the actual
generation
by dataset name .GVnn I believe you would be allset.
Thanks, Dave Hanson
464-8889
Subject: Re: gdg question
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Barkow, Eileen
Sent: Wednesday, April 11, 2007 12:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: gdg question
can one of you gurus out there please shed some light on this, since i
am
Yes, JOBB did start first, but apparently for the first time in 20
years!!
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Fletcher, Kevin
Sent: Wednesday, April 11, 2007 1:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: gdg question
Eileen,
I
IFF the file had been created on DASD you probably would not have seen a
problem. BUT because the file was created on a removeable media
(TAPE/CART), the CATALOG process does not complete until JOB END (which
I would think should be step end, but hey, what do I know?).
This happens whether or
-snip---
can one of you gurus out there please shed some light on this, since i
am not sure what the answer should be or whether or not this is normal,
since
these jobs supposedly have been running and working for the last 20
years
In
[EMAIL PROTECTED],
on 02/01/2007
at 11:20 AM, Tim Hare [EMAIL PROTECTED] said:
In essence one generation per day of month, with missing generations
if we don't run that day (state holiday or whatever).
How and when will you delete each GDS from the previous year? If you
don't delete them
A separate GDG for every month would give you that ability to read all of
JAN, FEB, etc.
If you were to add an extra step at the end of the GDG-creating JOB to
define a direct reference you would not need to be concerned about
the holes, like this:
DEF ALIAS (NAME(whatever.FEB05)
when you reference a GDG dataset by the root name only, I believe it reads
the individual datasets LIFO rather than FIFO (or at least from highest #
to lowest # - if may not actually look at when created) - if the order of
input read is improtatn to you, than this might not be a satisfactory
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Hare
Sent: Thursday, February 01, 2007 10:20 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: GDG question
I'm pretty sure I can do this, but I'm looking for a second
opinion (and
you're
1 - 100 of 106 matches
Mail list logo
