Messages

451

MP Server / Upgrade from 8.5 to 10.1

« on: September 26, 2017, 11:56:30 AM »

I am getting conflicting stories here.

I've done a successful upgrade from 8.5 to 9.5, with a stop at 9.0 because we were using RDF and were going to use ODF in 9.5

What about 10.1?

I've heard that I can go directly from 8.5 to 10.1 since we aren't using any special features or crazy configurations. I've also had someone at IBM tell me that I need to go from-

8.5-9.0-9.50-10.1 

What has everyone that's on 10.1 upgraded from. And how was your upgrade path. I also tried finding this on IBM's website but I cant seem to..

452

MP Server / Re: Unable to delete application group

« on: September 26, 2017, 09:51:44 AM »

Temporary work around. I just needed the app groups deleted because the environment was messy.

Now its messy, just in a different spot. I took the storage set associated with the troublesome application group and copied it - StorageSet.09260217

Then I modified the original StorageSet and pointed it to Cache. Since I didn't have any data loaded that was useful, didn't matter. Once that was done I deleted the application groups successfully and reverted back the old storage set settings.

It was somewhat confusing - mainly because the retention was something like...

Cache for 5 days
move to TSM
Expire @ 30

You'd think that it wouldn't matter if there was no data! Thanks for the pointers.

453

MP Server / Re: Unable to delete application group

« on: September 26, 2017, 06:17:51 AM »

I think you posted in the wrong thread. 

I believe you are correct. It's been a busy few days in the TSM world, and I'm the TSM admin.

454

MP Server / Re: Unable to delete application group

« on: September 25, 2017, 11:57:59 AM »

So, I am seeing this now in another tier, this time when loading.

Resource testfile.ARD.res will be added as resource >16-10-0<.  Compression Type(OD77) Original Size(7623127) Compressed Size(4430013)
An error occurred.  Contact your system administrator and/or consult the System Log.  File=arsadmp.c, Line=1252
Unable to store the object >16<.  Object size 4430013
arsload: 09/22/17 14:28:15 Loading failed
arsload: Processing failed for file >testfile.ARD<

We've unfortunately had to engage IBM on this one. They shot me over to TSM support.

455

Report Indexing / Re: Viewing Index File

« on: September 25, 2017, 07:02:01 AM »

thanks ill try this.

456

MP Server / Re: Cache Storage on new drive

« on: September 23, 2017, 12:23:39 PM »

Sounds like it would require less headaches and less engineering to get your Windows SA's to change the drive mapping back to f:\

457

Report Indexing / Re: Viewing Index File

« on: September 23, 2017, 12:22:29 PM »

I know 

This is more for my own knowledge. As far as my TSM error goes, we opened a PMR with IBM, sent them the system log, and we got back the fourth hit on google search for the error message.

THANKS !!!!!!

458

Report Indexing / Viewing Index File

« on: September 22, 2017, 12:14:45 PM »

I have a afp file that is failing to load due to a TSM issue. It passes indexing and generates the .out / .ind / .res files fine..

appears that the .ind file is a binary file..any quick way to view it?

459

MP Server / Color conversion issue with afp2pdf

« on: September 18, 2017, 07:58:36 AM »

Couldn't think of a better spot to put this in, so MP it is.

Users have a PDF File Generated from Exstream. The text at the top is wording and it comes out a light shade of green.

When it goes through the AFP2PDF conversion process, it is more of a dark shade of green. In the past I would look at the a2pxopts.cfg file for this, but that isn't being used in this system All I see are the following within /opt/ondemand/config

879 Aug  3  2012 afp2html.ini
141 Aug  3  2012 afp2pdf.cfg
 2066 Aug  3  2012 arswww.ini
551 Aug  3  2012 afp2pdf.ini
721 Aug  3  2012 arsxenos.ini
1024 Aug  3  2012 .

IVe done something similar like this before with afp2pdf, where I had to change the various shadings of black and white for GOCA's. Not sure what this approach would be.   Thanks

460

MP Server / Re: Unable to delete application group

« on: September 18, 2017, 06:49:47 AM »

I just stumble upon the same issue, while deleting an ApplicationGroup.
From the admin client I receive the error: "The server failed while accessing application group data. Contact your system administrator."
(See also: http://www-01.ibm.com/support/docview.wss?uid=swg21272955)

Unfortunatelly the whole TSM node containing the documents of this ApplicationGroup was already deleted some time ago.

Is there a way to delete such orphaned ApplicationGroups without recreating the TSM node?
E.g. by manipulating ARSAG.SID ?

that is a very bad idea. There goes your warranty/support from IBM if you have an issue. I've done things like this in the past but only when there was NO other option.

461

MP Server / Re: Changing retention for historical loads

« on: September 15, 2017, 06:13:04 PM »

::bangs head off desk::

462

MP Server / Re: CMOD upgardes : v8.4.1 to v10.1 on Windows

« on: September 15, 2017, 11:20:53 AM »

I am hearing conflicting stories about upgrading to 10.1

Based on what I am CURRENTLY hearing...

You would have to go from 8.4.1, to 8.4.3, to 8.5, to 9.0, to 9.5, to 10.1...but who knows.

I did recently an 8.5 to 9.5 and the only reason we had to take a hop and do 9.0, was because we were using RDF

463

MP Server / Re: Changing retention for historical loads

« on: September 15, 2017, 11:19:22 AM »

I don't mean to keep beating a dead horse with this one. But heres where more confusion lays. You mentioned one storage set for each AG..

One implementation I have seen, was several thousand application groups. We had one storage set defined in CMOD. I am not sure what the retention on the TSM side was at the time. We had so many initiatives going on within CMOD, that I didn't have time to learn anything about ANYTHING ELSE!

I wonder how that worked..we were strictly TSM, and anything that was cache was being migrated through a painfully slow process. We ran arsmaint weekly..using the -cdeimr flags. And app group life of data/indexes was various, 2555, 3650, 365, forever..etc.

So I wonder if we were just deleting the index and keeping the orphan document in TSM.

464

MP Server / Re: Delete/keep document after loading

« on: September 14, 2017, 11:45:12 AM »

Thanks for the help.  I will give it a try

Just as a tip from a bunch of CMOD installs I've seen..

All the times that arsload is ran as a deamon, or even when it's called programmatically, ive always seen -nvf.

Whenever I am doing my own unit testing, messing around with CMOD, or just trying something, I just got in the habit of typing -nvf as a flag.

465

MP Server / Re: Delete/keep document after loading

« on: September 14, 2017, 09:34:51 AM »

Look into the -n flag of arsload:

 -n Do not remove files