Pat I'm looking at this from the point of view of an acceptable level of quality in the implementation of a function - an acceptable level for IBM, that is. I have deliberately stayed away from how it could be fixed because that is now very, very difficult. That's the problem with a botched design. Fixing up the botched description is easier and I have done it - and posted it. Although whether or not it - or something accurately like it - will see the light of day in the manual is another matter.
I'm so upset because I care about these matters. This one's a bit tricky since it's not really VTAM any more but why should the IP side of Communications Server have lower standards that the SNA side? Who knows, maybe the SNA side said that's a poor design, it should be something else - and - as you implied - the estimated cost of the proper implementation was considered too high - for one bit/(sub)operand in a macro, one test in the implementing logic and one more (sub)operand to describe in the manual? Then the "suits" on the IP side said "Do it anyway the simplest way and let's risk the customers having some existing text in their USS messages which matches a system symbol. Who uses ampersands concatenated to text anyway?." The "suits" may even have asked what the risks were. They may or may not have been told that system-defined system symbols were unlikely to be a risk but that installation-defined could be any 8 character name the customer systems programmer cared to dream up and that would be a perpetual risk.[1] Maybe an USS message 10 could have a company name and it may be part of the style of the company to express themselves as Hammond&Drew, for example - without spaces. What if the systems programmer at Hammond & Drew decided that he/she needed an installation-defined system symbol &DREW to represent the "Disaster Recovery" site at "East-West" corporation? Let's look at the more hidden possibilities that Martin highlighted since my basic premise is that this design just hasn't been thought through. It's a feature of 3270 data streams that all "constructed" characters, that is those made up from bits or the 6-bit value that is used to calculate the presentation space position have to part of the character set so that the business bits, 2 to 7, determine bits 0 and 1. Martin has already shown us how easily the SBA order second address byte could end up being one of the selection characters - although, HOSTNET apart - just about vanishingly unlikely. It's the system symbols selected by the system programmer up against a 3270 data stream order which could cause most havoc. The same applies to attribute bytes and I actually bothered to analyse the likelihood of an "accident" here - and it's quite good news - for the design I mean! X'50' is significantly X'10' which means an input field and it's unusual to put text into an input field in an USS message - but not inconceivable - because I've done it! However it makes sense - to me anyhow - when the "modify data tag (MDT) bit, bit 7, is on - and in X'10' it isn't. Of course, there may be some system programmers who want to use the 4 basic colours who don't mind possibly confusing their users by having input fields which aren't - so to speak - in order to colour the text in the field green. The USS messages created by such system programmers are "at risk". There's also the Write Control Character (WCC) at the beginning of the data stream. Would the scan know to skip over that? On the evidence of the implementation, I wouldn't want to assume that - but at least it's easily fixed - if they can afford it! Did these matters come up when the design was discussed? - Rhetorical! - > 1. The product is "working as designed". Can't lamentable design be subject to APAR - especially if it can be shown that what worked before the change doesn't work after the change - thereby inhibiting the change? I know you've been through this sort of thing but surely "shame" has a role ,especially if you can get a customer "suit" to contact the IBM "suit" responsible for the lamentable design - maybe I'm being naive. > 2. If "suits" were involved I think they were those that decided staffing levels. And financial matters in general but, at least in days gone by, IBM maintained standards way higher than this. > 3. I may be thinking designers rather than developers, but I don't think "incompetence" is an operative word here. To someone who understands the matter - see the analysis above - "incompetence" is the only word that seems to fit. The appearance of "incompetence" may have been forced on both the designers and developers - in which case my abject apologies to them - because some penny-pinching "suit" mentioned offers they couldn't refuse. It may be a genuine case of "quick and dirty" with no option that kept a roof over their family's heads. > On the TCP/IP side this is a very small group ... The change to the stand-alone TN3270 server took place around the same time as this enhancement which implies somebody or some bodies reasonably competent with TN3270 function was/were available. > I suspect this is a matter of wanting to touch a house of cards as little as possible. The bulk of the work is in performing the substitution. What's missing is the (sub)operand setting a bit which asks permission to use system symbols with maybe a few words not dissimilar to my analysis above concerning the care that needs to be taken. I can a see a political process arising there because that involves the macros - which aren't that complicated - but that's VTAM territory. > Once again, ..., but I think this is a very unfortunate characterization. He > is in no way "of inadequate intelligence". This was an euphemism for what I really wanted to say. I guess there is a scenario involving twisted arms, compounded by thoroughly confused manual authors, which could be conjured up. It was a red rag - an extended "expletive deleted" moment - that the enhancement was described under the SCAN|LUNAME suboperand but didn't rely on SCAN|LUNAME in practice and that the "permission" aspect implied by the SCAN|LUNAME suboperand was what was missing from the design. In other words, what they should have done was staring them in the face once it had been added to the manual. If you know someone - you suggest only one - who is likely to be involved, it would be fascinating to know the inside story. Similarly, the last time I thought about it, I could come up with two names "on the VTAM side". I talked to one - you know who - not so long ago privately and I know he is very particular in limiting what he covers to what he knows - and how he knows it!!! I have had dealings with the other name I have in mind. He also took a minimal risk by introducing a start option where the default behaviour was not the prior behaviour but that was correcting a bit of a design infelicity. >> It's cheaper if you just impose the change in the TN3270 server logic. > Or possibly that was the only way to get it done at all. The IBM I used to know had quality standards to set against accounting considerations. This all puts me in mind of the USS enhancement which introduced the @@@@RUNAME and @@@SENSE variables into the BUFFER text. The developer involved, knowing my interest in these matters from FORUM traffic, asked me to be a test site and slipped me the module. It just worked and there was little to say but - fine, go ahead. I wonder if I had been asked to "road test" this enhancement I would have spotted the difficulties. I would have needed to see the manual text and I would probably have raised a question there. It's also clear that Martin Kline would have done a very good job if he had been asked to "road test" this function. - > I don't have any of the inside IBM connections that Chris has ... Actually my closest contact near IBM development has left in the last few months. In any case I'm an ex-SE. It was expected of SEs that they should be gentle to customers and less gentle to developers[2] - it was their job! A country- level manager said something close to that on my last trainee course; "quality" was the word he emphasised - that was back in 1969! > so I can't say he is wrong, ... I hope you have seen enough above to know what the difficulty is. This enhancement could play fast and loose with an installation's existing USS messages without having asked permission. There's a hidden risk for every customer migrating from before V1R8 to V1R8 or later and thereafter every time an installation-defined system symbol is created. That's why I don't believe I - and Martin Kline - are wrong - and that's what the so- called "problem analysis report" should emphasise in it's bid to become an *authorised* "problem analysis report" (APAR)[3]. Chris Mason [1] I've been involved in selecting some installation-defined system symbols so that systems can run in normal production and at a disaster recovery site. Nobody thought that we might need to take care about what was coded in USS messages when we selected the names! [2] There used to be two key head office departments. One supported salesmen where the brilliance of the products was promoted though glossy documents and presentations. The other supported the SEs and allowed them to express their disappointment with what was being foisted on the customers so that the deficiencies could be passed onto development. I belong to the latter persuasion! [3] Some sources claim that "problem" should be "program" in APAR but a Rochester (iSeries) page I found with Google showed "problem" - and that's a bit more honest! On Wed, 5 Aug 2009 16:21:32 -0500, Patrick O'Keefe <[email protected]> wrote: >On Tue, 4 Aug 2009 19:03:22 -0500, Chris Mason ><[email protected]> wrote: > >>... >>Yes, the whole design is a total mess. I suggest you hit your IBM >>support with this shoddy design with as much force as you can >>muster. It's incompetence piled on incompetence, in the >>implementation *and* the description. It shows what can >>happen when the "suits" force a "quick-and-dirty" enhancement >>and use developers who clearly don't understand the environment >>in which they are working to implement it. > >I don't have any of the inside IBM connections that Chris has so I >can't say he is wrong, but I see this much differently on a number >of points. > >1. The product is "working as designed". If you want this changed >you're going to have to submit a Requirement with a very strong >business case. Fixing USS design flaws isn't going to be very >high on anybody's list. > >2. If "siuts" were involved I think they were those that decided >staffing levels. > >3. I may be thinking designers rather than developers, but I >don't think "incompetence" is an operative word here. On the >TCP/IP side this is a very small group (possibly one person) working >on less than stellar code. On the VTAM side I suspect it is down to >about nobody - not for the USS part. Rather than incompetence, >I suspect this is a matter of wanting to touch a house of cards as >little as possible. > >>... >>Instead the "people of inadequate intelligence" have amazingly >>done the exact opposite. > >Once again, I may be thinking designer rather than developer, but >I think this is a very unfortunate characterization. He is in no way >"of inadequate intelligence". > >>... >>I'm guessing that the reason they shied away from altering the >>USSMSG macro ... is that they didn't want to involve the SNA >>(VTAM) side of the Communication Server house in their clandestine >>enhancement. > >I think it much more likely that there was nobody on VTAM side to >work on it. They are (he is?) stretched pretty thin. > >>It's cheaper if you just impose the change in the TN3270 server >>logic. > >Or possibly that was the only way to get it done at all. > >Pat O'Keefe ---------------------------------------------------------------------- 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
