Multiprint SAPNotes

Table of Content
0001919773 - SAP Java Connector Release 3.0.11

0001077727 - SAP JCo 3.0 release and support strategy
SAP Note
Version 1 Validity: 30.09.2013 -
active
Language English (Master)
Header Data
Released On 01.05.2014 05:23:44
Release Status Released for Customer
Component BC-MID-CON-JCO Java-Connector
Priority Correction with high priority
Category Program error
Symptom
1. The integrity of an LUW (Logical Unit of Work) is destroyed when using
JCoCustomDestination instances in a stateful JCo context with other scope types than the
default scope.
2. An RFC request to a just registered JCo RFC server does not reach the JCoServer and the
connection is hanging infinitely.
3. CPIC error messages "Connection to partner '<host>:<port>' broken / Connection reset
by peer" are recognized at the RFC communication partner side (e.g. in SAP gateway
trace file dev_rd.trc) when the JCo application program terminates.
4. A java.lang.NullPointerException is thrown when calling method JCoRepository.save().
5. The method JCoListMetaData.isOptional(<name|index>) always returns false after loading a
repository with calling method JCoRepository.load().
6. A java.lang.NullPointerException is thrown when trying to logon with certain languages to
a non-Unicode ABAP system.
7. No caller program name is sent from JCo to the RFC communication partner.
8. A JCoServer instance does not start if one of the configured AS ABAP repository systems
is down.
9. A single JCo installation cannot be used with a 32-bit and 64-bit JVM simultaneously
without modifying the operating system's library loading path environment variable.
Other Terms
SAP Java Connector, JCo, JCo3, JCoCustomDestination, scope type, LUW, stateful
connection, hanging server connection, connection reset by peer, NullPointerExceptiom, NPE,
JCoRepository, repository, save, load, optional parameter flag, isOptional, logon, caller
program name, RFC attributes, RFC communication error at JCoServer startup, AS ABAP
repository system down, central installation, multi-platform installation, library loading path
Reason and Prerequisites
The following program errors have been fixed and further improvements have been made:
1. Scope types were lost when using JCoCustomDestination instances. Remote function calls
via a JCoCustomDestination instance were always executed within the default scope type
context. In case that the current JCo context was stateful, this resulted in the same RFC
connection being used for all JCoCustomDestination instances and therefore possibly
destroyed the integrity of an LUW (Logical Unit of Work).
Note: This bug was present in JCo release 3.0.10 only.
2. If an RFC request was immediately sent to a just registered JCoServer RFC connection,
this newly registered RFC server connection could have get into an unrecoverable
hanging situation before the incoming RFC request could have been dispatched and
processed. At the communication partner side the RFC request did not return and the
active RFC connection kept hanging in status 'connected'.
3. When shutting down the JCo application program, pooled idle and still open RFC
connections were not closed properly before the application program terminates. This
resulted in these pooled RFC connections being interrupted instead with getting CPIC
error messages "Connection to partner '<host>:<port>' broken / Connection reset by
peer" at the RFC communication partner side.
4. A java.lang.NullPointerException was thrown when saving a JCoRepository instance which
contained a remote function module template with an empty import parameter list.
5. The meta data information that specifies if a parameter is an optional parameter or not
was lost after loading a JCoRepository instance from a Java I/O character stream. Calling
method JCoListMetaData.isOptional(<name|index>) on any parameter meta data that was
loaded by a JCoRepository always returned false in this case.
6. A java.lang.NullPointerException was always thrown when trying to logon to a non-
Unicode ABAP system with using one of the new logon languages that are available in
Unicode SAP systems only. Now an appropriate JCoException with error group
RFC_ERROR_LOGON_FAILURE will be thrown in such a scenario instead.
7. A caller program name is now sent to the communication partner when opening a new
RFC connection. It can be retrieved from the RFC attributes at the communication partner
side. The caller program name 'SAPJCo30' is used per default. An arbitrary custom
program name can be set by specifying the Java system property -Djco.program_name=
<ProgramName> as a JVM startup parameter.
8. Starting JCoServer instances has been improved with now doing lazy initializations of RFC
repository destinations and with ignoring and tolerating RFC communication errors at
startup.
9. The JCo runtime initialization has been enhanced with a multi-platform library loading
feature which allows to create a central JCo installation that can be started on various
operating systems and with using different Java Virtual Machines without any
configuration change. For example, JCo can now be installed on a single central network
share and be used from several operating systems like Windows, Linux or Mac OS X
simultaneously. Or one can work locally with a single JCo installation and use a 32-bit
and a 64-bit JVM simultaneously or choose one or the other JVM alternately at will.
For using this feature it is only required to put all desired platform dependent JCo JNI
libraries in specifically named subdirectories of the directory where the sapjco3.jar file
resides, e.g. <sapjco3.jar_DIR>\ntamd64\sapjco3.dll, <sapjco3.jar_DIR>\ntintel\sapjco3.dll
or <sapjco3.jar_DIR>/linuxppc64/libsapjco3.so.
See the JCo configuration documentation chapter "Runtime initialization" for further
details and the list of valid platform specific subdirectoy names.
Solution
Install and use the latest patch level of the SAP Java Connector 3.0.
Please download at least the SAP Java Connector 3.0.11 from the SAP Service Marketplace at
http://service.sap.com/connectors . You will find the download package with the latest patch
level for various platforms by navigating to "SAP Java Connector" -> "Tools & Services" ->
"Download SAP JCo Release 3.0". An installation guide is included in the download archive.
Validity
Software Component From Rel. To Rel. And Subsequent
SAP JCO 3.0 3.0

