Multiprint Sapnotes 2k3p2m

:<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( ) 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 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 ed JCoServer RFC connection, this newly ed 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'. Note: This bug was present in JCo release 3.0.10 only. 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 IC error messages "Connection to partner ' :<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( ) 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= 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 at least the SAP Java Connector 3.0.11 from the SAP Service Marketplace at http://service.sap.com/connectors . You will find the package with the latest patch level for various platforms by navigating to "SAP Java Connector" -> "Tools & Services" -> " SAP JCo Release 3.0". An installation guide is included in the 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 strategy

This document is referenced by: SAP Notes (2) 1077727 SAP JCo 3.0 release and strategy 2026482 SAP Java IDoc Class Library Release 3.0.11

SAP Note

1748457 - SAP Java Connector Release 3.0.10 Version 1 active

Validity: 31.07.2012 -

Language English (Master)

Header Data Released On Release Status Component Priority Category

12.08.2013 21:28:45 Released for Customer BC-MID-CON-JCO Java-Connector Correction with high priority Program error

Symptom 1. An RFC request to a ed 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 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 ed 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 nonUnicode 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 SAP Java Connector, JCo, JCo3, hanging server connection, memory leak, slow performance, ed 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

Reason and Prerequisites The following program errors have been fixed and further improvements have been made: 1. A program error in the underlying native IC 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 ed 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 ed 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. Note: This bug was present in JCo release 3.0.9 only. 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 ed JCo RFC servers and related SAP AS ABAP systems which actually were not connected to the problematic SAP gateway host. 4. for calling external RFC server programs as well as 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 ed SessionReferenceProvider if the session would be still alive nevertheless. Note: This bug was present in JCo release 3.0.9 only. 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.



References This document refers to: SAP Notes 1902880 Business Connector 4.8 Service Release 9 (SR9) 1900587 SAP Java IDoc Class Library Release 3.0.10 1877907 1791529 1671480 1425520

of extern-to-extern RFC communication with JCo 3.0 GW: Hanging connections between J2EE and gateway SAP Java Connector Release 3.0.9 Disable NI cache for host and service names

1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (6) 1791529 GW: Hanging connections between J2EE and gateway 1919773 SAP Java Connector Release 3.0.11 1671480 SAP Java Connector Release 3.0.9 1425520 Disable NI cache for host and service names 1900587 SAP Java IDoc Class Library Release 3.0.10 1902880 Business Connector 4.8 Service Release 9 (SR9)

SAP Note


Validity: 09.01.2012 -




Symptom 1. A memory leak in the Java heap is recognized. 2. A JCoException with the IC 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 identification data is not ed. 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 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

Reason and Prerequisites The following program errors have been fixed and further improvements have been made: 1. A memory leak was removed at the internal destination management within the JCoTimeoutChecker thread. This memory leak was created each time that the ed DestinationDataProvider instance updated or deleted a previously used destination from its destination configuration repository. Note: This bug was present in JCo release 3.0.8 only. 2. A program error in the underlying native IC 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 IC 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 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 ing to log on with external 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.



Packages & Patches Package Patches

Software Component Package Patch Level SAP JCO 3.0 SP009 000000

References This document refers to: SAP Notes 1855836 SAP Java IDoc Class Library Release 3.0.9 1795909 Business Connector 4.8 Service Release 8 (SR8) 1748457 SAP Java Connector Release 3.0.10 1701870 RFC client communication ing SNC without SSO 1664732 I-C: Client with wrong appc header version rejected 1649086 SAP Java IDoc Class Library Release 3.0.8 1643299 SAP Java Connector Release 3.0.8 1077727 SAP JCo 3.0 release and strategy 895560 for languages only available in Unicode systems

This document is referenced by: SAP Notes (8) 1567669 SAP Java IDoc Class Library Release 3.0.7 1701870 RFC client communication ing SNC without SSO 1643299 SAP Java Connector Release 3.0.8 1855836 SAP Java IDoc Class Library Release 3.0.9 1649086 SAP Java IDoc Class Library Release 3.0.8 1664732 I-C: Client with wrong appc header version rejected 1748457 SAP Java Connector Release 3.0.10 1795909 Business Connector 4.8 Service Release 8 (SR8)

SAP Note


Validity: 02.12.2011 -




