How about a good old fashioned rant?



  • So I'm onsite at a customer location this week, testing a new interface to a 3rd party software system which is located elsewhere.  I'm in integration hell.  Last week the other software vendor kept insisting that we test the interface before the T1 was installed by having us email them XML data output from our program.  Okay, fine.  This week it's become apparent to me that it was a total waste of time, as I suspected.  Always, always, always get your infrastructure in place FIRST, and then test.

    So Monday I show up onsite, no router at one end.  Tuesday I show up again, still working on the network.  Late afternoon we finally get connectivity, and immediately have errors.  Hey this is a new interface so errors out of the starting gate are to be expected.  Other than having wasted almost two days onsite websurfing because they weren't ready, I'm copacetic.  Keep in mind my customer paid for this trip, so I'm a little annoyed at the wasted time.  Oh well, keep on truckin.

    Today the other vendor and I spend all day butting heads.  Their system queues up messages, and refuses to proceed to the next message until after I've ack'ed the first one.  Normally this is fine, but it's not robust enough to handle problems.  For example, the error we ran into yesterday - badly formatted XML on my part, which I had my programmer fix overnight.  Try to start testing again today... no dice because they INSIST that we ack the error message their system sends us from yesterdays bad messages. 

    I have them clear their message buffer and try again.  But there's some weird network glitch and it takes about an hour to clear.  When we finally get the connection back up, they start processing messages we sent an hour ago and then sending us errors because we didn't ack them an hour ago and aren't acking them now.  I'm having my programmer fix our end so that it acks all errors they send us and immediately throw them away just to clear the buffer and allow us to start fresh. 

    It goes something like this:

    1. we send subscription request

    2. they ack it

    3. they send subscription response (kind of another ack)

    4. we send a heartbeat

    5. they send an error because we didn't ack a message from an hour ago when the network was down

    (this happens 5 times then they drop the socket)

    6. regain connection, we send a subscription request

    7. they ack it

    8. they send a subscription response

    9. we send a heartbeat

    10. they send an error because we never acked the error from before they dropped the socket (#5), etc etc.



  • Hmm...  *scratches head*   I think I see your problem here...  Yup, there it is: no Y chromosome.



  • Funny, I was thinking earlier that it's bringing out the Y chromosome in me.  I was ranting to myself that their system is acting like a bad wife holding grudges and my system has to tell it "yes dear" just to shut it the hell up.

    Anyway, I thought I should elaborate a little more on why we're not acking their error message.  We're trying but they're not using standard XML and they've embedded the original "bad" message inside the error, so our parser tripped over it.  No matter, we're in the early stages of a custom new interface so we're having to code to their spec which we do commonly.  But in those early problematic stages of working out the bugs of an interface, it's probably not a good idea to queue messages forever like they are.  When one end trips and falls over bad message formatting, you really need to drop the connection and start afresh after the software is fixed.

    Back to nontechnical ranting, it's also a wasted business trip because I've been working in a room alone all week.  No need to physically access any hardware, and I haven't seen anybody face to face.  My counterpoint at the other software vendor is making me email her to let her know when I'm ready to test and then she calls me back.  And she's only a business analyst, completely unable to diagnose problems or fix them on her end, so there's been ALOT of sitting around waiting. 



  • @jetcitywoman said:

    like a bad wife holding grudges and my system has to tell it "yes dear" just to shut it the hell up.

    RL confirmation available.



  • @jetcitywoman said:

    Anyway, I thought I should elaborate a little more on why we're not acking their error message.  We're trying but they're not using standard XML and they've embedded the original "bad" message inside the error, so our parser tripped over it. 

     

    You mean they are embedding data their parser has already determined is not valid XML into an XML response? Is at least inside a CDATA section, if so?

     



  • No CDATA in sight.  A few people have looked at their messages and told me that it's not standard XML.  It may be a bad attitude, but I don't care enough to look up what standard XML looks like.  I just want to code it the way they say and get the hell out.  :-)

    They are embedding the original bad message inside a <originaldocument> tag.  It's not so bad, it's just that they didn't tell us they were going to do that.  My partner and I also can't tell the difference between how they're using NAK and error messages, they seem interchangeable.  Oh, and they insist that we send an ACK to their NAK, which is amusing if nothing else.



  • @jetcitywoman said:

    No CDATA in sight.  A few people have looked at their messages and told me that it's not standard XML.  It may be a bad attitude, but I don't care enough to look up what standard XML looks like.  I just want to code it the way they say and get the hell out.  :-)

    I hope for your sanity your not actually doing that yourself? There are quite a few libraries out there that will not only help you in building the XML, but also verifying that its valid to some schema you hopefully maintain.

    @jetcitywoman said:

    They are embedding the original bad message inside a <originaldocument> tag.  It's not so bad,

    Yes it is. the method i see used most is just a direct respons, but when that's not possible (because of the queued design) you will mostly get send back which message was bad, and what  was bad about it. Since you hopefully keep a archive of send messages you can look it up, to see what went wrong.

    @jetcitywoman said:

    My partner and I also can't tell the difference between how they're using NAK and error messages, they seem interchangeable.  Oh, and they insist that we send an ACK to their NAK, which is amusing if nothing else.

    amusing, but i kinda agree with that. If its not too much trouble to do and increases the visibility of errors in the process i'm all for it. If for whatever reason their NAK didn't reach you, they now know that they have to try and send it again or send of some warning mail. 



  • @stratos said:

    I hope for your sanity your not actually doing that yourself? There are quite a few libraries out there that will not only help you in building the XML, but also verifying that its valid to some schema you hopefully maintain.
     

    Ah, now you're going to say that *I'm* the WTF.  We're "old school", working on a 30+ year old product that I actually passionately love.  My coworker wrote the device driver in assembler and I'm working in Cobol.  We don't do any of that fancy Winders bullhocky here (and we walk to work uphill in the snow every day).  I know it makes you guys cringe to hear that, but it's really a stable system, easily and quickly customizable.  Part of my frustration was having to wait several hours for bimbo to send her Windows logs off to her engineers to tell us what was wrong, and then when they tell me it takes me 5 minutes to fix my program.   We're very nimble, if old fashioned.  So I'm not sure if any new libraries would help us.  And having said that, they didn't pay us enough to go full-hog parsing the XML for every possible message variation i.e. support XML fully.  This was only a 3-week project on our end.  We searched the messages for exactly the tag we wanted, grabbed the data from it, and ignored the rest.  

    @stratos said:

    amusing, but i kinda agree with that. If its not too much trouble to do and increases the visibility of errors in the process i'm all for it. If for whatever reason their NAK didn't reach you, they now know that they have to try and send it again or send of some warning mail. 

     It wasn't alot of trouble to do, but we can't see the benefit (to us) for doing it.  It's just a rule.  They don't care if we actually do anything with their messages, only that we ACK them.  Also, if we fail to ACK all they do is keep sending the same error message over and over.  That's why I couldn't accomplish a thing for the first two days.  My software was failing to parse properly, and even after I'd fixed it, their software was obsessing over the old mis-formatted messages from the day before.



  • @jetcitywoman said:

    Ah, now you're going to say that *I'm* the WTF.  We're "old school", working on a 30+ year old product that I actually passionately love.  My coworker wrote the device driver in assembler and I'm working in Cobol.  We don't do any of that fancy Winders bullhocky here (and we walk to work uphill in the snow every day).  I know it makes you guys cringe to hear that, but it's really a stable system, easily and quickly customizable.  Part of my frustration was having to wait several hours for bimbo to send her Windows logs off to her engineers to tell us what was wrong, and then when they tell me it takes me 5 minutes to fix my program.   We're very nimble, if old fashioned.  So I'm not sure if any new libraries would help us.  And having said that, they didn't pay us enough to go full-hog parsing the XML for every possible message variation i.e. support XML fully.  This was only a 3-week project on our end.  We searched the messages for exactly the tag we wanted, grabbed the data from it, and ignored the rest.  

    I wasn't saying anything, i was thinking it though ;P 

    But Ouch!!  parsing xml inside of cobol, wouldn't it be easier to use some fancy new language as glue to do the xml handeling and let it feed cobol with stuff cobol likes to eat. I've never worked with cobol though, so my opinion on that isn't worth much.

    I also find the "30+ year old product that i actually passionately love." quite disturbing for some reason. But when you like working with a language that's that old, it might not be strange.



  • Actually Cobol isn't that bad for parsing.  Depending on what you need to do, we can do it with as little as one command:

    INSPECT DATA-STRING TALLYING CHAR-CTR FOR CHARACTERS BEFORE "<MessageGroup>".

    or some such.  Not bad at all.  Verbose yes.  But then I've been thinking this week that XML is also verbose but at least Cobol isn't case-sensitive.  

    I actually feel worse for my compatriot working in assembler.  He's got to do some amount of parsing too, and... well, the way you parse in assembler is character by painfully detailed character.  I do try to do as much as I can in my Cobol program, but he likes a challenge and he's a total assembler geek so I don't want to ruin all his fun.

    BTW, I don't passionately love Cobol.  It was always toward the bottom of my list of all the languages I learned.  I love our product, and the Cobol is only the price I pay for sticking with a beautiful product. I know it's still hard to imagine Cobol being associated with anything elegant and robust.  But our product is, so there you go.  That's how wonderful it is.  My company actually has competing products written in things like .NET and C-whatever, but I can't tear myself away from the old workhorse who never lets anybody down.  (Well, that and the fact that our product line is profitable while the newer products aren't.  Ahem!)



  • @stratos said:

    But Ouch!!  parsing xml inside of cobol, wouldn't it be easier to use some fancy new language as glue to do the xml handeling and let it feed cobol with stuff cobol likes to eat. I've never worked with cobol though, so my opinion on that isn't worth much.

    Oh, no, you misunderstood. They're not parsing the XML purely in COBOL, 'cause that would be just nuts. They're also parsing the XML in assembly language ([i]i.e.[/i], VMS Macro)!

    Jetcitywoman loves to tell me how great VMS is because you can so easily link together modules built in any language. Build up a program out of a little C here, a little COBOL there, no problem. And I know this is true, because I worked with VAX/VMS back in college and used to mix Pascal and C and assembler with no effort -- no _stdcall BS, etc., etc. -- just tell the linker what you're trying to do and it all just worked. Pretty neat, actually. I had to wait for .NET to come along before I could mix languages with the same degree of ease on the Windows platform.

    So, why not get a nice open-source XML parser written in C or C++, for example Xerces or Expat and link that in when you need to parse XML? Don't want to port it to VMS yourself? Why not just download Xerces for VMS from HP's website?



  • Good point, and I honestly hadn't even thought of it.  Now I just make excuses:  I was working on two large projects simultaneously, only had about 3 weeks to complete this one and this one was up against a hard deadline, so I'm not sure I had time to investigate and implement an open-source library.  Okay, excuses aside, the hard deadline is actually quite rare for my workplace, so now that I know about this, I can do it on future projects.

    And Dgvid's right about combining programs of different languages in VMS, so there's no obstacle there.  (The "magic" is only that the VMS engineers established long and long ago a standardized calling methodology for all programs AND the operating system, so passing data back and forth between modules is trivial.  And actually, you don't even need to link them together.  Totally independent programs can pass data and call each other by using the standard calling procedures.)

    A personal observation on the use of parsing some of the XML in my coworker's Macro device driver:  I privately wondered if that wasn't stupid.  We already have drivers for tcpip sockets, so I thought we could just use one for this, and do all of the XML parsing in the application program.  So I wondered why my project manager specified and quoted the project the way he did.  We have several Macro programmers however, who may very well be put out of work if we just reused the old drivers. 

    I know you guys are tearing your hair out right now, reading that.  I know.  It's kind of dumb, if they want to stay employed, they should probably keep their skills current or at least become more flexible by learning other languages.  On the other hand, these guys are our equivalent of brain surgeons, we don't want to ask them to become general practitioners.  They're all late 50's or older so the odds of them finding other programming jobs with new skills are pretty low.  And since they are extremely highly skilled in what they DO know, it would be a shame to just throw them away like yesterday's garbage.  This crosses over into staffing concerns rather than just technology.   And actually, given that this is a 30+ year old product using what is seen by the industry as obsolete skills and tools, we couldn't pay any young programmer enough work on this, so we need to keep these older guys to support the product.  They're irreplaceable by the very nature of their being seen as obsolete.  Isn't that a fun catch-22?



  • @jetcitywoman said:

    I love our product, and the Cobol is only the price I pay for sticking with a beautiful product.

    Wow! :) In my current work situation, being able to say 'I love our product' seems like some kind of unreachable paradise...


Log in to reply