References
This document refers to:
SAP Notes
1748457 SAP Java Connector Release 3.0.10
1077727 SAP JCo 3.0 release and support strategy
This document is referenced by:
SAP Notes (2)
2026482 SAP Java IDoc Class Library Release 3.0.11
SAP Note
active
Header Data
Released On 12.08.2013 21:28:45
Symptom
1. An RFC request to a registered JCo RFC server does not reach the JCoServer and the
connection is hanging infinitely.
2. A memory leak in the Java heap is recognized.
3. Slow performance at RFC request dispatching to JCoServers is recognized.
4. JCo 3.0 does not support RFC communication with non-ABAP systems (the so-called
extern-to-extern RFC communication).
5. The capability to persist and use local RFC meta data repository storages is
missing.
6. A java.lang.StackOverflowError is thrown at calling some JCoRepository API.
7. A long running stateful RFC request to a registered JCoServer is unexpectedly
interrupted due to a connection cancel operation from the JCo server side.
8. Calling method JCoServerContextInfo.getCallType() always returns null.
9. A java.lang.NullPointerException is thrown when trying to communicate with a non-
Unicode ABAP system that uses an ambiguous blended code page.
10. Under special circumstances calling method
JCoRepository.getStructureDefinition(String name) or
JCoRepository.getRecordMetaData(String name) returns null.
11. JCo.getRepositoryDestinationID(String destinationID) unexpectedly returns null for
a given destinationID.
Other Terms
SAP Java Connector, JCo, JCo3, hanging server connection, memory leak, slow performance,
registered RFC server, extern to extern RFC communication, TPNAME, persistent JCoRepository,
save, load, JSON, StackOverflowError, MetaDataStorage, stateful RFC server request,
connection interruption, cancel, SessionReferenceProvider, JCoServerContextInfo,
JCoServerCallType, null, NullPointerException, NPE, 6110,
jco.use_repository_roundtrip_optimization, jco.destination.one_roundtrip_repository,
repository destination ID
1. A program error in the underlying native CPIC communication software layer has been
fixed that under certain circumstances RFC connections to a JCoServer could have get
into an unrecoverable hanging situation. Then RFC requests to a registered JCoServer
instance did not return and the appropriate RFC connection could not be canceled but
kept hanging infinitely in any state, even in state 'disconnecting'.
Please see SAP note 1791529 for further details.
2. A memory leak was removed within the internal JCo session management. The memory
leak occurred after a custom SessionReferenceProvider implementation had been
registered at the JCo runtime environment. Its method
SessionReferenceProvider.isSessionAlive(sessionId) was never called which resulted in
numerous JCo session objects not getting freed although the sessions already had
expired.
3. In case of RFC server registrations to some SAP gateway taking a long time for
whatever reason (e.g. because the relevant SAP AS ABAP system or SAP gateway is
currently in shutdown or startup phase, the host itself is not reachable via network or
due to network performance issues), the whole RFC request dispatching to all running
JCoServer instances was extremely slow and therefore lead to a performance degradation
also of those registered JCo RFC servers and related SAP AS ABAP systems which actually
were not connected to the problematic SAP gateway host.
4. Support for calling external RFC server programs as well as support for receiving
RFC requests from external RFC client programs has been added.
Please see SAP note 1877907 for further details.
5. A new feature has been added allowing to save and load a complete JCoRepository
instance in JSON format to and from standard Java I/O character streams.
Please see the API Documentation at class JCoRepository for further details.
6. Depending on the defined DDIC (Data Dictionary) types and structures and on the
defined RFM (Remote Function Module) interfaces at SAP AS ABAP system side a
java.lang.StackOverflowError could have been thrown when a JCoRepository instance was
storing the queried RFC meta data into its internal MetaDataStorage instance.
7. Long running stateful RFC server requests from ABAP to Java were always interrupted
after the configured session timeout interval (default is 10 minutes) without checking
at the registered SessionReferenceProvider if the session would be still alive
nevertheless.
8. Method JCoServerContextInfo.getCallType() always returned null instead of the
current type of the incoming RFC request in form of a JCoServerCallType enumeration
object.
9. A java.lang.NullPointerException was always thrown from the internal JCo method
getAttributes() when trying to communicate with a non-Unicode ABAP system that uses an
ambiguous blended code page like SAP code page 6110.
10. A JCoRepository instance in roundtrip optimization mode (e.g. the middleware
property 'jco.use_repository_roundtrip_optimization' was set to 1 at its creation time)
always returned null when querying structure or record meta data from an SAP AS ABAP
system with methods JCoRepository.getStructureDefinition(String name) and
JCoRepository.getRecordMetaData(String name).
11. Under some special circumstances the method JCo.getRepositoryDestinationID(String
destinationID) returned null indicating that the respective JCoDestination instance for
the given destinationID has not been used for repository queries yet although this is
not true.
Solution
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1902880 Business Connector 4.8 Service Release 9 (SR9)
1877907 Support of extern-to-extern RFC communication with JCo 3.0
1791529 GW: Hanging connections between J2EE and gateway
1425520 Disable NI cache for host and service names
SAP Notes (6)
1791529 GW: Hanging connections between J2EE and gateway
SAP Note
active
Header Data
Released On 24.07.2012 12:30:33
Symptom
2. A JCoException with the CPIC error message "client with wrong appc header version
rejected" is thrown.
3. An RfcGetException with message "Received a callback from the communication partner"
was logged in the RFC error log file dev_jco_rfc.trc and maybe also some table
parameters of a called Remote Function Module (RFM) are empty or do not contain the
expected data.
4. RFC logon attempts hang infinitely or take too long without being interrupted after
60 seconds or after the configured RFC connect timeout interval.
5. Fields of type XSTRING contain one 0-byte value after setting a null-reference value
into them.
6. JCo trace information in JCoServer scenarios is missing when using a
JCoServerRequestHandler instance (RFC request/response model).
7. The properties 'jco.session_timeout' and 'jco.session_timeout.check_interval' cannot
be set as Java system properties with the -D argument when starting the JVM.
8. A Remote Function Call (RFC) with using Secure Network Communication (SNC) for
encryption but without using the Single Sign On (SSO) mechanism for logon
authentifaction is not possible.
9. An RFC logon to an SAP ABAP backend system with external user identification data is
not supported.
10. An RFC logon to an SAP ABAP backend system fails with a JCoException and the error
message "Select one of the installed languages" being thrown when using a logon
language that is available in Unicode SAP systems only.
11. The JCoDestinationMonitor interface is lacking an API for querying the number of
threads that are currently waiting for a free connection.
Other Terms
SAP Java Connector, JCo, JCo3, memory leak, APPC header, RFC callback, destination "BACK",
table delta management, XSTRING, SNC, SSO, JCO_ERROR_COMMUNICATION, JCO_ERROR_SYSTEM_FAILURE,
JCO_ERROR_TIMEOUT, JCO_ERROR_LOGON_FAILURE
1. A memory leak was removed at the internal destination management within the
JCoTimeoutChecker thread. This memory leak was created each time that the registered
DestinationDataProvider instance updated or deleted a previously used destination from
its destination configuration repository.
2. A program error in the underlying native CPIC communication software layer has been
fixed that sometimes led to RFC connections getting broken. In this case a JCoException
with error group JCoException.JCO_ERROR_COMMUNICATION was thrown and contained the CPIC
error message "client with wrong appc header version rejected".
Please see SAP note 1664732 for further information.
3. RFC callbacks to the JCo framework were not handled correctly. Although receiving an
RFC callback is not an error by itself, there was always an error of type
RfcGetException with message "Received a callback from the communication partner"
logged in the RFC error log file dev_jco_rfc.trc. Despite this log entry, no error or
exception was thrown to the JCo application or signalled to the communication partner.
Even if the requested RFC function module was not available and could not be processed,
this was not done and the RFC callback was ignored. If the delta management for RFC
table parameters was active, the erroneous RFC callback handling could furthermore have
caused lost table data and table data inconsistencies between the two communication
partners.
Now RFC callbacks are handled correctly with throwing a JCoException of error group
JCoException.JCO_ERROR_SYSTEM_FAILURE, if the requested function module is not
available, and only in this case an error is logged to the RFC error log file
dev_jco_rfc.trc.
4. RFC logon attempts to an SAP ABAP system have not been interrupted if they were
running too long and exceeded the time span that was specified by the JCo middleware
property 'jrfc.client_connect_timeout' (default is 60 seconds). Now a JCoException with
error group JCoException.JCO_ERROR_TIMEOUT will correctly be thrown in such a
situation, thus interrupting the currently running RFC logon attempt.
Note: This bug was present from JCo release 3.0.5 to 3.0.8 only.
5. After calling method JCoRecord.setValue([name|index], null) or
JCoRecord.setValue([name|index], new byte[0]) for setting the default or an empty field
value on fields of type JCoMetaData.TYPE_XSTRING, the field was not cleared and empty
afterwards but contained one 0-byte value, i.e. a byte array of length 1 (byte[] = {
0x00 }). This 0-byte value was also sent via RFC to the communication partner, if the
JCoMetaData.TYPE_XSTRING field was part of an importing, changing or tables parameter
in a JCoFunction or a JCoRequest object.
6. When using the RFC request/response model at the JCoServer side with a
JCoServerRequestHandler instance processing the incoming RFC requests, JCo neither
traced the API calls to the handleRequest(...) method invocations nor any meta data or
content data of these RFC requests, even if the respective JCo trace level was set for
writing such information.
7. In addition to setting the properties 'jco.session_timeout' and
'jco.session_timeout.check_interval' with the method JCo.setProperty(String key, String
value), these two properties can now also be set as Java system properties with the -D
argument when starting the JVM and they will be recognized at JCo initialization.
8. With the new destination logon property 'jco.client.snc_sso' it is possible to turn
off the Single Sign On (SSO) mechanism of SNC by setting it to the value 0. Thus, it is
possible to log on to an SAP ABAP backend system with some other user ID not fitting to
the SNC identity, while SNC can still be used for encrypting the network communication.
As a prerequisite, a minimum SAP system kernel patch level is required as mentioned in
SAP note 1701870.
9. The destination properties 'jco.client.extid_type' and 'jco.client.extid_data' have
been added for supporting to log on with external user identifaction data to an SAP
ABAP backend system. For this logon variant it is mandatory to use SNC.
10. Some languages like Armenian, Georgian, Vietnamese, Macedonian and many others are
available in Unicode SAP systems only. If logging on with such a language to an SAP
ABAP backend system, it was mandatory to specify an additional destination property
like 'jco.client.codepage' with indicating a unicode communication type, otherwise such
logons failed with an JCoException.JCO_ERROR_LOGON_FAILURE showing the error message
"Select one of the installed languages" although the appropriate language was
installed.
This logon procedure has been improved so that it does not require any additional
communication code page destination property anymore in this case. The unicode
communication type is now automatically detected and used for logging on with such new
SAP system language keys.
Please see SAP note 895560 for more details on languages that are only available in
Unicode SAP systems.
11. The new API JCoDestinationMonitor.getWaitingThreadCount() has been added for
querying the number of threads that are currently waiting for a free connection. Please
see the API Documentation for further details.
Solution
Validity
SAP JCO 3.0 3.0

