The Cornfield Workload

Nostalgia time again. How many remember the old orange-covered Technical Bulletins that the System Centers used to produce? (How many actually remember when we had regional Area System Centers?). Back in those days, the VM Performance report was a collaboration of the VM Performance Evaluation team in the Development Lab and one of the System Centers. We'd pull together the bulk of the data and information and then turn it over for additional writing and editing and formalizing to one or more people in the centers.

Seeing my name on one of the inside pages listing the 'contributors' was awesome. And Mom got a copy that year for Christmas. Having a last name that starts close to the beginning of the alphabet has pros and cons. On one hand, I was one of the first names on the list. On the other hand, when people were looking for someone to help answer questions, I was one of the first names on the list. I recall getting an email shortly after we published a performance report for one of the last VM/SP releases. Someone in the field had read the report and wanted more information on the CORNFIELD benchmark. Yes, the CORNFIELD benchmark. Don't worry, I had not heard of it either. I wrote back asking which CORNFIELD benchmark? To which they replied, "The one you mention in the VM/SP Performance Report".

Up to that point, I had thought I wasn't new to performance anymore and knew pretty much what all we did. But suddenly there is a whole benchmark that I had never even heard about and which apparently was in our Performance Report. I started asking around. I got some ideas, but they were all stretches. There was a workload we ran for VSE called PACE COB. Someone suggested maybe they think COB as in corn on the cob? (I actually don't recall what the PACE COB meant. I think it used POWER and I remember we eventually replaced it with the DYNAPACE workload). Then someone discussed maybe it was part of the CMS interactive workloads we ran to load test VM with a simulation of multiple CMS users doing program development. One of the simulations included using XEDIT to create a FORTRAN programs, compile them, and run them. Get ready for this. One of the FORTRAN programs was one that computed the coverage when spreading manure on fields. Maybe cornfields?!!

I went back to my new friend in the field with my two new possibilities. Which were both wrong. To make things easier (and perhaps because he was starting to think he should have started at the other end of the alphabet), he pointed me to the exact page in the report where we talk about CORNFIELD. The page corresponded to a section where we reported on CMS performance, actually providing pathlength and page reference data on various CMS commands. I started reading through the table of commands: SET, ACCESS, COMPARE, CORNFIELD, ... 

CORNFIELD?!!! Did you figure it out yet? This was in early days, at least for me, of proof or spell checking. The software decided COPYFILE should have been CORNFIELD. I laugh about it now, but at the time, many of us looked at each other asking how did we miss that? It was a good lesson learned.

Thinking back on this story, I also reflect fondly on the desire of those involved to report accurately and completely on the performance of a new release. We took pride in it. We worked well with other teams since in those days not everyone could 'publish' information. It was an expense so you wanted to get it right. These days the requirements to publish information are down to just 'can you operate a kyebored?'. Or maybe there aren't any requirements.