Sun-Spots-Request@RICE.EDU (William LeFebvre) (07/20/88)
SUN-SPOTS DIGEST Tuesday, 19 July 1988 Volume 6 : Issue 145
Today's Topics:
file `which which` mystery solved
Re: file `which foo` fails on 3.4/3.5
for Ted Schroeder: ibm-ebcdic tape from unix-ascii file
Documentation on printcap?
Network Licensed Software Pricing (LONG)
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: 8 Jul 88 17:45:13 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: file `which which` mystery solved
Don Kark (wiley!don@uunet.uu.net) pinpointed the cause of
file `which which`
returning
/usr/ucb/which: No such file or directory
My .cshrc file contains conditionally defined aliases for cd, pushd and
popd that write $cwd into the namestripe of shell/cmdtools; and in
addition, it does a "cd $cwd" after defining the aliases to start things
up. Naturally, this "cd" alias uses an "echo -n" to write into the
namestripe, and `which which` returns this "invisible" string together
with "/usr/ucb/which".
Since "which" uses a "_which_saved_path_" variable, I changed the "cd
$cwd" to "if (! $?_which_saved_path_) cd $cwd", and everything works fine.
My original posting said that I encountered the problem under SunOS 3.4
and 3.5 but not 3.2. It seems that in the case of the 3.4 and 3.5
machines, I was at the console, in suntools, but on the 3.2 machine I must
have rlogin'ed.
In summary, the moral of the story is that one should be very careful
about writing stuff to stdout (and stderr?) from .cshrc.
Mike Khaw
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: 7 Jul 88 19:11:43 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: file `which foo` fails on 3.4/3.5
Reference: v6n129
I got email messages from 2 people. One said he had exactly the same
problem as I reported. Another said he got an error message about some
problem with a socket(!) (sorry, I've lost that message).
Even more interesting:
bar% rsh foo file `which which`
where "bar" is my SunOS 3.5 machine, and "foo" is my 3.2 machine, hangs
the shell on "bar".
Mike Khaw
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
[[ Since "which" gets its job done by playing with your .cshrc and .login,
it's quite possible that users with different .cshrc and .login files will
experience different results. I'm not guaranteeing it, just saying that
it is possible. --wnl ]]
------------------------------
Date: 6 Jul 88 18:08:43 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: for Ted Schroeder: ibm-ebcdic tape from unix-ascii file
I'm posting my reply because the e-mail address given by Mr. Schroeder
didn't work.
> I have a hunk of C code that I want to port (sort of) to an IBM
> mainframe....
You should be able to hack the following shell script that I wrote to
transport source from Unix to a Tandem (fixed-length EBCDIC records with
some very specific blocking factor requirements). Your IBM system may
also require "IBM standard" tape labels. If you can get a spec. on what
those labels need to contain, you can manually or automatically generate
the correct "tape label" files on your Sun and copy them in the
appropriate order to the tape. The script uses the "copytape" freeware
program to work around a tape density problem with DEC tu-81 drives -- you
can ignore that stuff.
Mike Khaw
--->8--->8--->8---
#! /bin/csh -f
# given a list of directories and/or files, write a 1600 bpi
# ebcdic tape blocked at 13200 bytes/block, 132 bytes/record.
onintr cleanup
if ($#argv == 0) then
echo -n "Files/directories to write to tape: "
set pathlist = ($<)
else
set pathlist = ($*)
endif
find $pathlist -type f -print | sort > /usr/tmp/fl$$
set kbytes = 0
foreach file (`cat /usr/tmp/fl$$`)
set filesize = `du -s $file`
@ kbytes = $kbytes + $filesize
end
@ mbytes = $kbytes / 1024 + 1
if ($mbytes > 28) then
echo "$mbytes Mbytes won't fit on 1 tape -- try again"
exit
endif
# kludge around 1600bpi tu-81 bug in ultrix 1.2:
# - dd the files to 6250bpi tape
# - use copytape to clone a 1600bpi copy
set CPTAPE = /usr/app/tape/copytape/rcptape/copytape
while (1)
mt status >& /dev/null
if ($status == 10) break
echo -n "Hit RETURN when the tape is online: "
echo $< > /dev/null
end
foreach file (`cat /usr/tmp/fl$$`)
dd obs=13200 cbs=132 conv=ibm,block files=1 if=$file of=/dev/nrmt8
end
mt rew
while (1)
echo -n "remote tape is on (hostname): "
set remote = $<
rsh $remote hostname >& /dev/null
if ($status == 0) break
echo "You don't have access to $remote"
end
while (1)
set remstat = `rsh $remote 'mt status >& /dev/null; echo $status'`
if ($remstat == 10) break
echo -n "Hit RETURN when the remote tape is online: "
echo $< > /dev/null
end
$CPTAPE /dev/rmt12 ${remote}:/dev/rmt0
mt rewoffl
rsh $remote mt rewoffl
# print the file list
if (`printenv | fgrep PRINTER` == '') setenv PRINTER kept-imagen
echo "printing list of tape contents to $PRINTER"
imprint /usr/tmp/fl$$
cleanup:
rm -f /usr/tmp/*$$
--->8--->8--->8---
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: 7 Jul 88 19:10:30 GMT
From: 1bhansen@teknowledge-vaxc.arpa (Bob Hansen)
Subject: Documentation on printcap?
I am trying to make an Epson LQ-850 jump through some hoops and I would
really appreciate some "quality" documentation on printcap. Specifically,
I would like to find out more about the flag masks and whether I can use
these to control some printer functions. I have been trying to use a
"trial and error" method to learn more about this but I am getting rather
frustrated. Thanks.
Bob Hansen
1bhansen@teknowledge-vaxc.arpa
or this newsgroup
[[ The "flags" masks are flags for the tty driver. See the manual page
tty(4). One set of flags effects the "sg_flags" field in the struct
sgttyb, and the other ("xs" and "xc") effects the "local mode" flags.
Don't forget the leading "0" in printcap to indicate that they're octal!
There is a document called "4.2BSD Line Printer Spooler Manual" that was
distributed with 4.2. It is buried somewhere deep within one of the Sun
manual sets. Probably in one of the system manager manuals. --wnl ]]
------------------------------
Date: 8 Jul 88 19:33:32 GMT
From: helios!carter@uunet.uu.net (Mike Carter)
Subject: Network Licensed Software Pricing (LONG)
[[ This long message is the last one in this issue of the digest. --wnl ]]
A Pricing Strategy for Network Licensed Software July 8, 1988
------------------------------------------------
The concept of licensing software to a network of workstations,
rather than to a single CPU, is becoming increasingly attractive as large
workstation networks become more common. The cost and power of workstation
hardware has reached the point where it is practical to assign a workstation
to an individual design engineer as a private desktop resource. A SUN 3/60
workstation (or comparable workstation) can address much of the broad
spectrum of daily activities of an individual designer. However, the cost
of licensing many different software packages on a per-designer (single-CPU)
basis quickly becomes prohibitive, particularly when most of those packages
will be used only occasionally.
Network software licensing allows a pool of workstations to share
access to a smaller number of copies of a particular software package.
Any of the workstations may run the software package, but while they are
doing so, they "lock up" one copy of that software, so that all other
workstations have one less copy available to draw upon. The number of
copies of a particular software package which are required to service a
network of workstations is highly dependent on the software usage "duty
cycle". The more often a particular software package is used (a reasonable
measure of the "value" of a software package), the more necessary it will
be to have a large number of copies accessable to the network.
A number of software vendors have privately expressed their
willingness to support the concept of network software licensing. However,
very few of them appear to have decided on a formal pricing strategy. One
approach, which provides a reasonable balance between the interests of
vendor and purchaser, and is easy to implement and maintain, is outlined
below. The suggested pricing formula for network software licensing is
very straightforward. It is simply:
Network_size - Network_licences
Net_price= Std_price * { 1 + Net_factor * ------------------------------- }
Network_size
where
Net_price= cost per "networked" software licence
Std_price= standard "single-CPU" licence price
Net_factor= cost weighting factor for network licensing
(0 < Net_factor < 2.0)
Network_size= number of workstations in the desired network licensing
"pool" (this number may be different for different
software packages)
Network_licences= number of networked licences actually purchased
so that the total licensing cost for each software package used in a
network will be:
Net_total= Network_licences * Net_price
The fixed value chosen for "Net_factor" will clearly impact the
overall cost of a network licensed software package. Software vendors
will prefer this value to be as high as possible, and software buyers
will prefer a value which is as low as possible. If "Net_factor" is zero,
then a network software licence costs the same as a single-CPU licence.
If "Net_factor" is 2.0, then it costs as much to buy one network software
licence which could be shared by two stations, as it would to buy two
single-CPU licences for those stations. These two conditions provide
the limiting values for "Net_factor". A suggested "reasonable" value
for this parameter is:
Net_factor= 0.50
This value produces a 25% increase in the base price of a unit
licence, when that licence is "shared" by two machines. This seems a fair
increment to pay for the flexibility of being able to run one copy of
software on either of two workstations, when only one workstation at a
time may access that software copy.
The above formula for networked software pricing also applies
to subsequent purchases of the same software package. A reasonable
implementation of network software licensing facilitates further purchases
of a software package, as increased access requirements or network size
require. Future expansion can occur in several ways: the network can grow,
while the number of licensed software copies remains constant; the number
of licensed copies can increase, while the network size remains constant;
or growth can occur in both number of licensed copies and in network size.
Under any of these circumstances, there is a net positive additional fee,
which is simply given by:
Additional_fee= Net_total(new) - Net_total(old)
where
Net_total(new)= total licensing cost calculated using the new values
of Network_size and Network_licences, and the current
standard single-CPU licence price
Net_total(old)= total licensing cost calculated using the old values
of Network_size and Network_licences, and the CURRENT
standard single-CPU licence price
Use of only the current value of "Std_price" in all parts of the
computation of "Additional_fee" eliminates all concerns about aberrations
caused by past pricing policies. At all times, the calculation of the
current price for a networked software licence is based on the current
price for a standard single-CPU licence.
Note that as the number of networked licences approaches full
deployment (one licence for every station in the network), the proposed
pricing strategy degenerates to the current pricing strategy for multiple
copy single-CPU licences. Software buyers who prefer to license one
copy of a software package on every workstation will not be penalized by
the suggested pricing strategy. At the other end of the spectrum, as the
number of network workstations becomes much larger than the number of
network licences, the incremental cost of adding yet another workstation
to the network approaches zero. This is reasonable, because the value of
a network licence which is shared between 1000 stations is really very
little more than its value when shared between 500 stations; in practice,
none of the stations will be able to obtain access to it when they need to!
There is a possibility under the proposed network software licensing
strategy that vendors would feel that they have less incentive to improve
the speed of their software. If a software package runs slowly, it will be
tied up longer by each workstation, so more copies could be required to
service the overall network (leading to greater sales for the vendor).
This situation will be prevented in two ways. Firstly, faster software
tends to command a higher base price than comparable slower software. This
will increase the vendor's return on that product, because the base price
is the starting point for the networked license price. Secondly, market
forces will tend to select the more efficient software packages for survival;
vendors with slow software will tend to go out of business, because execution
time is usually a major factor for frequent users of a software package.
Software vendors will find it easy to maintain the above network
license pricing strategy. Under existing single-CPU licensing strategies,
vendors already maintain records of licensed customer workstation host IDs,
and therefore already know the number of workstations in the licensed
"network". Vendors also know their own current single-CPU licence prices.
The value for "Net_factor" would probably be a vendor constant (perhaps
even an industry constant), but could be fixed on a per-customer basis
if the vendor chose to do so. The only additional information a vendor
would need to record is the current number of network licences for each
separate software package they have sold to a customer; this is a minimal
additional burden on the software vendor!
The above proposal is very basic. It is described in some detail
in order to explore some of the implications of a network licensing
strategy. The need for network software licensing is quite clear in the
new era of large workstation networks. If software buyers and vendors
agree with this proposal, then I would hope for its implementation in a
reasonably timely manner. If software buyers or vendors can suggest
better alternatives, then I would welcome their comments.
Mike Carter
Semiconductor Division
Mitel Corporation
360 Legget Drive
Kanata, Ontario K2K 1X5
Canada
UUCP: ...uunet!helios!carter
Telephone: (613) 592-2122 x3326
FAX: (613) 592-4784
------------------------------
End of SUN-Spots Digest
***********************