dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (11/14/88)
RE postings: <558@nikhefh.hep.nl> <3f6dd85c.ba7d@apollo.COM> <869@cernvax.UUCP>
<563@nikhefh.hep.nl> <3f960034.ba7d@apollo.COM> <17798@shemp.CS.UCLA.EDU>
Eric Wassenaar (e07%nikhefh%mcvax.uucp@uunet.uu.net) has a problem with the
SR10 FORTRAN compiler and Wayne Geiser (geiser@apollo.COM) has been trying to
help.
Here are 3 suggestions that might be worth while:
1) DSEE. I've never used it but I hear that DSEE is used inside Apollo and else
where for managing large software projects. Maybe DSEE could help Eric manage
thoss large FORTRAN source files and provide automatic splitting and compilation.
2) Enhance the FORTRAN compiler. Add an option that would automatically spit out
separate COFF files for each subroutine in the source file, complete with the
needed debug references back to the source file. EG when the "-split" flag was
set, the compiler would do the splitting and compiling of each routine, creating
some kind of derived name for each COFF module.
3) Enhance Apollo COFF. The COFF format has provisions for vendor-specific
information, Apollo already has its "Domain header." Add the missing library
information in an extended Apollo header, or the SRI header, or some new
Apollo-specifc header.
The last 2 suggestions probably should be sent to Apollo as APRs.
Now I'd like to address some non-technical issues:
1) Around the preceding postings some flames have sprung up, this is unfortunate.
Good natured griping about a problem is OK but when it degenerates to name-calling
and cuss words, nobody wins. Wayne Geiser, Larry Allen, Ollie Jones, etc. are
NOT customer service reps paid to answer our mail. These guys are knowledgeable
people, like R&D, with lots of work to do inside of Apollo, who take time out
to try to help us. They are not the service people that you get when you call
the 800 number (if they did answer that phone, they'd never get anything done).
If they did drop out of this list because of abuse received or for fear of having
to watch each word they wrote, WE would be the losers. None of these individuals
is responsible for corporate attitude or philosophy.
2) Apollo is in the middle of a "damned if you do, damned if you don't" situation.
For years it has been beat up for not providing "real UNIX." The Apollo bean
counters saw an alarming loss of market share (look at Apollo stock prices VS
Sun). They sent out the marketing troups to find out what they needed to do to
reverse the trend, the majority of the "squeeky wheels" said "give us real UNIX."
So now Apollo is in the middle of a major upheaval, trying to meet the market
demand without loosing much existing functionality. Along the way, decisions are
going to have to be made about conflicting features (EG case sensitivity). Some
things will have to end up on the losing end, some people are going to be unhappy.
Either we can reject the change and stand still while the world moves on, or we
can accept the change (and the pain) and go with the new. (SR10 has caused me
some pain, our disk quota system was based upon pre-10 ACLs and now I have to
figure out a work around.)
In some cases, these decisions were based on marketing considerations, not
technical ones. The marketing types heard the people who were bitching loudest,
not those who were fat, dumb, and happy. (dumb here meaning silent.) In these
cases, we should yell at the marketing types, the R&D people are only following
corporate orders. SR10 represents a major effort on Apollo's part to
try to respond to the demands of the masses, which disproves the charge:
"Apollo seems to feel that the world revolves about themselves and damn anyone
who thinks differently."
3) In the process of a major change, like SR10, mistakes are bound to be made.
Lets point them out but not scream at Apollo for not getting it right the first
time round.
This is too much rambling but I wanted to get it off my chest.
Dave Funk (speaking for myself, not necessarily for the University of Iowa.)