Support Packages & Patches
Support Package Patches
Software Component Support Package Patch Level
SAP JCO 3.0 SP009 000000
References
SAP Notes
1701870 RFC client communication supporting SNC without SSO
1664732 CPI-C: Client with wrong appc header version rejected
895560 Support for languages only available in Unicode systems
SAP Notes (8)
1701870 RFC client communication supporting SNC without SSO
1664732 CPI-C: Client with wrong appc header version rejected
SAP Note
active
Header Data
Released On 02.12.2011 15:09:52
Symptom
1. A memory leak in the native heap is recognized.
3. A performance degredation is observed when communicating with an R/3 release 4.6C
system.
4. A JCoServer instance is stopped after changing its configuration.
5. An exception is thrown when specifying a value of format sapgw##s for the connection
property 'gwserv'.
6. JCoCustomDestination instances were never invalidated and illegally remained usable.
7. SSO tickets and X.509 certificates are not used when being updated on a
JCoCustomDestination instance.
8. A JCoCustomDestination instance returns a wrong JCoRepository object or is using
wrong destination logon data for repository meta data queries.
9. Changing or updating a JCoDestination object for a JCoCustomRepository instance is
not possible due to an exception being thrown.
10. Calling the method JCoDestination.getMonitor() sometimes throws a
JCoRuntimeException with error group JCO_ERROR_RESOURCE.
11. A JCoDestinationMonitor instance is obviously reporting wrong connection pool data
for the monitored destination.
12. Calling the method JCoDestination.getRepository() throws a JCoRuntimeException with
error group JCO_ERROR_CONFIGURATION, if only a repository user but no standard user,
user alias, or logon ticket are configured.
13. The performance of single threaded JCo applications is bad when doing stateless RFC
calls.
Other Terms
SAP Java Connector, JCo, JCo3, memory leak, JCO_ERROR_LOGON_FAILURE,
JCO_ERROR_DESTINATION_DATA_INVALID, JCO_ERROR_ILLEGAL_STATE, JCO_ERROR_CONFIGURATION,
JCO_ERROR_RESOURCE
The following program errors have been fixed:
1. A memory leak in the native layer existed when receiving data from the backend.
Thus, more and more native memory was allocated and the process could run out of
memory. Please check SAP note 1595477 for details.
2. Under certain circumstances, a memory leak was caused by the internal destination
management within a repository. This could have happened when creating many
JCoCustomDestination instances from destinations, which did not have an associated
repository yet. In this situation the first call to
JCoCustomDestination.getRepository() on each of such a JCoCustomDestination instance
created a memory leak in the Java heap being located in the returned JCoRepository
object.
3. When communicating with an R/3 release 4.6C system which is running with a 4.6D
kernel, the reset of pooled connections was not working as expected. Instead of simply
resetting the context in the backend, the connection was closed and reopened again. In
networks with high latency this led to an undesired performance degredation. This was
caused by wrongly checking the partner release number instead of the kernel release
number.
4. When a JCoServer instance had to be restarted due to a change in the configuration
being signaled by an update event, the server did not come up, but was stopped instead.
In particular, simply adjusting the trace flag led to this situation. This was caused
by the fact, that the new server instance was already started, before the old one had
been shutdown completely.
5. If specifying a gateway service with the destination data connection property
'jco.client.gwserv' or with the server data connection property 'jco.server.gwserv',
all property string values of format sapgw##s (with # being a placeholder for a digit)
were not accepted and an exception was thrown or an error message was logged saying
that the gateway service parameter needs to be of a different format. Contrary to this
error message, gateway service parameters of format sapgw##s are valid and may be
specified alternatively to parameter values of format sapgw## or #### for directly
specifying the TCP port number.
6. A JCoCustomDestination instance was never invalidated and remained usable, even if
the destination configuration, which it is based on, was changed or deleted. Now, a
JCoException with error group JCoException.JCO_ERROR_DESTINATION_DATA_INVALID will
correctly be thrown, if a JCoCustomDestination instance will be used in such a
situation.
7. New SSO tickets or X.509 certificates that are set for a JCoCustomDestination
instance were not used, in case that there was already another SSO ticket or X.509
certificate previously being used for this destination. The previously set SSO ticket
or X.509 certificate was cached and still used instead of the new one. This led to a
JCoException with error group JCoException.JCO_ERROR_LOGON_FAILURE being thrown, if the
SSO ticket or X.509 certificate has been expired in the meantime.
8. After setting a repository destination with method
JCoCustomDestination.setRepositoryDestination(JCoDestination), the JCoCustomDestination
instance used the passed destination's client connections instead of the desired
repository connections. Depending on the destination configuration this might have led
to a wrong repository being returned on a subsequent call to
JCoCustomDestination.getRepository() and/or wrong targeted connections and logon
parameters being used for future meta data queries of the returned JCoRepository
instance.
9. The setting of a destination for a JCoCustomRepository instance has been improved.
Now, it is possible to change the destination for remote meta data queries with method
JCoCustomRepository.setDestination(JCoDestination). Before this improvement, it was
only allowed to set a destination once and subsequent calls to
JCoCustomRepository.setDestination(JCoDestination) led to a JCoRuntimeException with
error group JCoException.JCO_ERROR_ILLEGAL_STATE being thrown.
10. The method JCoDestination.getMonitor() threw a JCoRuntimeException with error group
JCoException.JCO_ERROR_RESOURCE saying that the destination would not be initialized or
would have been already removed, although this was not true and the JCoDestination
instance was actually valid. This error situation only occurred if the JCoDestination
instance's getMonitor() method was called for the first time and there was no
connection pool available for this destination at that time.
11. JCoDestinationMonitor instances returned wrong data after the connection pool being
associated to the monitored JCoDestination instance was temporarily removed due to
inactivity on this destination. In such an error situation the JCoDestinationMonitor
instance always reported that there would not be any open connection and consequently
the number of pooled and used connections would both be 0. But that potentially did not
reflect the real situation where several new connections for the monitored destination
meanwhile might have been opened again.
12. The method JCoDestination.getRepository() threw a JCoRuntimeException with error
group JCoException.JCO_ERROR_CONFIGURATION saying that the configuration for this
destination would be invalid in case there was a repository user defined, but no
standard user, user alias or logon ticket were configured. Contrary to this error
message, a destination configuration containing only a repository user is sufficient at
least for the creation of and usage by a JCoRepository instance.
13. Without concrete pooling configuration settings, pooling was not used at all in
JCo, but the connections were immediately closed, if they were not longer needed, which
leads to unnecessary latencies. Hence, the default behavior regarding the connection
pooling has been improved. If the DestinationDataProvider does not specify the property
jco.destination.pool_capacity for a certain destination, the default value 1 is used
for this property now instead of 0. This means that connection pooling is enabled by
default now and thus dramatically increases the performance of typical single threaded
applications, which do not care about connection pooling.
Solution
Validity
SAP JCO 3.0 3.0

