MultiValue Tools

ROCKETEER Peter Schellenbach posted 04-29-2024 13:21

Hi Joe - 

I just installed 7.3a on my laptop, then installed the host programs into a new account on Universe 11.3.4 on Centos 7.8. No script errors, and wED runs fine.

The error you are seeing, "A request to the MultiValue database server is pending", is entirely on the Windows end of things, nothing to do with Universe. wED uses COM to communicate with the Universe server, and somewhere in the chain of COM components, something is stuck. I have seen this happen occasionally, but never was able to pin down the exact cause. Could be timing or permissions or invalid registration. I would uninstall AccuTerm, reboot, reinstall AccuTerm and reboot again, just to make sure registration is correct and hopefully if any permissions were invalid, they will also be corrected.

Thanks, Pete

Joe Goldthwaite posted 04-29-2024 14:55

I uninstalled atwin73a and made sure everything was gone including registry entries.  When I fire it back up I get the message to enter the activation code.  So far so good.

The problem I have now is that my CD key for AccuTerm 7 doesn't work for 7.3a. I must have had it at some point but I can't find it anywhere. Is there any way you could send me my authorization key to my personal email?

Brian Speirs posted 04-29-2024 15:38

I have had some issue in the past after a new install ... but they were a long time ago, and I can't remember the exact symptoms.

However, the fix was simple. I simply ran the command:    CATALOG FTBP *     in each account that used any of the AccuTerm programs (same for GUIBP etc). Essentially, this replaces the program pointers installed by AccuTerm with the native pointers used by whatever MVDB you are using.

You might want to check the format of that command to use your preferred style of cataloguing.

That might not be the answer in this case - but it is worth a try.

Cheers,

Brian

Joe Goldthwaite posted 05-02-2024 23:00

This gets stranger and stranger. I had hoped that I would be the only one having the problem, but other people connecting to this new machine are experiencing it too. I've done some more testing and found some additional points. The problem occurs on both Telnet and SSH. I was able to duplicate it because some files cause the issue every time they are opened, while others do not.

The problem is independent of the terminal type. Once it happens, AccuTerm is locked up until the terminal is reset. Resetting the connection doesn't fix it. It has to be the terminal.

Since I was able to duplicate the problem with Telnet, I fired up Wireshark to see what the host was sending compared to what the working machine was sending. I could see WED talking to the host and then start sending the file. On the working machine, the entire file was sent. On the problem machine, it only got partway through the file and then just stopped sending anything.

Now it gets even stranger. It seemed like I was having the problem with large files. Small files were working more reliably. To test that, I wrote a program that would create a string of X's for any input size, write it to a test file, and then use WED to edit it. I kept trying different file sizes until I found the cutoff. I could open an item that was 7911 bytes or less. Anything 7812 bytes or higher locks up. I did another test where I took the program that I had been testing and did the same thing by sending the first ### bytes. I thought the number would be the same, but with the program, the cutoff was 7317 bytes. All tests from 7318 bytes forward failed.

It's possible the issue might be with the network settings. Tomorrow, I'm going to have the VMware admin check the virtual hardware for differences between the machines.

I'm hoping that this will ring a bell for someone who understands networks and could point me in a direction.

I have the Wireshark captures if anyone would like to take a look at them.

Thanks, Pete and Brian, for your helpful posts. It's appreciated.

P.S. This is a dealbreaker for some of our developers who absolutely, positively do not want to learn ED.

Brian Speirs posted 05-02-2024 23:22

Ouch!

I hate to suggest it, but is VSCODE an option? There was a release of AT7 that allowed this (I think it was 7.4 - which I don't have a copy of). Pete can verify this.

We moved to AT8 a couple of years ago, where VSCODE is definitely supported. It starts a REST server in the background to deal with the data transfer - so that may get around your transfer issues.

Personally, I much prefer using WED. I really don't like waiting 35 seconds for an editor to start up ... and then have to mark the created workspace as "Trusted" before I can start working.

Cheers,

Brian

Joe Goldthwaite posted 05-03-2024 10:28

Here's something new.  I started thinking that it was strange that I have to reset the terminal to get things working after I stop Server Mode. I figured that if resetting AccuTerm gets it working again, how can it be the network? This morning I got it locked up and then killed the Universe process from a different terminal. Then I got this error:

H0041ERR: -123 Packet size error!0000002824934

That's coming from AccuTerm going to the Centos Box.  Based on the wireshark trace I think the network is sending a malformed packet and the error trapping in AccuTerm is putting it into some kind of state where it stops functioning. That doesn't happen every time I kill the process. Sometimes AccuTerm stays locked  up until I reset the terminal.

I think I've got a network configuration issue on this box and it's hitting an error processing bug on the AccuTerm side. 

Hi Brian,

I don't have a copy of AccuTerm 7.4 either so I can't directly switch to VSCode. The programs are shared on the network so they can be edited that way. You lose the ability to recompile from the editor and like you, I prefer WED.  The problem for the non ED developers is that you have to often have to edit database records or dictionaries that are not shared over the network.

I don't like VSCode. I use it all the time but I really don't like it.  I tried to not use it but you can't get away from it any more. At least it's slowly killing Microsoft Visual Studio. I hate that monstrosity even more. It amazing how they took the simple effective tool that was VB6 and turned it into something requiring a college class to learn to use!

Bill Brutzman posted 05-03-2024 10:46

I thought that UniVerse was certified on certain Operating Systems.   As UniVerse is a major-league (enterprise) proprietary dataBase having staggering complexity and sophistication.    Why not leave the rocket science to Rocket?

Joe Goldthwaite posted 05-03-2024 11:02

Hi Bill,

I'm not on the contact list for Rocket. In general I trust  the community of developers more than a company's tech support team. The first is made up of experts with a vast array of experience. The second  tends to be smaller with more limited knowledge. That's not to say they can't be very good. It's just hard to compete with a much larger team.

Joe G.

ROCKETEER Peter Schellenbach posted 05-03-2024 11:50

Joe - are you connecting to a current, fully patched, version of Universe? A long time ago (10 years?) we encountered a bug in Universe which behaved much like you describe. It was somehow related to using an INPUTCLEAR statement in BASIC, which AccuTerm's host programs use. I'd have to dig into my archives to find the UV release that has the issue and the patch that fixes it. In the mean time, you might search FTBP for INPUTCLEAR and comment it out and recompile the FTBP programs. Use "RUN FTBP FTCHK" to recompile everything. Be sure to disconnect and test from a new session.

While AccuTerm does support VSCode as an alternative to wED, the connector uses common subroutines in the host programs so would likely have the same problem.

Thanks, Pete