Messages

286

MP Server / Re: Error running ARSXML export.

« on: February 04, 2019, 10:24:41 AM »

Okay cool. I will try that. I figured it would work because I am able to arsdoc get directly from my 9.5 Instance to the 8.5 Instance.

287

MP Server / Re: Error running ARSXML export.

« on: February 04, 2019, 06:48:25 AM »

I'll try that, thank you!

No Bueno (Running on 9.5 Linux to 8.5 AIX) - ARS2084E The client and server are incompatible.  Reinstallation of the product is required.

2.2.9.5.0.12) Release (9.5.0.12)
      PH03836 - CMOD Server crashes when deleting Applications with the Windows Administrator or Batch Admin

Maybe this is related? shrug.

288

MP Server / Error running ARSXML export.

« on: February 02, 2019, 10:17:03 AM »

I am trying to do an export of my application groups and dependent objects from my QA server and I am getting an error.

60 AG/350-ish Apps-

arsxml export -u admin -p ondemand -h archive -e c -r adpl -i exportAGs.xml -o exportedQAAgs.xml -v
Attempting login for userid 'admin' on server 'qaENV' ...
Searching applicationGroups for application .
Querying applicationGroup, AG00
Query of applicationGroup, AG000 was successful.
.................Runs for a few seconds
Query of applicationGroup, AG was successful.
Querying applicationGroup, AG1
Unable to allocate enough memory.  File=arsapplg.C, Line=2360

I tried running this from my dev server to my QA server. Also directly on my QA server with the same result. ARSSOCKD does not crash, and nothing in the system log.

It's version 8.5.0.6. Has anyone seen this? Should i throttle it, maybe do batches of 10 or so?

289

Other / Re: Upgrading TSM using Centera

« on: February 02, 2019, 09:45:11 AM »

Now, to transfer from one TSM to another, like RHEL as suggested, I don't remember that a copy of a node was not possible if it was plugged with Centera.
I will need to ask the people who were involved in that in some of my previous projects or current workplace.
Unfortunately I am in holidays now until next Wednesday, so I won't be able to give you an answer before next week. So if someone has some experience, I hope he will be able to share, otherwise I will try to give something next week.

Per IBM- That is not possible with Centera. We are also storing files in a file device class which is a compliance/DR concern for us. Based on everything that I have researched and some convos with our IBM AVP : We are going to take the approach of using fresh servers and extracting from AIX and reloading into Linux.

We have an entire Linux CMOD architecture setup and currently running that is not being used. It was setup in 2016 and the migration was never started. CMOD and TSM on independent servers. CMOD 9.5, DB2 10.5, TSM 7.1.1. I think I am going to apply the latest fixpacks for CMOD and DB2, and upgrade to Spectrum Protect 8.1 since we want to use ICOS. We don't have any data in this environment currently.

I have some questions about this, mostly around the extract/reload. I have never had to do an extract like this before of an entire system. I know there's several ways I can do it. Here's my initial thoughts-

ARSXML export of my objects
ARSDOC get
ARSLOAD running as a daemon

As far as the extract goes- I can see two ways of doing it but I am sure there are more. We have 55 application groups, 352 applications.

Some quick metrics show me that in the past 5 years we have loaded a total of 156,802 individual files. The total size for the files retrieved was 2.3TB, and we stored a total of 500GB after compression. 117 Million rows were inserted into the database. Total time for all loads from the 87 records is around 350 hours. Each application group has no more than 17 fields defined.

1) arsdoc get -u admin -p password -h archive -g APPGROUP -L LOADID <--Retrieve each load as one file, let ARSLOAD DAEMON reload.
 
2) arsdoc get -u admin -p password -h archive -g APPGROUP -acgNv -I "where doc_name='1FAAA' -o OUTPUT <--Retrieve each load as a .out/.ind/.res file, let ARSLOAD reload. The benefit I can see doing this is that I will have the index and it will use the generic indexer instead of calling ACIF/PDF indexer, which would save some system resources I would imagine.

