436
MP Server / Re: Issue with CMOD 10.1 and Content Collector for SAP 4.0
« on: September 04, 2018, 07:20:01 AM »
Thanks for posting the resolution!
Ed
Ed
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.
437
z/OS Server / Re: SSL on z/OS
« on: August 22, 2018, 12:55:56 AM »
Hmmm - i have the following:
SSL_KEYRING_FILE=ARSSOC95.SSLRING
which was created by:
RACDCERT ID(ARSSV950) ADDRING(ARSSOC95.SSLRING)
You have:
SSL_KEYRING_FILE=ssltring
a) make sure the case is correct as I think it's case sensitive
b) try adding the server instance owner to that parm with a slash as a delimiter, for example
SRVR_INSTANCE_OWNER=ARSSERVR
SSL_KEYRING_FILE=ARSSERVR/ssltring
________
Also, run the display commands I have here...
http://www.odusergroup.org/forums/index.php?topic=1987.msg9972#msg9972
...and make sure what you see makes sense.
Ed
SSL_KEYRING_FILE=ARSSOC95.SSLRING
which was created by:
RACDCERT ID(ARSSV950) ADDRING(ARSSOC95.SSLRING)
You have:
SSL_KEYRING_FILE=ssltring
a) make sure the case is correct as I think it's case sensitive
b) try adding the server instance owner to that parm with a slash as a delimiter, for example
SRVR_INSTANCE_OWNER=ARSSERVR
SSL_KEYRING_FILE=ARSSERVR/ssltring
________
Also, run the display commands I have here...
http://www.odusergroup.org/forums/index.php?topic=1987.msg9972#msg9972
...and make sure what you see makes sense.
Ed
438
z/OS Server / Re: z/OS 2.2 Upgrade Notes
« on: August 16, 2018, 11:26:11 AM »
LE APAR PI93384
In other words
OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.
NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions. Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.
Ed
Quote
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
* Users of POSIX(ON) Language Environment *
* applications which expect to roll back the *
* in-progress update to the recoverable *
* resources when SIGXCPU is received and *
* there are no signal handlers registered for *
* SIGXCPU by the applications. *
****************************************************************
* PROBLEM DESCRIPTION: *
* When Language Environment applications *
* are terminated with return code 3000 *
* due to unhandled SIGXCPU under *
* POSIX(ON), the in-progress updates to *
* recoverable resources would be *
* committed instead of being rolled back. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
See the problem description.
PROBLEM CONCLUSION:
The code has been changed to ensure that, when a Language
Environment application is terminated with return code 3000 due
to unhandled SIGXCPU under POSIX(ON), the ThliAbnormalTerm flag
for all the threads in the process which receives SIGXCPU are
set to ON to notify Unix System Service to propagate the flag
to TCB_PTHREADTERMABNORMAL. The TCB_PTHREADTERMABNORMAL flags
are set to ON to indicate that the TCBs are terminated
abnormally. Then DB2 or other resource managers can check the
TCB_PTHREADTERMABNORMAL flags to determine commit or roll back
the in-progress transactions.
TEMPORARY FIX:
*********
* HIPER *
*********
In other words
OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.
NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions. Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.
Ed
439
z/OS Server / LE PTF Changes Behavior of ABENDs
« on: August 16, 2018, 11:25:38 AM »
LE APAR PI93384
In other words
OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.
NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions. Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.
Ed
Quote
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
* Users of POSIX(ON) Language Environment *
* applications which expect to roll back the *
* in-progress update to the recoverable *
* resources when SIGXCPU is received and *
* there are no signal handlers registered for *
* SIGXCPU by the applications. *
****************************************************************
* PROBLEM DESCRIPTION: *
* When Language Environment applications *
* are terminated with return code 3000 *
* due to unhandled SIGXCPU under *
* POSIX(ON), the in-progress updates to *
* recoverable resources would be *
* committed instead of being rolled back. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
See the problem description.
PROBLEM CONCLUSION:
The code has been changed to ensure that, when a Language
Environment application is terminated with return code 3000 due
to unhandled SIGXCPU under POSIX(ON), the ThliAbnormalTerm flag
for all the threads in the process which receives SIGXCPU are
set to ON to notify Unix System Service to propagate the flag
to TCB_PTHREADTERMABNORMAL. The TCB_PTHREADTERMABNORMAL flags
are set to ON to indicate that the TCBs are terminated
abnormally. Then DB2 or other resource managers can check the
TCB_PTHREADTERMABNORMAL flags to determine commit or roll back
the in-progress transactions.
TEMPORARY FIX:
*********
* HIPER *
*********
In other words
OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.
NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions. Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.
Ed
440
MP Server / Re: Sending Stats
« on: August 09, 2018, 09:23:03 AM »Quote
I think the product you're linking to is the Filenet System Monitor -- which, while an awesome product, also had a shock-and-awe pricetag.
Double
on my end.Glad I don't have to deliver those kinds of numbers in my present gig.
Ed
441
z/OS Server / Re: Recommended DB2 on z/OS Service, V12
« on: August 09, 2018, 09:20:19 AM »
Just FYI - here's the level of Db2 V12 we're currently running:
DSNG007I -DSNC DB2 CATALOG LEVEL (V12R1M500 )
CODE LEVEL (V12R1M502 )
CURRENT FUNCTION LEVEL (V12R1M501 )
HIGHEST ACTIVATED FUNCTION LEVEL (V12R1M501 )
DSNR002I -DSNC RESTART COMPLETED
Ed
DSNG007I -DSNC DB2 CATALOG LEVEL (V12R1M500 )
CODE LEVEL (V12R1M502 )
CURRENT FUNCTION LEVEL (V12R1M501 )
HIGHEST ACTIVATED FUNCTION LEVEL (V12R1M501 )
DSNR002I -DSNC RESTART COMPLETED
Ed
442
Report Indexing / Re: PDF Page Piece info - help
« on: August 09, 2018, 09:09:39 AM »
Comp type Input Output Rows
OD77 104,964,644 98,569,326 250
OD77 19,441,637 18,070,032 100
None 602,067 602,675 10
Disable 602,067 602,676 10
Disable 19,441,645 19,445,485 100
LZW12 19,441,649 25,353,227 100
LZW16 19,441,634 24,814,181 100
Those are the types of numbers I'd expect to see if the input was already compressed.
Ed
443
MP Server / Re: Sending Stats
« on: August 09, 2018, 06:54:01 AM »
I have never used this or even touched it. All I know is that I heard about this in an announcement:
https://www-01.ibm.com/support/docview.wss?uid=swg27021523
IBM System Dashboard for Enterprise Content Management integration support
Use IBM System Dashboard for Enterprise Content Management to proactively identify and resolve potential performance problems before they occur.
Ed
https://www-01.ibm.com/support/docview.wss?uid=swg27021523
IBM System Dashboard for Enterprise Content Management integration support
Use IBM System Dashboard for Enterprise Content Management to proactively identify and resolve potential performance problems before they occur.
Ed
444
z/OS Server / Re: Recommended DB2 on z/OS Service, V12
« on: August 08, 2018, 11:23:05 AM »
Symptom:
After rolling out service to Db2 products, ARSSOCKD starts, hangs, and abends S0C4.
The successful startup message...
ARS0351I The ARSSOCKD instance ARCH1010 is ready
...is never produced.
___________________________________________________________
Looking at the dump:
PSW=47042001 80000000 00000000 11769074
(Running in PRIMARY, key 0, AMODE 64, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
Unable to identify the area at ASID(X'00A3') address 11769074.
ASCB166 at F96400, JOB(ARSTECH1), for the home ASID
ASXB166 at 9FD000 and TCB166V at 9C62E8 for the home ASID
HOME ASID: 00A6 PRIMARY ASID: 00A3 SECONDARY ASID: 00A6
General purpose register values
0-1 00000000_18616C48 00000000_129FE000
2-3 0000030E_00000000 00000000_12A1D000
4-5 00000000_1245E380 00000000_129FE000
6-7 00000000_11DF1CA0 0000030E_04AC1D08
8-9 00000200_40500240 0000030E_04AC1D08
10-11 00000000_00000008 0000030E_04AE5630
12-13 00000000_1A0D7EE8 00000000_7E655800
14-15 0000030E_04AC2488 00000000_11769FF4
LIST 11769074. ASID(X'00A3') POSITION(X'-04') LENGTH(X'08') INSTRUCTION
11769070 | 50F0 A000 | ST R15,X'0'(,R10)
11769074 | 5050 A004 | ST R5,X'4'(,R10)
R10 is the base. Looking back up we see (the psw is this 0x1074)
11768000 A7F40055 00000000 12A1D000 C3D8C3D4 | x4.......~}.CQCM |
11768010 C5E2C2F1 F1F1F040 4040F0F1 61F2F261 | ESB1110 01/22/ |
11768020 F1F8F1F5 4BF4F440 C8C3D8C3 F1F1F040 | 1815.44 HCQC110 |
11768030 D6E2A9F1 4BF94000 D7C9F9F0 F8F5F740 | OSz1.9 .PI90857 |
11768040 E2D440C3 D8C3F0F0 F4F65C40 F5F6F5F5 | SM CQC0046* 5655 |
11768050 60E5F4F2 40B440D9 D6C3D2C5 E340E2D6 | -V42 . ROCKET SO |
11768060 C6E3E6C1 D9C56B40 C9D5C34B 40F1F9F9 | FTWARE, INC. 199 |
11768070 F96B40F2 F0F1F840 C1939340 D9898788 | 9, 2018 All Righ |
11768080 A3A240D9 85A28599 A585844B 40000000 | ts Reserved. ... |
11768090 40404040 40404040 C0F403D1 0A8F0700 | {4.J.... |
Likely candidates for this problem are PI97869 or maybe PI97867.
But it's not a CMOD problem - contact Db2 support.
Ed
After rolling out service to Db2 products, ARSSOCKD starts, hangs, and abends S0C4.
The successful startup message...
ARS0351I The ARSSOCKD instance ARCH1010 is ready
...is never produced.
___________________________________________________________
Looking at the dump:
PSW=47042001 80000000 00000000 11769074
(Running in PRIMARY, key 0, AMODE 64, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
Unable to identify the area at ASID(X'00A3') address 11769074.
ASCB166 at F96400, JOB(ARSTECH1), for the home ASID
ASXB166 at 9FD000 and TCB166V at 9C62E8 for the home ASID
HOME ASID: 00A6 PRIMARY ASID: 00A3 SECONDARY ASID: 00A6
General purpose register values
0-1 00000000_18616C48 00000000_129FE000
2-3 0000030E_00000000 00000000_12A1D000
4-5 00000000_1245E380 00000000_129FE000
6-7 00000000_11DF1CA0 0000030E_04AC1D08
8-9 00000200_40500240 0000030E_04AC1D08
10-11 00000000_00000008 0000030E_04AE5630
12-13 00000000_1A0D7EE8 00000000_7E655800
14-15 0000030E_04AC2488 00000000_11769FF4
LIST 11769074. ASID(X'00A3') POSITION(X'-04') LENGTH(X'08') INSTRUCTION
11769070 | 50F0 A000 | ST R15,X'0'(,R10)
11769074 | 5050 A004 | ST R5,X'4'(,R10)
R10 is the base. Looking back up we see (the psw is this 0x1074)
11768000 A7F40055 00000000 12A1D000 C3D8C3D4 | x4.......~}.CQCM |
11768010 C5E2C2F1 F1F1F040 4040F0F1 61F2F261 | ESB1110 01/22/ |
11768020 F1F8F1F5 4BF4F440 C8C3D8C3 F1F1F040 | 1815.44 HCQC110 |
11768030 D6E2A9F1 4BF94000 D7C9F9F0 F8F5F740 | OSz1.9 .PI90857 |
11768040 E2D440C3 D8C3F0F0 F4F65C40 F5F6F5F5 | SM CQC0046* 5655 |
11768050 60E5F4F2 40B440D9 D6C3D2C5 E340E2D6 | -V42 . ROCKET SO |
11768060 C6E3E6C1 D9C56B40 C9D5C34B 40F1F9F9 | FTWARE, INC. 199 |
11768070 F96B40F2 F0F1F840 C1939340 D9898788 | 9, 2018 All Righ |
11768080 A3A240D9 85A28599 A585844B 40000000 | ts Reserved. ... |
11768090 40404040 40404040 C0F403D1 0A8F0700 | {4.J.... |
Likely candidates for this problem are PI97869 or maybe PI97867.
But it's not a CMOD problem - contact Db2 support.
Ed
445
z/OS Server / Re: Recommended DB2 on z/OS Service, V10 and V11
« on: August 08, 2018, 11:22:19 AM »
Symptom:
After rolling out service to Db2 products, ARSSOCKD starts, hangs, and abends S0C4.
The successful startup message...
ARS0351I The ARSSOCKD instance ARCH1010 is ready
...is never produced.
___________________________________________________________
Looking at the dump:
PSW=47042001 80000000 00000000 11769074
(Running in PRIMARY, key 0, AMODE 64, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
Unable to identify the area at ASID(X'00A3') address 11769074.
ASCB166 at F96400, JOB(ARSTECH1), for the home ASID
ASXB166 at 9FD000 and TCB166V at 9C62E8 for the home ASID
HOME ASID: 00A6 PRIMARY ASID: 00A3 SECONDARY ASID: 00A6
General purpose register values
0-1 00000000_18616C48 00000000_129FE000
2-3 0000030E_00000000 00000000_12A1D000
4-5 00000000_1245E380 00000000_129FE000
6-7 00000000_11DF1CA0 0000030E_04AC1D08
8-9 00000200_40500240 0000030E_04AC1D08
10-11 00000000_00000008 0000030E_04AE5630
12-13 00000000_1A0D7EE8 00000000_7E655800
14-15 0000030E_04AC2488 00000000_11769FF4
LIST 11769074. ASID(X'00A3') POSITION(X'-04') LENGTH(X'08') INSTRUCTION
11769070 | 50F0 A000 | ST R15,X'0'(,R10)
11769074 | 5050 A004 | ST R5,X'4'(,R10)
R10 is the base. Looking back up we see (the psw is this 0x1074)
11768000 A7F40055 00000000 12A1D000 C3D8C3D4 | x4.......~}.CQCM |
11768010 C5E2C2F1 F1F1F040 4040F0F1 61F2F261 | ESB1110 01/22/ |
11768020 F1F8F1F5 4BF4F440 C8C3D8C3 F1F1F040 | 1815.44 HCQC110 |
11768030 D6E2A9F1 4BF94000 D7C9F9F0 F8F5F740 | OSz1.9 .PI90857 |
11768040 E2D440C3 D8C3F0F0 F4F65C40 F5F6F5F5 | SM CQC0046* 5655 |
11768050 60E5F4F2 40B440D9 D6C3D2C5 E340E2D6 | -V42 . ROCKET SO |
11768060 C6E3E6C1 D9C56B40 C9D5C34B 40F1F9F9 | FTWARE, INC. 199 |
11768070 F96B40F2 F0F1F840 C1939340 D9898788 | 9, 2018 All Righ |
11768080 A3A240D9 85A28599 A585844B 40000000 | ts Reserved. ... |
11768090 40404040 40404040 C0F403D1 0A8F0700 | {4.J.... |
Likely candidates for this problem are PI97869 or maybe PI97867.
But it's not a CMOD problem - contact Db2 support.
Ed
After rolling out service to Db2 products, ARSSOCKD starts, hangs, and abends S0C4.
The successful startup message...
ARS0351I The ARSSOCKD instance ARCH1010 is ready
...is never produced.
___________________________________________________________
Looking at the dump:
PSW=47042001 80000000 00000000 11769074
(Running in PRIMARY, key 0, AMODE 64, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
Unable to identify the area at ASID(X'00A3') address 11769074.
ASCB166 at F96400, JOB(ARSTECH1), for the home ASID
ASXB166 at 9FD000 and TCB166V at 9C62E8 for the home ASID
HOME ASID: 00A6 PRIMARY ASID: 00A3 SECONDARY ASID: 00A6
General purpose register values
0-1 00000000_18616C48 00000000_129FE000
2-3 0000030E_00000000 00000000_12A1D000
4-5 00000000_1245E380 00000000_129FE000
6-7 00000000_11DF1CA0 0000030E_04AC1D08
8-9 00000200_40500240 0000030E_04AC1D08
10-11 00000000_00000008 0000030E_04AE5630
12-13 00000000_1A0D7EE8 00000000_7E655800
14-15 0000030E_04AC2488 00000000_11769FF4
LIST 11769074. ASID(X'00A3') POSITION(X'-04') LENGTH(X'08') INSTRUCTION
11769070 | 50F0 A000 | ST R15,X'0'(,R10)
11769074 | 5050 A004 | ST R5,X'4'(,R10)
R10 is the base. Looking back up we see (the psw is this 0x1074)
11768000 A7F40055 00000000 12A1D000 C3D8C3D4 | x4.......~}.CQCM |
11768010 C5E2C2F1 F1F1F040 4040F0F1 61F2F261 | ESB1110 01/22/ |
11768020 F1F8F1F5 4BF4F440 C8C3D8C3 F1F1F040 | 1815.44 HCQC110 |
11768030 D6E2A9F1 4BF94000 D7C9F9F0 F8F5F740 | OSz1.9 .PI90857 |
11768040 E2D440C3 D8C3F0F0 F4F65C40 F5F6F5F5 | SM CQC0046* 5655 |
11768050 60E5F4F2 40B440D9 D6C3D2C5 E340E2D6 | -V42 . ROCKET SO |
11768060 C6E3E6C1 D9C56B40 C9D5C34B 40F1F9F9 | FTWARE, INC. 199 |
11768070 F96B40F2 F0F1F840 C1939340 D9898788 | 9, 2018 All Righ |
11768080 A3A240D9 85A28599 A585844B 40000000 | ts Reserved. ... |
11768090 40404040 40404040 C0F403D1 0A8F0700 | {4.J.... |
Likely candidates for this problem are PI97869 or maybe PI97867.
But it's not a CMOD problem - contact Db2 support.
Ed
446
Tips and Tricks / Re: JCL That I Find Handy
« on: July 26, 2018, 10:46:44 AM »
Certificates - listing info in z/OS
//TMP1 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
RACDCERT SITE LIST
RACDCERT CERTAUTH LIST
/*
If you have WAS on the system you may have some certificate data already on your system
//TMP3 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
RACDCERT LISTRING (WASKeyring) ID(WSADMIN)
RACDCERT ID(WSADMIN) LIST
RACDCERT ID(WSADMIN) LISTMAP
/*
//TMP1 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
RACDCERT SITE LIST
RACDCERT CERTAUTH LIST
/*
If you have WAS on the system you may have some certificate data already on your system
//TMP3 EXEC PGM=IKJEFT01,
// DYNAMNBR=200
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSTSIN DD *
RACDCERT LISTRING (WASKeyring) ID(WSADMIN)
RACDCERT ID(WSADMIN) LIST
RACDCERT ID(WSADMIN) LISTMAP
/*
447
z/OS Server / Re: SSL on z/OS
« on: July 24, 2018, 02:51:22 PM »
Jeff -
z/OS Security Server RACF Security Administrator's Guide
When googling, I found this:
RACF and SSL Security With Digital Certificates
http://ibmsystemsmag.com/CMSTemplates/IBMSystemsMag/Print.aspx?path=/mainframe/tipstechniques/systemsmanagement/RACF-and-SSL-Security-With-Digital-Certificates
Is what you're trying to do the same problem as an FTP client connecting to an FTP server on the same LPAR?
Ah, but isn't what you're trying to do to connect to a local system?
Could it possibly be as easy as the RACF commands under here:
These are really RACF questions. There used to be a RACF user group out on the forums, I believe. Maybe ask on IBM-MAIN?
Be sure to watch the system console for RACF error messages like the one I received for "INSUFFICIENT ACCESS AUTHORITY".
Please let us know what you've tried.
Ed
z/OS Security Server RACF Security Administrator's Guide
Quote
Site certificate
A certificate that is associated with an off-platform server or other network
entity, such as a peer VPN server. This category of certificate can also be
used to share a single certificate and its private key among multiple RACF
user IDs. When used for sharing, a certificate might be referred to as a
placeholder certificate.
When googling, I found this:
RACF and SSL Security With Digital Certificates
http://ibmsystemsmag.com/CMSTemplates/IBMSystemsMag/Print.aspx?path=/mainframe/tipstechniques/systemsmanagement/RACF-and-SSL-Security-With-Digital-Certificates
Is what you're trying to do the same problem as an FTP client connecting to an FTP server on the same LPAR?
Quote
When using FTP under z/OS to connect to a remote system (whether it’s another z/OS system or not), and still using only server certificates, our client again needs to have knowledge of the remote servers’ certificate in order to validate it.
Ah, but isn't what you're trying to do to connect to a local system?
Quote
...you’ll have been given the CA certificate for the site to which you’re connecting.
Could it possibly be as easy as the RACF commands under here:
Quote
To accept a self-signed certificate from a server, use the following RACF definitions:
These are really RACF questions. There used to be a RACF user group out on the forums, I believe. Maybe ask on IBM-MAIN?
Be sure to watch the system console for RACF error messages like the one I received for "INSUFFICIENT ACCESS AUTHORITY".
Please let us know what you've tried.
Ed
448
z/OS Server / Re: SSL on z/OS
« on: July 24, 2018, 07:59:58 AM »Hi Ed (and all)
Do you know if this works with a SITE certificate? We'd like to share the cert for batch usage.
Thanks!
Jeff - is what you're doing basically the same thing that I did here:
http://www.odusergroup.org/forums/index.php?topic=2296
Ed
449
OD/WEK & JAVA API / Re: DocID Encryption
« on: July 23, 2018, 05:30:11 PM »
I'm not an ODWEK guy at all but I know a little bit about this.
As Alessandro says elsewhere on these forums:
http://www.odusergroup.org/forums/index.php?topic=2233.msg9028#msg9028
The userid is also part of the encryption.
This is described in the 9.5.0.3 readme
http://www-01.ibm.com/support/docview.wss?uid=swg27046127&aid=1
\
Beginning with 9.5.0.3 the document identifier generated by ODWEK
has changed such that it is now encrypted and base64 encoded.
Prior to 9.5.0.3 the document identifier had to be encrypted and/or
encoded by the application before being used on the Web.
Considerations:
1) ODWEK will no longer generate the 'old' document identifier.
Therefore any ODWEK application that leverages this 'new'
document identifier must be at ODWEK 9.5.0.3 or later.
2) ODWEK document identifiers are independent of the OnDemand
server.
3) By default, ODWEK will no longer support being given the
'old' document identifier in which to recreate an ODHit object
- for example the recreateHit() api.
It is possible however to allow ODWEK to support accepting the
'old' document identifier. This can be done by specifying
ARS_SUPPORT_OLD_ODWEK_DOCIDS=1 in the ars.cfg configuration
file for the OnDemand Server (in order to support this flag -
the OnDemand server must also be at a 9.5.0.3 or later.
4) By default ODWEK will use an encryption key in which to
uniquely identify the OnDemand instance in which it is going
against (by default the OnDemand library server hostname and
port). It is possible for a customer to override this key by
way of the setEncryptionKey() on the ODServer object.
5) It is possible customers could see a decrease or increase in
the size of the 'new' document identifier compared to the
'old' document identifier. Keep in mind that because it is
now encrypted and base64 encoded, comparing the sizes is not
a fair comparison.
Ed
As Alessandro says elsewhere on these forums:
http://www.odusergroup.org/forums/index.php?topic=2233.msg9028#msg9028
Quote
...the docid for security reasons they use the user ID for the user requesting the docid to "encrypt" the docid.
So if userA gets a docid, and gives it to userB, then userB cannot use the docid, since he is not userA
The userid is also part of the encryption.
This is described in the 9.5.0.3 readme
http://www-01.ibm.com/support/docview.wss?uid=swg27046127&aid=1
\
Beginning with 9.5.0.3 the document identifier generated by ODWEK
has changed such that it is now encrypted and base64 encoded.
Prior to 9.5.0.3 the document identifier had to be encrypted and/or
encoded by the application before being used on the Web.
Considerations:
1) ODWEK will no longer generate the 'old' document identifier.
Therefore any ODWEK application that leverages this 'new'
document identifier must be at ODWEK 9.5.0.3 or later.
2) ODWEK document identifiers are independent of the OnDemand
server.
3) By default, ODWEK will no longer support being given the
'old' document identifier in which to recreate an ODHit object
- for example the recreateHit() api.
It is possible however to allow ODWEK to support accepting the
'old' document identifier. This can be done by specifying
ARS_SUPPORT_OLD_ODWEK_DOCIDS=1 in the ars.cfg configuration
file for the OnDemand Server (in order to support this flag -
the OnDemand server must also be at a 9.5.0.3 or later.
4) By default ODWEK will use an encryption key in which to
uniquely identify the OnDemand instance in which it is going
against (by default the OnDemand library server hostname and
port). It is possible for a customer to override this key by
way of the setEncryptionKey() on the ODServer object.
5) It is possible customers could see a decrease or increase in
the size of the 'new' document identifier compared to the
'old' document identifier. Keep in mind that because it is
now encrypted and base64 encoded, comparing the sizes is not
a fair comparison.
Ed
450
OD/WEK & JAVA API / Re: Connection cannot be established using ODWEK
« on: July 23, 2018, 05:16:46 PM »
This is a long shot but I saw this a couple years ago with ODWEK and ARSSOCKD both at 9.0.0.6.
...the root cause of the WAS timeout
issues is related to shortages in the native JVM heap storage, running
31-bit Java.
The solution will be to first upgrade the afp2pdf program to the 64-bit
version and then to switch the WAS Java, which is currently still
running 31-bit due to dependencies on the afp2pdf program, from 31- to
64-bit.
Ed
...the root cause of the WAS timeout
issues is related to shortages in the native JVM heap storage, running
31-bit Java.
The solution will be to first upgrade the afp2pdf program to the 64-bit
version and then to switch the WAS Java, which is currently still
running 31-bit due to dependencies on the afp2pdf program, from 31- to
64-bit.
Ed