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,
Hello,
I have a question on GDGs
We have a GDG data set GDG.DSNAME.G0001V00 and append data into
this data set throughout the day.
We then run a batch job where we do the following:
1. Read GDG.DSNAME(0)
2. Delete GDG.DSNAME(0) as follows
//DELETE EXEC PGM=IEFBR14
//DD1
] On Behalf Of Fred Kaptein
Sent: Tuesday, January 18, 2011 11:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: GDG Question
Hello,
I have a question on GDGs
We have a GDG data set GDG.DSNAME.G0001V00 and append data into
this data set throughout the day.
We then run a batch job where we do the following
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
) will be G0002 no matter what. else happens.
If you Try to alloc ANOTHER (+1) it will tell you G0002 already exists.
You have to alloc (+2) to get to G0003
From: Fred Kaptein fred.kapt...@hp.com
To: IBM-MAIN@bama.ua.edu
Date: 01/18/2011 09:40 AM
Subject:GDG Question
Sent by:IBM
@bama.ua.edu
Subject: GDG Question
Hello,
I have a question on GDGs
We have a GDG data set GDG.DSNAME.G0001V00 and append data into
this data set throughout the day.
We then run a batch job where we do the following:
1. Read GDG.DSNAME(0)
2. Delete GDG.DSNAME(0) as follows
a trailer record with
a record count) you can just use DSN=GDG(0),DISP=MOD.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Fred Kaptein
Sent: Tuesday, January 18, 2011 12:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: GDG Question
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
On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote:
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote:
Maybe. If the gener abends, the XMIT group will be kept. If it fails with
a non-zero return code, they will be deleted.
Thanks for the warning. I tested it out by forcing an out
On Fri, 30 Jan 2009 07:12:46 -0600, Tom Marchant m42tom-
ibmm...@yahoo.com wrote:
On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote:
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote:
Maybe. If the gener abends, the XMIT group will be kept. If it fails with
a non-zero return
-snip--
Tom Marchant wrote:
On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote:
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote:
Maybe. If the gener abends, the XMIT group will be kept. If it fails with
a
First I want to thank everyone for all of their ideas. After due
consideration,
here is what I think we'll end up doing.
I'm going to create two GDG datasets:
/* IDCAMS COMMAND */
DEFINE GENERATIONDATAGROUP -
(NAME(PROD.XMIT.TXNFILE) -
LIMIT(6) -
)
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick fswarbr...@gmail.com
wrote:
First I want to thank everyone for all of their ideas. After due
consideration,
here is what I think we'll end up doing.
I'm going to create two GDG datasets:
/* IDCAMS COMMAND */
DEFINE GENERATIONDATAGROUP -
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote:
On a business day we'll have two jobs. The first one will look very much like
this:
//GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A
//BACKUP EXEC PGM=IEBGENER
//SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE
//SYSUT2 DD
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant m42tom-
ibmm...@yahoo.com wrote:
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote:
On a business day we'll have two jobs. The first one will look very much like
this:
//GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A
//BACKUP EXEC
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant m42tom-ibmm...@yahoo.com
wrote:
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote:
On a business day we'll have two jobs. The first one will look very much like
this:
//GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A
//BACKUP EXEC
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: 2009-01-27 8:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: New GDG question
Consider the following...
A file is received (via FTP) 7 days a week from somewhere. The FTP
: New GDG question
Hello,
This might run into trouble if you need to open lots of datasets due to
holidays.
Suppose, your program always defines the last 3 datasets (0), (-1) and
(-2) with the corresponding DD statements in your JCL.
However, you'll have some program logic to determine what day
to send a file, you aren't
re-processing yesterday's data.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 27, 2009 7:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: New GDG question
Consider
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
Consider the following...
A file is received (via FTP) 7 days a week from somewhere. The FTP writes to
generation +1.
Problem: The program that uses the file(s) runs only every business day. On
a regular Tuesday-Friday it needs to only read the most recent generation
(0). But on Monday it
One easy way is for the daily job to process all generations of the
dataset, then delete them when it's captured the data.
There are variations on that theme using that would involve copying the
FTP generations to a workday generation if you need to keep the input.
One thing I've learned,
...@bama.ua.edu] On Behalf
Of Frank Swarbrick
Sent: Tuesday, January 27, 2009 8:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: New GDG question
Consider the following...
A file is received (via FTP) 7 days a week from somewhere. The FTP writes
to generation +1.
Problem: The program that uses the file(s) runs only
I have several possible solutions for you, some free some not.
1) The company I work for markets a product called SyzAuto which allows you
to schedule JOBs (or tasks or commands) based on Day of Week, Month, and
various frequencies) with IF logic etc. Most job scheduling systems allow
for this
I've handled this scenerio in the past by having the ftp write to a non-gds
dsn.
Then have the transfer trigger an IEBGENER that concatenates (0) gen with
the non-gds to create (+1) gen.
This can then run any number of times until the business day processes the
files by just calling the (0) gen
respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
GDG Question
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
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
: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Ted MacNEIL
Skickat: den 20 januari 2009 18:03
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: GDG Question
Why doesn't'GV00 roll over to G0001V01?
Rather than starting over at G0001V00...
Why does it really matter?
You can
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
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
Jerry Fuchs
Senior Systems Engineer
Wendy's Arby's Group
One Dave Thomas Blvd.
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
1 - 100 of 129 matches
Mail list logo