J2EE ENGINE SERVERCORE 7.10 SP015 000000
J2EE ENGINE SERVERCORE 7.11 SP010
000000
SAP JCO 3.0 SP008 000000
References
SAP Notes
1595477 Memory leak in native layer of SAP Java Connector
SAP Notes (5)
1595477 Memory leak in native layer of SAP Java Connector
SAP Note
active
Header Data
Released On 05.05.2011 11:55:19
Priority Correction with medium priority
Symptom
1. Using scopeTypes with the default SessionReferenceProvider implementation of the JCo
runtime does not work as expected.
2. A ConcurrentModificationException occurs when processing requests in a JCoServer
with a callstack similar to the following: java.util.ConcurrentModificationException
at java.util.HashMap$AbstractMapIterator.checkConcurrentMod()
at java.util.HashMap$AbstractMapIterator.makeNext()
at java.util.HashMap$KeyIterator.next()
at java.util.HashMap.analyzeMap()
at java.util.HashMap.rehash()
at java.util.HashMap.rehash()
at java.util.HashMap.putImpl()
at java.util.HashMap.put()
at com.sap.conn.jco.rt.SimpleSessionRefProvider.jcoServerSessionPassivated()
at com.sap.conn.jco.rt.DefaultServerWorker.callFinishedInternal()
3. For a repository it is impossible to retrieve a metadata definition. The metadata
lookup always fails with a JCoException with group
JCoException.JCO_ERROR_LOGON_FAILURE. In the end one of the users configured as
repository user is locked.
4. The valid value of 9 for jco.server.snc_qop in a server configuration is not
accepted by the JCoServer runtime.
5. When sending a tRFC request to a JCoServer a NullPointerException without any
descriptive message is retrieved in the ABAP system and is written to the log on JCo
side.
6. A 3.1I system tries to execute a function module on a JCoServer, but failes with an
error message similar to "RFC_ERROR_SYSTEM_FAILURE: You cannot adjust the state of a
ServerConnection with this method."
7. Your SessionReferenceProvider is sometimes receiving null as sessionID in the event
jcoServerSessionFinished().
Other Terms
The problems above have been caused by the following bugs in JCo 3.0.6:
1. The default SessionReferenceProvider used by the JCo runtime did not support
scopeTypes.
2. The JCoServer is run under high load with the default SessionReferenceProvider. No
other SessionReferenceProvider is registered with JCo. In the
SimpleSessionReferenceProvider not all blocks that needed a synchronization were really
synchronized.
3. The repository is shared between several destinations. Many of them have a separate
user configured for repository lookups and one of them is configured incorrectly: The
repository user/password combination is not correct. For the lookup, repeatedly the
"bad" destination is used instead of switching to the next one, which is the expected
behavior.
4. JCo was using a wrong range for jco.server.snc_qop when checking the properties:
[0..8] instead of [1..9]
5. There is no JCoServerTIDHandler or no JCoServerUnitIDHandler set for a JCoServer.
There is no check for null issued before accessing the handler when receiving a
tRFC/qRFC or bgRFC unit.
6. Some special behavior needed for a 3.1I system being the client was not done
properly in the JCo runtime since JCo 3.0.5.
7. The request is executed in a stateless server context. In this case, the sessionID
retrieved from jcoServerSessionStarted() was not stored in the JCoServer.
Solution
Upgrade to at least JCo 3.0.7, which is available on the download page under
http://service.sap.com/connectors -> SAP Java Connector -> Tools & Services -> Download SAP
JCo Release 3.0.<currentPatchLevel>. Please note that on Windows systems you need to make
sure that you use the updated ATL and C runtime provided by Microsoft. Otherwise JCo won't
work any more, the cause is the same as for the kernel as described in note 1375494, where
you can also find an installation description for the updated C runtime.
1. The default implementation of the SessionReferenceProvider was re-implemented as
DefaultSessionReferenceProvider and is now exposed in com.sap.conn.jco.ext package and
supports scopeTypes by default. If an application/infrastructure that uses the default
implementation wants to disable scopeType support again it has to register new
DefaultSessionReferenceProvider(false) via the Environment class. Find more details in
the JavaDoc.
2. The new implementation DefaultSessionReferenceProvider ensures to synchronize
accesses to internal structures whenever necessary.
3. The repository is now treating the JCoException.JCO_ERROR_LOGON_FAILURE properly and
gives the next destination a try for the lookup.
4. The correct range [1..9] for jco.server.snc_qop is checked now.
5. If such a handler is missing and a corresponding request shall be processed, JCo now
throws a a JCoRuntimeException with group JCoException.JCO_ERROR_ILLEGAL_STATE that
provides a clarifying message.
6. The JCoServer runtime now behaves correctly again when a 3.1I system is
communicating with it.
7. The event jcoServerSessionFinished() now always gets a non-null sessionID passed.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
SAP Notes (5)
1586688 JCoServer finish event receives null session ID
SAP Note
active
Header Data
Released On 22.09.2010 13:18:48
Symptom
1. If in a structure, table or function module a scalar type (e.g. CHAR, NUMC, etc) is
refering to a data element, the name of that data element is not returned in
getRecordTypeName() in JCo 3.0.5, although this worked fine in JCo 3.0.0 to 3.0.4.
2. A JCoDestination is associated with a scopeType via
JCoDestinationManager.getDestination(destName, scopeType). If you now create a
JCoCustomDestination from the retrieved destination, the scopeType information is
ignored, when executing a function module.
3. If table type FOO has a table type BAR as line type and one of the rows of FOO
contains only an empty table BAR, then an exception occurs that looks similar to:
JCO_ERROR_XML_PARSER: Parameter PARAM_FOO: After a value an end tag must follow. That
did not happen in "em><item><BAR_COL".
4. RFC function module parameters might not get initialized correctly, if an ABAP
system field (e.g. SY-DATLO or SY-TIMLO) is defined as their default value. This might
also lead to ConversionExceptions being thrown when trying to read these values with
the JCoParameterList.getValue() or the various JCoParameterList.get<type>() methods.
5. If a gateway is protected with a reginfo file, a JCoServer is not allowed to
register itself from a certain host and/or a certain program ID with that gateway.
Unfortunately, the JCoServer does not recognize such a registration failure as an
unrecoverable configuration error, and hence tries to re-register again immediately.
This is of course failing again, which in turn leads to an endless loop and rapidly
growing dev_jco_rfc.trc files.
6. When terminating a JCo application, the ABAP system writes an entry containing "SAP-
RC=223" into the syslog. This happens, even if the DestinationDataProvider is
deregistered from JCo.
7. When processing changes in a server configuration, not all changes are recognized by
the JCoServer upon receiving them from the ServerDataProvider. And even if a change is
recognized correctly for a running JCoServer, the subsequent update causes the
JCoServer to get aborted.
8. The setting for the maximum restart delay for a server is ignored.
Other Terms
If in a structure, table or function module a scalar type (e.g. CHAR, NUMC, etc) is refering
to a data element, the name of that data element is not returned in getRecordTypeName() in
JCo 3.0.5, though this worked fine in JCo 3.0.0 to 3.0.4.
1. When creating the JCoCustomDestination, the scopeType was not passed to it.
2. The parser did a wrong interpretation of the nested row tag (item).
3. The default value processing was very rudimentary.
4. In such a case the registration seemed to be successful, but the gateway immediately
sends a first message signalling the insufficient permission. This message was
interpreted in a wrong way.
5. When a DestinationDataProvider is deregistered from JCo, the connections established
by destinations created from this provider should be closed. However, this did not work
for repository connections.
6. Not all configuration parameters were processed when updating a cached server
configuration. When a running server was updated and needed to be stopped due to the
changes, then the new instance was simply not started.
7. Both the server configuration parameter (jco.server.max_startup_delay) and the
middleware configuration parameter (jco.middleware.max_startup_delay) were not
processed correctly.
Solution
you can also find an installation description for the updated C runtime.
1. When creating the JCoCustomDestination the scopeType is now passed to it.
2. The parser can now deal with the representation of an empty row for a table type
with a table type as line type .
3. The default value processing was extended to provide values for most of the SY
fields, where a resonable value was possible.
4. The message signalling the insufficient permission is now considered to be an
unrecoverable configuration issue and hence the server is stopped immediately.
5. When a DestinationDataProvider is deregistered from JCo, the repository connections
are now closed.
6. The server configuration update processing was re-worked and does now check all
configuration options. Moreover, a running server is replaced by an updated instance
which is also started as necessary.
7. jco.server.max_startup_delay and jco.middleware.max_startup_delay are now processed
correctly.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1557856 SAP Java IDoc Class Library Version 3.0.6
1493256 Metadata lookup in IDocLibrary 3.0 fails
1489157 Invalid parameter values with SY-Field defaults in JCo/JRA
1456826 Reduction in roundtrips with SAP Connectors
SAP Notes (8)
1456826 Reduction in roundtrips with SAP Connectors
1475856 ScopeType ignored for JCoCustomDestination
1489157 Invalid parameter values with SY-Field defaults in JCo/JRA
1493256 Metadata lookup in IDocLibrary 3.0 fails
SAP Note
active
Header Data
Released On 29.03.2010 15:26:18
Symptom
1. A NullPointerException is thrown in the delta management for table parameters within
JCo.
2. Setting a value for a field of type BCD with a value containing an invalid
character, e.g. an 'a' is accepted withou en error.
3. When executing multiple tRFCs or bgRFCs in parallel threads, some of the tRFCs or
bgRFCs get lost without any error message. In particular, this can lead to data loss
during IDoc communication.
Other Terms
1. The function module in ABAP executes a callback to destination BACK for a system
check.
2. JCo does not check whether the value consists only of digits, where digits are
expected.
3. A multi-threading issue in JCo 3.0.3 and 3.0.4 with respect to tRFC and bgRFC.
Solution
you can also find an installation description for the updated runtime.
1. Delta management in JCo does now act properly in case of callbacks.
2. JCo does now check for validity with regard to digits.
3. The cause for the multi-threading issue has been identified and fixed.
Read the release notes for more information.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1438660 Loss of tRFCs and IDocs with JCo 3.0.3 and 3.0.4
SAP Notes (4)
1438660 Loss of tRFCs and IDocs with JCo 3.0.3 and 3.0.4
SAP Note
active
Header Data
Released On 23.12.2009 11:55:06
Symptom
1. When executing a synchronous call, a JCoException with the message "Incorrect size
of TID encountered [null]" is thrown.
2. When trying to communicate with an SAP system, the communcation fails with an
exception in the NI layer: hostname 'xxxxxxxx' unknown.
Other Terms
qRFC, z/OS, conversion
1. The destination was set to stateful. When a qRFC was executed, the queue name was
stored in the connection context, but had not been reset after the function module
invocation, so that the succeeding call was interpreted as a qRFC again, leading to a
check for the TID. Such a TID is certainly not available for synchronous requests, and
as a consequence the exception is raised as mentioned above.
2. z/OS specific: JCo needs to run on an EBCDIC variant of z/OS. In that case some
ASCII/EBCDIC conversion was not done when looking up the address. (see also note
1406061)
Solution
Upgrade to at least JCo 3.0.4. Please note that on Windows systems you need to make sure
that you use the updated ATL and C runtime provided by Microsoft. Otherwise JCo won't work
any more, the cause is the same as for the kernel as described in note 1375494, where you
can also find an installation description for the updated runtime.
1. The queue name that is stored in the connection context is now reset after the
function module invocation.
2. The necessary ASCII/EBCDIC conversion is now done when looking up the address.
Validity
SAP JCO 3.0 3.0

