Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Justin Derrick

Pages: 1 ... 127 128 129 130 131 [132] 133
1966
MP Server / Re: Migration off Centera
« on: May 22, 2009, 04:35:59 AM »
Hi Walt.

For arsadmin, you only need to use the Object ID -- '123FAAA'.

Good luck!

-JD.

1967
WEBI interface / Re: WEBi 1.0.3 Download
« on: May 07, 2009, 06:39:55 AM »
Hi Steve.

If you order a media kit, you'll definitely receive a copy of WEBi.

Otherwise, it should be available to you via Passport Advantage.

Good Luck!

-JD.

1968
Hey Michael, Geoff...

I can't say I've actually noticed this new behavior in the past, but you should be able to emulate the writing of specific messages to a file by enabling and possibly customizing arslog.

-JD.

1969
MP Server / Re: Snaplock with OnDemand & TSM?
« on: March 19, 2009, 05:09:25 AM »
Wow...  I thought this thread was dead for sure...

Without getting too deep, I highly recommend keeping TSM as a component of your CMOD system because it allows for redundancy, flexibility, and near infinite capacity.  Even for new customers who say that their system "won't grow to be that big", I stress the importance of having TSM to allow for future growth that might not be obvious -- things like acquisitions, mergers, new lines of business, or new uses for CMOD.  Most of the concerns about running TSM can be dealt with with a couple days of training.

In terms of SnapLock and CMOD, the system that was eventually implemented connected SnapLock to TSM, and used in very much the same way that it was when they simply had TSM and optical libraries.

I'm not familiar enough with the inner workings of the SnapLock product to be able to suggest how it might be used without TSM, but feel free to post again with more details about how you were planning on using it for us to review and talk about.

Good luck!

1970
Documentation / Re: Update/Upgrade notifications
« on: March 17, 2009, 07:13:03 AM »
Hi Sandeep...

I have a couple of links I open up once a month to check for software updates and patches:

In addition to Fred's link to the CMOD binaries, I frequently check for DB2 news:

http://www-01.ibm.com/software/data/db2/support/db2_9/

If you organize these bookmarks into a single folder in a browser like Firefox or Safari, you can choose "Open all Links in Tabs" (by placing the folder in the Bookmark Bar, then right-clicking on the Folder name) and have all of the links load up in the background, then quickly see what's new and exciting in the world of CMOD.

Take care...

-JD.

1971
Report Indexing / Re: Report Name problems
« on: March 11, 2009, 08:07:25 AM »
Hi Gordon...

You didn't say it explicitly -- but you're using multiple Application definitions in your Application Group, right?

If so, the easiest way would be mapping the 'Application ID' to the report name.

-JD.

1972
MP Server / Re: Migration off Centera
« on: March 11, 2009, 07:40:34 AM »
Hi Walt.

The object id you're talking about is built from the values in the database tables.  Changing the tables changes the object id (and by extension, the load ID).

In terms of 'utilities', I usually custom-build scripts (or sometimes I modify existing ones) for a particular purpose.  Those scripts use the IBM ars* programs as much as possible to keep your system in a state that IBM will support -- but I collect information from DB2, TSM, and the filesystem to get the job done safely, quickly, and entirely automatically.

In this situation, I'd use arsadmin retrieve and arsadmin store to pick the items up, and put them into newly configured and defined TSM nodes.  The database changes are made with SQL statements for speed, but can also be done with arsdoc for full logging.

There are a few opportunities to consider when making this move, because it's a major one:
 
  • Giving each AG it's own node gives you very fine-grained control over retention without the hassle of implementing Records Manager.
  • If you have a large system, this may present an opportunity to offload the TSM component to another system, like the purpose-built IBM DR550.
  • If your system is more than a few years old, and you have data that isn't compressed with OD77, you could save a substantial amount of storage space by re-compressing your data.
  • Since you're shuffling all this data around, it might be a good opportunity to improve performance by reviewing your retrieval patterns, and 'backfilling' your cache filesystem for Folders that hit TSM a lot.

