Discussion:
extended GDG implementation
(too old to reply)
Pommier, Rex
2017-08-29 19:09:00 UTC
Permalink
Raw Message
Hello list,

I have what are probably simple questions regarding the relaxation of the 255 generation GDG limit. We are running z/OS 2.2 so are eligible for the relaxation. I know I need to make a change to the IGGCATx member to activate the capability and I need to add EXT to the GDG definition. So here are my (rather basic) questions.

1. Can I implement an IGGCATxx member short of an IPL? I don't have one now, relying on the defaults, and I don't see anything in the INIT&TUNING manual that indicates that I can implement this dynamically, sadly.

2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the answer to this is "no, it can only be done at GDG definition time" but am hoping.

3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including the ones that have fallen off?

TIA - again!

Rex

The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2017-08-29 19:13:15 UTC
Permalink
Raw Message
Rex,

See my >> comments below.

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
Sent: Tuesday, August 29, 2017 3:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: extended GDG implementation

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 generation GDG limit. We are running z/OS 2.2 so are eligible for the relaxation. I know I need to make a change to the IGGCATx member to activate the capability and I need to add EXT to the GDG definition. So here are my (rather basic) questions.

1. Can I implement an IGGCATxx member short of an IPL? I don't have one now, relying on the defaults, and I don't see anything in the INIT&TUNING manual that indicates that I can implement this dynamically, sadly. <<not sure if a catalog restart would reread IGGCATxx. We did it via one of our maintenance IPLs across the plex.

2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the answer to this is "no, it can only be done at GDG definition time" but am hoping. << no, sadly, we just tried this. ALTER does not allow you to change from std to EXT.

3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including the ones that have fallen off? >>my storage guys say they rename the GDG's, fix the base, and rename them back. I cant say Ive tried that, but that’s what they tell me.

TIA - again!

Rex

The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dyck, Lionel B. , TRA
2017-08-29 19:15:16 UTC
Permalink
Raw Message
I can't answer (1) or (2) but you should check out CBTTape File 951 from Nick Light - it has a tool called GDGP that will help 'migrate' from existing GDG's to the new extended GDG. Be careful using it with SMS managed datasets but for tape it should be fine as it will uncatalog, delete the GDG base, redefine the GDG, and recatalog the datasets. I haven't tried it on tape but see no reason that it shouldn't work.

As always with the CBTTape ymmv so experiment before using in production

--------------------------------------------------------------------------
Lionel B. Dyck
Mainframe Systems Programmer - TRA

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
Sent: Tuesday, August 29, 2017 2:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] extended GDG implementation

Hello list,

I have what are probably simple questions regarding the relaxation of the 255 generation GDG limit. We are running z/OS 2.2 so are eligible for the relaxation. I know I need to make a change to the IGGCATx member to activate the capability and I need to add EXT to the GDG definition. So here are my (rather basic) questions.

1. Can I implement an IGGCATxx member short of an IPL? I don't have one now, relying on the defaults, and I don't see anything in the INIT&TUNING manual that indicates that I can implement this dynamically, sadly.

2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the answer to this is "no, it can only be done at GDG definition time" but am hoping.

3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including the ones that have fallen off?

TIA - again!

Rex

The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Doug Henry
2017-08-29 19:23:57 UTC
Permalink
Raw Message
2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the >answer to this is "no, it can only be done at GDG definition time" but am hoping.
3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) >and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 >is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape >generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including >the ones that have fallen off?
TIA - again!
Rex
For answer to part 2 and 3 see Marna Wallle's blog. As always Marna gives good advice.

http://www.share.org/blog/gdg-to-gdge-conversions

Doug

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-08-29 19:54:08 UTC
Permalink
Raw Message
Post by Pommier, Rex
Hello list,
I have what are probably simple questions regarding the relaxation of the 255 generation GDG limit. We are running z/OS 2.2 so are eligible for the relaxation. I know I need to make a change to the IGGCATx member to activate the capability and I need to add EXT to the GDG definition. So here are my (rather basic) questions.
1. Can I implement an IGGCATxx member short of an IPL? I don't have one now, relying on the defaults, and I don't see anything in the INIT&TUNING manual that indicates that I can implement this dynamically, sadly.
2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the answer to this is "no, it can only be done at GDG definition time" but am hoping.
3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including the ones that have fallen off?
<snip>

For (1), Managing Catalogs says, "The system applies IGGCATxx values at
IPL time as well as at the restart of the Catalog Address Space." You
can restart Catalog using F CATALOG,RESTART. Be aware that Catalog
operations will be suspended for a bit while that happens.

For (2), I don't see an ALTER keyword that would do that, nor the
Extended attribute (for GDGs) in the alterable attribute list, in Access
Method Services Commands.

