4 ms·
While I didn't personally work on the Cobol side, I worked at a company on the consuming side. The whole thing was rather fun. The Cobol code would literally en
by virmundi 10y ago
While I didn't personally work on the Cobol side, I worked at a company on the consuming side. The whole thing was rather fun. The Cobol code would literally enter data into screens. Sometimes the screen data input was slowed to mirror that of a human. The result from each screen were known to fit in character matrixes. They would scrape the matrix into some data structure and move to the next screen by tabs and enter key presses. After the proper screens were polled, the data was rolled up and returned.
The Cobol guys liked to mock the Java team. They said that Java was slow. They pointed to how our system interacted with theirs. So one day for UAT I got permission to make async calls to their services. BAM! Mainframe was hit hard. The Cobol guys were swearing. They couldn't understand what nearly took down their system. Turns out all it took was a thread pool of 100. We ended up using the async wrappers around time-sensitive sections with only 10 or so threads, if I recall properly.