Symptom 1. A memory leak in the native heap is recognized. 2. A memory leak in the Java 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 but no standard , alias, or logon ticket are configured. 13. The performance of single threaded JCo applications is bad when doing stateless RFC calls.

Other 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

Reason and Prerequisites 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 T 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 ed 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 defined, but no standard , alias or logon ticket were configured. Contrary to this error message, a destination configuration containing only a repository 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.




Software Component Package Patch Level J2EE ENGINE SERVERCORE 7.10 SP015 000000

J2EE ENGINE SERVERCORE 7.11 J2EE ENGINE SERVERCORE 7.20 J2EE ENGINE SERVERCORE 7.30 J2EE ENGINE SERVERCORE 7.31 SAP JCO 3.0

SP010 SP008 SP007 SP003 SP008

000000 000000 000000 000000 000000

References This document refers to: SAP Notes 1671480 SAP Java Connector Release 3.0.9 1595477 Memory leak in native layer of SAP Java Connector 1572431 SAP Java Connector Release 3.0.7 1567669 SAP Java IDoc Class Library Release 3.0.7 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (5) 1567669 SAP Java IDoc Class Library Release 3.0.7 1572431 SAP Java Connector Release 3.0.7 1275665 Business Connector 4.8 Service Release 7 (SR7) 1671480 SAP Java Connector Release 3.0.9 1595477 Memory leak in native layer of SAP Java Connector

SAP Note


Validity: 05.05.2011 -

Header Data


Released On Release Status Component Priority Category

05.05.2011 11:55:19 Released for Customer BC-MID-CON-JCO Java-Connector Correction with medium priority Program error

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.jcoServerSessionivated() 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 s configured as repository 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

Reason and Prerequisites 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 scopeTypes. 2. The JCoServer is run under high load with the default SessionReferenceProvider. No other SessionReferenceProvider is ed 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 configured for repository lookups and one of them is configured incorrectly: The repository / 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 at least JCo 3.0.7, which is available on the page under http://service.sap.com/connectors -> SAP Java Connector -> Tools & Services -> 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 s scopeTypes by default. If an application/infrastructure that uses the default implementation wants to disable scopeType again it has to 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 ed.

Validity

Software Component From Rel. To Rel. And Subsequent SAP JCO 3.0 3.0


Software Component J2EE ENGINE SERVERCORE 7.11 J2EE ENGINE SERVERCORE 7.20 J2EE ENGINE SERVERCORE 7.30

Package SP008 SP006 SP004

Patch Level 000000 000000 000000

References This document refers to: SAP Notes 1643299 SAP Java Connector Release 3.0.8 1567669 SAP Java IDoc Class Library Release 3.0.7 1467969 SAP Java Connector Release 3.0.6 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (5) 1567669 SAP Java IDoc Class Library Release 3.0.7 1586688 JCoServer finish event receives null session ID 1467969 SAP Java Connector Release 3.0.6 1643299 SAP Java Connector Release 3.0.8 1275665 Business Connector 4.8 Service Release 7 (SR7)

SAP Note

1467969 - SAP Java Connector Release 3.0.6 Version 2

Validity: 22.09.2010 -


active



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> () methods. 5. If a gateway is protected with a reginfo file, a JCoServer is not allowed to 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- 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 "SAPRC=223" into the syslog. This happens, even if the DestinationDataProvider is deed 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

Reason and Prerequisites The problems above have been caused by the following bugs in JCo 3.0.5: 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 ed 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 deed 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 at least JCo 3.0.6, which is available on the page under http://service.sap.com/connectors -> SAP Java Connector -> Tools & Services -> 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. When creating the JCoCustomDestination the scopeType is now ed 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 deed 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.



Software Component Package Patch Level J2EE ENGINE SERVERCORE 7.10 SP011 000000

References This document refers to: SAP Notes 1572431 SAP Java Connector Release 3.0.7 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 1438294 SAP Java Connector Release 3.0.5 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (8) 1572431 SAP Java Connector Release 3.0.7 1456826 Reduction in roundtrips with SAP Connectors 1475856 ScopeType ignored for JCoCustomDestination 1275665 Business Connector 4.8 Service Release 7 (SR7) 1557856 SAP Java IDoc Class Library Version 3.0.6 1438294 SAP Java Connector Release 3.0.5 1489157 Invalid parameter values with SY-Field defaults in JCo/JRA 1493256 Metadata lookup in IDocLibrary 3.0 fails

SAP Note


Validity: 29.03.2010 -




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

