I noticed this problem with A-Shell 6.5.1631.2/libashmysql 1.4.141. It persists in A-Shell 6.5.1633.4/libashmysql 1.4.142. If I revert back to A-Shell
6.4.1556.0/libashmysql 1.4.141 it goes away.

In the following snippet all the columns fetch correctly except rec.cust'quantity. The actual statement contains 95 columns.
The actual value in the DB is rec.cust'quantity=1. But, it's fetched as 0

Here's a link to ashlog files for the broken and working versions with the SQLCONF_TRACE enabled. It also contains a .LSX of the program.

https://send.firefox.com/download/aee7da9f5a/#0E64CszAt0_NQv7jfAh0LQ

Ping

Sorry, wasn't ignoring it, just sounded complicated so was trying to get some simpler issues resolved first. I'll definitely get to it this afternoon.

That's fine, just making sure the email notification didn't fall through the cracks.

I haven't been able to reproduce this. I created a small test database with 405 fields, and executed a selection and fetch similar to yours, but all the retrieved values are good. (This was with 6.5.1633.1 and libashmysql 141 and 142).

There's nothing obviously special about that particular field in your select/fetch routine that isn't working. And other than the value of 0 vs 1, the traces for the two versions seem otherwise consistent. So it's hard to come up with an explanation of why one field out of 95 would come back with the wrong value. Particularly when all 405 of the fields in my test seem to read and write correctly.

You say that you noticed it in 6.5.1631; do you know if it worked in an earlier 6.5, i.e. before the enhancement in 1630 to support fetching a row into an ordmap? Or before 1628 when the 128 parameter limit was removed?

Have you tried any variations of the SELECT statement, perhaps using the generic SQLTEST2 test program? (That is, does the problem only manifest when selecting 95 fields, or does it show up if you only select a couple of fields?)

Would it be practical to export a few records to a CSV file so that I could import them here to reproduce the issue?

It works in 1626.0, but does not in 6.5.1628.1.

I wasn't able to find any EL7 version between these two to test. It seems like that 1628.1 is the version it stops working correctly in.

We have a suite of ISAM/SQL audit/sync programs; which, as it sounds compares all records in an ISAM file to a DB table. Determining the records that are 'out of sync' needing UPDATE, INSERTS, and DELETES. The example program was just one I selected, but all of them are falsely reporting every record in the DB have something "out of sync" needing UPDATE.

If you can't reproduce this, I can let you connect to my laptop an debug. Unfortunately, I'm using my laptop today to do a Sales Demo, with the VM you'd be SSHing into.

The XCALL parameter infrastructure was substantially redesigned in 6.5.1628, so that makes sense as the place for the break. That, and the fact that it seems somewhat intermittent, at least in the sense of popping up in various places rather than systematically in the Nth parameter, gives me a couple of ideas on where to dig deeper. I'll give you an update on the investigation later today.

I think I may have found the issue. It was specific to certain floating point conversions used in the FETCHR_FIELDS variation of the SQLOP_FETCH_ROW operation. The patch involves updates of both the ashell executable (6.5.1634.4) and the libashmysql.so (1.4.143). I've posted beta versions for you to test under EL7 ...

ash-6.5.1634.4-el7.tz
libashmysql.so.1.4.143.el7.tz

There are a lot of permutations of the FETCH_ROW variations combined with database field types and application variable types to test, so it would be a good idea to run your audit/sync utility thoroughly!

The audit/sync program runs as expected.

Sounds like a wrap. I'll generate the other platform versions and post them to the regular download directories tomorrow.

Good, can you add "-upd" to the end of the EL7 file for consistency?

We have a "script" that creates update tarballs from your site, and it assumes "-upd" is in the filename.

Sorry, that was beta mistake. The official versions are now in the official dist/65dev/ subdirectories with their standardized names:

ash-6.5.1634.4-el7-upd.tz
ash-6.5.1634.4-el6-upd.tz
ash-6.5.1634.4-el5-upd.tz
ash-6.5.1634.4-w32-upd.zip
ash-6.5.1634.4-w32c-upd.zip
ash65notes.txt