Could we reboot this project?

Topics: Developer Forum, Project Management Forum
Developer
Aug 7, 2013 at 8:30 PM
There still seems to be a lot of life in big iron computing, so I can see this library being helpful to developers for some years to come. Let's face facts: the original coders are nowhere to be found, and there are few coders out there familiar enough with the 3270 protocol to be very helpful. It's even hard for us to debug problems found by other users of Open3270 because that requires access to others' mainframes. Sure can't let just anyone poke around in there! So, we're largely on our own to fix problems we encounter.
It took me a while to figure out how to fix the "sense 00004002" bug, and part of what slowed the process was trying to decipher the project's source code. The OpenTN3270 code currently works like a charm, but it looks like a bag of shit.
  1. One out of every six lines of code has some sort of code tidbit commented out without explanation. What the hell does "BUGBUG" mean? Does a bug exist there or was one fixed in that location?
  2. Variables and methods have unhelpful names. They're often single letters or needlessly abbreviated to the point that only a Telnet expert would know what their meaning is. It's like the code has already gone through an obfuscator.
  3. Few methods' function are documented, and the context gives little clue as to what they are intended to do (see number 2).
  4. There are classes with upwards of 4,000 lines of code. WTF? Who needs design or architecture?
  5. Everything is coded in an inconsistent, messy, old-fashioned C style. There are more underscores than numbers in the code. Needlessly public fields are everywhere. ALL_CAPS abound for method names (No, we don't have macros in C#). The rest of the method names aren't capitalized. There's no need to keep lines to 80 columns anymore, either, unless you're using a terminal version of Visual Studio or coding on a screen with the resolution of a Gameboy. It hasn't been 1993 for a long time. Nothing is organized spatially. Essentially, crap is just strewn everywhere.
  6. What's with all these branches? Doesn't anyone ever merge back into main?
I'm independently cleaning everything up and fixing what I have the knowledge to fix. I've spent a few days trying to just bring this project into the current era in terms of readability, and I've only gotten two ginormous classes cleaned up to the point where they are fairly usable. They still have 3,000 lines of code each, though, because I've only just started to break them into multiple classes. I really think it would behoove the project to completely trash everything in source control and start out fresh with a clean start. I'd love to upload my codebase with the hope that it could jump start more improvements. Perhaps those who have had trouble in the past would give it another shot and potentially be better positioned to investigate and fix the problems they encounter.
Thoughts?

Josh Usovsky
Coordinator
Aug 8, 2013 at 9:13 AM
Skwerl, I've given you permissions to commit code changes. so please feel free to take this project forward. I don't have access to a TN3270 server anymore.

That said, the latest revision of the code is buggy, because of my attempts to pull in different patches that were floating around in these forums. Please inspect the SVN history. You'll see the different branches (patches from different users). The code worked BEFORE I started committing the patches. The code worked for each branch. It's only after I merged the branches back into trunk that the code started getting buggy, so I assume that there were some changes that conflicted. Retracing my steps would probably be the best way to debug the biggest bugs, instead of trying to debug them from scratch.

Once I get access to a server again, I'll start helping out again.

Francois Botha
Coordinator
Aug 8, 2013 at 9:23 AM
Skwerl wrote:
There still seems to be a lot of life in big iron computing, so I can see this library being helpful to developers for some years to come. Let's face facts: the original coders are nowhere to be found, and there are few coders out there familiar enough with the 3270 protocol to be very helpful. It's even hard for us to debug problems found by other users of Open3270 because that requires access to others' mainframes. Sure can't let just anyone poke around in there! So, we're largely on our own to fix problems we encounter.
It took me a while to figure out how to fix the "sense 00004002" bug, and part of what slowed the process was trying to decipher the project's source code. The OpenTN3270 code currently works like a charm, but it looks like a bag of shit.
  1. One out of every six lines of code has some sort of code tidbit commented out without explanation. What the hell does "BUGBUG" mean? Does a bug exist there or was one fixed in that location?
  2. Variables and methods have unhelpful names. They're often single letters or needlessly abbreviated to the point that only a Telnet expert would know what their meaning is. It's like the code has already gone through an obfuscator.
  3. Few methods' function are documented, and the context gives little clue as to what they are intended to do (see number 2).
  4. There are classes with upwards of 4,000 lines of code. WTF? Who needs design or architecture?
  5. Everything is coded in an inconsistent, messy, old-fashioned C style. There are more underscores than numbers in the code. Needlessly public fields are everywhere. ALL_CAPS abound for method names (No, we don't have macros in C#). The rest of the method names aren't capitalized. There's no need to keep lines to 80 columns anymore, either, unless you're using a terminal version of Visual Studio or coding on a screen with the resolution of a Gameboy. It hasn't been 1993 for a long time. Nothing is organized spatially. Essentially, crap is just strewn everywhere.
  6. What's with all these branches? Doesn't anyone ever merge back into main?
I'm independently cleaning everything up and fixing what I have the knowledge to fix. I've spent a few days trying to just bring this project into the current era in terms of readability, and I've only gotten two ginormous classes cleaned up to the point where they are fairly usable. They still have 3,000 lines of code each, though, because I've only just started to break them into multiple classes. I really think it would behoove the project to completely trash everything in source control and start out fresh with a clean start. I'd love to upload my codebase with the hope that it could jump start more improvements. Perhaps those who have had trouble in the past would give it another shot and potentially be better positioned to investigate and fix the problems they encounter.
Thoughts?

Josh Usovsky
To help with your questions, this library was ported from the x3270 C project. Not by me, but by one of the previous developers. That explains the naming convention and big class files. After the port was fairly stable, the project was pretty much abandoned, but there were still some bugs. Many users submitted patches here in the forums (a lot of them by Chris Coulter, for example). I managed to get hold of the previous coordinator and got commit access, and as explained above, tried to merge the patches into the code systematically. That explains the many branches. But yes, they are merged back into trunk, although that created another bug, which is yet to be solved.
Developer
Aug 8, 2013 at 3:59 PM
Ah, so this was a C port. That makes a lot of sense and explains most of the things that had me scratching my head and pulling out my hair.
I understand the difficulties of merging in a bunch of changes from disparate branches. Perhaps there could be only a single branch that users can add changes to. We could merge code changes in frequently from that branch after reviewing and prevent the situation of having too many simultaneous branches. What bug was it that you are referring to, specifically? Is it the "sense 4002" one?

Thanks so much for commit rights, Francois. I'll start checking in changes ASAP.

Josh Usovsky
Coordinator
Aug 12, 2013 at 9:30 AM
The many branches were only a temporary thing for me to organise the many patches. It wasn't meant to be used in the future. The branches have been merged back into trunk, so, except for debugging the new bugs that were created with the merge, I think you can ignore them going forward and focus on trunk only.
Developer
Aug 12, 2013 at 3:32 PM
Thank you, Francois. That's what it looked like to me, too, so I am glad to hear that.
I've made a handful of check-ins over the past few days. I've done an initial light refactoring pass on the largest classes and added a WPF demo application. Hopefully that will help give folks an additional jump start along with the original console sample. In the coming days, I will be continuing to update and clean-up on the rest of the classes before moving on to larger refactoring, like breaking the big guys into smaller classes.
In the meantime, stability it still quite good, but I have found one race condition that occasionally shows up, and the Erase command has a problem. I'll jump on fixing those shortly as well.

Josh Usovsky