Reason and Prerequisites The problems above have been caused by the following bugs in JCo 3.0.4: 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 at least JCo 3.0.5, which is available on the page under http://service.sap.com/connectors -> SAP Java Connector -> Tools & Services -> 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 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.


References This document refers to: SAP Notes 1467969 SAP Java Connector Release 3.0.6 1438660 Loss of tRFCs and IDocs with JCo 3.0.3 and 3.0.4 1405464 SAP Java Connector Release 3.0.4 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (4) 1467969 SAP Java Connector Release 3.0.6 1405464 SAP Java Connector Release 3.0.4 1275665 Business Connector 4.8 Service Release 7 (SR7) 1438660 Loss of tRFCs and IDocs with JCo 3.0.3 and 3.0.4

SAP Note


Validity: 23.12.2009 -




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 qRFC, z/OS, conversion

Reason and Prerequisites The problems above have been caused by the following bugs in JCo 3.0.3: 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 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. Read the release notes for more information.

Validity Software Component From Rel. To Rel. And Subsequent SAP JCO 3.0 3.0 SAP_BASIS 720 720

References This document refers to: SAP Notes 1438294 SAP Java Connector Release 3.0.5 1406061 z/OS: JCo 3.0.3: ERROR hostname unknown 1385673 SAP Java Connector Release 3.0.3 1375494 SAP system does not start after applying SAP kernel patch 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (4) 1385673 SAP Java Connector Release 3.0.3 1406061 z/OS: JCo 3.0.3: ERROR hostname unknown 1275665 Business Connector 4.8 Service Release 7 (SR7) 1438294 SAP Java Connector Release 3.0.5

SAP Note

1385673 - SAP Java Connector Release 3.0.3 Version 1 - active

Validity: 15.09.2009




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 NullPointerException, StackOverflowError,

Reason and Prerequisites The problems above have been caused by the following bugs in JCo 3.0.2:

1. There were some prerequisites: The JCoServer configuration had been updated within a ServerDataProvider that did not 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 JCo 3.0.3. 1. The inconsistency in the JCoServer management has been removed. 2. If an excetion 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. Read the release notes for more information.


References This document refers to: SAP Notes 1405464 SAP Java Connector Release 3.0.4 1388694 Hanging connections to JCo 1358698 JCo cuts off last field of a structure or table

1310832 SAP Java Connector Release 3.0.2 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (4) 1388694 Hanging connections to JCo 1405464 SAP Java Connector Release 3.0.4 1275665 Business Connector 4.8 Service Release 7 (SR7) 1310832 SAP Java Connector Release 3.0.2

SAP Note






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..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 vector, session management, BCD, stateful, logon failure,

Reason and Prerequisites The problems above have been caused by the following bugs in JCo 3.0.1: 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 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 JCo 3.0.2. 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 ing the value to the parse 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. Read the release notes for more information.


References This document refers to: SAP Notes 1385673 SAP Java Connector Release 3.0.3 1312880 Security Note: clear text in trace file 1298438 Hanging JCo threads 1264236 SAP Java Connector Release 3.0.1 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (5) 1385673 SAP Java Connector Release 3.0.3 1264236 SAP Java Connector Release 3.0.1 1275665 Business Connector 4.8 Service Release 7 (SR7) 1298438 Hanging JCo threads 1312880 Security Note: clear text in trace file

SAP Note






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: IC-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 SAP GUI, Popup, ArrayIndexOutOfBoundsException, BCD, packed, connection leak, stateful, BCD_BADDATA

Reason and Prerequisites 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 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 IC 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 JCo 3.0.1. 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 IC layer has been removed. 6. The connection leak has been removed. Read the release notes for more information. Moreover, new platforms are now ed 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 in note 1077727.

Validity

Software Component From Rel. To Rel. And Subsequent SAP JCO 3.0 3.0

References This document refers to: SAP Notes 1310832 SAP Java Connector Release 3.0.2 1258724 Starting SAPGUI using external RFC libraries 1252962 ArrayIndexOutOfBoundsException when opening a connection 1077727 SAP JCo 3.0 release and strategy

This document is referenced by: SAP Notes (4) 1252962 ArrayIndexOutOfBoundsException when opening a connection 1258724 Starting SAPGUI using external RFC libraries 1275665 Business Connector 4.8 Service Release 7 (SR7) 1310832 SAP Java Connector Release 3.0.2

