Messages

1

z/OS Server / Re: ARS0020E OAM ERROR: FUNCTION=QUERY RETURN CODE=0000000C REASON-CODE= 9404FCD4

« on: October 03, 2017, 02:31:54 AM »

Hi Ed

Now we have done the rebind as suggested by the Technote mentioned below and the problem vanished. 
So thanks again for your help. 

What puzzles me is that according to our historic change data, we upgraded from V2 to V7 around 01jul2007
but this error concerned documents loaded up to two years later (10jul2009).

Is there a straightforward answer to that?


Regards
Hans 

2

z/OS Server / Re: ARS0020E OAM ERROR: FUNCTION=QUERY RETURN CODE=0000000C REASON-CODE= 9404FCD4

« on: September 29, 2017, 01:33:15 AM »

Hi Ed

Thank you very much. 
It sure sounds like our problem.

We will try it out as soon as possible.


Regards
Hans

3

z/OS Server / ARS0020E OAM ERROR: FUNCTION=QUERY RETURN CODE=0000000C REASON-CODE= 9404FCD4

« on: September 27, 2017, 06:10:32 AM »

Hello
We are running an old OnDemand system (V8.5.0.5) for a client that is not willing to pay for an upgrade.
Guess they are planning to move to something else. z/OS version is V2.1.

We are experiencing an odd error on this system on all documents spread over four folders:

10:29:38  ARS0024E DMG1HJB Object >1IDMAB< in Application Group >UAA< not found     
10:29:38  in node >OD390V21< 
       
10:29:38  ARS0020E DMG1HJB SM Error: ARSZDOCG: 00000017(00000010) OAM ERROR:         
10:29:38  FUNCTION= QUERY    RETURN CODE= 0000000C REASON-CODE= 9404FCD4,           
10:29:38  Return Code=23, Reason=0, File=arssmsms.cpp, Line=999 

It seems to concern the age of the document. When I do a random check it appears that all
documents loaded before 11jul2009 can’t be retrieved.

We have recently applied the z/OS21: RSU1706 level on this system. And the document retrieve problems
have started after this apply.
Part of HOLD data in PTF UA91366 in this level states that DB2BIND is required. That has been performed.
If not we would not be able to retrieve any documents at all.


I’m not sure how to translate the error msg, but my best guess after consulting the “DFSMSdfp Diagnosis” manual is this:


12 (X'0C')   X'94'       x     y     z
OTIS DB2 error during collection table processing. yz represents the DB2 SQL error. Convert the yz to decimal, and look up the resulting
SQL code in DB2 Messages and Codes.    yz       DB2 SQL code

This adds up to be an SQL error -812:

-812 
THE SQL STATEMENT CANNOT BE PROCESSED BECAUSE A BLANK COLLECTION-ID
WAS FOUND IN THE CURRENT PACKAGESET SPECIAL REGISTER WHILE TRYING TO
FORM A QUALIFIED PACKAGE NAME FOR PROGRAM program-name.consistency-token USING PLAN plan-name

Explanation
The last entry or the only entry in the package list for the plan contained an asterisk (*) as the value of the collection ID.
The CURRENT PACKAGESET special register must be set to a nonblank collection ID to form a qualified package name.

System action
The statement cannot be processed.

Programmer response
Set the CURRENT PACKAGESET special register to the correct collection ID, or ask your system administrator to check the plan's package list for correctness.


Have understood the error msg correct?
And if yes any ideas of what the cure for this error could be?

Or is there something we have missed in the applied RSU level?


We have run a trace on the DB2 side but it wasn't particular informative. We don't see the SQL -812 error here.

The one we ran to figure out that we needed the DB2 bind mentioned above directly showed a SQL -805 error on module CBRHTBSV.



Regards
Hans Busk

4

z/OS Server / Re: CMOD for z/OS V8.5.0.5 and enhanced password support

« on: January 19, 2017, 03:58:06 AM »

Forgot to mention that the client uses the standard Windows client to access the documents.
So they type in their password at logon.


Hans

5

z/OS Server / CMOD for z/OS V8.5.0.5 and enhanced password support

« on: January 19, 2017, 03:50:51 AM »

Hi

We have a client running on the V8.5.0.5 level of CMOD for z/OS. The z/OS level is V2.1
I know this is out of support but until now the client haven’t been interested in getting it upgraded.
I suspect they are looking for some kind of replacement. They already have started archiving some of their documents
using other solutions, but time will show.

Nevertheless they are still using CMOD and now they are asking us to evaluate what changes will be needed on their full system
to implement some degree of enhanced password support.
As far as I have been told they want to be able to use passwords with a length of at least 10 chars, mixed case and special chars.

Will their current CMOD level support this or will we need to bring them to a higher fixpack: V8.5.0.x or even bring V9.x in play?
   
The password checking is performed by RACF and we don't want to change that part.


Kind Regards
Hans Busk

6

z/OS Server / ARS0188E ARSMSG Unable to create thread. The return code is 112

« on: April 19, 2016, 06:44:00 AM »

Hi

Running OnDemand for z/OS V8R5M0L6 on a z/OS v2.1 system

We got ARS0188E msg followed by an abend with a SYSTEM COMPLETION CODE=A03 three times shortly after each other:   

