Activity for John Eberhard
-
John Eberhard posted a comment on ticket #454
"setTcpNoDelay" is a data source method. In the URL, you should use "tcp no delay=true" in the URL.
-
Error on connection with password blank (not null) on version 11.2
-
Support for CCSID 65535 for Data Translation - JT400 jar ver 10.7
-
Extremely slow queries filtering with date 0001-01-01
-
This project has moved to github: https://github.com/IBM/JTOpen If the below information does not help, please report the problem there. It looks like you need to configure your connection to use date format ISO to correctly process the 0001-01-01 date. Here is an example of the behavior without the date format setting and with the date format setting. ~> java -jar jt400.jar "jdbc:as400:$SYSTEM" $USERID $PASSWORD >select date('0001-01-01') from sysibm.sysdummy1 00001 null *** Warning *** SQLState:...
-
Yes, it should be in JTOpen 11.0 Fixes and enhancements in JTOpen 11.0 released 2022-04-13 ... JDBC: Add connection property: tcp no delay
-
jdbcClient: Handle char type for reflective method call
-
JDBC:Internal Password Changes
-
JDBC:Internal Password Changes
-
The latest version of JTOpen should be compatible with all versions of "IBM i", as nothing is purposely changed to break backward compatibility. However, only the versions of "IBM i" that are currently in service are regularly tested and officially supported.
-
Performance Issues due to Packet Size
-
It looks like the application is requesting that auto generated keys are to be returned by the insert statement. The JTOpen 5.4 driver did not always correctly return generated keys. If generated keys are not retrieved by the application, can the prepare of the insert statement be changed to not request generated keys? In the JTOpen 5.4 driver the inserts are batched. In the recent drivers, the inserts cannot be batched because the return of auto generated keys was requested. Details: Tracepoint...
-
JDBC:Internal Password Changes
-
Can you provide traces of running with the old driver and the new driver so that I can compare them? Can you also use toolbox trace=all?
-
Clear sensitive data from memory
-
Refactor SignonConverter
-
JDBC: XADataSource interfaces for char[] password
-
JDBC: Rowset interfaces for char[] password
-
You'll need to contact liberty / websphere support to make the changes outlined above.
-
The JTOpen JDBCDataSources were changed to add a setPassword(char[]) method. The old setPassword(String) method was deprecated. This is because putting a password in a String is insecure, as the JVM may cache the string -- thus exposing the password if the process memory is dumped or if the JVM is dumped. It looks like com.ibm.ws.jdbc.internal.JDBCDriverService.setProperty method is confused and is trying to use the setPassword(char[]) method instead of the setPassword(String) method. It is trying...
-
Performance Issues due to Packet Size
-
Try setting the block size property "block size" Specifies the block size (in kilobytes) to retrieve from the system and cache on the client. This property has no effect unless the "block criteria" property is non-zero. Larger block sizes reduce the frequency of communication to the system, and therefore may increase performance. https://jt400.sourceforge.net/doc/com/ibm/as400/access/doc-files/JDBCProperties.html
-
JT400 - libraries LIST
-
Sorry, there is nothing that can be done. I suspect dbeaver is using the database metadata API's to request the list of the schemas on the database. The system is returning the list because there are a lot of schemas on the system.
-
Parameters are cut off in prepared statement
-
This is working as designed. Since the parameter is a CHAR(2) the driver is only able to send a CHAR(2) as the parameter. The parameter is truncated to Vi which then matches the value in the column. To avoid this problem, you can use the "query replace truncated parameter" connection property, which does the following. Specifies the value that should be used in place of a truncated parameter of an SQL query. By default, the parameter is silently truncated to the length for the parameter. Consider...
-
JDBC: Permit cancel when using seamless failover
-
JDBC: Permit cancel when using seamless failover
-
Deprecate interfaces where password passed as a String
-
Deprecate interfaces where password passed as a String
-
Deprecate interfaces where password passed as a String
-
Deprecate interfaces where password passed as a String
-
Deprecate interfaces where password passed as a String
-
Provide a custom 'SSLSocketFactory'
-
Refresh token and timeouts
-
Missing native implementation of AS400Credential
-
You need to use the jt400Native.jar file that is shipped on the system. It is available in the following locations. /qibm/proddata/os400/jt400/lib/java6/jt400Native.jar /qibm/proddata/os400/jt400/lib/java8/jt400Native.jar /qibm/proddata/os400/jt400/lib/java9/jt400Native.jar /qibm/proddata/os400/jt400/lib/jt400Native.jar When using the swap support, you need to make sure your application is single-threaded, as the swap function applies to the entire job (not just the current thread).
-
ServiceProgramCall 7 Parameters maximum
-
One more thing. You should not be defining os.name when starting the JVM, as that will produce the behavior you are seeing. $ /QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -Dos.name=OS/400 -jar /qibm/proddata/os400/jt400/lib/java9/jt400.jar jdbc:as400:localhost $USERID $PASSWORD java.lang.NullPointerException at com.ibm.as400.access.PortMapper.getServerSocket(PortMapper.java:143) at com.ibm.as400.access.PortMapper.getServerSocket(PortMapper.java:129) at com.ibm.as400.access.AS400ImplRemote.signonConnect(AS400ImplRemote.java:3390)...
-
JDBC: Close network socket on error
-
JDBC: Update trace to include system name with RDB name
-
JDBC: javadoc updates
-
JDBC: ConnectionPool do not error if setThreadUsed does not change setting
-
The fix will be in the next release, which is currently under test.
-
JT400 SQL Query Latency on Windows Server 2019 or 2022
-
I suspect the problem is that windows uses the nagle algorithm to reduce network load. This causes TCP/IP requests to be delayed -- hoping for a buffer to fill up. See bug 454 for more information.
-
Error: No suitable driver found for jdbc:as400:....
-
This is working as expected. The pre-jdk6 jar does not have support for the autoloading the the JDBC driver. For that jar, you need to use the older JDBC convention of using Class.forName to load the JDBC driver. For autoloading to work, you use to use a jar file for jdk6 or later.
-
Add constructor AS400JDBCConnectionPoolDataSource(AS400)
-
JDBC: Handle SQL7061 reason code 80 as blocked mirror system
-
JDBC: Support LocalTime,LocalDate,LocalDateTime
-
Change AS400JDBCStatement.toString() to return the query instead of name
-
Sorry, that is not possible. The method is already defined as follows. public java.lang.String toString() Returns the statement name. The statement name could be used in other ways by other applications, so making the change could break other applications.
-
I do see those time changes in JDBC 4.2. I'm not sure how they were missed. There will be the assumption that milliseconds will be lost when converting from LocalTime to SQLTIME. The timezone ones may not be possible. From JDBC 4.2 spec at https://download.oracle.com/otndocs/jcp/jdbc-4_2-mrel2-spec/ Additional Mappings to Table B-4, Mapping from Java Object to JDBC Types Added support to map java.time.LocalDate to JDBC DATE. Added support to map java.time.LocalTime to JDBC TIME Added support to map...
-
Java 8 Time API - PreparedStatement setObject
-
LocalDate is not supported. It looks like it can be converted to a String, then the string can be used. LocalTime is not supported. The problem is that the local time could have a minisecond component which would not be supported. You can try converting LocalTime to a String, but that would probably only work if the result looks like HH:MM:SS.
-
JDBC: Add connection property: tcp no delay
-
Problems with DatabaseMetaData.getColumns() with columns names included lower cases
-
Add new JDBC Property
-
"tcp no delay" has been added as a JDBC connection property. The fix is available in SVN and will be included in the next JTOpen release.
-
JDBC: Add connection property: tcp no delay
-
Include original exception in thrown exception
-
Driver does not support get/set network timeout for connections
-
The get/set network timeout does not work using a threaded server. If the network timeout was actually used, early versions of the jt400 driver would not behave correctly. To prevent this problem, later version of the driver detect that a threaded server is being used and disallows those method. The change was made in JTOpen 10.4 Fixes and enhancements in JTOpen 10.4 (released 2020-06-30) JDBC: setNetworkTimeout not supported when "thread used=true" To use network timeout, you need to set the following...
-
FTP should send \r\n when logging in
-
FTP should send \r\n when logging in
-
jt400 AS400 class problem with system property os.version when working with OpenJDK 11 on IBM i
-
Are you manually setting os.name to OS/400? I believe os.name should be OS400 for Open JDK. If os.name is OS400, then you will not be going into this branch of the code. Native method support for OpenJDK is not available, so a userid and password must always be supplied when using OpenJDK.
-
By definition void setQueryTimeout(int seconds) throws SQLException Sets the number of seconds the driver will wait for a Statement object to execute to the given number of seconds. By default there is no limit on the amount of time allowed for a running statement to complete. If the limit is exceeded, an SQLTimeoutException is thrown. A JDBC driver must apply this limit to the execute, executeQuery and executeUpdate methods. In your case, the execute portion has completed and data is now being fetched...
-
As I mentioned above, the issue is on the IBM i where the system is not processing the cancel quickly enough. I would suspect a lot of processing is occurring below the TIMI and the cancel is not handled until that processing is completed.
-
JDBC: Report warnings from prepare
-
Misc: Code cleanup
-
Illegal AccessError in Graphical Toolkit with Java 9
-
The Graphical Toolkit (jui400.jar) is not part of the open source JTOpen. Only the binary jar file is included in the jtopen.zip file. You will need to contact IBM i service to get support for jui400.jar.
-
AS400FileRecordDescription.retrieveRecordFormat does not support CLOB types
-
JDBC: AS400JDBCArray fixes
-
Trace: Remove public read access from trace file
-
Jobs ELAPSED_CPU_PERCENT_USED discrepancy
-
Varchar parameter and pcml v7 support in ProgramCallDocument
-
Data type mismatch. (P#=1) testDataTruncation(AS400JDBCConnectionImpl.java:6141)
-
So, the problem is that when a parameter marker is used, then the JDBC driver has to convert the long value to the type of the parameter marker, in this case a NUMERIC(9). In this case, the number cannot be converted so an error is thrown. If it were to be converted to a different value, say just 999999999, it is then possible for the query to return a wrong answer. In your example, where the database does not throw an error, the database is converting both EXAMPLECOLUMN and 1234567890 to types that...
-
If the long value passed is > 999999999 then the exception is correct. A value larger than 999999999 cannot be converted to a NUMERIC(9). What is the long value being passed to setLong?
-
Can you provide a recreate with the column definitions and the value that is being set?
-
SequentialFile.setRecordFormat() fails on DDS BINCHAR
-
DatabaseMetaData.getTables returns Systemtables
-
The problem is the Q_ table isn't a "SYSTEM TABLE", it's a user table, but a temporary user table created by the system during the truncation operation. Your program that is looking at the tables needs to handle the case where a table is dropped between the time of the getTables call and the time that the program attempts to access the table.
-
One more thing. You should not be defining os.name when starting the JVM, as that will produce the behavior you are seeing. $ /QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -Dos.name=OS/400 -jar /qibm/proddata/os400/jt400/lib/java9/jt400.jar jdbc:as400:localhost eberhard tim8soup java.lang.NullPointerException at com.ibm.as400.access.PortMapper.getServerSocket(PortMapper.java:143) at com.ibm.as400.access.PortMapper.getServerSocket(PortMapper.java:129) at com.ibm.as400.access.AS400ImplRemote.signonConnect(AS400ImplRemote.java:3390)...
-
Are you passing a userid and password? Since the native optimizations are not available, you need to connect using a userid and password.
-
JDBC: AS400JDBCArray fixes
-
JDBC: Fix float array conversion
-
jt400.jar and Java 11 from IBM i OSS
-
The change of name is actually desirable. The problem is that the OSS JVM does not have support for ILE native methods. So, many of the native methods used by JTOpen are not available. JTOpen should still work, it will just act like any other client running on a standard JVM. It's just that native optimizations will not be available. I know the OSS team was going to look for a way to allow some native optimizations to work and they were planning on contributing those changes back.
-
[Info] client ILE debugger
-
Sorry, we don't have any idea how the ILE debugger works.
-
JDBC:Type conversion fixes
-
JDBC: ResultSet update method fixes
-
JDBC: ResultSet update method fixes
-
JDBC: jdbcClient array fixes
-
Build: PCML fixes
-
Build: Fix all8 target to not build base jt400.jar
1 >
