[Info-vax] OpenVMS future directions - discussion topics
William Pechter
pechter at S20.pechter.dyndns.org
Thu Mar 5 13:39:48 EST 2015
In article <ckh577Ftf5nU2 at mid.individual.net>,
Bill Gunshannon <billg999 at cs.uofs.edu> wrote:
>In article <a2eac5ff-8053-4ac4-b8ec-f07e7e493d6e at googlegroups.com>,
> johnwallace4 at yahoo.co.uk writes:
>> On Sunday, 15 February 2015 19:50:12 UTC, JF Mezei wrote:
>>> On 15-02-15 11:08, David Froble wrote:
>>>
>>> > The most expensive way to develop software is to have an in-house staff.
>>> >
>>> > A much more economical method is to have a "trusted" vendor with the
>>> > expertise to produce what is required.
>>>
>>> Trade rag common sense. But in reality, this cannot be blindly applied
>>> to all cases. There are computing functions which are fairly common
>>> across companies (payroll, accounting), but there are indusrtries that
>>> truly have a "one off" application very specific to not only their
>>> industry but to the company's unique product or service.
>>>
>>> Outsourcing that unique software to some consulting firm means that the
>>> firm will make vast profits from the work. And you pay full cost of
>>> development since that software is propretiary and not sold to anyone else.
>>>
>>> So there are cases where it makes sense to do it in-house (even if you
>>> hire some consultants) because it is a unique part of your company and
>>> not software whose costs could be lowered by having it sold to different
>>> companies.
>>>
>>> > No, I don't buy that. While there can be an expensive lack of quality,
>>> > there cannot be an inexpensive quality.
>>>
>>> The one comment to make about VMS is that the APIs are well documented
>>> and work as documented. This is a HUGE time saver when developping apps
>>> and generates more reliable apps. This should be marketed.
>>>
>>> The one aspect that does need work though is the TCPIP interface. I
>>> found DNS requests via $QIO to not work as documented. (or documentation
>>> was not good).
>>>
>>> > It's like the bean counter who asks "why should we use this $2 oxygen
>>> > sensor when we can use this $.10 oxygen sensor?" and then the customers
>>> > are in the shop every month for a new oxygen sensor.
>>>
>>> At the end of the year: 12 * 0.10 = $1.20 which is cheaper than the $2
>>> one. The beancounters don't factor lost productivity from researchers
>>> since researchers are in R&D and don't generate revenues and they get
>>> paid to wtiddle their thumbs when they don't change O2 sensors. (being
>>> sarcastic here).
>>>
>>> However, if a cheap sensor, despite being cheaper over time, caused
>>> production to halt whenever it needed to be changed, then the costs of
>>> halted production would be factored in and that $2 sensor would be more
>>> than justified.
>>
>> JF wrote:
>> "if a cheap sensor, despite being cheaper over time, caused
>> production to halt whenever it needed to be changed, then the costs of
>> halted production would be factored in and that $2 sensor would be more
>> than justified."
>>
>> I admire your confidence in management.
>>
>> Since the cost of production disruption likely comes out of a different
>> stovepipe/empire than the initial cost of purchase of decent parts, there
>> are plenty of organisations where your logic doesn't apply, despite your
>> logic being entirely sensible.
>>
>> Only if someone sensible is overseeing *both* budgets, and only if his/her
>> management chain are prepared to admit the real problem(s), will the
>> obvious sensible solution be adopted.
>>
>> Good luck with that.
>
>Finally someone else who can actually see beyond the trees....
>
>When I was at West Point and UUCP was still the only real INTERNET :-)
>we had a connection between us iin Orange County and Phillips Labs in
>Putnam County. This was different counties, opposite sides of the
>Hudson River, and different Area Codes. You can probably imagine what
>the cost of any phone call between us was. From the roof of Building
>600 where our UUCP node was I could see Phillips Labs. I once asked
>why we didn't just put in an LOS (line-of Sight) microwave link between
>us as that would pay for itself in about six months. I was told that
>the problem was the budget the money came out of. We didn't pay for
>our phone service directly, it came out of the Post phone budget. But
>if we bought the microwave link the cost of the equipment would come
>out of our budget, so, it was cheaper to just continue the way we were.
>
>How's that for logic?
>
>bill
>
>--
>Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
>billg999 at cs.scranton.edu | and a sheep voting on what's for dinner.
>University of Scranton |
>Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill --
Your idea reminded me of my wife's free uucp hack. Her housemate
worked for NJ Bell and ran a multiline chat system out of her house so
they tipped me to a cheap way to span a serial network throughout NJ.
We just used Veriz-- (er N.J. Bell at the time) -- $5.00/month call forwarding
here out of my house to get a full newsfeed across a half dozen LATA lines
to push the data from one house down to the nearest end point which would
just either receive the data or forward the call.
Of course this wasn't a commercial option -- but on an individual's home
phone it was the cheapest way to gain access.
We paid for selective call forwarding on friends modem lines when
we didn't have anyone in midpoints to act as a Usenet node.
They still would forward when busy so it didn't hurt their BBS and
AOL usage 8-).
For $5.00 per node per month plus modem cost (which we all had anyway) we
had 1/3 of NJ picking up newsfeeds in 1987 until PPP and SLIP became available
at ISP's in around '93 or so.
There are ways to do things that are legal just because the telco's hadn't
ever expected anything to do that.
We served fido's, home Unix boxes, etc.
As far as getting the news feed... I was the Sysadmin and UUCP guy at my work
place and getting the feed wasn't a problem in most places I worked.
Of course, before warez groups and all the *.binaries.* and video stuff
the feed we had could fit on a 300mb CDC9766 (RM05 equiv) pack with
a week retention. I held 2 80mb drives at home in a 68k box and had a short
retention on most groups I passed through and kept the DEC and Unix stuff for
a longer term.
This is the routing map I used when Ilast had uucp running...
Losex was in Ocean County about a half hour from home. Tsdiag was at the
Concurrent Computer Oceanport facility.
I was the feed point in the middle through 94... I think I stopped the
news feed when I got on monmouth.com around then.
Don't know who has the phone number now... and the Area Code's changed too.
Google Maps just showed me the latitude and longitude was actually about
2 miles from the house... Pre-gps I guess.
#N i4got
#S 386-sx25; Linux 99.13
#O Lakewood MicroSystems
#C Bill Pechter
#E i4got!postmaster
#T +1 908-935-0629
#P 17 Meredith Dr, Tinton Falls, NJ 07724
#L 40 19 49 N 74 05 37 W
#U losex
#W i4got!pechter (Bill Pechter); Thu Oct 13 17:10:45 GMT 1994
#
i4got losex(DAILY*2),tsdiag(DAILY*2),ka2qhd(DAILY)
i4got .lakewood.com
i4got=i4got.ukp.com
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
More information about the Info-vax
mailing list