...@oppenheimerfunds.com wrote:
From: Lester, Bob bles...@oppenheimerfunds.com
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:25 AM
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of esmie moo
Sent
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of esmie moo
Sent: Friday, August 07, 2009 11:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
John,
I would like to try out your suggestion LISTC ALL CAT
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of esmie moo
Sent: Friday, August 07, 2009 10:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
Bob,
Thanks for the examples. The disks are SMS managed however
OF NOSCRATCH GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:42 AM
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of esmie moo
Sent: Friday, August 07, 2009 10:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REPORT
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of esmie moo
Sent: Friday, August 07, 2009 10:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
I ran the job but received errors which would explain why. Just
John,
I tried out your suggestion and it works. Thanks.
--- On Sat, 8/8/09, McKown, John jmck...@healthmarkets.com wrote:
From: McKown, John jmck...@healthmarkets.com
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:37 AM
Thanks Bob for your help as well.
--- On Sat, 8/8/09, Lester, Bob bles...@oppenheimerfunds.com wrote:
From: Lester, Bob bles...@oppenheimerfunds.com
Subject: Re: REPORT OF NOSCRATCH GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:48 AM
-Original Message-
From
-snip---
Is there a way to produce a list of GDG disk dsns that were defined with NOSCRATCH parM? We have a problem with disk space and it was noticed that several GDG dsns that were rolled off but were still on the dasd because
Hi Folks,
Does anyone out there have anything that will 'mass-change' GDGs from
NOSCRATCH to SCRATCH?
Thanks!
Bob Lester
Systems Storage
Oppenheimerfunds
303.768.3504
bles...@oppenheimerfunds.com
--
Bob,
The Dino Software T-REX product provides the capability for mass-change
for SCRATCH/NOSCRATCH and other attributes. If you'd like additional info,
feel free to contact me directly.
Regards,
Tony
--
Tony Brown
DINO Software Corporation
http://www.dino-software.com/
1-800-480-DINO (3466)
ALTER 'gdg base entry' SCRATCH
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm
For these types of issues, I usually do a 3.4 list with SAVE to a dataset, then
create the ALTER control cards en-masse.
Once the ISPF LIST dataset has been altered, I then just EX it.
Or sometimes I would write a rexx to create the ALTER control cards.
Lizette
Does anyone out there
Lester,
I have some old SAS-code that will do the trick.
It reads catalog records (created by running EXPORT TEMPORARY on the
catalog(s) I need to check) and generates the necessary ALTER statements for
each GDG Base record that is in NOSCRATCH status. After that, all you need
to do is execute
DSLIST results to a dataset (in this case after a SORT VOL command to get
the GDG bases together where VOL=??) for post-execution.
Scott Barry
SBBWorks, Inc.
--
For IBM-MAIN subscribe / signoff / archive access instructions
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ulrich Krueger
Sent: Monday, May 18, 2009 11:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDG tool?
Lester,
I have some old SAS-code that will do the trick.
It reads catalog records
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
One way of doing is by having the processing job to the following:
1) Add a step to backup all gens of the FTP GDG
//backup exec pgm=Iebgener
//sysut1 dd dsn=FTP.FILES,disp=shr Backup all
gens
//sysut2 dd dsn-FTP.FILES.BACKUP, disp=etc...
2
an append instead of a replace. Then have them just FTP the data
into generation 0 of the GDG. When you run your job, just use
generation 0 and as the last step of the job, create an empty +1
generation. The other benefit of this type of scenario is that if for
some reason the other end neglected
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!
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 to keep it going.
Rex
-Original Message
Based on Ted's comment about not needing to do anything strange with GDG
rolling in 1981, maybe my training course was wrong...
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Pommier, Rex R.
Sent: Tuesday, January 27, 2009 8:46 AM
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,
is not
the same as SMFDOW. The values of these SMF set symbols allow me to
generate the alias name for the related GDG... As I said, works like a
charm.
HTH
Gary Green
Never use a 2x4 when a 2x6 will do just as well!
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m
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
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
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
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.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Zelden
@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
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
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.
--
For IBM-MAIN subscribe / signoff / archive access instructions
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.
is enhanced with better date
selection options (which it still wasn't even in z/OS 1.10).
But we've been here before...
IEAMDBLG seems to work sufficiently for pulling yesterday's OPERLOG to a PS
file (GDG) and deleteing on that boundary.
Couldn't this code be generalized to work for SMF (or other
---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.
-unsnip
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
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
by using
DSN=...(+1) will fail. Manual intervention is required by the user to
correct all the existing entries in the GDG before any new entries can be
created. Good doc from IBM about how to correct the problem is not easily
found. At 3:00 AM Sunday morning, this could really be FUN
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,
of GDGs created *more frequently* than daily?
My opinion wasn't GDGs are not used, rather GDGs are usually created on
daily basis or less frequently.
BTW: I think that a reason why IBM didn't increase maximum LIMIT() for
GDG is lack of interest: Those customers who needed it already use
pseudo
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
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 characters. The semantics
I would like would be the ability
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
Well, having not gotten a straight answer to a straight question, I did a quick
test.
I had a GDG:
uid.GDGTEST.G0001V00
uid.GDGTEST.G0002V00
uid.GDGTEST.G0003V00
uid.GDGTEST.G0004V00
I then allocated
uid.GDGTEST.G0005V03
And I ended up
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
201 - 300 of 517 matches
Mail list logo