ca.portal.admin

Parallel Unload/Reload

Discussion created by ca.portal.admin on Jun 7, 2006
Hello all,

A few years ago, I saw messages on this list about using parallel jobs
for
unloads and reloads.

For a new project, we are facing a situation where we may have to unload
and
reload an area with 150,000,000 records connected to a system owned
index
(MA set).

We have FAST ACCESS and it's good but not that good.

Can somebody provide feedback on the methodology for parallel unloads
and
reloads discussed here a few years ago ?

TIA,

Claude Ferland
Contractor
NYC

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








Normal

Normal
Parallel Unload/Reload
"Hello all,

A few years ago, I saw messages on this list about using parallel jobs for
unloads and reloads.

For a new project, we are facing a situation where we may have to unload and
reload an area with 150,000,000 records connected to a system owned index
(MA set).

We have FAST ACCESS and it's good but not that good.

Can somebody provide feedback on the methodology for parallel unloads and
reloads discussed here a few years ago ?

TIA,

Claude Ferland
Contractor
NYC

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








Normal

Normal
Re: [IDMSVENDOR-L] Broken pointer utility
" Some of our users do their own backups, so
they can restore after running a batch job that went awry. This works
fine, as long as they keep their backup and restore JCL current. We
have had a few cases where someone forgot to update their JCL after
adding a new file to the database.


not offering advice here, but just based on my own experiences ... NEVER
let developers put in jobs in production to backup production database
data. (especially the one you do not know about) Since 12.0, the idea is
that developers do not need to know the dataset layout. Since they do not
have DDs in their jobs anymore to see what files are used (or even in the
CV startup) - its an unnecessary burden to change ""application"" production
(backup) jobs when database files are added (missed backup) or dropped
(abended jobs)

i suppose if they backup using generics, you might get away with it, but
when a pre- or post- local mode update job backup is desired, the
DBA-authored DBA group backup job for that application is run.

now on the other hand, if the dev team (and not the DBA) is responsible
for data integrity and d/r, then let them handle the backups - but i have
not found this to be true in most places I have worked.


the bottom line is .. if they database is corrupted due to a bad appl
backup, the appl folks will fix it, right? NAAAAAAAAAAAAAAAAAAAA


just my thoughts ...

The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

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








Normal

Normal
Re: Broken pointer utility
"We rarely have broken chains any more. When we do, they are usually
caused by improper recovery. Some of our users do their own backups, so
they can restore after running a batch job that went awry. This works
fine, as long as they keep their backup and restore JCL current. We
have had a few cases where someone forgot to update their JCL after
adding a new file to the database.

Another cause of broken chains is bad backups, where the user did not
verify that all areas were offline before taking the backup.


-----Oorspronkelijk bericht-----
Van: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]Namens Miley, Dan L
Verzonden: dinsdag 6 juni 2006 16:15
Aan: IDMS-L@LISTSERV.IUASSN.COM
Onderwerp: Re: Broken pointer utility


I am just curious as to the cause of the group's broken chains. We
haven't had one in 10 years (at least). Is it mostly local mode updates
gone awry, improper recovery, or what? In general, we have strict rules
on update (most applications use CV update exclusively, except for MRP,
which still does some local update), so I am sure that is why we never
have problems.

Thanks,
Dan Miley
Lockheed Martin

Outcomes