Knowing
a bit of math has always given me a leg up in my career. In the summer of 1968
I had just finished my second undergraduate year (I don't say sophomore,
because I graduated in three years). I was able to get an internship in the MIS
department of Uniroyal through a friend of my parents. The first day they gave
me the IBM Programming Aptitude Test (the standard of the time) that was kind
of like the math part of an SAT. I blew them away with the speed and accuracy
with which I completed it. Then I had an interview with the department manager.
He had originally hired me to help convert a bunch of old Autocoder programs to
RPG, but realized that my skills were way beyond that. He had a problem to
solve that he felt that he would have to do himself because he didn't have
anyone on his staff who could handle it (he had a master's degree in math). So,
he outlined it for me and that became my project for the next several weeks
(*2).
Project
Background
This
was for the footwear division of Uniroyal - the former US Rubber - and they
made US Keds and Redball Jets among a lot of other footwear. Footwear is
constructed by starting with what's known as a "last" - a foot-shaped
piece of material that the shoe is constructed around (see *1 for more
details). Because these were sports shoes, the lasts were primarily aluminum.
There are different types of lasts for different types of shoes.
Lasts
also come in different sizes. But these sizes don’t match the shoe size. In the
US there are ranges of sizes for men, for women, and for children. But a men’s
size 6 is made on the same last as a woman’s size 8, etc. So, these different
ranges must be converted to a common “last size”.
Finally,
shoe production must be scheduled in full cases, not in pairs. For smaller
shoes, there are generally twelve pairs to a case, but for larger shoes, there
are only six pairs in a case.
The
Production Problem
For
each week in the shoe factory, we start with the “wish list” of the sales
department, i.e. how many pairs of shoes in each style and size they believe
they can sell for the coming week, e.g. 30 pair of style 123, women’s size 9.
We also know that we have so many pair of lasts of type AB in each size. (Oh,
and we have to take account of the fact that some shoes can be made fairly
quickly so we would be able to use the same last more than once in that week.) The
question then become, do we have enough of that type of last to make all the
shoes that the sales department would like?
The
“Shape” of the Program
To
solve this problem, we need a couple of matrices. Envision the primary one as a
large square matrix (N by M) where the rows are the different styles and the
columns are the different sizes (of the lasts). Then there is a smaller (N by 1)
matrix containing the various styles and another smaller (1 by M) matrix
containing the available last inventory.
We
are going to process one type of last at a time. We first load in (from mag
tape at the time), the last inventory and populate the 1xM matrix. Then we read
(from a second tape), all the sales department desires, put the particular
style and attributes (Men/Woman/Child) in the Nx1 matrix and the desired
production in the NxM matrix (after doing all the conversion from shoe size to
last size).
Now
for the hard part. Going one column at a time, we add up the sales desired for
the column and compare it to the available last inventory for the column. If we
have enough, then great, we’re done for that column. But let’s say that we only
have enough lasts to cover X% of the sales desires. We spread the last
inventory over the desires, giving X% to each desire. Then we take each result
and “round down” to case amounts, so if the desire for a particular style/size
was 180 (of a size that we can get 12 pairs in a case) and we only have
allocated enough lasts to make 153, then we round down the 153 to 144 (a
multiple of 12). After going through all the desires in a column, then the
residual (9 in our example cell) from all the rows is unused lasts. We take all
the unused lasts, and go through the process again, seeing if we can, in the
fairest way possible, manage to make any of the cells up to the next case-lot.
After possible multiple passes of spreading and rounding down to case lots, if
we cannot fill any more cases, then we advance to the next last size and repeat
for each column. (Don’t worry if you don’t understand all the nuances of the
above, that’s why it took someone with an understanding of math to write this
program).
Once
we’re done with all the iterations of the above, we spit out the answers in the
form of revised production for each style/size.
Consequences
of 1960’s Technology
This
program ran on an IBM360 model 40 with 128K of memory. There were limitations
on input, memory, and CPU speed. While we had disk drives, they were only
available for things like the customer master (in indexed file) and not for
other uses. The memory partitions were limited to 82K for the main partition
plus a couple of small foreground partitions as well as space for the operating
system. We were only allowed 4 tapes drives per partition.
Thus,
the coding had to be as concise as possible and there were limits on the size
of the matrices as well. We also used 3 tape drives – one for last inventory,
one for sales desires, and one for the production results. The latter would be
printed in the form of production schedules by a later program.
But
because there were so many calculations take place as the program worked
through each column of the matrix in order, spreading inventory, rounding down
to case lots, re-spreading leftover inventory, etc. the program would use a lot
of CPU time and put out the “wait light” on the CPU. Most programs of the time
were I/O bound as they were usually waiting for the tape drives. But this one
would read a bunch of stuff from the two input tapes, by compute-bound while it
did all the calculations, then would write a bunch of stuff on the one output
tape. The operator instructions were generally, if the wait light on the CPU
goes out that means that the program has gone into a loop and is not working,
so they needed to cancel it. This was the only program in the entire
installation of its kind and I had to write instruction on it, “this program
puts out the wait light, do NOT cancel it!”
The
Results
As
these were the days of punched cards for programming, everything had to be
written on coding sheets and submitted to the keypunch department – with a wait
time depending on how big your program was. Getting changes made required the
same process, so one was constantly waiting on others. Program compiles and
tests were overnight submissions since daytime was reserved for production
runs. So, things took a lot longer than they do now.
As a
result, it took several weeks to write and test the above program. In between I
did things like write the print routine for the production schedule, made some
other minor changes to other programs, and even debugged a few of those pesky
Autocoder programs that I had been hired for in the first place. My boss was
happy with my work.
I
was hired for a second summer the following year – writing a funding model for the
corporation’s international division. And when I finished grad school, even
though it was the middle of a recession in 1971, I was hired full-time. After a
little over a year, the MIS director took early retirement and went to work as
VP of Finance for Olin-Winchester. He then called me and asked me to join him
there. But that’s another story (*3).
Notes:
No comments:
Post a Comment