ARS0188E ARSMSG Unable to create thread. The return code is 112 
ARS0188E ARSMSG Unable to create thread. The return code is 6   
IEF450I ARSSP ARSSP ARSSP - ABEND=SA03 U0000 REASON=00000000
        TIME=13.08.32                                       

ARS0188E ARSMSG Unable to create thread. The return code is 6   
IEF450I ARSSP ARSSP ARSSP - ABEND=SA03 U0000 REASON=00000000     
        TIME=13.21.32                                           

ARS0188E ARSMSG Unable to create thread. The return code is 6   
IEF450I ARSSP ARSSP ARSSP - ABEND=SA03 U0000 REASON=00000000
        TIME=13.28.10                                       

This happened about two hours ago and since last restart of the OnDemand task there has been no errors.


The manual says:

ARS0188E
The thread cannot be created. The return code is rc=returnCode

Explanation
There might not be enough memory for each process.

User response
Ensure that the maximum amount of memory per process is unlimited. Then try the command again. If the problem persists, contact IBM® Software Support.


I can only find a tip for what to do when running OnD on a Unix system.

Any ideas of what I shall look for on z/OS?


Regards
Hans 

7

z/OS Server / Re: ARS5479E INVALID INDEXING PARM

« on: October 28, 2015, 09:55:33 AM »

Hi Alessandro,

Thanks.

Really nice to know that there is someone to turn to if it gets too rough :-)


Kind regards
Hans

8

z/OS Server / Re: ARS5479E INVALID INDEXING PARM

« on: October 22, 2015, 05:31:17 AM »

Hi all

Thanks for your answers. They helped me out. The documents are loading now. Huge difference between  a   ,   and a   .   

And why not push on to the next levels?
Well this upgrade was planned many months back. But due to different set backs in my company it was never executed.
Furthermore my close are more experienced colleague on OnDemand chose to retire during a restructuring period. So suddenly I had it all for my self. And I chose to carry out this already described plan instead of adding more steps to.
Hopefully I gain some knowledge so I feel confident to make an attempt for V9+ in a not so far future.

Regards and thanks again
Hans   

9

z/OS Server / ARS5479E INVALID INDEXING PARM

« on: October 16, 2015, 05:31:21 AM »

Hi

I'm doing an upgrade of z/OS OnDemand from V7.2.1.6 to V8.5.0.6 via V7.1.2.9 and V8.4.1.7.

I have now reached the final level and suddenly I get the above error when running a load job.
The same load job ran without errors on the two intermediate levels.

Full error message:

arsload: Using /tmp/arstmp for temporary files                                                                                     
arsload: Processing file >/tmp/arstmp/67114011 (DD:INPUT-NULLFILE)<                                                               
arsload: Load Version <8.5.0.6> Operating System <z/OS> <04.24.00>                                                                 
arsload: Server Version <8.5.0.6> Operating System <z/OS> <04.24.00> Database <DB2> <10.01.0005>                                   
arsload: 10/16/15 11:09:38 -- Loading started, --UNKNOWN-- bytes to process                                                       
The following message was returned from the OS/390 indexer (ARSZSTDR error_message = ARS5479E INVALID INDEXING PARM. NUMERIC VALUE
XPECTED AT COL 00008. FOUND >0.1< INSTEAD. PARM STARTS WITH FIELD1=0.1,30,(TRIGGER=1).                                             
The OS/390 indexer failed with the specified return code. (Arsl390 return code is 4).                                             
Loaded 0 rows into the database                                                                                                   
arsload: 10/16/15 11:09:39 Loading failed                                                                                         
arsload: Processing failed for file >/tmp/arstmp/67114011 (DD:INPUT-NULLFILE)<                                                     
arsload: Processing has stopped.  The remaining files will NOT be processed.                                                       


And here are the Indexer Parameters:

CPGID=277
FILEFORMAT=RECORD
TRIGGER1=*,1,X'F1',(TYPE=GROUP)
FIELD1=0.1,30,(TRIGGER=1,BASE=0)
INDEX1='index_key',FIELD1,(TYPE=GROUP,BREAK=YES)
ANYEXIT=NFOSXANY


Found this on ibm.com...

Additional syntax checking for the indexing parameters


Technote (FAQ)

Question

Does the OS/390 Indexer of Content Manager OnDemand for z/OS have additional syntax checking functionality for indexing parameters?


Answer

The indexing parameters are text strings. Several parameters contain values that must be converted to integers.
All string values from the indexing parameters that get converted to integers are now checked to ensure they can successfully be converted to integers.

The ARS5479E message is generated when an invalid string value is found which causes the load to fail.

An example of this message is:

ARS5479E INVALID INDEXING PARM. NUMERIC VALUE EXPECTED AT COL 00008. FOUND >=1< INSTEAD. PARM STARTS WITH TRIGGER=1=*,1,X'F1',(TYPE
 


My guess is that the period in "FIELD1=0.1" is the problem, but what contents should I end up with in the FIELD1 parameter when trying to solve the problem?

We have had an IBM consultant coding all the OnDemand definitions around the application using the above Indexer Information including the ANYEXIT in use.
So I can't assess the impact of fx changing the parameter to

FIELD1=0,1,30,(TRIGGER=1,BASE=0) or something else.


I am also curious to know this apparently has been working without problems on V7... and V8.4.


Any help will be highly appreciated.



Regards
Hans Busk