For (3), I don't, but I'd want to try a test case or two first!
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2017-09-11 17:06:57 UTC
Permalink
Raw Message
Hi List,

First of all, thanks everybody for your assistance.

Second, just to close this, I followed John's recommendation about recycling the CATALOG address space to pick up the ability to use extended GDGs. Yes, I did this off hours when there was very little running on the machine and it worked fine. After the capability was in place via the catalog address space cycle, I was able to uncatalog all the virtual tape generations, redefine the GDG base as extended, and recataloged all the tapes to the redefined GDG. All worked as advertised. Users are happy they can now access their old stuff which makes me happy too. :-)

Thanks everybody, again.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Eells
Sent: Tuesday, August 29, 2017 2:55 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: extended GDG implementation
Post by Pommier, Rex
Hello list,
I have what are probably simple questions regarding the relaxation of the 255 generation GDG limit. We are running z/OS 2.2 so are eligible for the relaxation. I know I need to make a change to the IGGCATx member to activate the capability and I need to add EXT to the GDG definition. So here are my (rather basic) questions.
1. Can I implement an IGGCATxx member short of an IPL? I don't have one now, relying on the defaults, and I don't see anything in the INIT&TUNING manual that indicates that I can implement this dynamically, sadly.
2. Once it is active, can I use an IDCAMS ALTER to change between the old limit and an extended one? I am positive the answer to this is "no, it can only be done at GDG definition time" but am hoping.
3. Here's the scenario that has led me to this point. We just discovered we have a tape based GDG defined with LIMIT(255) and we have had several generations fall off the end. This is data we need to recover. Presuming the answer to question 2 is "no" as I strongly suspect, does anybody see an unsurmountable problem with (carefully) uncataloging all the tape generations, redefining the GDG base as extended with an appropriate limit, and recataloging all the generations, including the ones that have fallen off?
<snip>

For (1), Managing Catalogs says, "The system applies IGGCATxx values at
IPL time as well as at the restart of the Catalog Address Space." You
can restart Catalog using F CATALOG,RESTART. Be aware that Catalog
operations will be suspended for a bit while that happens.

For (2), I don't see an ALTER keyword that would do that, nor the
Extended attribute (for GDGs) in the alterable attribute list, in Access
Method Services Commands.

For (3), I don't, but I'd want to try a test case or two first!
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-08-30 16:11:32 UTC
Permalink
Raw Message
Basically the extended GDG has a new format. So the old GDG cannot become the new GDGE without some effort.

For example: If the datasets are TAPE - Uncatalog tape, create the new GDGE, catalog the tape

Marna (as others have stated) has done testing and provide some suggestions on how to tackle this. There was a discussion on if it is on DASD and Migrated, does it need to be recalled in-order to do this.

IBM did not provide a "switch" from GDG to GDGE. Due to it being a new function in the catalog it has a very different structure than a GDG.

As shops move to the GDGE function, I am hoping that IBM will find an easier way to do this.

So my understanding is the GDG datasets have to be converted to the GDGE format.


Lizette
Post by Jousma, David
-----Original Message-----
Behalf Of Pommier, Rex
Sent: Tuesday, August 29, 2017 12:10 PM
Subject: extended GDG implementation
Hello list,
I have what are probably simple questions regarding the relaxation of the 255
generation GDG limit. We are running z/OS 2.2 so are eligible for the
relaxation. I know I need to make a change to the IGGCATx member to activate
the capability and I need to add EXT to the GDG definition. So here are my
(rather basic) questions.
1. Can I implement an IGGCATxx member short of an IPL? I don't have one
now, relying on the defaults, and I don't see anything in the INIT&TUNING
manual that indicates that I can implement this dynamically, sadly.
2. Once it is active, can I use an IDCAMS ALTER to change between the old
limit and an extended one? I am positive the answer to this is "no, it can
only be done at GDG definition time" but am hoping.
3. Here's the scenario that has led me to this point. We just discovered we
have a tape based GDG defined with LIMIT(255) and we have had several
generations fall off the end. This is data we need to recover. Presuming
the answer to question 2 is "no" as I strongly suspect, does anybody see an
unsurmountable problem with (carefully) uncataloging all the tape
generations, redefining the GDG base as extended with an appropriate limit,
and recataloging all the generations, including the ones that have fallen
off?
TIA - again!
Rex
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-08-31 09:08:03 UTC
Permalink
Raw Message
Post by Lizette Koehler
Basically the extended GDG has a new format. So the old GDG cannot become the new GDGE without some effort.
IMHO it's not so big thing. The format is only the record(s) in ICF
calatalog, the datasets are GDG-GDGE agnostic.
I can imagine a routine to temporary write GDG entry content in some
temp space, delete the GDG entry, create GDGE entry and fill it with the
content. There is no need to touch the datasets on DASD, ML1/2 or tape
since there is no metadata there to change.
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...