SEO

We are running on Win 2003/DB2 V8 FP7a.

My question concerns Task Center. I have about 200 tasks created and
scheduled in Task Center. We are going to be moving many of the
databases from this server to another V8 server and I really, really,
really don't want to have to re-key all of these tasks on the new
system.

The Task Center "export" function seems to only export general task
information like the description and type of task, but not the task
itself. I'm not really sure what this is good for since it does not
appear to be compatible with the Task Center "import" function.

I thought about backing up the tools database and restoring on the
target system, but then I'd wipe out the tasks already defined on the
target system.

If I knew the appropriate tables in the tools database I could export
the data and import it into the target system, but they use so many
auto-generated keys (apparently) that it would be a big risk on
duplicating key values.

Does anybody know of a way to do this?

Is there a "batch" method of defining a task to Task Center?
Thanks in advance,
klh

"klh" <khar0429@yahoo.com> wrote in message
news:1107204018.661814.29360@c13g2000cwb.googlegro ups.com...
> We are running on Win 2003/DB2 V8 FP7a.
>
> My question concerns Task Center. I have about 200 tasks created and
> scheduled in Task Center. We are going to be moving many of the
> databases from this server to another V8 server and I really, really,
> really don't want to have to re-key all of these tasks on the new
> system.
>
> The Task Center "export" function seems to only export general task
> information like the description and type of task, but not the task
> itself. I'm not really sure what this is good for since it does not
> appear to be compatible with the Task Center "import" function.
>
> I thought about backing up the tools database and restoring on the
> target system, but then I'd wipe out the tasks already defined on the
> target system.
>
> If I knew the appropriate tables in the tools database I could export
> the data and import it into the target system, but they use so many
> auto-generated keys (apparently) that it would be a big risk on
> duplicating key values.
>
> Does anybody know of a way to do this?
>
> Is there a "batch" method of defining a task to Task Center?
> Thanks in advance,
> klh
>
Not sure, but can't you just backup and restore the tools database to the
new server?

BTW I would move to FP8 if you can.

> Not sure, but can't you just backup and restore the tools database to
the
> new server?

Unfortunately, I can't do that the target server is not a new server
and it already has databases and tasks defined on it. So restoring the
tools database to the target server would wipe out the tasks on that
system.

> BTW I would move to FP8 if you can.
Can you expand on this? I was looking at the APAR list for that fixpak
the other day and it only listed fixes for fixpaks 7a, 7, 6, etc. but
not fixpak 8. Is there anything specifically it fixes?

Thanks,
klh

"klh" <khar0429@yahoo.com> wrote in message >
> > BTW I would move to FP8 if you can.
> Can you expand on this? I was looking at the APAR list for that fixpak
> the other day and it only listed fixes for fixpaks 7a, 7, 6, etc. but
> not fixpak 8. Is there anything specifically it fixes?
>
> Thanks,
> klh
>
There are many fixes for FP8. I don't know if they messed up the APAR list
for the OS/FP you were looking at, but it is there for most of the OS's.
http://www-306.ibm.com/software/data...ownloadv8.html

If Backup/restore is not an option, could you try using db2move???
That tool allows you to select tables by schema and/or owner. Extract
using export and import those tables using db2move import insert.
You still ay run into primary key violations from the contents to the
target but I don't know as I haven't looked at the table to see if it
has a PK constraint and what it is.
HTH, Pierre.

klh wrote:
> We are running on Win 2003/DB2 V8 FP7a.
>
> My question concerns Task Center. I have about 200 tasks created and
> scheduled in Task Center. We are going to be moving many of the
> databases from this server to another V8 server and I really, really,
> really don't want to have to re-key all of these tasks on the new
> system.
>
> The Task Center "export" function seems to only export general task
> information like the description and type of task, but not the task
> itself. I'm not really sure what this is good for since it does not
> appear to be compatible with the Task Center "import" function.
>
> I thought about backing up the tools database and restoring on the
> target system, but then I'd wipe out the tasks already defined on the
> target system.
>
> If I knew the appropriate tables in the tools database I could export
> the data and import it into the target system, but they use so many
> auto-generated keys (apparently) that it would be a big risk on
> duplicating key values.
>
> Does anybody know of a way to do this?
>
> Is there a "batch" method of defining a task to Task Center?
> Thanks in advance,
> klh
>

--
Pierre Saint-Jacques - Reply to: sescons at attglobal dot net
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.

