I upgraded our old 8.3 (7.1.2.11) version to 8.4.0.3. Now I am testing this new version. I am able to load reportdata as usual. So far so good.
But when I want to view the data I allways get the window with ?No documents meet the search criteria?. Also for the ?system log?data !
This happens with the PC Client, which in fact is still the old 7.1.2.9 version but also with the new 8.4.0.3 ODWEK.
The new version of the PC Client is not available for me yet. Our Windows department will install soon I hope.
I browsed into the DB2-tables and see the indexes for the reportdata and the systemlogdata is actually stored.
Anyone an idea what the cause can be?
Eef
That's strange. I know you're on a mainframe, but are their any 'console messages' from arssockd? In the multiplatforms world, arssockd writes diagnostic messages to the console (/dev/console) which can be read with dmesg (on Linux), or switched to be the local console by using the swcons command (on AIX).
I'd also check DB2 for diagnostic info.
So far I have not seen any message in the system or joblog.
Can this have something to do with the ODF feature.
With V7 we do not have the ODF feature at all. Even not the installation material.
Now with V8 the ODF is included in the installation material and in the new targets.
When I load a report from JES2 with ARSLOAD (ARSYSPIN) some extra messages are in the SYSPRINT
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
APK440I ACIF AT PM09217 HAS COMPLETED NORMALLY WITH RETURN CODE 0.
arsload: 03/15/12 14:19:06 Indexing completed
arsload: 03/15/12 14:19:06 -- Loading started, 25870 bytes to process
OnDemand Load Id = >5239-1-0-42FAA-0-0<
*arsuload - 04/01/2008(V8 PK62394)*
fopen for dbowner.dat failed
ODF not configured. ARSULOAD will not initiate report distribution
Loaded 10 rows into the database
Document compression type used - OD77. Bytes Stored = >1118< Rows = >10<
*arsuload - 04/01/2008(V8 PK62394)*
shutting down
arsload: 03/15/12 14:19:06 Loading completed
arsload: Processing successful for file >/var/ars/tmp/SYS0001167109044 (D
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have never seen the messages with 'arsuload' and ODF before.
First question is: how can I disable the ODF feature?
Second question: can there be a reason CMOD is not finishing the loadproces because of ODF? And is that the reason why no records satisfy the search criteria?
Eef
Be very careful when trying to disable the ODF feature. The manual states that you can rename the arsuload exit on your HFS to prevent those messages from appearing. We did this in test and it worked fine. When we tried it in production it brought down all our instances, which was compounded by the fact that it resided on a read only directory. Just be sure to test. It can be found in /usr/lpp/ars/bin/exits and IBM recommends renaming it to ARSULOAD.bak. This info can be found in the Common Configuration Problems Manual. That said, we ran with that message for years and it doesn't cause any issues so I seriously doubt that's your issue.
As for your original question, hard to say what the problem is without more information. Sounds like some configs got crossed in the upgrade.
Do you have document level checking?
To isolate the problem,
IF you have SRVR_FLAGS_DOCUMENT_EXIT=1
THEN set SRVR_FLAGS_DOCUMENT_EXIT=0, recycle the STC then retest.
Ed,
I changed SRVR_FLAGS_DOCUMENT_EXIT=0. This works! Thanks.
I think I have to look at the User security exits we use. There must be a difference between v7 and v8.
Eef
I upgraded from 2.1 to 8.4.0.3 .
My recollection is an old PC client does not know the new v 8.4 database structures, and a newer PC client is mandatory.
I found the reason why not finding any documents.
It has to do with the ARSUSECX and ARSUSEXZ security exits. We use 2 exit-points:
ARS.SECURITY with RACF class ARS1FLDR and ARS1APGP for CMOD Instance1
ARS.SECURITY2 with RACF class ARS2FLDR and ARS2APGP for CMOD Instance2
I just used the wrong library with the ARSUSECx modules. My test enviroment relates to ARS.SECURITY2 but I used the library with the ARS.SECURITY modules. That doesn?t match! Racf does not contain the right profiles for my test environment.
So Ed?s reply with the SRVR_FLAGS_DOCUMENT_EXIT=0 was a good suggestion, but it bypasses the security exits. Nothing more than that.
Now its works like it used to do!
> So Ed?s reply with the SRVR_FLAGS_DOCUMENT_EXIT=0 was a good suggestion, but it bypasses the security exits.
Very true, Eef! But at least it allows us to isolate the problem instead of having no idea what is wrong.
Glad you figured it out, and as always, my best to all of my CMOD friends on the other side of the Atlantic!
Ed