SAP Note

1077727 - SAP JCo 3.0 release and strategy Version 27 Validity: 30.04.2014 - active


Header Data Released On Release Status Component Other Components Priority

01.05.2014 05:21:09 Released for Customer BC-MID-CON-JCO Java-Connector

BC-MID-BUS Business Connector Recommendations / Additional Info

Category

Release planning information

Symptom ed platforms and JDKs for the SAP Java Connector 3.0 (SAP JCo 3.0).

Other SAP Java Connector, JCo, SAPJCO, sapjco3.jar, JCo3, life cycle, , version, release, patch level, SAP Service Marketplace, SMP

Reason and Prerequisites 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 ed 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 features and it is also not subject to the end-of-maintenance restrictions of the JVMs of other vendors. The end of maintenance and 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 ed and available for via the SAP Service Marketplace at http://service.sap.com/connectors -> SAP Java Connector -> Tools & Services -> 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 ed 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]

The JCo 3.0 release is ed for the following operating systems in combination with the SAP JVM 6 or the Java 6 Standard Edition of the corresponding platform vendor [mentioned in brackets]: Windows x86 32bit (Versions: Windows Server 2003, Windows Server 2008, Windows XP, Windows Vista, Windows 7, Windows 8) [Oracle JSE 1.6.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.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 x86 64bit (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]

The JCo 3.0 release is ed for the following operating systems in combination with the 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] Windows x64 64bit (Versions: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 7, Windows 8) [Oracle JSE 1.7.0] Linux x86 32bit (Versions: SuSE SLES10, SuSE SLES11, RedHat EL5, RedHat EL6) [IBM or Oracle JSE 1.7.0] Linux x86 64bit (Versions: SuSE SLES10, SuSE SLES11, RedHat EL5, RedHat EL6) [IBM or 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 s 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 ing and using other JCE providers

exclusively.


References This document refers to: SAP Notes 1919773 SAP Java Connector Release 3.0.11 1900587 SAP Java IDoc Class Library Release 3.0.10 1877907 of extern-to-extern RFC communication with JCo 3.0 1663178 New prerequisites for SAP JVM 5.1 and 6.1 on AIX 1375494 SAP system does not start after applying SAP kernel patch 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 strategy

This document is referenced by: SAP Notes (28) 1671480 SAP Java Connector Release 3.0.9 1425520 Disable NI cache for host and service names 1681565 SAP Java Connector 3.0 Hotfix installation 1557856 SAP Java IDoc Class Library Version 3.0.6 1438294 SAP Java Connector Release 3.0.5 1310832 SAP Java Connector Release 3.0.2 1278181 Usage of CTS+ Command Line Tool (Export) 1877907 of extern-to-extern RFC communication with JCo 3.0 2026482 SAP Java IDoc Class Library Release 3.0.11 1375494 1748457 2032963 1752456 1900587

SAP system does not start after applying SAP kernel patch SAP Java Connector Release 3.0.10 DB2-z/OS: Recommended Java SDK for z/OS SAP Java IDoc Class Library 3.0 Hotfix installation SAP Java IDoc Class Library Release 3.0.10

549268 1567669 1572431 1582525 1467969 1385673 1388694 1643299 1855836 1253440 1405464 1264236 1269638 1919773

SAP JCo 2.x release and strategy SAP Java IDoc Class Library Release 3.0.7 SAP Java Connector Release 3.0.7 CTS+ Integration for SBOP PC MS 7.5 and 10.0 SAP Java Connector Release 3.0.6 SAP Java Connector Release 3.0.3 Hanging connections to JCo SAP Java Connector Release 3.0.8 SAP Java IDoc Class Library Release 3.0.9 SAP JCo on z/OS SAP Java Connector Release 3.0.4 SAP Java Connector Release 3.0.1 Setting up the different Java JVMs for JCo3 on IBM i SAP Java Connector Release 3.0.11

Multiprint Sapnotes 2k3p2m

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Multiprint Sapnotes 2k3p2m

More Documents from "Positive Pause" 5r4a7

Multiprint Sapnotes 2k3p2m

Wowza Playlist Generator 1w3bh

Trademark Ppt 6n96w

Brochure - Amjad Khan Boxing Foundation 344g61

Common Transaction Slip l1u22

Contoh Pengisian (pt) Catatan Perkembangan Pasien Terintegrasi 3v4j15