IDMS

  • 1.  IDD and reversing DMCL changes

    Posted Jun 03, 2007 04:53 PM
    Hi all,

    When making DMCL changes in preparation for a ""Space
    Maintenance Release"", occasionally we have to defer the
    implementation. So then we reverse the DMCL changes by
    (re-)modifying both the Segment & the DMCL, and genning the
    DMCL. NB: Basically we convert it back to what it was
    previously. And it can be a time-consuming process.

    However, I came up with a ""new method"" of doing this quickly;
    ie: backup the IDD catalog component (3 datasets), before
    making any DMCL changes.
    And if we have to roll-back, I just simply restore the IDD
    Catalog. And it seems to work sweet. (NB: Have only used this
    in the test region).

    However, the senior DBA is uncomfortable with this, as he is
    unsure what it might affect.

    Can someone please shed some light on this, as to whether it is
    an okay thing to do. All feedback gratefully received.

    NB: As a comparable practise - our production IDD migration
    procedure is done by copying the IDD Base Component (2
    datasets) from the Acceptance environment to the Production
    environment, and it has been done this way for many years, with
    no problems.

    Thanks very much.
    This e-mail may contain confidential or privileged information. If
    you think you have received this e-mail in error, please advise the
    sender by reply e-mail and then delete this e-mail immediately.
    Thank you. Aetna
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDD and reversing DMCL changes
    "You can also just punch out the to-be-affected areas and load them back
    in with a batch IDD job if necessary. The only caveat here is if any of
    the areas involved have been EXTENDED - if this is the case then you
    have to load the area definition back in with the original number of
    pages and perform the EXTEND SPACE online to bring the area back up to
    its prior configuration, since extend specs in IDD are displayed as a
    comment. PLUS, if you do not do this, you will not know immediately
    that you have mis-defined the area. But the CALC algorithm will be
    using the wrong page range, and you will start getting 0326 errors for
    records that DO exist, and you will be allowed to ADD records defined as
    ""duplicates not allowed"" when they already DO exist, because the CALC
    algorithm is telling IDMS to look on the wrong page . . . Been there,
    done that. Not a pretty picture.

    HOWEVER, given that I assume that you're restricting access to the CV
    during your modifications to yourself alone, your method of performing a
    physical (as opposed to logical) backup and restore of the IDD files via
    a native OS utility should work fine - the only changes being reversed
    with the restore should be those that you have made (and wish to
    reverse). I do this kind of thing all the time. Just play it safe and
    back up the files when the CV is down, and make sure that you are
    backing up all physical aspects of the file from the OS' perspective -
    such that you need not specify a DD (or DLBL for VSE) for the restore.
    Otherwise you're asking for trouble.

    Thus, given all of the above, I'd go with your method if you can.

    Hopefully this information is helpful.

    Mike Champagne


  • 2.  Re:IDD and reversing DMCL changes

    Posted Jun 03, 2007 04:53 PM
    Hi all,

    When making DMCL changes in preparation for a ""Space Maintenance
    Release"", occasionally we have to defer the implementation. So then we
    reverse the DMCL changes by (re-)modifying both the Segment & the DMCL,
    and genning the DMCL. NB: Basically we convert it back to what it was
    previously. And it can be a time-consuming process.

    However, I came up with a ""new method"" of doing this quickly; ie: backup
    the IDD catalog component (3 datasets), before making any DMCL changes.
    And if we have to roll-back, I just simply restore the IDD Catalog. And
    it seems to work sweet. (NB: Have only used this in the test region).

    However, the senior DBA is uncomfortable with this, as he is unsure what
    it might affect.

    Can someone please shed some light on this, as to whether it is an okay
    thing to do. All feedback gratefully received.

    NB: As a comparable practise - our production IDD migration procedure is
    done by copying the IDD Base Component (2 datasets) from the Acceptance
    environment to the Production environment, and it has been done this way
    for many years, with no problems.

    Thanks very much.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDD and reversing DMCL changes
    "Mike,

    Note that the DMCL is not kept in the ""IDD"" dictionaries, it is in the
    catalog (DCCAT, DCCATX and DCCATLOD). You have probably already figured
    that out in your test region.

    We have a process that works well, and we typically do dozens or scores
    of space changes in a single maintenance window. Here is a high-level
    sketch of what we do.

    In the days or weeks before the maintenance window, we create a ""local""
    set of catalog datasets and a small, local loadlib by copying the
    Production catalog dictionaries DCCAT, DCCATX and DCCATLOD to alternate
    named datasets, then unlocking these local areas.

    We run the syntax for the ALTER SEGMENT, INCLUDE FILE, GENERATE DMCL,
    and PUNCH DMCL LOAD MODULE in the local catalogs. The link step gives
    the output DMCL load module a slightly different name than the ""real
    DMCL"". Note that if we mess up some syntax, we can easily just run the
    copy jobs to recerate them.

    This allows the local load module to be used in the ... RELOAD USING
    DMCL ..."" clause of the unload/reload. Of course, if you are doing an
    XPAGE, you use the real DMCL (old), not the new one.

    After the unload/reloads run successfully, we then apply the ALTER
    SEGMENT, INCLUDE FILE, GENERATE DMCL, and PUNCH DMCL LOAD MODULE to the
    real catalog, and the output is the real DMCL module into the real loadlib.

    Hope this gives you some ideas on alternatives.

    Jim Ritterbusch

    Mike Baker wrote:
    Hi all,

    When making DMCL changes in preparation for a ""Space Maintenance Release"",
    occasionally we have to defer the implementation. So then we reverse the
    DMCL changes by (re-)modifying both the Segment & the DMCL, and genning
    the DMCL. NB: Basically we convert it back to what it was previously. And
    it can be a time-consuming process.

    However, I came up with a ""new method"" of doing this quickly; ie: backup
    the IDD catalog component (3 datasets), before making any DMCL changes.
    And if we have to roll-back, I just simply restore the IDD Catalog. And it
    seems to work sweet. (NB: Have only used this in the test region).

    However, the senior DBA is uncomfortable with this, as he is unsure what
    it might affect.

    Can someone please shed some light on this, as to whether it is an okay
    thing to do. All feedback gratefully received.

    NB: As a comparable practise - our production IDD migration procedure is
    done by copying the IDD Base Component (2 datasets) from the Acceptance
    environment to the Production environment, and it has been done this way
    for many years, with no problems.

    Thanks very much.


    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDD and reversing DMCL changes
    "Hi all

    At runtime the DMCL is just a Load Module.

    We generate ALL DMCL Load Modules in our development environment - we maintain separate Dev and Prod DMCLs.

    We never update our production catalog ( we are not using the SQL Option!).

    We back up a DMCL load module before a re-gen.

    ""Space Maintenance"" needs 2 DMCLs; old and new sTo:
    our back out is a simple load module replacement (and the obvious database restore). If we need to back out the DMCL changes we do it at our leisure!

    Cheers
    Martin

    ________________________________

    From: IDMS Public Discussion Forum on behalf of Mike Baker
    Sent: Sun 03/06/2007 21:53
    To: IDMS-L@LISTSERV.IUASSN.COM
    Subject: IDD and reversing DMCL changes



    Hi all,

    When making DMCL changes in preparation for a ""Space Maintenance Release"",
    occasionally we have to defer the implementation. So then we reverse the
    DMCL changes by (re-)modifying both the Segment & the DMCL, and genning
    the DMCL. NB: Basically we convert it back to what it was previously. And
    it can be a time-consuming process.

    However, I came up with a ""new method"" of doing this quickly; ie: backup
    the IDD catalog component (3 datasets), before making any DMCL changes.
    And if we have to roll-back, I just simply restore the IDD Catalog. And it
    seems to work sweet. (NB: Have only used this in the test region).

    However, the senior DBA is uncomfortable with this, as he is unsure what
    it might affect.

    Can someone please shed some light on this, as to whether it is an okay
    thing to do. All feedback gratefully received.

    NB: As a comparable practise - our production IDD migration procedure is
    done by copying the IDD Base Component (2 datasets) from the Acceptance
    environment to the Production environment, and it has been done this way
    for many years, with no problems.

    Thanks very much.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDD and reversing DMCL changes
    "Don't forget that the SYSTEM Catalog may also have Schemas, Tables, Views
    and restraints besides Segments, DMCL's, DBNAME's and DBTABLE's.

    Bill Allen


  • 3.  Re: IDD and reversing DMCL changes

    Posted Jun 03, 2007 08:10 PM
    as far as I am aware, NOTHING in the catalog complex is used at
    runtime - only a source repository to use in generating (temporary)
    load objects in the catalog load area, en route to a load library
    load module - as long as any emergency changes made after the backup
    but before the restore are carried forward (followed by a regen of
    the DMCL with the emergenncy changes) - i think you would be fine
    This is Chris Hoelscher and I approved this email
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDD and reversing DMCL changes
    ">as far as I am aware, NOTHING in the catalog complex is used at
    runtime - only a source repository to use in generating (temporary)
    load objects in the catalog load area, en route to a load library
    load module - as long as any emergency changes made after the backup
    but before the restore are carried forward (followed by a regen of
    the DMCL with the emergenncy changes) - i think you would be fine
    This is Chris Hoelscher and I approved this email
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    IDD and reversing DMCL changes
    "Hi all,

    When making DMCL changes in preparation for a ""Space Maintenance Release"",
    occasionally we have to defer the implementation. So then we reverse the
    DMCL changes by (re-)modifying both the Segment & the DMCL, and genning
    the DMCL. NB: Basically we convert it back to what it was previously. And
    it can be a time-consuming process.

    However, I came up with a ""new method"" of doing this quickly; ie: backup
    the IDD catalog component (3 datasets), before making any DMCL changes.
    And if we have to roll-back, I just simply restore the IDD Catalog. And it
    seems to work sweet. (NB: Have only used this in the test region).

    However, the senior DBA is uncomfortable with this, as he is unsure what
    it might affect.

    Can someone please shed some light on this, as to whether it is an okay
    thing to do. All feedback gratefully received.

    NB: As a comparable practise - our production IDD migration procedure is
    done by copying the IDD Base Component (2 datasets) from the Acceptance
    environment to the Production environment, and it has been done this way
    for many years, with no problems.

    Thanks very much.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: DCMT V PR nnnnnnnn NC
    "Cheers, thanks Gary & Rene.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Test Fix for LE/370 Programs running with IBM apar PK28112
    "Chris -

    I thought a recompile might solve my problem.
    I used the Enterprise COBOL for Z/OS compiler and still had the same
    problem.
    TC23407 was the silver bullet.

    Thanks.
    Jon





  • 4.  Re: IDD and reversing DMCL changes

    Posted Jun 04, 2007 04:37 AM
    You can also just punch out the to-be-affected areas and load
    them back in with a batch IDD job if necessary. The only
    caveat here is if any of the areas involved have been EXTENDED
    - if this is the case then you have to load the area definition
    back in with the original number of pages and perform the
    EXTEND SPACE online to bring the area back up to its prior
    configuration, since extend specs in IDD are displayed as a
    comment. PLUS, if you do not do this, you will not know
    immediately that you have mis-defined the area. But the CALC
    algorithm will be using the wrong page range, and you will
    start getting 0326 errors for records that DO exist, and you
    will be allowed to ADD records defined as ""duplicates not
    allowed"" when they already DO exist, because the CALC algorithm
    is telling IDMS to look on the wrong page . . . Been there,
    done that. Not a pretty picture.

    HOWEVER, given that I assume that you're restricting access to
    the CV during your modifications to yourself alone, your method
    of performing a physical (as opposed to logical) backup and
    restore of the IDD files via a native OS utility should work
    fine - the only changes being reversed with the restore should
    be those that you have made (and wish to reverse). I do this
    kind of thing all the time. Just play it safe and back up the
    files when the CV is down, and make sure that you are backing
    up all physical aspects of the file from the OS' perspective -
    such that you need not specify a DD (or DLBL for VSE) for the restore.
    Otherwise you're asking for trouble.

    Thus, given all of the above, I'd go with your method if you can.

    Hopefully this information is helpful.

    Mike Champagne