DB2 - L

Expand all | Collapse all

Db2 12 z/OS - old logs and new definitions

  • 1.  Db2 12 z/OS - old logs and new definitions

    Posted Jun 26, 2021 06:44 AM
    Hello y'all,

    today's puzzle was the following:

    we need to redefine larger Db2 logs, to try and not have a log switch every 15 seconds in some of our production systems, and because we want to ensure that all our members of a DS group have the same number of logs (yes this is not necessary but it's tidier and it makes it easier to know how many logs you have "left" if archive is a bit slow).

    HOWEVER here's the catch: some of our logs were defined in the middle ages or so, e.g. 1993, and they apparently are NONINDEXED instead of LINEAR - so our REPRO fails miserably with a definition of linear datasets (we didn't know what the issue was until investigation)... AND with datasets defined as NONINDEXED too! *insert here string of characters from the top line of the keyboard*

    if we define a DS as nonindexed, we get:

    REPRO INFILE(LOG1DS1) -
    OUTDATASET(RZxx.DB11.LOGCOPY1.DS01)
    IDC3302I ACTION ERROR ON RZxx.DB11.OLD.LOGCOPY1.DS01
    IDC3351I ** VSAM I/O RETURN CODE IS 156 - RPLFDBWD = X'2808009C'
    IDC31467I MAXIMUM ERROR LIMIT REACHED.
    IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
    IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

    which is an *ahem* index error.... 

    since we didn't want to spend all bloomin' weekend on this issue we simply deleted the newly defined logs, restored the backup and decided to look into it later, but does anyone have any idea how we can "convert" our old log datasets to something more let's say at least 19th century?

    TIA - have a good weekend everyone.


    ------------------------------
    Aurora


    Stay safe and healthy, y'all
    ------------------------------


  • 2.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 01:23 AM
    Why are you copying your old logs? Create new log datasets, delete old BSDS entries and
    add your new ones .

    I think the error you're seeing is because an ESDS / NONINDEXED CI contains 7 (?) bytes of
    VSAM overhead - so as far as VSAM is concerned it sees records of 4089 bytes. I think it
    would be impossible to copy.

    James Campbell



    On 26 Jun 2021 at 10:44, Aurora Emanuela Dellanno via wrote:

    > Hello y'all,
    >
    > today's puzzle was the following:
    >
    > we need to redefine larger Db2 logs, to try and not have a log switch every 15 seconds in some of our production systems, and because we want to ensure that all our members of a DS group have the same number of logs (yes this is not necessary but it's tidier and it makes it easier to know how many logs you have "left" if archive is a bit slow).
    >
    > HOWEVER here's the catch: some of our logs were defined in the middle ages or so, e.g. 1993, and they apparently are NONINDEXED instead of LINEAR - so our REPRO fails miserably with a definition of linear datasets (we didn't know what the issue was until investigation)... AND with datasets defined as NONINDEXED too! *insert here string of characters from the top line of the keyboard*
    >
    > if we define a DS as nonindexed, we get:
    >
    > REPRO INFILE(LOG1DS1) -
    > OUTDATASET(RZxx.DB11.LOGCOPY1.DS01)
    > IDC3302I ACTION ERROR ON RZxx.DB11.OLD.LOGCOPY1.DS01
    > IDC3351I ** VSAM I/O RETURN CODE IS 156 - RPLFDBWD = X'2808009C'
    > IDC31467I MAXIMUM ERROR LIMIT REACHED.
    > IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
    > IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
    >
    > which is an *ahem* index error....
    >
    > since we didn't want to spend all bloomin' weekend on this issue we simply deleted the newly defined logs, restored the backup and decided to look into it later, but does anyone have any idea how we can "convert" our old log datasets to something more let's say at least 19th century?
    >
    > TIA - have a good weekend everyone.
    >
    >
    > ------------------------------
    > Aurora
    >
    >
    > Stay safe and healthy, y'all
    > ------------------------------
    >
    >

    --
    This email has been checked for viruses by AVG.
    https://www.avg.com




  • 3.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 03:33 AM
    hi James!

    sorry I'm not really following you, not enough coffee I suppose - are you saying just cold start DB2? That of course is something we had thought about, but only if we can't find a way of preserving our log data.

    also, why should I delete the old entries from the BSDS - I mean what exactly should I delete, the log dataset names are the same, we are not defining fewer logs, just bigger.

    Thanks.

    ------------------------------
    Aurora


    Stay safe and healthy, y'all
    ------------------------------



  • 4.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 03:43 AM
    Aurora, 
    All the logs are in the archives, so except the one which is active you can forget all the others.
    add new log n times 
    archive the current log 
    update bsds to delete all old logs
    need just one db2 recycle.










  • 5.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 06:07 AM
    ok sorry, maybe I'm thick instead because I really don't understand - WHY do I need to delete the logs from the BSDS, and what logs would I delete?

    I am not adding any new datasets, I am delete / defining the ones I have, larger...

    ------------------------------
    Aurora


    Stay safe and healthy, y'all
    ------------------------------



  • 6.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 07:03 AM
    I think the suggestion is to add "new" (bigger) logs then delete the old ones. Give the new ones different names in fact

    Phil G

    Sent from my iPad





  • 7.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 12:44 PM
    That's what I would do. Copying log files is nice and easy when you want to keep them as they are. Let's say, if you just want to move them to a different set of disks. But when you need to apply some change on them, copying can be troublesome if possible at all.

    It is slower, but easier and safer, to add active log files newly defined as you need them to be. Then, when your 'old' set of active log files are all archived, you can remove them and end up with only the set of bigger active log files you wanted in the first place. No information will be lost, it all will be archived. 

    This approach will take two outages, though.

    ------------------------------
    Jaime Fernandez
    ------------------------------



  • 8.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 28, 2021 12:53 PM

    If you change names, please contact your MF Storage admins/Sysprogs.  Ensure the new names will be handled by DFSMS (hsm and dfdss and ACS Codes)

     

    Lizette

     

     






  • 9.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jun 29, 2021 12:38 AM
    The BSDS contains not only the names of your log files, but also their start and end RBAs,
    LRSNs and timestamps. If you blandly delete a log file and create/format a new one with the
    same name it is possible that Db2 might decide to go looking in that new file for some old log
    records. And will be surprised when they are not there.

    I also do not know if, when switching log files, Db2 checks that the file it is switching to
    contains the log information it is expecting (from the last time it was in use). It might do this
    to ensure that you have formatted the file.

    That is why you need to delete the BSDS entries for the old log clusters and recreate them
    for the new - Db2 will know that the log clusters do not contain old log records.

    Of course I am not saying 'cold start Db2'. I am saying find a time when Db2 is using log files
    you are happy with (i.e. your new larger LINEAR clusters); make sure all previous logs have
    been archived; stop Db2; delete ESDS log files; create and format LINEAR log files; delete
    BSDS entries; add BSDS entries; start Db2.

    And, of course do not delete the BSDS entry for the log files that are active at the time you
    stop Db2 - or the actual log files. They will be needed in the restart. By making sure that
    they are your new improved log files you only need one stop of Db2.


    James Campbell


    On 28 Jun 2021 at 10:06, Aurora Emanuela Dellanno via wrote:

    > ok sorry, maybe I'm thick instead because I really don't understand - WHY do I need to delete the logs from the BSDS, and what logs would I delete?
    >
    > I am not adding any new datasets, I am delete / defining the ones I have, larger...
    >
    > ------------------------------
    > Aurora
    >
    >
    > Stay safe and healthy, y'all
    > ------------------------------
    > -------------------------------------------
    > Original Message:
    > Sent: Jun 28, 2021 03:42 AM
    > From: Nguyen Duc Tuan
    > Subject: Db2 12 z/OS - old logs and new definitions
    >
    > Aurora, All the logs are in the archives, so except the one which is active you can forget all the others.add new log n times archive the current log update bsds to delete all old logsneed just one db2 recycle.
    >
    >
    >
    >
    >
    >
    >
    > Original Message:
    > Sent: 6/28/2021 3:33:00 AM
    > From: Aurora Emanuela Dellanno
    > Subject: RE: Db2 12 z/OS - old logs and new definitions
    >
    > hi James!
    >
    > sorry I'm not really following you, not enough coffee I suppose - are you saying just cold start DB2? That of course is something we had thought about, but only if we can't find a way of preserving our log data.
    >
    > also, why should I delete the old entries from the BSDS - I mean what exactly should I delete, the log dataset names are the same, we are not defining fewer logs, just bigger.
    >
    > Thanks.
    >
    > ------------------------------
    > Aurora
    >
    >
    > Stay safe and healthy, y'all
    > ------------------------------
    >
    > Original Message:
    > Sent: Jun 28, 2021 01:23 AM
    > From: James Campbell
    > Subject: Db2 12 z/OS - old logs and new definitions
    >
    > Why are you copying your old logs? Create new log datasets, delete old BSDS entries and
    > add your new ones .
    >
    > I think the error you're seeing is because an ESDS / NONINDEXED CI contains 7 (?) bytes of
    > VSAM overhead - so as far as VSAM is concerned it sees records of 4089 bytes. I think it
    > would be impossible to copy.
    >
    > James Campbell
    >
    >
    >
    > On 26 Jun 2021 at 10:44, Aurora Emanuela Dellanno via wrote:
    >
    > > Hello y'all,
    > >
    > > today's puzzle was the following:
    > >
    > > we need to redefine larger Db2 logs, to try and not have a log switch every 15 seconds in some of our production systems, and because we want to ensure that all our members of a DS group have the same number of logs (yes this is not necessary but it's tidier and it makes it easier to know how many logs you have "left" if archive is a bit slow).
    > >
    > > HOWEVER here's the catch: some of our logs were defined in the middle ages or so, e.g. 1993, and they apparently are NONINDEXED instead of LINEAR - so our REPRO fails miserably with a definition of linear datasets (we didn't know what the issue was until investigation)... AND with datasets defined as NONINDEXED too! *insert here string of characters from the top line of the keyboard*
    > >
    > > if we define a DS as nonindexed, we get:
    > >
    > > REPRO INFILE(LOG1DS1) -
    > > OUTDATASET(RZxx.DB11.LOGCOPY1.DS01)
    > > IDC3302I ACTION ERROR ON RZxx.DB11.OLD.LOGCOPY1.DS01
    > > IDC3351I ** VSAM I/O RETURN CODE IS 156 - RPLFDBWD = X'2808009C'
    > > IDC31467I MAXIMUM ERROR LIMIT REACHED.
    > > IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
    > > IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
    > >
    > > which is an *ahem* index error....
    > >
    > > since we didn't want to spend all bloomin' weekend on this issue we simply deleted the newly defined logs, restored the backup and decided to look into it later, but does anyone have any idea how we can "convert" our old log datasets to something more let's say at least 19th century?
    > >
    > > TIA - have a good weekend everyone.
    > >
    > >
    > > ------------------------------
    > > Aurora
    > >
    > >
    > > Stay safe and healthy, y'all
    > > ------------------------------
    > >
    > >
    >
    > --
    > This email has been checked for viruses by AVG.
    > https://www.avg.com <https: www.avg.com="">
    >
    >
    > Original Message:
    > Sent: 6/26/2021 6:44:00 AM
    > From: Aurora Emanuela Dellanno
    > Subject: Db2 12 z/OS - old logs and new definitions
    >
    > Hello y'all,
    >
    > today's puzzle was the following:
    >
    > we need to redefine larger Db2 logs, to try and not have a log switch every 15 seconds in some of our production systems, and because we want to ensure that all our members of a DS group have the same number of logs (yes this is not necessary but it's tidier and it makes it easier to know how many logs you have "left" if archive is a bit slow).
    >
    > HOWEVER here's the catch: some of our logs were defined in the middle ages or so, e.g. 1993, and they apparently are NONINDEXED instead of LINEAR - so our REPRO fails miserably with a definition of linear datasets (we didn't know what the issue was until investigation)... AND with datasets defined as NONINDEXED too! *insert here string of characters from the top line of the keyboard*
    >
    > if we define a DS as nonindexed, we get:
    >
    > REPRO INFILE(LOG1DS1) -
    > OUTDATASET(RZxx.DB11.LOGCOPY1.DS01)
    > IDC3302I ACTION ERROR ON RZxx.DB11.OLD.LOGCOPY1.DS01
    > IDC3351I ** VSAM I/O RETURN CODE IS 156 - RPLFDBWD = X'2808009C'
    > IDC31467I MAXIMUM ERROR LIMIT REACHED.
    > IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
    > IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
    >
    > which is an *ahem* index error....
    >
    > since we didn't want to spend all bloomin' weekend on this issue we simply deleted the newly defined logs, restored the backup and decided to look into it later, but does anyone have any idea how we can "convert" our old log datasets to something more let's say at least 19th century?
    >
    > TIA - have a good weekend everyone.
    >
    >
    > ------------------------------
    > Aurora
    >
    >
    > Stay safe and healthy, y'all
    > ------------------------------
    >
    >
    > Reply to Sender : https://www.idug.org/eGroups/PostReply/?GroupId=253&MID=172007&SenderKey=683ebab5-e040-48f8-b8a2-aaa84e373bd8&MDATE=757645%253b47%253d&UserKey=0e114382-b62d-4df5-8bae-216292fc0091&sKey=KeyRemoved
    >
    > Reply to Discussion : https://www.idug.org/eGroups/PostReply/?GroupId=253&MID=172007&MDATE=757645%253b47%253d&UserKey=0e114382-b62d-4df5-8bae-216292fc0091&sKey=KeyRemoved
    >
    >
    >
    > You are subscribed to "DB2 - L" as jacampbellaus@gmail.com. To change your subscriptions, go to http://www.idug.org/preferences?section=Subscriptions&MDATE=757645%253b47%253d&UserKey=0e114382-b62d-4df5-8bae-216292fc0091&sKey=KeyRemoved. To unsubscribe from this community discussion, go to http://www.idug.org/HigherLogic/eGroups/Unsubscribe.aspx?UserKey=0e114382-b62d-4df5-8bae-216292fc0091&sKey=KeyRemoved&GroupKey=37484667-8556-4529-8eb2-a1404f7c5c5f.



    --
    This email has been checked for viruses by AVG.
    https://www.avg.com




  • 10.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jul 31, 2021 10:24 AM
    ok today was our maintenance window, and we finally got the *ahem* silly buggers sorted out - @James Campbell I kept your email handy and followed the steps - in case you are interested, the answer to your "I also do not know if, when switching log files, Db2 checks that the file it is switching to contains the log information it is expecting (from the last time it was in use)" is: yes it does.

    DB2 at startup checks the RBA of all logs against the BSDS entries and ABENDs if you for example have forgotten that bit from your complicated long JCL *ahem again, nasty cough I've got here*.

    but happy days all good now, we may even get 15 minutes of DB2 activity per log!

    Have a good weekend y'all.


    ------------------------------
    Aurora


    Stay safe and healthy, y'all
    ------------------------------



  • 11.  RE: Db2 12 z/OS - old logs and new definitions

    Posted Jul 25, 2021 07:36 AM
    Hi, Good day, 
    I also got the same error message while performing a Repro of old ESDS nonindexed logs files to Linear ones. 
    I even tried creating them as nonindexed, but still the same error came. 

    There is no disclaimers in the manual about not using Repro in case the format of the log files are different. 

    So, we used the 2nd method provided which does not need a repro 

    If you cannot use the Access Method Services REPRO command, follow this procedure:

    1. Ensure that all active log data sets except the current active log data sets have been archived. Active log data sets that have been archived are marked REUSABLE in print log map utility (DSNJU004) output.
    2. Stop Db2.
    3. Rename or delete the reusable active logs. Allocate new, larger active log data sets with the same names as the old active log data sets.
    4. Run the DSNJLOGF utility to preformat the new log data sets.
    5. Run the change log inventory utility (DSNJU003) with the DELETE statement to delete all active logs except the current active logs from the BSDS.
    6. Run the change log inventory utility with the NEWLOG statement to add to the BSDS the active logs that you just deleted. So that the logs are added as empty, do not specify an RBA range.
    7. Start Db2.
    8. Issue the ARCHIVE LOG command to cause Db2 to truncate the current active logs and switch to one of the new sets of active logs.
    9. Repeat steps 2 through 7 to enlarge the active logs that were just archived.


    Regards

    Eswar



    ------------------------------
    Eswar PrasadChandrasekaranA
    ------------------------------