If Backup/restore is not an option, could you try using db2move???
That tool allows you to select tables by schema and/or owner. Extract
using export and import those tables using db2move import insert.
You still ay run into primary key violations from the contents to the
target but I don't know as I haven't looked at the table to see if it
has a PK constraint and what it is.
HTH, Pierre.

klh wrote:
> We are running on Win 2003/DB2 V8 FP7a.
>
> My question concerns Task Center. I have about 200 tasks created and
> scheduled in Task Center. We are going to be moving many of the
> databases from this server to another V8 server and I really, really,
> really don't want to have to re-key all of these tasks on the new
> system.
>
> The Task Center "export" function seems to only export general task
> information like the description and type of task, but not the task
> itself. I'm not really sure what this is good for since it does not
> appear to be compatible with the Task Center "import" function.
>
> I thought about backing up the tools database and restoring on the
> target system, but then I'd wipe out the tasks already defined on the
> target system.
>
> If I knew the appropriate tables in the tools database I could export
> the data and import it into the target system, but they use so many
> auto-generated keys (apparently) that it would be a big risk on
> duplicating key values.
>
> Does anybody know of a way to do this?
>
> Is there a "batch" method of defining a task to Task Center?
> Thanks in advance,
> klh
>

--
Pierre Saint-Jacques - Reply to: sescons at attglobal dot net
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.

Pierre Saint-Jacques wrote:
> If Backup/restore is not an option, could you try using db2move???

I had considered this, but as you mention there are too many collisions
on primary key values. I might do a little more digging to see if
there are only a few tables I could export, change the primary keys
(and related foreign keys), then import. In the end though it sounds
like it is going to take about as much time as it would to just type it
all in again.

It'd be nice if IBM would supply a nice way to do batch exports and
imports of the ENTIRE definition of a scheduled task. Maybe a future
release or fixpak?? ;-)

Thanks for the suggestions though.
klh

Out of curiosity, what kind of functionality are you using task center
for?

This isn't the answer you were looking for, but...it might be less
time-consuming to just rewrite the tasks as simple scheduled software
using bash, ksh, python, perl, ruby, or whatever.

We've got a variety of scripts for this purpose. A simple script runs
hourly and warns of any filesystem or tablespace over a configuration
threshold on each of a dozen servers. Others warn of tables requiring
runstats, warehouse or marts not loading, servers offline, another
dumps all ddl & configuration info, others export or load data, etc,
etc.


buck

Buck Nuggets wrote:
> Out of curiosity, what kind of functionality are you using task
center
> for?

Mainly we just need a method of scheduling routine maintenance,
backups, runstats, etc.

> This isn't the answer you were looking for, but...it might be less
> time-consuming to just rewrite the tasks as simple scheduled software
> using bash, ksh, python, perl, ruby, or whatever.

We have Windows 2003 servers, so I think the only default scheduler is
the "AT" scheduler or "Scheduled Tasks" in Control Panel. We could use
these for some functions, but the Task Center has a lot nicer features.
For one thing we can trigger follow up jobs and can run multiple
schedules for the same job. We could probably simulate the same thing
in those schedulers, but it might be just as much effort going that
route. It's kind of brutal setting things up in Task Center, but once
you get things set up it's pretty solid. If they only had the bulk
import and export functions it would be a fantastic product (in my
opinion).

> For one thing we can trigger follow up jobs and can run multiple
schedules for the same job. We could probably simulate the same thing
> in those schedulers, but it might be just as much effort going that
route.

Right - for simple schedulers like cron or whatever windows uses, you
end up putting more logic into the actual script to work around
dependencies than if you were using something like a mainframe
scheduler, or it sounds like task center. I think you can run cron on
windows via cygwin, but it won't support triggers or dependencies.

> If they only had the bulk import and export functions it would be a
fantastic product (in my opinion).

Yeah, I once inherited a data warehouse with 800 source systems (!)
running sql server using DTS (the sql server etl tool). And then
discovered how difficult it was to promote etl packages from dev to
test to prod - since they were all stored in the database. The prior
operation had an entire team retyping them by hand and retesting them
in production. We yanked all that stuff out and replaced it with a
simple custom etl application and our maintenance dropped from
horrifying to almost nothing overnight. I just recently saw a lengthy
sql server magazine article on tips for moving packages from one server
to another - so it appears that they still haven't really figured it
out.

I wonder what's going to be in db2 8.3?


Good luck,

buck