Breaking News
Comments
Newest First | Oldest First | Threaded View
Stargzer
User Rank
CEO
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! :-)



EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

What's the Best Traveling Toolkit?
Max Maxfield
7 comments
A few years ago at a family Christmas party, I won a pocket knife as part of a "Dirty Santa" game. This little scamp was a Buck 730 X-Tract. In addition to an incredibly strong and sharp ...

Rishabh N. Mahajani, High School Senior and Future Engineer

Future Engineers: Don’t 'Trip Up' on Your College Road Trip
Rishabh N. Mahajani, High School Senior and Future Engineer
9 comments
A future engineer shares his impressions of a recent tour of top schools and offers advice on making the most of the time-honored tradition of the college road trip.

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
41 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Karen Field

July Cartoon Caption Contest: Let's Talk Some Trash
Karen Field
153 comments
Steve Jobs allegedly got his start by dumpster diving with the Computer Club at Homestead High in the early 1970s.

Top Comments of the Week
Flash Poll
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)