ca.portal.admin

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

Discussion created by ca.portal.admin on Apr 18, 2006
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.

Outcomes