While I will always agree that having ONE system is the more organized and
long-term cheaper way to go,  I have seen many many cases where application
software has no end of hardcoded usernames, groupnames, accountnames,
passwords, etc. etc. in the source code.  It takes a lot of carefull work to
eliminate this kind of roadblock to using a single system.

At my last consulting project at Warner Bros, we built a very slick little
setup that eliminated all of this hardcoded stuff that tied their software to
a specific system and to a specific account, group, etc.  We created a logon
UDC that did various SETVARs for a predefined set of variables and then used
a common subroutine in an XL to read each of these variables and pass the
values back to all of the calling programs.

Before we started on this task, their situation was the reverse in that they
couldn't have either a seperate test system or a true seperate test
environment ont he same system due to these hardcoded values.  Now they can
continue to have a seperate production system and a seperate test system, or
they can combine both functions onto a single system without any conflicts
due to these formerly hardcoded values.

Wayne Boyer
Cal-Logic

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *