IDMS

[IDMS-L] Disaster recovery for a IDMS network DBMS

  • 1.  [IDMS-L] Disaster recovery for a IDMS network DBMS

    Posted Apr 18, 2006 12:51 PM
    Hello all,

    I am planning to implement a Disaster recovery strategy that ideally
    should
    include as many of the online transactions as is viable. We have
    successfully tested the basic recovery that included recovering the
    lpar,
    the up to date IDMS system backup and full application backups to a
    different location. The procedures are in place to copy these to
    physical
    tapes and transport them to the recovery site.

    We are using z/OS 1.6 and IDMS rel. 16 with SP 1.

    The application is implemented as a network database; we do not have the
    IDMS SQL option available for our use. I have seen a couple of tools
    (e.g.
    DARSTRAN and ASG-Replication Suite(tm) for CA-IDMS(r) Data) that are
    designed
    to use the IDMS journals to replicate an IDMS database to a different
    relational DBMS environment. So far as I can see these tools would not
    help
    for replication of a network database for disaster recovery purposes. I
    have
    been informed that IDMS does not have the capability to ""sync"" databases
    at
    different locations.

    Another approach for replication could be at the disk sub-system level.
    Apparently disk sub-system replication requires that the DBMS support a
    ""quiescent point"" for the replication process to be effective.

    The more straightforward approach would be to remove the offloaded
    journals
    from the originating site, either by copying them to tape or potentially
    transmitting the files to the recovery site. I am assuming we would not
    have
    the current CV disk journal in the case of disaster recovery because it
    would be destroyed or irrecoverable due to the nature of the ""disaster"".


    I am looking for feedback for how other sites are addressing the issue
    of
    disaster recovery that includes a procedure for recovering online
    transactions. Are there any ""gotchas"" with the transmission of the
    offloaded journals that I should be aware of?

    TIA

    Tim Williams
    Alberta Department of Justice
    CANADA




    This communication is intended for the use of the recipient to which it
    is
    addressed, and may contain confidential, personal and/or privileged
    information. Please contact the Justice/Solicitor General HelpDesk
    (Help.Desk@gov.ab.ca) @ (780) 415-2998 immediately if you are not the
    intended recipient of this communication, and do not copy, distribute,
    or
    take action relying on it. Any communication received in error or
    subsequent reply, should be deleted or destroyed.

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








    Normal

    Normal
    Re: Available PAGE Ranges
    "Bill

    Providing your user is on 14.1 and beyond. Have you considered using PAGE Groups to get relief from the PAGE GROUP 0 pool? For no application changes are required. Every APPLICATION dictionary. and application data we have is in separate PAGE Group's. Only thing usual, you must take define a MESSAGE SEGMENT and use a ""common"" DSNAME, that would be the same DSN for all application and system dictionaries (otherwise you would have to clone your message DSN's and keep them in sync. OUCH!)

    The only items our shop have in pool zero, are the ""common area's"", for example DIRLDICT; USERCTLG, TOOLDICT, only one ""common"" in house error-file used across CV's. and each individual SYSTEM dictionaries for each unique CV (note we use the common MESSAGE SEGMENT for each of these as well).

    If an application dictionary is required by another CV, we have it in update in one CV and retrieval in the others.

    *--->Sample DBTABLE entry for an application dictionary using page group:

    CREATE
    DBNAME DBTBS51.EG1TDICT
    MATCH ON SUBSCHEMA OPTIONAL
    MIXED PAGE GROUP BINDS NOT ALLOWED <--------
    INCLUDE SEGMENT EG1TDICT
    INCLUDE SEGMENT EG1TDLOD
    INCLUDE SEGMENT EG1TMSG1
    INCLUDE SEGMENT EG1TNDVR <-----our ENDEVOR PAK, LOG, ADM
    INCLUDE SUBSCHEMA IDMSNWKA MAPS TO NDVRNWKA
    ;

    *---->SAMPLE SEGMENTS defined using PAGE GROUP 53

    ++++++++++++++++++++++++++++++++++
    CREATE
    SEGMENT EG1TMSG1
    FOR NONSQL
    PAGE GROUP 53
    MAXIMUM RECORDS PER PAGE 255
    ;
    CREATE
    FILE EG1TMSG1.EG1TMSG1
    ASSIGN TO EG1TMSG1
    *> DSNAME 'IDMS.MSGSDICT.MSGSMSG1.DDLDCMSG'
    DISP SHR
    NONVSAM
    ;
    CREATE
    SEGMENT EG1TDICT
    FOR NONSQL
    PAGE GROUP 53
    MAXIMUM RECORDS PER PAGE 255
    ;
    CREATE
    SEGMENT EG1TDLOD
    FOR NONSQL
    PAGE GROUP 53
    MAXIMUM RECORDS PER PAGE 255
    ;
    CREATE
    SEGMENT EG1TNDVR
    FOR NONSQL
    PAGE GROUP 53
    MAXIMUM RECORDS PER PAGE 255
    ;
    +++++++++++++++++++++++++++++++



    Edward A. Timm
    Sallie Mae, Senior Database Analyst
    ETIMM@salliemae.com
    (317) 596-1182
    Fax (317) 595-1494
    ARCHCONB@aol.com 04/17/2006 02:27:46 AM >>>
    Hello All:

    Anybody have a utility that can provide you with a report of the available
    page ranges? Can you share it?

    I have a client that has almost exhausted the 16,777,215 Pages available in
    page group zero but it takes forever to find available page ranges using
    IEBEYEBALL.

    Bill Allen

    This E-Mail has been scanned for viruses.

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








    Normal

    Normal
    COBOL LE multiple enclave support
    "I am having some trouble understanding the documentation on COBOL LE
    multiple enclave support. We have this turned off at present. Can
    someone tell me what kind of situations would see a big benefit from
    turning it on?

    Kay Rozeboom
    State of Iowa
    Information Technology Enterprise
    Department of Administrative Services
    Telephone: 515.281.6139 Fax: 515.281.6137
    Email: Kay.Rozeboom@Iowa.Gov

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








    Normal

    Normal
    Re: COBOL LE multiple enclave support
    "There will be benefits if you have ADS dialogs that LINK to Cobol programs multiple times in a single execution of the dialog (i.e. within a single IDMS-DC task). With multiple enclave support OFF the LE environment is established for each and every LINK. When you have multiple enclave support ON the LE environment is established only once - and all the Cobol programs referenced within the task are treated as being a ""single Cobol run unit"" (which is the way that I think of an ""enclave"" - rightly or wrongly).

    If you have a DC-Cobol program that does a ""pseudo converse"" you will have to turn multiple enclave support OFF for that program. I believe there may be other exceptions to the ability to use multiple enclave support - but that would be the main one. We have had it ON for a couple of years now with no problems - and some measurable benefit although I can't give a figure.

    Cheers - Gary

    Gary Cherlet
    Justice Technology Services
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:cherlet.gary@saugov.sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents.
    Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services.
    Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.