Messages

301

iSeries / Re: script to update storage set

« on: January 16, 2019, 09:13:33 AM »

Are you exporting these app groups to a new server?

If so - try exporting with the checkbox "no storage set" checked

use ARSXML to update the app group settings.

302

MP Server / Re: Large Migration + Codepage

« on: January 15, 2019, 11:01:32 AM »

Bumping this back to life with some new things.

Currently, in production we are running TSM 5.5 with a few centera nodes setup. We want to go to Spectrum Protect 8.1 on RHEL. I am wondering if this will work..keep in mind i've never done it this way--


export NODENAME filedata=all toserver=NEWSERVER
for each NODE we have defined

Any thoughts or advice on this approach?

303

MP Server / Re: Message 111 - OnDemand is unable to determine the link for the file

« on: January 10, 2019, 01:35:18 PM »

Thanks. I will look into this. I just need to figure out what happened and how to duplicate the error in my test system.

After running -R against a file I unlinked, I am getting this-

   114   Unable to open file >/arscache/cache1/0/WDA/RES/3<.  The error number is 2  Srvr->TEST non-SSL<-

304

MP Server / Re: Message 111 - OnDemand is unable to determine the link for the file

« on: January 10, 2019, 11:59:04 AM »

Excluding the 111/164 messages from our last ARSMAINT are below. We are running - "arsmaint -cvsr" nightly.

The 199 messages we were told are due to a bug in 8.5.0.6...The effected AG is "TFA"

   124   Filesystem Stats Name(/arscache/cache2) Data(65%) Inodes(0%)  Srvr->prod non-SSL<-
    32   Logoff
   124   Filesystem Stats Name(/arscache/cache1) Data(65%) Inodes(2%)  Srvr->prod non-SSL<-
   107   An unknown file or directory in found in the OnDemand cache >/arscache/cache2/0/GDA<  Srvr->prod non-SSL<-
   199   Unexpected empty directory in cache >/arscache/cache1/retr/HEA/DOC<  Srvr->prod non-SSL<-
   199   Unexpected empty directory in cache >/arscache/cache1/retr/AEA/DOC<  Srvr->prod non-SSL<-
   107   An unknown file or directory in found in the OnDemand cache >/arscache/cache1/0/LEA<  Srvr->prod
   109   Cache Expiration: Internal Date(17906) MinPct(80) MaxPct(80) Server(prod)
   107   An unknown file or directory in found in the OnDemand cache >/arscache/cache1/0/CEA<  Srvr->prod non-SSL<-
   107   An unknown file or directory in found in the OnDemand cache >/arscache/cache1/0/EDA<  Srvr->prod non-SSL<-
   110   Cache Migration: Internal Date(17906) Server(prod)
    30   Login: loopback 127.0.0.1 non-SSL (AIX) (ARSMAINT) (8.5.0.6)

305

MP Server / Re: Message 111 - OnDemand is unable to determine the link for the file

« on: January 10, 2019, 08:56:30 AM »

It looks like all the links are still in tact in production,but every night we get the same 71 messages.

They are all related to the same application group, and it all seems like the resources are in numerical order, 6800-6871, as example (Across arscache1/arscache2)

I broke the link in our test environment and ran the same ARSMAINT and I'm not getting a 111 message.

weird

306

MP Server / Message 111 - OnDemand is unable to determine the link for the file

« on: January 08, 2019, 12:52:18 PM »

Hello all,

We recently had to move our arscache file system (jfs) to the jfs2 file system. Our unix team created the new volumes and then migrated everything over.

After the migration, I am seeing 71 errors in our system log, similar to this:

OnDemand is unable to determine the link for the file >/arscache/cache2/0/TFA/RES/6849<.  The error number is 2  Srvr->prod 10.10.10.10 non-SSL<-
 (Also same errors pointing to additional /arscache/cache1/0/TFA/RES/68** files)

We started off by looking at the links and everything looks good. So far, we haven't had any reports from users about their statements appearing incorrect. I tried duplicating the issue in our test environment and I also didn't see any issue with the output.

Has anyone ever seen this error? If so, what was your resolution?

8.5.0.6 on AIX btw.. Thanks in advance.

307

MP Server / Re: Version 9.5 with Spectrum Protect

« on: December 10, 2018, 07:24:33 AM »

Thank you all.

This is not a long-term thing, for now..

308

MP Server / Version 9.5 with Spectrum Protect

« on: December 07, 2018, 07:47:07 AM »

Does anyone have experience (or even know if it will work), running the following-

CMOD 9.5 + Spectrum Protect (Storage pools setup for IBM Cloud object storage?)

From what i am reading, if we wanted to load directly from CMOD to Cloud object storage, we would need 10.1..

I am unsure if 9.5 supports 8.1 spectrum protect or vice versa. does anyone have input on this?

309

MP Server / Re: TSM expiration vs CMOD expiration

« on: December 04, 2018, 12:50:46 PM »

Thank you, sure is going to be a task to figure this out.

Not sure why the life of data and indexes was set to 180, in a storage set named FOREVER.

Regarding certain app groups, I hope that the life of data and indexes is set to 365 days for the 1YEAR storage set

310

MP Server / Re: TSM expiration vs CMOD expiration

« on: December 04, 2018, 11:31:10 AM »

It obeys both.  TSM deletes the data never, CMOD deletes the metadata after 180 days. 

Even if we aren't using -c and -d flags with arsmaint?

311

MP Server / TSM expiration vs CMOD expiration

« on: December 03, 2018, 12:25:54 PM »

Have a question, I think I know the answer

We have a TSM storage set labeled FOREVER that never expires on the TSM side.

For some reason, the expiration for all CMOD app groups that use that storage set is set to 180 days, which is incorrect. Per business requirement, these documents need to be held for 8 years, or 2920 days.

We currently stopped all deletions/purges done via arsmaint, we were running arsmaint -cdeirm (we removed -c and -d) until we figure out requirements on all of our application groups.

My question is this-

IF TSM is set to NEVER expire, but CMOD is set to 180 days, which one does it listen to?

My next question will depend on the answer to that   thanks in advance!

312

MP Server / Re: ARSLOAD daemon vs manual

« on: November 30, 2018, 06:51:05 AM »

I've seen both. We used manual calls of arsload when the file name wasn't compliant, or it was something weird like that.

With all the CMOD customers I've seen, we have used daemons, usually multiple. And there has been zero issues at all. I guess it depends on what you're loading and your volumes.

313

Documentation / Re: CMOD 10.1 ODWEK compatibility

« on: November 27, 2018, 07:16:10 AM »

migrate away from solutions like ICI and Xenos and replace them with Free/Open Source Software solutions instead.

-JD.

Hey Justin, can you PM me these Open Source Solutions. I am curious.

Thanks

314

Documentation / Re: CMOD 10.1 ODWEK compatibility

« on: November 26, 2018, 10:45:06 AM »

Hey Norbert.

This is why IBM always recommends that the ODWEK and CMOD Server components are *always* the same version.  I've seen some rather frightening combinations in production that I never thought would work, but managed to work just well enough for management to ignore the problem a little longer. 

-JD.

I second this. I mixed 8.5.0.5 ODWEK with 8.5.0.6 ARSSOCKD once and it was an absolute nightmare. Instability, random crashes, slowness, explainable issues.

I always tell my clients to keep ODWEK/CMOD SERVER the SAME EXACT VERSION down to the patch.

315

General / C2070-985 Withdrawn

« on: November 26, 2018, 07:26:10 AM »

Hello all,

I see that C2070-985 was withdrawn in March of this year.

Does anyone know if this test is going to be replaced with a test for 9.5 or 10.1