3) Regarding the storing process - Anymore, with the implementation of things like ICOS, and even other high speed archives- Is there really any benefit to loading to cache and then migrating to TSM? I can see how this would have been a case in the past with older storage methods like jukeboxes and optical platters, but I would imagine that new archives even things like Centera, ECS, S3, etc..are significantly faster. I am thinking of having our new environment load directly to spectrum protect.

On an average day, we have around 10,000 retrievals via ODWEK.
Based on the 66 records and similar AFP files with similar resources-

Retrieval from Cache - .017 Seconds
Retrieval from TSM - (TSM5.5/AIX6.1/CMOD and TSM on the same box) - Using a FILE device class - 0.023 Seconds
Retrieval from TSM - (TSM5.5/AIX6.1/CMOD and TSM on the same box) - Using a CENTERA device class - 0.427 Seconds

On an average day, we have around 200 loads, about 98% of them are stored as AFP.
Comparing files that have exact application group settings, and exact indexing settings, with similar AFP structure-
Load directly to TSM - FILE device class - 3.8 Seconds
Load directly to TSM - Centera device class - 4.6 Seconds
Load directly to CACHE - 4.9 Seconds

Our system is small compared to what I've encountered in the past.

Big difference - Wondering what kind of performance increases/decreases we can expect with ICOS, I would imagine probable some better performance using the latest and greatest versions of our software since we are currently so behind.

I'd like some feedback on my two thoughts of retrieval to reload the files- and if anyone has a better more efficient way of doing it I am all ears. Also thoughts on loading directly to Spectrum Protect over cache. Thanks everyone!

290

MP Server / Re: ARSSOCKD Crash when calling TSM.

« on: February 02, 2019, 08:56:25 AM »

Update on my issue- It's more than TSM/ARSLOAD

I tried unloading a document that's loaded to cache-

jeff@server:/home1/jeff> arsadmin unload -u admin -p ondemand -h archive -g MULTI -L 6141-64-0-2FAA-17451-17451
LoadId matches existing LoadId in System Log
Connection cannot be established for the >archive< server
Unable to unload data from OnDemand - LoadId(6141-64-0-2FAA-17451-17451) Rows Deleted(0)

I'm def going to move on from this. We are moving from AIX to Linux and since this is a very low dev environment, and I already have a Linux box in place, I am probably going to extract data from my QA system and do my testing there. Thanks all for the guidance, I never like "starting over"..I usually like to play and figure things out, but since we are in a time crunch, yeah that's my best bet.

It's also good to see that others have that mindset too! Thanks again!

291

MP Server / Re: ARSSOCKD Crash when calling TSM.

« on: January 31, 2019, 06:18:49 PM »

Well putting aside the server is too old, if there was no connection with TSM in X years, then maybe the whole configuration with TSM is not correct anymore, not the correct port/server, etc...

Have you tried to check the dsm.sys and dsm.opt configuration? If they are still correct?

I compared every CMOD / TSM setting to a working environment, including all dsm.sys/opt and they are all the same. My other environment works fine.

292

Other / Re: Upgrading TSM using Centera

« on: January 31, 2019, 01:45:33 PM »

I confirmed with IBM that you can't copy device classes / nodes / all that fun stuff from AIX to Linux.

That's why we are upgrading in place, for now. Thanks for the feedback! I have heard issues about resource contention and things like that.

293

Report Indexing / Re: Do I need to provide Index parameters to load a simple report

« on: January 31, 2019, 12:24:39 PM »

I usually make a single field named bogus in the app group and put a trigger on it, I will setup a simple index that doesnt have any meaning/requirement..then i setup "rdate" as "t" in the app settings, then I simply don't map the bogus field at the folder level. That's how i have done it for years.

294

MP Server / Re: ARSSOCKD Crash when calling TSM.

« on: January 31, 2019, 10:44:57 AM »

Well, a return code 79 on AIX is 'Connection Refused'.  So...  firewall?