SAP_BASIS 720 720

References
SAP Notes
1406061 z/OS: JCo 3.0.3: ERROR hostname unknown
1375494 SAP system does not start after applying SAP kernel patch
SAP Notes (4)
1406061 z/OS: JCo 3.0.3: ERROR hostname unknown
SAP Note
Version 1 Validity: 15.09.2009
- active
Header Data
Released On 31.10.2009 19:26:11
Symptom
1. A NullPointerException is thrown, as soon as a new request for a JCoServer is
coming in.
2. When an implementation of a JCoServerTIDHandler throws an exception within
checkTID(), the exception message is not visible in the transaction monitor (sm58) of
the calling ABAP system.
3. The last field within table rows or a structure does not contain valid values, even
though values have been sent by the communication partner.
4. A StackOverflowError occurs in the JCoRepository.
5. The value of a changing parameter is not available in the response of a function
module invocation.
Other Terms
NullPointerException, StackOverflowError,
1. There were some prerequisites: The JCoServer configuration had been updated within
a ServerDataProvider that did not support events. Afterwards that server was started
again, but had not been stopped properly before. This led to an inconsistency within
the JCoServer management.
2. If an exception occurred in checkTID(), the message text was not sent to the
caller.
3. If the last field in the metadata of the structure or table in the sending partner
system has a shorter length than JCo is using for receiving the data, the last field
value had simply been dropped.
4. If two lookups in a JCoRepository occurred simultaneously in two threads, an
inconsistency could occur caused by race conditions when adding the metadata to the
cache storage.
5. If the JCo application did not set a value to a changing parameter, it simply was
not sent to the ABAP system, and as a consequence was also not sent back after the
function module processing.
Solution
Upgrade to JCo 3.0.3.
1. The inconsistency in the JCoServer management has been removed.
2. If an excecption occurs in checkTID, the message text is now sent to the caller.
3. The last field within table rows or a structure is now filled with all the data
available from the partner.
4. Race conditions while adding metadata to the cache are now avoided.
5. A changing parameter will now always be sent to the ABAP system, except for the
case that the application set it to inactive.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1388694 Hanging connections to JCo
1358698 JCo cuts off last field of a structure or table
SAP Notes (4)
SAP Note
- active
Header Data
Released On 16.04.2009 14:00:25
Symptom
1. When setting one digit values (e.g. 4 or 7) for BCD fields, the resulting value is
always 0.0 - with n times the digit 0 after the dot, corresponding to the number of
decimals (n) in the metadata definition of that field.
2. When a failure occurs while opening a connection, the error group
JCO_ERROR_CANCELLED with the exception message "Handle close pending" is coming up,
instead of the expected JCO_ERROR_LOGON_FAILURE with the correct error message.
3. Stateful server connections cannot be set to stateless again.
4. Under very high load both getUsedServerThreadCount() and
getMaximumUsedServerThreadCount() are increasing above the configured maximum, until
the load is lower again and then remain at the wrong high level.
5. A ConversionException is thrown when trying to get a negative value from a field of
type CHAR as a converted numeric value, if the value has been assigned to the CHAR
field in ABAP code.
6. A java.lang.UnsatisfiedLinkError with the message
com.sap.i18n.cp.ConverterJNI.ConvertCToXArrR([B[CII[BII[I)I occurs, when a blended
codepage is used, e.g. 6100.
7. If the path to the SAP GUI startup script contains blanks, starting the Java GUI
fails on MacOS and Unix platforms.
8. If a table is part of the changing parameter list, and is not containing any row,
then the table is always returned empty after having executed the function module.
9. Certain data types are not returned correctly by getRecordMetaData(), if there is a
table type with a table type as line type somewhere in a deeply nested type
definition.
Other Terms
vector, session management, BCD, stateful, logon failure,
1. One digit values were interpreted incorrectly.
2. When adding a timeout for the logon in JCo 3.0.1, logon failures have not been
mapped correctly to the expected exception.
3. The setStateful(false) invocation on the JCoServerContext was simply ignored.
4. The counter for the monitor value was only increased in high load scenarios, but
never decreased.
5. ABAP stores negative values with a sign after the number value, e.g. 1-, which is
not accepted by the Java parse<NumberType> methods.
6. The native methods needed for blended codepages were not exported in the JNI
library.
7. The command to start a Java GUI was not created properly in that case.
8. JCo did not send a table to ABAP, if the table had no rows and was part of a
changing parameter list. Therefore ABAP did not send the (filled) table back either.
9. The interpretation of the returned values in the metadata function modules for
those data types was not done correctly.
Solution
1. One digit values are now interpreted incorrectly.
2. Logon failures are again mapped correctly to the expected exception.
3. The setStateful(false) invocation on the JCoServerContext is now handled.
4. The counter for the monitor value is now increased and decreased correctly.
5. Before passing the value to the parse<NumberType> method, JCo moves the negative
sign from the end to the beginning of the value, if necessary.
6. The native methods needed for blended codepages were added to the export list in
the JNI library.
7. The command to start a Java GUI can now deal with blanks in the path name of the
executable.
8. JCo is now always sending the table to ABAP, if the table is not set to inactive.
9. The metadata for the nested table types is now created properly.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1312880 Security Note: clear text password in trace file
1298438 Hanging JCo threads
SAP Notes (5)
1298438 Hanging JCo threads
1312880 Security Note: clear text password in trace file
SAP Note
- active
Header Data
Released On 18.11.2008 09:28:30
Symptom
1. Your function module needs to run with a SAP GUI attached, but you are not able to
attach one. The property "jco.client.use_sapgui" results in the error message "No GUI
available".
2. A thread dump of your application shows that there is either no
JCoDispatcherWorkerThread or even two of them, leading to either no RFC requests being
processed by your application or to crashes, when both threads access the same native
memory at the same time. In one Java process exactly one JCoDispatcherWorkerThread
needs to exist, independent of the number of JCoServers that has been started.
3. An ArrayIndexOutOfBoundsException is thrown, when working with function modules
that contain more than 127 non-scalar parameters in one parameter list.
4. When using default values for BCD variables, a runtime error BCD_BADDATA occurs on
ABAP side.
5. During stateful server communication, the connection is broken during a second or
later call, if the data volume on the line is larger than 16000 bytes. In the
dev_jco_rfc.trc file messages like "com.sap.conn.jco.JCoException: (102)
RFC_ERROR_COMMUNICATION: CPIC-CALL: CMRCV on convId: 30129925 no SAP ErrInfo
available" can be seen.
Small data volumes can be processed without an error.
6. An ArrayIndexOutOfBoundsException: 10000 is thrown, when trying to connect to an
arbitrary backend, and thus the connection fails.
Other Terms
SAP GUI, Popup, ArrayIndexOutOfBoundsException, BCD, packed, connection leak, stateful,
BCD_BADDATA
The above problems have been caused by the following bugs and missing features in JCo 3.0.0:
1. JCo 3.0.0 is lacking support for starting a SAP GUI by setting the
"jco.client.use_sapui" property.
2. There are synchronization issues when starting the JCoDispatcherThread.
Furthermore, severe errors under high load could end the JCoDispatcherThread.
3. An overflow in the counter for non-scalar parameters occurred.
4. The default value for BCD values was encoded incorrectly.
5. An inconsistency between the JCo RFC and the CPIC layer leads to the cancellation
of the connection.
6. This is due to a connection leak caused by exceptions when trying to abort a
connection. See details in note 1252962.
Solution
1. It's now possible to start a SAP GUI locally with a newly introduced starting
method, and attach it afterwards to the JCo connection. Note 1258724 describes the
prerequisite of the backend for this new method.
2. The synchronization issues have been solved and more errors are caught within the
run method of the dispatcher thread.
3. The type of the counter was changed from byte to int.
4. The default value is now encoded correctly.
5. The inconsistency between the JCo RFC and the CPIC layer has been removed.
6. The connection leak has been removed.
Read the release notes for more information. Moreover, new platforms are now supported with
3.0.1:
Solaris on x86_64
Linux on PowerPC64
IBM i (also known as OS/400...)
z/OS
Read the details about the platform support in note 1077727.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1258724 Starting SAPGUI using external RFC libraries
1252962 ArrayIndexOutOfBoundsException when opening a connection
SAP Notes (4)
1252962 ArrayIndexOutOfBoundsException when opening a connection
1258724 Starting SAPGUI using external RFC libraries
SAP Note
1077727 - SAP JCo 3.0 release and support strategy
Version 27 Validity:
30.04.2014 - active
Header Data
Released On 01.05.2014 05:21:09
BC-MID-BUS Business Connector
Priority Recommendations / Additional Info
Other Components
Category Release planning information
Symptom
Supported platforms and JDKs for the SAP Java Connector 3.0 (SAP JCo 3.0).
Other Terms
SAP Java Connector, JCo, SAPJCO, sapjco3.jar, JCo3, life cycle, download, version,
release, patch level, SAP Service Marketplace, SMP
SAP JCo 3.0 is replacing SAP JCo 2.0 and SAP JCo 2.1 and is released for Java 5, Java 6
and Java 7.
Note that SAP JCo 3.0 is incompatible with former versions of SAP JCo. For details and
migration instructions read the documentation of SAP JCo 3.0.
Solution
SAP JCo 3.0 is made available to customers according to the license agreement for SAP JCo
(For details of the agreement see http://service.sap.com/connectors).
JCo 3.0 is supported for the SAP JVM 5 and SAP JVM 6 as well as for the Java 5, Java 6 and
Java 7 Standard Editions of the corresponding platform vendor. It is recommended to use the
SAP JVM 5 or 6, because it adds further diagnostic support features and it is also not subject
to the end-of-maintenance restrictions of the JVMs of other vendors.
The end of maintenance and support for SAP JCo 3.0 is scheduled for December 31, 2017.
The format of the JCo version number is <MajorRelease>.<MinorRelease>.<PatchLevel>.
Only the latest patch level of each release is supported and available for download via the
SAP Service Marketplace at
http://service.sap.com/connectors
-> SAP Java Connector
-> Tools & Services
-> Download SAP JCo Release 3.0
Generally a new patch level is downwards compatible to the previous patch levels of the
same release. So the files of an old JCo 3.0 installation may simply be replaced with the latest
ones.
Currently, the latest patch level for SAP JCo 3.0 is version 3.0.11.
On Windows platforms, JCo 3.0 requires the Visual Studio 2005 C/C++ runtime libraries
(8.0.50727.4053) to be installed on the system. See SAP note 1375494 for details on how to
install them.
The JCo 3.0 release is supported for the following operating systems in combination with the
SAP JVM 5 or the Java 5 Standard Edition of the corresponding platform vendor [mentioned
in brackets]:
Windows x86 32bit (Versions: Windows Server 2003, Windows XP, Windows Vista,
Windows 7, Windows 8) [Oracle JSE 1.5.0]
Windows x64 64bit (Versions: Windows Server 2003, Windows Server 2008, Windows
Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows XP,
Windows Vista, Windows 7, Windows 8) [Oracle JSE 1.5.0]
Windows Itanium 64bit (Versions: Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2) [Oracle JSE 1.5.0]
Linux x86 32bit (Versions: SuSE SLES9, SuSE SLES10, SuSE SLES11, RedHat EL4,
RedHat EL5, RedHat EL6) [IBM or Oracle JSE 1.5.0]
Linux x86 64bit (Versions: SuSE SLES9, SuSE SLES10, SuSE SLES11, RedHat EL4,
RedHat EL5, RedHat EL6) [IBM or Oracle JSE 1.5.0]
Linux Itanium 64bit (Versions: SuSE SLES9, SuSE SLES10, RedHat EL4, RedHat EL5)
[Oracle JSE 1.5.0]
Linux zSeries 64bit (Versions: SuSE SLES9, SuSE SLES10, RedHat EL5) [IBM JSE
1.5.0]
Linux PowerPC 64bit (Versions: SuSE SLES9, SuSE SLES10, SuSE SLES11, RedHat
EL4, RedHat EL5, RedHat EL6) [IBM JSE 1.5.0]
AIX 64bit (Versions: 5.2, 5.3, 6.1, 7.1) [IBM JSE 1.5.0]
HP-UX PA-RISC (Versions: HP-UX B11.11, B11.23, B11.31) [HP JSE 1.5.0]
HP-UX Itanium (Versions: HP-UX B11.23, B11.31) [HP JSE 1.5.0]
Solaris SPARC 64bit (Versions: 9, 10) [Oracle JSE 1.5.0]
Solaris x64 (Version: 10) [Oracle JSE 1.5.0]
Apple MAC OS X Intel 32bit (Versions: 10.4, 10.5) [Apple JSE 1.5.0]
Apple MAC OS X Intel 64bit (Versions: 10.4, 10.5) [Apple JSE 1.5.0]
z/OS 64bit (Versions: 1.8, 1.9) (For details on JCo on z/OS please see also SAP note
1253440.) [IBM JSE 1.5.0]
IBM i 64bit (Versions: V5R4, V6R1) [IBM JSE 1.5.0]

SAP JVM 6 or the Java 6 Standard Edition of the corresponding platform vendor [mentioned
in brackets]:
XP, Windows Vista, Windows 7, Windows 8) [Oracle JSE 1.6.0]
Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows XP,
Windows Vista, Windows 7, Windows 8) [Oracle JSE 1.6.0]
Windows Itanium 64bit (Versions: Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2, Windows 7) [Oracle JSE 1.6.0]
Linux x86 32bit (Versions: SuSE SLES10, SuSE SLES11, RedHat EL5, RedHat EL6)
[IBM or Oracle JSE 1.6.0]
Linux Itanium 64bit (Versions: SuSE SLES10, RedHat EL5) [Oracle JSE 1.6.0]
Linux zSeries 64bit (Versions: SuSE SLES10, RedHat EL5) [IBM JSE 1.6.0]
Linux PowerPC 64bit (Versions: SuSE SLES10, SuSE SLES11, RedHat EL5, RedHat
EL6) [IBM JSE 1.6.0]
AIX 64bit (Versions: 5.3, 6.1, 7.1) [IBM JSE 1.6.0]
HP-UX Itanium (Versions: HP-UX B11.23, B11.31) [HP JSE 1.6.0]
Solaris SPARC 64bit (Versions: 10, 11) [Oracle JSE 1.6.0]
Solaris x64 (Versions: 10, 11) [Oracle JSE 1.6.0]
Apple MAC OS X Intel 32bit (Versions: 10.6, 10.7, 10.8, 10.9) [Apple JSE 1.6.0]
Apple MAC OS X Intel 64bit (Versions: 10.5, 10.6, 10.7, 10.8, 10.9) [Apple JSE 1.6.0]
z/OS 64bit (Versions: 1.8, 1.9, 1.10, 1.11, 1.12, 1.13) (For details on JCo on z/OS
please see also SAP note 1253440.) [IBM JSE 1.6.0]
IBM i 64bit (Versions: V6R1, V7R1, V7R2) [IBM JSE 1.6.0]

Java 7 Standard Edition of the corresponding platform vendor [mentioned in brackets]:
Windows x86 32bit (Versions: Windows XP, Windows 7, Windows 8) [Oracle JSE 1.7.0]
Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 7,
Windows 8) [Oracle JSE 1.7.0]
Linux zSeries 64bit (Versions: SuSE SLES11, RedHat EL6) [IBM JSE 1.7.0]
Linux PowerPC 64bit (Versions: SuSE SLES11, RedHat EL5, RedHat EL6) [IBM JSE
1.7.0]
AIX 64bit (Versions: 6.1, 7.1) [IBM JSE 1.7.0]
Solaris SPARC 64bit (Version: 11) [Oracle JSE 1.7.0]
Solaris x64 (Version: 11) [Oracle JSE 1.7.0]
Apple MAC OS X Intel 64bit (Versions: 10.7, 10.8, 10.9) [Oracle JSE 1.7.0]
z/OS 64bit (Versions: 1.13, 2.1) (For details on JCo on z/OS please see also SAP note
1253440.) [IBM JSE 1.7.0]
IBM i 64bit (Version: V7R2) [IBM JSE 1.7.0]

Note: JCo 3.0 requires for all Java Runtime Environments (JRE) that the used Java
Cryptography Extension (JCE) has to offer a provider which supports the MD5 hash
algorithm. This is already the case with the default JCE of all SAP JVMs and the mentioned
vendor JSEs but needs to be considered if registering and using other JCE providers
exclusively.
Validity
SAP JCO 3.0 3.0

References
SAP Notes
1663178 New prerequisites for SAP JVM 5.1 and 6.1 on AIX
1269638 Setting up the different Java JVMs for JCo3 on IBM i
1253440 SAP JCo on z/OS
549268 SAP JCo 2.x release and support strategy
SAP Notes (28)
1681565 SAP Java Connector 3.0 Hotfix installation
1278181 Usage of CTS+ Command Line Tool (Export)
2032963 DB2-z/OS: Recommended Java SDK for z/OS
1752456 SAP Java IDoc Class Library 3.0 Hotfix installation
549268 SAP JCo 2.x release and support strategy
1582525 CTS+ Integration for SBOP PC MS 7.5 and 10.0
1253440 SAP JCo on z/OS
1269638 Setting up the different Java JVMs for JCo3 on IBM i

Multiprint SAPNotes

Uploaded by

Copyright:

Available Formats

You might also like

Multiprint SAPNotes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multiprint SAPNotes

Uploaded by

Copyright:

Available Formats

Table of Content

0001919773 - SAP Java Connector Release 3.0.11

You might also like