Breaking News
Comments
Newest First | Oldest First | Threaded View
Stargzer
User Rank
Manager
Re: Frankenstein's Fix: the Mysterious Data Packet
Stargzer   2/12/2014 1:31:09 PM
NO RATINGS
I've seen that problem several times over the years, and it's always been a timing problem related to interactions of hardware design and software design.

One occurred when the one side didn't have enough time to process received data before the other side requested to send more, and things ended in a loop where the one side sent an ENQ (Enquiry or request to send data) and the other side only had time to send a WACK (Wait ACKnowledge) before the first side repeated the ENQ, and so on ad infinitum  I don't remember how they fixed that.

A second occurred when a new minicomputer-based (probably all TTL) RJE (Remote Job Entry) terminal kept dropping data. The vendor had their top programmer on site trying to fix it.  You could recognize him by the flannel shirt, blue jeans, and lost look on his face as he travelled between the RJE and a card punch an back, for what seemed like weeks on end.  We were finally asked to come in with a datascope and saw that as soon as the RJE sent the acknowledment for the last block of data, the mainframe shoved another ENQ down its throat, but the RJE didn't see it because it was still processing the last block it received.  It turns out the mainframe programmers had set the mainframe FEP (Front-End Processor) for full duplex, figuring it was faster and more efficient, and both modems were set for constant carrier.  The RJE, however, needed to be set for half duplex because it needed breathing room.  It was fixed when we convinced the system programmers to set the mainframe for half duplex and we reset the modems for switched carrier with a 250 ms turnon time.  With a quarter-second delay the RJE was happy, and so was its programmer!

A third one was also a timing issue, only this time a microprocesser- based barcode reader was stuffing things down the mainframe's throat too fast.  The group in charge of furniture inventory bought this neat little barcode reader to scan barcodes on furniture and sent it to the mainframe all in one fell swoop.  It worked great at the demo at another agency, using a larger IBM mainframe that we had.  On our system the mainframe kept dropping data.  Part of the problem was that the barcode reader blurted out all 64K bytes of data without stopping, and they had set the end of record as a carriage return.  The mainframe was set to sense a carriage return as end of data, and would terminate the read and go on to the next step in its program.  Ours was a slower mainframe, so by the time it got its act together and hung another read up, several records had gone past and into the bit bucket.  Part of the problem was that the application programmer read a record and then went on to process it, including disk access, before reading the next record, which took a lot of time (relative to the datacomm line speed).  It was fixed by changing the barcode reader to terminate each record with a Record Separator (RS) character and not send a carriage return until all 64K had been sent (many teeth were pulled as we interrogated the vendor progammer over the phone).  Then one of our datacomm systems programmers (to whom a macro-assembler was a high-level language) set the mainframe to continuously read data into a gargantuan buffer until it read the final carriage return that terminated the read.  The next step was to split out the records based on the RS character and then pass that list to the remainder of the program. 

"You have to understand how a starship operates."  -- Capt. Kirk, Star Trek: The Wrath of Kahn.

 

SandorD
User Rank
Rookie
Re: Frankenstein's Fix: the Mysterious Data Packet
SandorD   11/20/2013 5:09:31 PM
NO RATINGS
"...the IOP did not send a 'not ready for data' signal to the laptop"

"This is an example of the software person writing software to get around a

hardware problem."

 

There are always limits to the capabilities of the hardware, which the

software then needs to take into account and handle correctly.

This case sure sounds like a software problem to me! :-)



Flash Poll
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Engineer's Bookshelf
Caleb Kraft

The Martian: A Delightful Exploration of Math, Mars & Feces
Caleb Kraft
6 comments
To say that Andy Weir's The Martian is an exploration of math, Mars, and feces is a slight simplification. I doubt that the author would have any complaints, though.

The Engineering Life - Around the Web
Caleb Kraft

Surprise TOQ Teardown at EELive!
Caleb Kraft
Post a comment
This year, for EELive! I had a little surprise that I was quite eager to share. Qualcomm had given us a TOQ smart watch in order to award someone a prize. We were given complete freedom to ...

Design Contests & Competitions
Caleb Kraft

Join The Balancing Act With April's Caption Contest
Caleb Kraft
57 comments
Sometimes it can feel like you're really performing in the big tent when presenting your hardware. This month's caption contest exemplifies this wonderfully.

Engineering Investigations
Caleb Kraft

Frankenstein's Fix: The Winners Announced!
Caleb Kraft
8 comments
The Frankenstein's Fix contest for the Tektronix Scope has finally officially come to an end. We had an incredibly amusing live chat earlier today to announce the winners. However, we ...

Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)