Of course, I'd recommend less time figuring this out, and more time doing a 'pick and place' upgrade, where you back up the database and restore it to a newer version, and export the node data from TSM, and sync the caches to a new machine...  Trying to debug decade-old software will just be an exercise in futility.

Alessandro wrote a somewhat complete guide on doing these a while back.

-JD.

That may work for this environment. I don't even need the database or even the TSM node data. After looking at the occupancy of the nodes, The objects  There has not been a load to our TSM staging system in like 6-7 years. I could basically start from scratch, do an ARSXML export from QA, Setup some device classes, and arsdoc get from our test system directly into this box. 

This staging system is an absolute disaster

295

MP Server / Re: ARSSOCKD Crash when calling TSM.

« on: January 30, 2019, 08:43:23 PM »

Found a core.

---------------------------------------------------------------------------
LABEL:          CORE_DUMP
IDENTIFIER:     A924A5FC

Date/Time:       Wed Jan 30 22:19:01 EST 2019
Sequence Number: 2772919
Machine Id:      00C298F24C00
Node Id:         server
Class:           S
Type:            PERM
WPAR:            Global
Resource Name:   SYSPROC         

Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED

Probable Causes
SOFTWARE PROGRAM

User Causes
USER GENERATED SIGNAL

   Recommended Actions
   CORRECT THEN RETRY

Failure Causes
SOFTWARE PROGRAM

   Recommended Actions
   RERUN THE APPLICATION PROGRAM
   IF PROBLEM PERSISTS THEN DO THE FOLLOWING
   CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
SIGNAL NUMBER
          11
USER'S PROCESS ID:
              27066496
FILE SYSTEM SERIAL NUMBER
           5
INODE NUMBER
           0        4098
CORE FILE NAME
/tmp/ars_crash/core
PROGRAM NAME
arssockd
STACK EXECUTION DISABLED
           0
COME FROM ADDRESS REGISTER
??
PROCESSOR ID
  hw_fru_id: 0
  hw_cpu_id: 0

ADDITIONAL INFORMATION
ADSM_Make 15C
ADSM_Make 150
remove__7 E78
ArcSMS_De 330
ArcSMS_St D1C
ArcCSSMP_ 5D4
ArcCSSM_O 100
ArcCSP_SM 1A4
ArcXPORT_ 1C88
ArcSERVP_ 348
ArcSERVP_ 380
ArcSERVP_ 114
_pthread_ F4
??

Symptom Data
REPORTABLE
1
INTERNAL ERROR
0
SYMPTOM CODE
PCSS/SPI2 FLDS/arssockd SIG/11 FLDS/ADSM_Make VALU/15c FLDS/ArcSMS_De

296

MP Server / ARSSOCKD Crash when calling TSM.

« on: January 30, 2019, 07:17:05 PM »

Have a strange issue here on one of my old development servers. I am starting to think it's some kind of communication error..

First, here is my out of date "update in progress" system. Everything is on the same box. I do have a TSM 7.1 server configured in the dsm.sys file..

AIX 6.1
DB2 9.7
CMOD 8.5.0.6
TSM Client - Command Line Administrative Interface - Version 6, Release 2, Level 0.0
TSM Server - Server Version 5, Release 5, Level 7.0

Heres what does work:

-Loading to cache
-Retrieves from CACHE
-Loading from this server, to another tier's CMOD server, into THAT CMOD servers Cache/TSM (Same versions..)
-Creating/Updating/Exporting objects in CMOD
-Creating new dev classes / pools / nodes in TSM

I guess you could say the basics. Here is what does not work

-Loading into TSM, either the 5.5 server that is local, or even a remote 7.1 server
-ARSMAINT cache migration (-m)
-All of the objects in TSM are orphaned apparently...I have not tried dsmc retrieve.

