Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Urban Axelsson

Pages: [1]
1
I am also interested in Tomcat and ICN.
Have no experiences to share right now, will make an attempt to test a Tomcat deployment.

2
MP Server / Re: arsdoc hold_add Fails with 0x8010
« on: November 06, 2014, 05:58:31 AM »
No, large object support is not enabled on any application.
I have a PMR, the problem is that we have version 8.4.1.3 and IBM are not so eager to help.
Version 8.4.1.5 should have this fixed according to other sources. I'll upgrade to this, so we'll see.
I have a project ongoing to step up on version 9.x simultaneously. But it takes time to do this.
I just wanted to see if anyone had a quick fix for this.

3
MP Server / arsdoc hold_add Fails with 0x8010
« on: November 05, 2014, 12:43:16 AM »
Hi,
Has anyone encountered the same problem as I have done.
When running
arsdoc hold_add -G ICABANKDOC -f ERMGallring2 -h ARCHIVE -i "WHERE Datum>=1 AND Datum<=10287" -l ERMHold1
"Datum>=1 AND Datum<=10287" will retrieve 202 documents.

For every run, then always the first row is updated and the System Log msg shows
0x8010    Failed ...
0x8040    Not Processed ...

Msgnbr 258 from System Log
<delim=   >
<Action:Hold Add   Name:ERMHold1   Hid:6011>
<Application Group Name:ICABANKDOC   Agid:3997>
<Status Code   Status Text   Aid   Table Name   Applid   DATUM,yyyy:MM:dd   FILM
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10287,1998:03:01   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10285,1998:02:27   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10285,1998:02:27   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10285,1998:02:27   00
0x8004   Document Hold Already Exists   5532   MIB1   PK   10285,1998:02:27   00
0x8010   Failed                         5532   MIB1   PK   10285,1998:02:27   00
0x8040   Not Processed                  5532   MIB1   PK   10285,1998:02:27   00
0x8040   Not Processed                  5532   MIB1   PK   10285,1998:02:27   00
0x8040   Not Processed                  5532   MIB1   PK   10285,1998:02:27   00
0x8040   Not Processed                  5532   MIB1   PK   10285,1998:02:27   00
0x8040   Not Processed                  5532   MIB1   PK   10285,1998:02:27   00

4
MP Server / Re: Generic indexing CMOD 8.5
« on: July 01, 2011, 05:22:06 AM »
The latest respond from IBM

IBM Update 2011-06-30 08:55
We understand your pain, but the old format is not going to be supported any more.

This is not a defect and the documentation for V8.5 is being updated as well as a Flash is being published to inform customer that the old Generic Index is no longer supported.

So, although we did not warn customers that this support was removed, we have not claimed it was supported in V7.1 or later either. We allowed customers to continue to use the old Generic Index file format in order to give them time to transition to the new format.

Even the question to the IBM OD collegues in Europe if they know a customer with the same problem have had no result until now.
So far, you are the only customer who has complained.

5
MP Server / Re: Generic indexing CMOD 8.5
« on: June 23, 2011, 12:01:21 AM »
The latest respond from IBM

IBM Update 2011-06-23 08:55
I forwarded your response to the OD development and here their feedback:
"This support has been removed from the 8.5 source code. It would be difficult to restore it in 8.5, because there were so many changes for Unicode."
They will discuss it internal but there seems to be not a lot of hope. So it may be better to contact Services to convert the applications to use the new format.

6
MP Server / Re: Generic indexing CMOD 8.5
« on: June 21, 2011, 11:48:35 PM »
The latest respond from IBM

IBM Update 2011-06-22 07:47
received response from Development that the old generic index format   
is not supported in CMOD MP V8.5.                                       
Forwarded the information to the customer                               
                                                                       
ACTION PLAN:                                                           
============                                                           
wait for further feedback from L3 to documentation   

7
MP Server / Re: Generic indexing CMOD 8.5
« on: June 20, 2011, 11:57:55 PM »
Yes, there is no difference.

Urban

Did you try specifying the absolute file path in the indexer file?

8
MP Server / Re: Generic indexing CMOD 8.5
« on: June 20, 2011, 11:55:06 PM »
I have recived information from the IBM software support that confirms my analysis.

Respond from IBM:
I did some tests with the Generic Index in the old style and found the same result: it still is working in 841 but not in 8501. I will check it out if this is a bug or if this old format was depreciated.

9
MP Server / Generic indexing CMOD 8.5
« on: June 17, 2011, 04:15:43 AM »
Does anyone know if IBM removed the support for generic indexing with the old style of indexing.
Until now both formats worked.
This is what I found.
I have not found any official information to confirm this.

************************************************
The default format prio 7.x
************************************************
FIELD NAMES BEGIN:
rdate
studentID
FIELD NAMES END:
08/13/99
0012345678
statement8.out
0
0
09/13/99
0012345678
statement9.out
0
0

************************************************
Only format after version 8.5.x
************************************************
CODEPAGE:819
GROUP_FIELD_NAME:rdate
GROUP_FIELD_VALUE:08/13/99
GROUP_FIELD_NAME:studentID
GROUP_FIELD_VALUE:0012345678
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:/arstmp/statement8.out
GROUP_FIELD_NAME:rdate
GROUP_FIELD_VALUE:09/13/99
GROUP_FIELD_NAME:studentID
GROUP_FIELD_VALUE:0012345678
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:/arstmp/statement9.out

10
MP Server / Re: 8.3 to 8.4 migration
« on: August 09, 2010, 04:59:23 AM »
Is there a way to migrate data and index that is faster than using arsdoc. (Maybe some unofficial method.)

11
z/OS Server / Re: ARSXML PROBLEM
« on: September 28, 2009, 07:39:36 AM »
Is it somebody else who have a solution for this arsxml problem?
I have a similar type of problem.

Pages: [1]