Sun-Spots Digest, v6n145

[William LeFebvre]

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 at rice.edu
Send subscription add/delete requests to:  sun-spots-request at 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 at rice.edu" or mail the word "help" to the same address
for more information.

----------------------------------------------------------------------

Date:    8 Jul 88 17:45:13 GMT
From:    mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: file `which which` mystery solved

Don Kark (wiley!don at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
***********************