Well, you're probably correct, but I've completely replaced those parts in the new code. I decided something drastic had to be done when while accessing the vendor support system I noticed that TSSO had been installed by someone else for some kind of test (which apparently failed). It had developed a number of problems that were not in the version that was updated (and tested) to run on 1.9 and 1.10. It was fairly obvious in going through the long list of issues that he made and looking at the dumps that even if I was to fix all of his issues that the code in it's current form will probably completely cease to function within the next few releases of z/OS. His list had problems co-existing with several CA products, and some other vendor products, most notably SAP, and while there weren't any "actual" IBM ones on the list, it's possible that they didn't even run HSM as part of their testing (I know I didn't) so your problem is more than likely related to the ones they ran into. Any way, I did develop work arounds for them but none of them included removing any of those routines. That doesn't mean your ideas won't work, just that I didn't think to do it that way. :)
TSSO is still a good example of some great old fashion coding techniques. Over the years I had referenced back to it many times to figure out how to do some Assembler function that I had not learned how to do yet, but for the most part it's no longer very advanced code. I didn't even bother to pull anything from the actual existing code because for the most part it's obsolete (and wrong). I sat down one day (actually probably more like a month) and flowed out what I thought TSSO "should" be doing, and when I finished I decided that I didn't even care if I was correct, because the new flow that I had made a lot more sense and left a lot more room for growth. Any way, when I decided to totally re-write TSSO a short while back, I figured that I could refer back to parts of the code if I got stumped, but found that the couple of times that I did try to do that was a waste of time. I didn't bother to even check most of the old stuff, because there are large portions that not only were no longer functional, but the code itself was misleading. You have to remember that this stuff was written back in the 70's and 80's and was based on code from the early 70's (maybe even late 60's), so trying to figure out why they did (or didn't do) something is really frustrating and I decided was a big waste of time. Back then, they had fiche to work from, and while we are OCO now, it's actually a lot easier to do things in a more "supported" way. Also many of the people who have worked on it over the years didn't always have the best foundation for Assembler programming, but they found a way to make it work, (or at least not abend :)) so the code kept getting more tangled up in itself. What I figured to do was replace everything except for the TSSO name, get rid of the static AOF table, (everything is now built dynamically at startup, and you can update after as well), and loaded into data space(s) and other message processing related datasets. There is now SysPlex support as well. Actually the only "required" static stuff I have at all now is the startup parms. Once the whole project is complete we are going to make it available for just a small maintenance fee. Hopefully that is acceptable to people, otherwise we'll probably just use it internally and at our client sites and give it a new name. This unfortunately was necessary because TSSO "sort of" competes with one part of our automation suite (SyzCMDZ of the SyzAUTO, SyzSPOOL and SyzCMDZ product suite) so I had to argue to get the okay internally to move forward on this project in the first place. Originally I wanted to "save the day" by merging some of the capabilities of TSSO into SyzCMDZ, but that was COMPLETELY nixed from the start because SyzCMDZ was not designed or marketed to be "always on and running" as TSSO is. If the idea of providing it that way doesn't fly, maybe I can still get them to agree to merge it into SyzCMDZ after all, it does have some pretty cool capabilities. The thinking is that the development and on-going maintenance has to be recovered and no source code will be released (sorry), just the REXX samples, ISPF and WEB interface API's (oh, did did I forget to mention that I added WEB access to TSSO?) Currently it only displays some stats, and the console messages and lets some commands be entered, but eventually I want to be able to display (my idea of) the complete operator console interface image with backspace etc. The display part (including backspace for up to 600 minutes (or 500,000 messages, whichever happens first)) seems to work fine, but I still have some bugs in the support for message formatting (highlight etc.), receiving commands and directing them to the proper node and I still haven't decided how many simultaneous users to support. The development code can support up to 10 users, and still perform message processing with very little overhead, but development and real life sometimes conflict. The more capabilities I add to it, the more apt I think people will be to want to use it, so 10 might not be a good number. On the other hand, adding support to handle variable numbers of users probably isn't realistic either since someone might actually think 500 users is reasonable. I'm still a ways from a fully completed project, but I wrote it to be modular so that I could develop and test it as I had time and the basic features that map to the old TSSO capabilities are already functional. I have set myself a goal for what capabilities will constitute be the Alpha release, and assuming no major problems (after all it is my coding talents involved here), a short Beta followed by Version 1 release. Then I have a LONG laundry list of features to add to succeeding releases. Eventually, I hope to stabilize the code and only add new features that are requested by users (if they make sense) and keep the code functional for future releases of z/OS. I'm writing the DEBUG code base into it, so I think that debugging over succeeding releases of z/OS will be much easier than even our current products. I'm sorry for the length of this post, but I figured that a lot of people (between the posts here and the 50 or so emails I got so far today (if you don't get an answer back from me to your personal email and you didn't get caught in my SPAM filter, please accept this post as my response) were interested in the developments that it was time to disclose my plans. Originally I was going to wait until I finished, but since this all came up I figured that I was close enough that the target was no longer moving (that much). I would really be interesting in hearing what you all have to say about these developments, good and bad. I already understand that there will be a subset (or maybe a superset) of people who will be enraged by my plan, but hopefully they will also understand that the options (at least mine) are limited with respect to the original TSSO (and the costs involved in fixing it) and that a re-write is not the best answer in this case. I decided that a complete re-engineer was called for, but if you disagree I'm willing to listen to what you have to say. I only ask that you say it here and not flame me with personal email. If you want to tell me what a great job you think I'm doing, then by all means, send all the personal email you want :). Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
