Messages

1156

z/OS Server / Re: ABEND SA03 on CMOD

« on: November 09, 2010, 12:06:58 PM »

Bonjour Philippe!

You can get an SA03 abend from an ARSLOAD for various reasons ...
    a) ARSLOAD has previously connected to ARSSOCKD and then attempts to
       store a document after ARSSOCKD has ended/abended/stopped.
    b) ARSSOCKD was stopped while ARSLOAD was running as a STC
       processing spool files.
    c) ARSLOAD attempts to initialize without ARSSOCKD.  ARSLOAD
       requires ARSSOCKD be active.
    d) network communication between arssockd and arsload is not
       available when arsload needs it
    e) when DB2 becomes unavailable. OnDemand has no real toleration of
       a lost DB2 connection.
    f) if you run out of file handles. You can check for this with the
       following process ...
        /D OMVS,A=ALL
          to get the PID of ARSLOAD and then issue:
        /D OMVS,L,PID=<arsload pid value from above>
        The ARSLOAD STC should not have a MAXFILEPROC high water usage at
        or near the process limit.

       
Could any of the above occurred?

1157

Announcements & News / Re: ODUG Technical Conference - Thursday October 28th @ Information On Demand Vegas

« on: September 23, 2010, 09:02:06 AM »

More details:

http://www-01.ibm.com/software/data/2010-conference/

1158

z/OS Server / Re: Problem with ARSLOAD

« on: September 17, 2010, 11:54:05 AM »

Philippe is there an ARSnnnnnE error message in the ARSSOCKD started task?

Ed

1159

z/OS Server / Re: Problem with ARSLOAD

« on: September 17, 2010, 11:51:16 AM »

You have to be logged in to see the attachments.  I had the same problem at first, then I saw I wasn't logged in.

Ed

1160

z/OS Server / Re: What is the maximum size recommended to load in CMOD

« on: September 07, 2010, 11:27:43 AM »

Philippe - I agree completely with what Justin has said.

FYI - it's not the compression type in use that determines how much compression you'll get as much as it is the "compressability" of the document.    (A huge document of all zeroes compresses very well, a small document of random data - not so well).

Let us know if and how you have resolved your situation.

Ed

1161

z/OS Server / Re: PM07633 - Major Performance Improvement for V7 -> V8 migrations

« on: August 23, 2010, 12:58:20 PM »

This code change provides so much improvement it's been marked HIPER:
                                                                     
http://www-01.ibm.com/support/docview.wss?uid=isg1_ODMP710_H272711 

R711 PSY UK55884                                                     
R84A PSY UK55885                                                     
R841 PSY UK55886
                                                     
                                                                     
 

1162

z/OS Server / Re: What is the maximum size recommended to load in CMOD

« on: August 23, 2010, 12:55:37 PM »

Also, depending on how compressible the data is, you truly may be able to "fit 5 pounds in a 3 pound bag."

1163

z/OS Server / Re: My z/OS CMOD Bookmarks

« on: August 10, 2010, 12:42:37 PM »

CICS Client download:

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=db2cmto

The CICS Client is no longer available for download.

You need to open a problem ticket with Level 2 who will provide the latest client.

Note:  The CICS Client is not a part of the base CMOD product.  Rather it started out and still is a CMOD Services offering that has been made available upon request.

Ed

1164

z/OS Server / Re: OAM error testing DB2 8.1 New Function Mode

« on: August 04, 2010, 12:30:35 PM »

A quick search of the IBM site gives this technote which at the end which says that OTIS was probably not started.

http://www-01.ibm.com/support/docview.wss?uid=swg21002929

Would that be the problem?

Ed

1165

z/OS Server / Re: Upgrading to DB2 V9? Runstats Runstats Runstats

« on: July 20, 2010, 01:08:45 PM »

Well well well --- and I just found this today:

 
DB2 9 migration: SQL performance best practices
 

http://www-01.ibm.com/support/docview.wss?rs=64&context=SSEPEK&q1=Db2+9+migration&uid=swg27015988

Well worth the read!

1166

z/OS Server / Upgrading to DB2 V9? Runstats Runstats Runstats

« on: July 19, 2010, 06:29:56 AM »

I've seen a couple cases recently where CMOD has performed much worse after no change to CMOD, but an upgrade to DB2 V9.

This is a quote:

it appears that running                                               
runstats on our index data tables solved the problem. Even though there
were no deletes and no static binds, RUNSTATS was still necessary for 
these tables to account for change in cardinality. ....               
... Presumably this                                                   
was noticed when we migrated to version 9 because the optimization     
algorithms required greater accuracy of the catalog statistics.       
                                                                       

1167

z/OS Server / Re: PM07633 - Major Performance Improvement for V7 -> V8 migrations

« on: July 15, 2010, 10:42:31 AM »

Oops - the title is a bit misleading, don't know how to edit it.

This APAR affects H272741, H272841, H27284A .... in other words, if you're migrating from V2 -> V7 it'll improve table load throughput at that release as well.

PROBLEM DESCRIPTION(S):                                           
  PM07633 -                                                       
    ***************************************************************
    * USERS AFFECTED: All Content Manager OnDemand for z/OS users 
    *                 using arsdb -i                               
    ***************************************************************
    * PROBLEM DESCRIPTION: arsdb -i can experience long import     
    *                      times                                   
    ***************************************************************
    * RECOMMENDATION: None.                                       
    ***************************************************************
    arsdb -i was running with the ODBC autocommit enabled.  This   
    caused a commit to be performed after every insert of a row   
    into the table being imported.                                 

1168

z/OS Server / PM07633 - Major Performance Improvement for V7 -> V8 migrations

« on: July 15, 2010, 08:30:14 AM »

This APAR makes a huge difference.

ERROR DESCRIPTION:                                               
arsdb command import option (-i) performance degradation occurs 
due to frequency of commits. Even though the arsdb import code   
itself does not issue explicit commits, code elsewhere in arsdb 
turns on the ODBC auto-commit setting, a fact that the code to   
do the import was not cognizant of. (The auto-commits don't     
show up in an ODBC application trace.)                           

1169

z/OS Server / Re: Performance Gain For arsload

« on: July 07, 2010, 09:46:56 AM »

This is very short, step by step instructions on Tuning heap storage

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA2170/3.3.3.4?SHELF=CEE2BK71&DT=20060529020347

If anybody out there can find the time to try this out, I'm sure I and many others would love to hear your results.

Ed (trying to find a round tuit myself to try some of these things that I learn about)

1170

z/OS Server / Re: ENOUGH MEMORY

« on: July 07, 2010, 08:15:00 AM »

I think you'd better call support.

Only time I've ever seen something like this was on AIX, and was resolved by verifying /etc/security/limits file on the AIX box and then fixed by setting rss and rss_hard to -1 for both root and archive user.

That's the only advice I have.  :-(

Ed