arsload: 01/30/19 20:16:09 -- Loading started, 201946 bytes to process
Resource FILE.ARD.res will be added as resource >4-63-0<.  Compression Type(OD77) Original Size(13937709) Compressed Size(8041010)
Connection cannot be established for the >dev< server
Unable to store the object >4<.  Object size 8041010
arsload: 01/30/19 20:16:10 Loading failed
arsload: Processing failed for file >FILE.ARD<
Connection cannot be established for the >dev< server

From the TSM activity log when I load a file or run arsmaint, and arssockd crashes-

01/30/19   20:16:10      ANR0480W Session 10 for node MULTIOD (ONDEMAND) terminated
                                   - connection with client severed. (SESSION: 10)

ARSSOCK DEBUG-   Wed Jan 30 21:15:13 2019: OnDemand(3082) -> connect 1445, 127.0.0.1 errno = 79 rc = -1

Those are the only two messages that I currently have. Anyone have suggestions? I am pretty sure I checked everything at this point!

Thanks in advance.

297

Other / Upgrading TSM using Centera

« on: January 30, 2019, 05:51:21 PM »

Hi All,

Looking down the barrel of starting an upgrade from TSM 5.5 to V7.1.1, On AIX. I have read much documentation and talked to a few folks including IBM about the process, and I am aware of some things that might come my way due to the underlying database changes and conversion process.

My question is this, has anyone done this on their system that uses a centera device class? One of our original plans was to use TSM on RHEL on a separate server and to migrate everything over, but per IBM we can't do that with Centera device classes. So it looks like we are going to be upgrading our AIX servers in place.

Once concern that I do have- Is using CMOD / DB2 and TSM 7.1 all on the same box. Does anyone have experience with this kind of upgrade where centera is involved?

298

MP Server / Re: Report Failed - AN ACIF STORAGE REQUEST WAS UNSUCCESSFUL - REQUEST SIZE 314 GETM

« on: January 30, 2019, 07:35:08 AM »

That to me sounds like its an indexing error, and it cannot find the trigger.

I understand where you are coming from, with the large file erroring out. Usually when I would load a very large file - lets say for example around 4GB..Using 2 triggers, maybe a floating trigger, indexing every line- that's when it would fail. Usually, in that case it would give no error and simply run out of resources or something like that.

299

MP Server / Re: Report Failed - AN ACIF STORAGE REQUEST WAS UNSUCCESSFUL - REQUEST SIZE 314 GETM

« on: January 25, 2019, 06:47:02 AM »

Are there any other messages in the system log associated with the log ID of the 88 record?

300

OD/WEK & JAVA API / Re: What is your AFP to PDF Transform of choice?

« on: January 22, 2019, 10:05:10 AM »

3 Scenarios I've seen. The last one appears to be the most common and plainless

1) Transforming from AFP to PDF, storing as PDF (We didn't care about storage sizes..)

Transforming Xerox to AFP via Infoprint XT, then AFP2PDF (We tried this with both the C version and Java version of AFP2PDF, similar results...Slow)
AFP2PDF to transform HP Exstreme AFP files to PDF (painless and quick)
PCL2PDF to transform PCL to PDF, then it used the CMOD PDF Indexer (painless and quick)

The indexing tool that we used to index the AFP files, was pretty slick and simple to use, and with the support we had from Ricoh they were able to build us custom filters, it supported regular expressions, etc. This was Ricohs AVE (AFP Visual Environment?)

The integration to our custom loaders and CMOD was a long drawn out process, but it worked. Indexing new reports became easier, but it took significantly longer to load very large xerox files.

2) Transforming from AFP/Xerox/PCL to PDF, storing as PDF.

We used Xenos 5.6 for this. This is an extremely outdated version from what I remember, but it worked and it was extremely fast as far as indexing. The d2e studio was very complex, and it was the most expensive option. I believe a lot has changed since then though.

3) Loading AFP files, converting on the fly with afp2pdf/ODWEK

Currently using the C++ version of afp2pdf on solaris to convert natively loaded AFP files mostly from exstream upon retrieval. Zero issues. We can also customize fonts and things via the out of the box configuration files provided by Ricoh.