Good luck!

1973
MP Server / Re: Migration off Centera
« on: March 04, 2009, 08:25:18 AM »
Hi Walt.

Is there a specific reason you want to keep the node id's the same?  I've been approached about something very similar (but still different), and I've recommended a process where they extract data from the centera, put it into the new node, then tweak the node name in the database to reflect it's new location.  It's transparent to the end user, has virtually no chance of data loss, and is instantly reversible should something go wrong.

-JD.


1974
z/OS Server / Re: My z/OS CMOD Bookmarks
« on: February 05, 2009, 02:47:04 PM »

1975
MP Server / Re: OD Query Restriciton
« on: February 05, 2009, 01:48:48 PM »
You're very welcome, Wayne...

I try to check the mailing list and board at least once a day.  You can bookmark the page entitled 'Show unread posts since last visit', which helps streamline your reading -- it only shows you the new posts or replies since the last time you logged in.

-JD.

1976
MP Server / Re: Very Odd OD load failures - need help!!
« on: February 05, 2009, 01:46:39 PM »
Erk. 

Okay, it's fairly obvious that my UNIX shell script isn't going to help you out there... 

I'd definitely call this one a bug -- can you show us some error messages that arsload is kicking out?

-JD.


1977
MP Server / Re: Very Odd OD load failures - need help!!
« on: February 05, 2009, 09:09:23 AM »
Hi there.

Which platform are you on?

Also, what is the 'polling time' you have set on arsload (the -t option)?  You don't have the -n option set, do you?

Can you write a little script to do the loads for you?  On a UNIX platform, you could use this little script in the interim:  

#!/usr/bin/ksh
for i in `ls *.ARD`
do
  arsload <parameters> $i
done

(This script assumes that arsload invoked with a file name *is* removing the file afterwards.  If it isn't, add a 'gzip $i' on a separate line after the arsload line, and before the 'done' line to compress files.  You can clean out the directory with a simple 'rm *.gz' when your disk starts getting full.

Hope this helps!

-JD.

1978
MP Server / Re: OD Query Restriciton
« on: January 27, 2009, 08:04:29 AM »
Sadly, the best answer is, "The one that meets your needs."

I use them at the Group level, because it's easy to add and remove users from Groups -- AND, that functionality can be delegated to someone who is responsible for the group, meaning fewer support calls or requests to tweak user permissions.

-JD.

1979
Other / Re: How to find out data loss in TSM ???
« on: January 12, 2009, 01:20:50 PM »
Hi there.

The first priority in dealing with a data-loss situation is to understand exactly how and why data was misplaced -- then resolve that issue.  Hopefully you're past that stage.  If you're not, help reduce the impact of the situation by preventing cache expiration by NOT running arsmaint with the -c and -m options.

Unfortunately, there's no direct analogy to 'Load ID' in TSM.  Inside the TSM database, Application Groups are represented by 'Application Group ID Names', which aren't available in the Load ID.  Additionally, while you're given the 'base' of the object name in the Load ID, you can't be sure how many objects CMOD split the load into, nor their names.

It is possible to get a list of contents from the TSM volumes by using the 'query content' command, but then you're up against the unenviable task of trying to reconcile that information against the contents of your DB2 database.

For folks in situations similar to yours, I recommend a CMOD Data Audit.  I have some utilities that completely automate the detection (and in some cases, repair) of inconsistent archives, both for historical data loss, and as a preventative measure to ensure that inconsistencies don't re-occur.


1980
MP Server / Re: Identify documents using large object support
« on: January 10, 2009, 09:38:57 AM »
You read my mind....

I have a high-speed extractor that would assist in getting you the data you need in as short a time as possible.  Let's talk about that offline.

-JD.

Pages: 1 ... 127 128 129 130 131 [132] 133