Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread esmie moo
...@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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread McKown, John
-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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread Lester, Bob
-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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread esmie moo
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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread Lester, Bob
-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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread esmie moo
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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread esmie moo
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

Re: REPORT OF NOSCRATCH GDG DSNS

2009-08-07 Thread Rick Fochtman
-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

GDG tool?

2009-05-18 Thread Lester, Bob
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 --

Re: GDG tool?

2009-05-18 Thread Tony Brown
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)

Re: GDG tool?

2009-05-18 Thread Staller, Allan
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

Re: GDG tool?

2009-05-18 Thread Lizette Koehler
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

Re: GDG tool?

2009-05-18 Thread Ulrich Krueger
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

Re: GDG tool?

2009-05-18 Thread Scott Barry
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

Re: GDG tool?

2009-05-18 Thread Lester, Bob
-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

Re: New GDG question

2009-01-30 Thread Tom Marchant
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

Re: New GDG question

2009-01-30 Thread Frank Swarbrick
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

Re: New GDG question

2009-01-30 Thread Rick Fochtman
-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

Re: New GDG question

2009-01-29 Thread Frank Swarbrick
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

Re: New GDG question

2009-01-29 Thread Scott Barry
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

Re: New GDG question

2009-01-29 Thread Tom Marchant
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

Re: New GDG question

2009-01-29 Thread Frank Swarbrick
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

Re: New GDG question

2009-01-29 Thread Scott Barry
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

Re: New GDG question

2009-01-28 Thread frederick . verwijs
-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

Re: New GDG question

2009-01-28 Thread Mike Slattery
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

Re: New GDG question

2009-01-28 Thread Pommier, Rex R.
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

Re: GDG question

2009-01-27 Thread Kenneth E Thompson
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

Re: GDG question

2009-01-27 Thread Ted MacNEIL
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!

Re: GDG question

2009-01-27 Thread Pommier, Rex R.
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

Re: GDG question

2009-01-27 Thread Pommier, Rex R.
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

Re: GDG question

2009-01-27 Thread Ted MacNEIL
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

Re: GDG Question

2009-01-27 Thread Ed Gould
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

New GDG question

2009-01-27 Thread Frank Swarbrick
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

Re: New GDG question

2009-01-27 Thread Len Rugen
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,

Re: New GDG question

2009-01-27 Thread Gary Green
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

Re: New GDG question

2009-01-27 Thread Brian Westerman
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

Re: New GDG question

2009-01-27 Thread Brian Fraser
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

Re: GDG Question

2009-01-26 Thread John Kelly
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

Re: GDG Question

2009-01-26 Thread Ted MacNEIL
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

Re: GDG Question

2009-01-26 Thread Barry Merrill
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

Re: GDG Question

2009-01-21 Thread R.S.
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

Re: GDG Question

2009-01-21 Thread Ted MacNEIL
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

Re: GDG Question

2009-01-21 Thread R.S.
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

Re: GDG Question

2009-01-21 Thread Richards, Robert B.
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

Re: GDG Question

2009-01-21 Thread R.S.
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

Re: GDG Question

2009-01-21 Thread Mark Zelden
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

Re: GDG Question

2009-01-21 Thread Compton, John
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

Re: GDG Question

2009-01-21 Thread Richards, Robert B.
@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

Re: GDG Question

2009-01-21 Thread Scott Barry
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

Re: GDG Question

2009-01-21 Thread Ted MacNEIL
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

Re: GDG Question

2009-01-21 Thread Martin Kline
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

Re: GDG Question

2009-01-21 Thread John McKown
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

Re: GDG Question

2009-01-21 Thread Tom Marchant
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.

Re: GDG Question

2009-01-21 Thread Arthur Gutowski
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

Re: GDG Question

2009-01-21 Thread Rick Fochtman
---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

Re: GDG Question

2009-01-21 Thread Gerhard Postpischil
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

Re: GDG Question

2009-01-21 Thread J R
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

Re: GDG Question

2009-01-21 Thread John McKown
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

Re: GDG Question

2009-01-21 Thread J R
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

Re: GDG Question

2009-01-21 Thread Tom Marchant
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

Re: GDG Question

2009-01-21 Thread Thompson, Steve
-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

Re: GDG Question

2009-01-21 Thread Tom Marchant
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

2009-01-20 Thread Joe Aulph
Re: GDG Question 01/19/2009 02:41 PM

Re: GDG Question

2009-01-20 Thread Lizette Koehler
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

Re: GDG Question

2009-01-20 Thread Joe Aulph
Subject .edu Re: GDG Question 01/20/2009 09:16

Re: GDG Question

2009-01-20 Thread David Magee
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

Re: GDG Question

2009-01-20 Thread R.S.
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

Re: GDG Question

2009-01-20 Thread David Andrews
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,

Re: GDG Question

2009-01-20 Thread R.S.
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

Re: GDG Question

2009-01-20 Thread Chris Hoelscher
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

Re: GDG Question

2009-01-20 Thread Ted MacNEIL
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!

Re: GDG Question

2009-01-20 Thread John Kington
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

SV: GDG Question

2009-01-20 Thread Thomas Berg
: 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

Re: GDG Question

2009-01-20 Thread Robert A. Rosenberg
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

Re: GDG Question

2009-01-20 Thread Robert A. Rosenberg
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

Re: GDG Question

2009-01-20 Thread Robert A. Rosenberg
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

Re: GDG Question

2009-01-20 Thread John McKown
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

Re: GDG Question

2009-01-20 Thread Tom Marchant
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

Re: GDG Question

2009-01-20 Thread J R
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

Re: GDG Question

2009-01-20 Thread Guy Gardoit
, 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

Re: GDG Question

2009-01-20 Thread Lizette Koehler
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

Re: GDG Question

2009-01-20 Thread Ted MacNEIL
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

Re: GDG Question

2009-01-20 Thread David Andrews
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

Re: GDG Question

2009-01-20 Thread J R
: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

Re: GDG Question

2009-01-20 Thread David Andrews
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

Re: GDG Question

2009-01-20 Thread Lizette Koehler
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

Re: GDG Question

2009-01-20 Thread Lizette Koehler
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

Re: GDG Question

2009-01-20 Thread J R
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

Re: GDG Question

2009-01-20 Thread Rick Fochtman
-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

Re: GDG Question

2009-01-20 Thread Rick Fochtman
--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

Re: GDG Question

2009-01-20 Thread Chase, John
-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

Re: GDG Question

2009-01-20 Thread Rick Fochtman
--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

Re: GDG Question

2009-01-20 Thread J R
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

GDG Question

2009-01-19 Thread Jerry Fuchs
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

Re: GDG Question

2009-01-19 Thread David Andrews
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

Re: GDG Question

2009-01-19 Thread Jerry Fuchs
-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

Re: GDG Question

2009-01-19 Thread Scott Barry
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

Re: GDG Question

2009-01-19 Thread Robert A. Rosenberg
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

Re: GDG Question

2009-01-19 Thread Ted MacNEIL
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

Re: GDG QUESTION

2008-11-17 Thread Hillock, Timothy
, 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

<    1   2   3   4   5   6   >