Hi,

Does anyone have a working Centos 9/ATE combo? I tried this in 2022 and ATE failed to connect to Centos 9 as expected. I wasn't able to spend a lot of time trying anything as the server had to be working, so they changed the VM to Centos 8. Now they want to change to Centos 9 again for some Cyber Essentials thing.

Dom

Well... I happen to have such a thing! I'm not sure there's any particular issue on the ATE side, but there were a lot of issues on the CentOS 9 side, the largest of all being the painful pivot from 32 bit to 64 bit executables. (Your intrepid colleague Steve will hear more than he want about this topic next month at the Conference.) So this is still definitely a beta, but outside of FastCGI, I think it's all working. I suggest starting with a complete install:

ash-6.5.1741.1-el9-x86_64.bin

If you're having trouble connecting to it from ATE, you should probably start by grabbing the latest ashw32.exe from ash-6.5.1741.1-w32-upd.zip; if that doesn't resolve it we may need to look closer, but I didn't run into any particular issues other than making sure the sshd service was open.

A couple of important notes:

1) The installer will put all the executables in the /bin64 subdirectory, so you may need to adjust your PATH and/or startup commands. There's nothing stopping you from moving them to the /bin directory, but it seemed like good housekeeping to use a separate directory, especially if you end up wanting to run the 32 and 64 bit versions side by side.

2) Similarly, the library links will be installed in /usr/lib64 rather than /usr/lib. Here's how mine look in my latest test install. (Note that all of the 64 bit libraries have -el9-x86_64 suffixes.

3) The one application area that required adjustment for the 64 bit environment was the Excel library (aka AXL). The issue there is that the library uses 64 bit handles in the 64 bit environment. Previously we were storing those as B,4 variables; we had to switch to X,8 which unfortunately required a lot of adjustments since X acts like a string and so is not always a one-to-one replacement for B. I'm still looking at some issue there, so if you have any programs that use the API directory (libxl.bsi) or CSV2XL or PRTXLS, we may need another round to get that right.

4) One big advantage of the pivot to 64 bit is that Linux users can now use AXL to connect to SQL Server directly using the Microsoft ODBC connector, instead of having to use a Windows proxy (as you've been doing) or purchasing the third-party commercial ($$$) connector.

Let me know how it goes!

Not one to update to Centos 9 tomorrow then
I did try the 64/Ashell for a few minutes that Jack you installed on my Synology/NAS/CentOS Stream 8 and it very soon had issues...(so i left it one for a rainy day or a conference...)
one example:

Although there have been several SEGV issues found and fixed since that version I installed for you a few weeks back, it appears that there is still an issue with INIX. So thanks for the heads up! An update will be on the way shortly (for when you have nothing better to do).

Sure happy to give it a try again after the update...

Ok, there was a 64 bit-related bug in MX_USRIO (used within INIX.SBX) that was causing the negative status returned from a failed search to get converted to a large positive number, which then led to bad memory access when a subsequent call mistook it for a valid position with a module.

The fix is in 6.5.1741.2, available for various platforms here:

ash-6.5.1741.2-cs8-x86_64.tz
ash-6.5.1741.2-u20-x86_64.tz
ash-6.5.1741.2-el9-x86_64.tz
ash65notes.txt

Not to hijack this thread - (but i will )

Would it not make sense to start a new version of ashell that is compatible with 64bit OS?

(and go ahead and say that you are planning a in-person vote at the conference!)

Yes, it should be a separate thread, and yes, the pivot to the new version (7.0) is in the works. The version pivot though is not specific to the 32 vs 64 architecture. (One of the reasons for opting for 7.0 rather than 6.6 is to reduce the chance of confusion to whether "64" refers to a version or an architecture.)

I'm trying to get it done before the Conference, but I'd also like to get it stabilized somewhat first. And that's difficult to do while also doing a lot of experimentation in preparation for Conference topics, which has a tendency to reveal features that should be added. And then we have the sudden interest in new Linux platforms where 32 bit is becoming difficult or impossible to support. So as usual, there a lot of things swirling around in the mix.

sorry slow reply, took a few days off holiday, can confirm 1741.2 fixed the INIX / SEGV issue. - I shell try to continue using the 64 version.

No worries (some envy on my part perhaps). But thanks for the confirmation.

Sounds good Jack - and if your experience is anything like mine, when i am researching problem "A" i also seem to uncover problems "B" "C" and "D" which i wasn't even trying to fix in the first place!

Steve - thanks for paving the way to 9.0!

I can't say that happens to me very often. (Usually the unsought problem stack goes at least to "G" or "H".)

The UK has this "Cyber Essentials" program that is a security certification and Centos 8 Stream no longer qualifies as OSes must be supported and that ends 30/05/24.

Fortunately no one accesses our server directly from the internet, so the IT company has been able to work around the issue. Other customers might go for the same thing, so I am glad you (and Steve) are on the case.