Good day -

I used to blame my pal Herman for posting questions that maybe i should know the answer to... but now i am just going to take my lumps alone.

Not sure i understand the usage of the _64 nomenclature on some of the RHEL 7.x packages.

Is 7.X default 64 bit? If not, why not? If yes, then why have some .tz that are 64 and some that are not?

What is the big advantage of using 64 bit?

Do all flavors of Centos & RHEL7 O/S support it? Is it reliant on the OS or CPU or Both? I am assuming CPUs are all 64 now but not sure about the bus/memory/etc.. Especially on our hosted servers which might all be virtual machines!

(i left room for you to reply to each question )

Herman would be proud of you (since these are actually reasonable questions).

The idea is that if there is no x86_64 suffix, then it's 32 bit. I've posted both 32 and 64 bit versions of the RHEL 7 (-el7) packages, so this is necessary to tell them apart.

No - the default remains 32 bit, at least for now. I'm not sure if there's a good answer to the why not? I guess one reason was to allow the smoothest possible transition to 7.0 (for those who care about such things) without having to deal with the possibility of needing install more packages. There is also the possibility of running into external libraries that we don't yet have 64 bit versions of (such as the FastCGI library libfcgi.a). Also, if you're using AXL, the fact that the DYNLIB interface used by the Fn'LibXL functions deals with pointers and handles forced us to make changes to the library that will require swapping libxl.bsi for libxl64.bsi and recompiling the affected programs. One final complication with the universal pivot to 64 bit is that we haven't even begun that transition on the Windows side. (Not that there's any conflict or connection between 32 bit ATE and 64 bit A-Shell/Linux.) The problem with Windows is just that we have so many more external libraries that need to be dealt, and in some cases replaced entirely if 64 bit versions do not exist.

Probably none from the application standpoint. (ASB is effectively limited to 24 bit internal memory offsets, but already supports 64 bit disk offsets, so changing the internal architecture to 64 bit is not going to increase the maximum size of RUN or of disk files you can support.) It will theoretically allow you to allocate dynamic arrays exceeding 2GB, but as a practical matter, most Linux systems would be configured to prevent individual users from getting anywhere close to that (for resource sharing reasons). And I haven't been able to detect any significant performance differences, one way or the other. The main advantage is simply that, at least in the Linux world, 32 bit support is disappearing. I think it's already gone on the Debian / Ubuntu side. Also, given that all newer Linux platforms seem to target / assume / prefer 64 bit mode, having to deal with 32 bit libraries and packages adds a bit of a headache to the administrator's job. (In fact, even if the OS continues to support 32 bit, you may run into packages that are no longer being supported in 32 bit mode, possibly even introducing security problems if you can't update them.

Perhaps the single most significant practical advantage is that you can now use the Microsoft SQL Server ODBC connector for Linux (which is free, unlike the Easysoft connector which we previously had to use), removing the main hurdle preventing many Linux installations from connecting their A-Shell apps to SQL Server databases. (Of course that assumes the existence of one or more Windows servers with SQL Server on the network and IT or other data consumers at the workplace who can't understand why they can't just query your application data like they do other SQL data. But increasingly I'm finding that to be the case, at least in larger Linux sites.)

I think CentOS Stream 8 and RHEL9 plan to continue to support 32 and 64 bit for now. Debian/Ubuntu, as previously mentioned, have already dropped 32 bit support. If there are machines out there not capable of 64 bit, you wouldn't want to be using them for multi-user Linux installations! It's also hard to imagine any virtual machines which didn't support 64 bit. If that were the case, it would suggest a very old version badly in need of an update!

Evening Cap, thanks for the very well explained thesis!

So all things being equal - with the intent of "modernizing" and moving into the 21st century we should also bite the bullet and delve into the 64bit abyss. It would be good to ferret our any issues now then wait until something updates later and then find out there is no longer 32bit support.

We are still on RHEL7 (with the knowledge that we know that also needs to be updated in the near future - and will closely monitor the forum and contribute to ongoing discussions)

In the meantime we are planning to begin alpha-testing ashell 7.x for RHEL7. In the /dist area we will start with the latest .bin file and overlay the latest .tz. Would you recommend grabbing the latest 64bit tz in this case? Its a few revs behind the 32 bit flavor. (on a side note what a royal PITA for you to have to manage all these installs and NOW add a 64 bit variant!!! )

TIA

Actually, it's better to start your 64 bit experience with a proper -x86_64.bin complete install package, for the following reasons:

• You'll need the 64 bit libash* libraries that come with it.
• We decided to use $MIAME/bin64 intead of $MIAME/bin as the executable directory (mainly to allow both 32 and 64 bit versions to coexist but stay separated.

I'll post a proper bin package for -el7-x86_64 a bit later today.

Sounds good thank you!

Ok, here it is:

ash-7.0.1754.0-el7-x86_64.bin
ash70notes.txt

Thanks Cap.

Followup: Having some issues with the install - i will post here in case it helps anyone else or we can go offline of its better...

Got the following error messages - then noticed it says "CentOS Stream 8"... is it possible the wrong .bin would up in the /70rel folder?

Restoring A-Shell software
==========================

1. Make A-Shell subdirectories
2. Restore files from distribution....
Ensure diskette is loaded (or file ready), then press RETURN:
<processing> cpio: read error: Is a directory
tar (child): ash8exec.tz: Cannot open: No such file or directory <<<<<<<<<
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
3. Transfer run-time files....
[CentOS Stream 8 versions] <<<<<<<<<<
mv: cannot stat ‘ashell.el7’: No such file or directory
chown: cannot access ‘/hosting/edgemed/vm/miame/bin64/ashell’: No such file or directory
chgrp: cannot access ‘/hosting/edgemed/vm/miame/bin64/ashell’: No such file or directory
chmod: cannot access ‘/hosting/edgemed/vm/miame/bin64/ashell’: No such file or directory
chmod: cannot access ‘/hosting/edgemed/vm/miame/bin64/ashell’: No such file or directory
mv: cannot stat ‘pshell.el7’: No such file or directory
chown: cannot access ‘/hosting/edgemed/vm/miame/bin64/pshell’: No such file or directory
chgrp: cannot access ‘/hosting/edgemed/vm/miame/bin64/pshell’: No such file or directory
chmod: cannot access ‘/hosting/edgemed/vm/miame/bin64/pshell’: No such file or directory
mv: cannot stat ‘vue.el7’: No such file or directory

Something definitely not right there! I did actually test it, both before posting it and just now, and ... I don't get any errors (but you're right it does incorrectly say "CentOS Stream 8 versions"). That's a glitch I need to fix, but it shouldn't actually affect anything (it's just a hard-coded message in the script). So I think you have a different issue. Here's my complete screen output:

Restoring A-Shell software
==========================

1. Make A-Shell subdirectories
2. Restore files from distribution....
Ensure diskette is loaded (or file ready), then press RETURN:
<processing> 2598 blocks
3. Transfer run-time files....
[CentOS Stream 8 versions]
AM75G already defined to TERMINFO
WYSE50 already defined to TERMINFO
WYSE5G already defined to TERMINFO
Skipping TERMCAP update; AM75G already defined
Adding ASHLPR definition to ersatz.ini
ASHINC: ersatz already defined
Adding LIBXL definition to ersatz.ini
SOSFUNC: ersatz already defined
4. Transfer development files....

The A-Shell installation is now complete. You
will now need to do the following:
------------------------------------------------------------------
Add MIAME=/vm/miame1754
export MIAME to your profile environment
Add /vm/miame1754/bin64 to your path
Edit your MIAME.INI file (setup devices, use correct paths, etc.)

Note that where mine says "<processing> 2598 blocks", yours says: "<processing> cpio: read error: Is a directory". That leads me to wonder if there is some disconnect or glitch in the bin file that you downloaded (hopefully the same one you specified in the prompt for the installation Device.) The command that is generating the error is:
where $BINSPEC is the complete spec of the bin file that you entered. So you could try it again yourself, and if getting the same error, maybe compare that file to the one on the server.

Better yet, since I've uploaded a corrected version of the bin file (should now say CentOS 7 rather than Stream 8), and tested it a couple more times, try downloading it again. If still getting the error, let's see the actual command line you entered, as well as a ls -l on the bin file.

Good Friday -

Thanks for the update, that did the trick! We had to remember to point to the new /bin64 folder on our launch command (PSI for anyone following along to do this)

Not for the fun part...

OK having some immediate issues here and not sure if its 64/32 bit related or just 7.x

First question: We did install the 64bit bin file, and pointed the launch command to the /bin64 folder which does indeed launch the 64bit ashell (as it states in ver). However when attempting to go back to the 32bit 7.x ashell, it was still 6.5. I thought the idea was to bounce back and forth between the 32/64 bit flavors but apparently you are not including the 32 bit ashell with the bin? Are we now supposed to go back and install a 32 bit tz?

On the application side seeing some issues with xcall trim not working as advertised and click events locking up within tabx controls... after 2 or 3 clicks the programs become non-responsive. again not sure if its 32/64 related or not.

To clarify, the -x86_64.bin file has no 32 bit modules in it. If you want both versions installed, you need to run both installs separately (from the separate bin files). The 32 bit version installs the executables and libraries into the bin directory, while the 64 bit version installs them into the bin64 directory. But other than that (and the links from the /usr/lib and /usr/lib64 directories), they can share all the other /vm components. And you should even be able to run both architectures simultaneously.

On the XCALL TRIM issue, there could be something going on there, given that there was a considerable amount of tinkering with it as part of the issue discussed in this thread. But can you provide some details? The one issue that was a bit murky was whether TAB characters were considered "spaces" or not. In earlier versions, there was some inconsistency between the doc and the code, and even between the XCALL and function versions, with not all of them treating TAB same as space. Now it should be consistent (with TAB being treated as space) across TRIM, STRIP and EDIT (both the XCALL and function versions). If you were counting on the difference, we need to get to the bottom of that as soon as possible.

As for the click thing,that doesn't ring any bells. We probably need an example to work with.

Thanks for the feedback - just to clarify do you think we need a 32 bit flavor to play with or do you think the issues that i outlined above are purely part of ashell outside of the 64 bit flavor?

I will provide more insight on trim is a few...

While I don't think those particular issues should have any connection with 64 bit (especially since the click stuff is handled on the ATE side, so seems independent of the server architecture), it's hard to be absolutely certain. Since it doesn't take much to set up a sidecar 32 bit version, it might be worth getting that done up front so as to make it easy to test that question. In fact, I'd go one step further and rename your existing 6.5 bin directory to bin65 or binold, and then install the 7.0 32 bit version (into bin), allowing you to easily launch any of the three versions in question, all running the exact same application environment.

XCALL TRIM Fail example:

Code:
MAP1 A$,S,20
A$="ABCDEFG"+SPACE(20)
?"BEFORE:"
?LEN(A$),A$;"<"
?:?"AFTER:"
XCALL TRIM,A$
?LEN(A$),A$;"<"

Results:



seEems fairly cut and dry... suprised nobody saw this?

I'm surprised I didn't see it! I'm sure I tested that at one point, but then apparently tinkered with it again. It was the old off-by-one problem, triggered by a switch from pre- to post-decrementing a pointer, related to the ASB peculiarity of strings which don't necessarily have a trailing null. Anyway the fix is here:

ash-7.0.1754.1-el7-upd.tz
ash-7.0.1754.1-el7-x86_64-upd.tz

FOLLOWUP:

Tested both the above and the XCALL TRIM operation now works as advertised. ty.

Going to start a new question in next post below:

TABX Issue with 64bit ONLY:

Tested both recent 32/64 bit updates and can recreate the tabx and mouse click issue. After 2 or 3 successful clicks the mouse click event fails to register back to the code. This applies to tabx and clickable icons. I turned on a few traces and got this which might help:

1498 15:11:37 <TELNET:45e4> tab switching
1499 15:11:37 <TELNET:45e4> ProcessKBDClick: VK_xF70000 (mask:1)
1500 15:11:37 <TELNET:45e4> TABX switch canceled; VK_xF70000 sent; wait for app

Even using the accelerator keys do not work however an ESCAPE will register. Not sure any help there or not.

What does seem to be the case is that when the program his in the above "wait for app" mode that it is pretty much dead... no other click events will register. That should help.

I had this too with buttons under 64bit, I thought the latest version solved it so never reported it, but, no, still problem, they click but say no we on strike and do nothing still.

OHHH NOW A WARNING??!!!

When you refer to either 7.0 or 64 bit, are you talking about the server or ATE, or both? Clicking operations, and the traces you get when you open the System Message Window and activate, say, the ATE trace, are all ATE-side operations. Yet it almost sounds like you’re both saying it’s related to A-Shell version on the server?

Sorry not tried it again this week I not got buttons while being retro and decided to do programming on the am62a (not)

Yes think it’s server as toggling between two server versions of 32 /64 was enough to break or fix it.

And turning on the client-side ATE trace shows that the clicking stops doing anything?

From memory it stopped after ProcessKBDClick
But I’m not near PC to try it at mo, if only I could time travel back 5 hours in time and find myself in NC then I could show some extra traces for you.

Well it is Friday night, so you have my permission to sign out and go make trouble elsewhere!

Upgrading to 64bit Pints (they hold twice as much liquor)

(Actually 4 times as much!)

-- A-Shell 7.0.1754.1/64 Up and Running --

It does *NOT* work on the above flavor. Failing with 6.5 and 7.X versions of ATE.

It *DOES* work on the 32 bit version

PS: We should drag Steve back to the office for failing to report the above anamoly in a reasonable time!

Sorry to say but I'm not seeing what you guys are seeing. Does either one of you have an example program I can connect to via ATE?

I did a little digging this morning adding a few traces and from what I can tell or at least from this side of the pond its not exiting an INFLD when clicking on a button under 7.0.1753.2/64 this was under my home CentOS Stream 8, but Strangely no issues with Office Ubuntu 20.04 LTS and 7.0.1752.0/64 (slight ashell version variation) hence not really reporting the issues until I did some more investigation, so this may, may not be same as what Franks having.

Test 1

Linux: CentOS Stream 8
ATE: Version 6/5/1738.0
Ashell: Ashell 7.0.1753.2

Code Snippets:


Ashell 7.0.1753.2 exit INFLD with: INFLD'EXITCODE=-402


Test 2

Linux: CentOS Stream 8
ATE: Version 6/5/1738.0
Ashell: 7.0.1753.2/64

Same code as above but Ashell 7.0.1753.2/64 does not exit from INFLD by clicking any buttons.

BUT

Test 3

Linux: Ubuntu 20.04 LTS
ATE: Version 6/5/1738.0
Ashell: 7.0.1752.0/64


Strangely it works fine under 32 and 64.


Confused yet?

I disabled/deleted all OpenVPN to my NAS/CentOS I found OpenVPN just kept breaking things and it took too long every time to find then tweak the OpenVPN connection scripts to fix it, So I replaced it all with Tailscale.
If it helps I can send an invite to connect to my personal tailscale network, this then will allows you to ATE/Telnet straight on.

Good Monday Gents -

My experience is same as Steve. The click events dont register. This is under RHEL7 and 7.0.1754.1/64 and ATE 7.0.1753.3.

Jack - if you still have a working connection I can give you a recipe.

ps: and this is IMPORTANT - The click events work for the first 2 or 3 then Stop working! Definately an odd behavior.

Confused? Absolutely!

But: I did manage to turn your snippet into a working standalone program that suffers from the described problem in the CentOS Stream 8 platform running 7.0.1753.2/64 on the server with ATE 7.0.1753.3.

Presumably it is some kind of 32/64 bit overflow issue, although I haven't yet been able to pin it down. But I will ...

Happy hunting!

Ok, I think I tracked the problem down, at least on the CentOS Stream 8 platform. It was caused by an apparent inconsistency in sign extending the -1 INFLD funmap parameter value, such that the negative exitcodes were being ignored because the funmap bits were not all set. I've posted updates for -cs8 and -el7, but I was not actually able to reproduce the problem under the -el7 platform, so I'm not complete sure this is all of it. If not, then we may need to proceed to Plan B (connecting to your test system).

ash-7.0.1754.3-cs8-x86_64-upd.tz
ash-7.0.1754.3-el7-x86_64-upd.tz
ash70notes.txt

Morning,

A-Shell 7.0.1754.3/64 sure solve it this end on CentOS Stream 8 - Thanks!

Hey Cap - this also looks resolved in RHEL7. Good job!

I am not able to export to Excel using CSV2XL.SBX using 7.x:_64. See error messages below;

?Bad arg (type or size) passed to DYNLIB.SBR(arg #3)

?external library error at location counter &hC370 of csv2xl.sbx

See current SBX;

CSV2XL.SBX 234 636-343-207-462 2.1(286)

I think that issue was resolved in CSV2XL.SBX 2.2(291), included with 7.0.1750.2. Seems like it should have gotten updated by the 7.0 upgrade operation, but UPDCUR will also do the trick:

.LOG BAS:
.UPDCUR