HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"TERRY@spcvxa.spc.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 15 Sep 92 01:19:22 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Limiting access to outgoing mail.
Newsgroups: bit.listserv.pmdf-l

One additional point -- when I was testing the new quota code I happened
to try delivering mail across a DFS disk connection. The quota check
failed because the proxy account on the remote node has EXQUOTA (it has to
have it) and DFS didn't know that I had EXQUOTA privilege temporarily
disabled on the client side. So you can add proper handling of both
holdexquota and noexquota to the list of things DFS breaks when you
try to deliver mail across it.

This is all to one side of Terry's original questions (and answers) but
since DFS was discussed on info-pmdf recently I thought I would mention
this.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: bit.listserv.ashe-l
Date:         Mon, 14 Sep 1992 14:24:01 PDT
              <ASHE-L@MIZZOU1.BITNET>
From:         "Tamara M. Scott" <AS00TMS@UCSBVM.BITNET>

I sent the message "Index ASHE-L" to the Listserv@mizzou1 and
received back the response: "Index ASHE-L is unknown to LISTSERV."

I also received another message after a query stating that I am not
signed up to list ASHE-L.

Please let me know how to remedy these situations.  Thanks--TS
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Thu, 10 Sep 1992 09:51:33 EDT
Reply-To:     David Hopkins <DHOPKINS@ERS.BITNET>
From:         David Hopkins <DHOPKINS@ERS.BITNET>
Subject:      OS/2 Base SAS and MS SQL Server

Dear SAS Types,

Can OS/2 Base SAS access MS SQL Server data or Oracle file server data?

Do you need to purchase another module from SAS to do this?  SAS/Access?




--David Hopkins

+----------------------------------------------------------------------+
| David Hopkins, Programmer/Analyst| BITNET:  DHOPKINS@ERS             |
| US Department of Agriculture     | Tel:     202-219-0491             |
| Economic Research Service        | Fax:     202-219-1292             |
| Data Services Center, rm. 308    |          (ATTN: Rm 308)           |
| 1301 New York Ave., NW           |also, INTERNET: DHOPKINS@ERS.BITNET|
| Washington, DC  20005-4788       |                                   |
+----------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <HILL@CMSUVMA>
Newsgroups: bit.listserv.sas-l
Date:         Tue, 15 Sep 1992 08:43:25 CST
Reply-To:     Nancy <HILL@CMSUVMA.BITNET>
From:         Nancy <HILL@CMSUVMA.BITNET>
Subject:      MWSUG'92 Demo and Hands-on Update

Demonstration Area

Come by to see software demonstrations and learn more about new
services from SAS Institute Inc.  For the first time at MWSUG, the
Institute will present new software products and features
in a theater-style presentation area.  Topics include data analysis,
applications development, financial spreadsheets, cooperative
processing, and total quality management.

In addition to exhibits from SAS Institute, representatives from strategic
third-party hardware vendors will demonstrate their latest
product offerings and be available to answer your questions.

NOTE: Hewlett Packard will be raffling off a computer to those who
sign up at the exhibit area. This will happen at closing session but the
winner will not have to be present to win.

You'll also have an opportunity for hands-on experience at the local
IBM office which is located next door to the Hyatt Regency Crown
Center.
Seats are reserved on a first-come, first-serve basis.
Sign up at the MWSUG registration desk on Wednesday, September 30 or
in the Demonstration Area on Thursday, October 1.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Sep 1992 10:38:51 -0500
Reply-To:     Kernon Gibes <gibes@SWIRL.MONSANTO.COM>
From:         Kernon Gibes <gibes@SWIRL.MONSANTO.COM>
Subject:      RE: Response - Creating a long macro variable.
Comments: To: SAS-L@uga.cc.uga.edu@tin.monsanto.com
Comments: cc: GIBES@tin.monsanto.com

Regarding Perry's posting...

>Regarding Kernon Gibes' [sic] comments on Bob Snyder's response to the looong
>macro variable question, yes Bob's suggestion does work.  (See test below
>run successfully under VM/CMS.)  According to the SAS Guide to Macro
>Processing V5, Appendix 2, the max length of the macro variable is
>controlled by the MWORK= system option with a default of 2k (2048 bytes)
>and max value of 28k.  I agree with Bob, however, that there must be a
>more elegant solution than concatenating a huge macro variable.
>Regardless, his code works fine.
>
<stuff deleted>

1) Yes, I was wrong about the limit on macro variable lengths.

2) No, Bob's code does not work fine.  Try testing it on the ACTUAL
   situation; that is, where POSSANS has length of 200 characters.
   (Or, say, two records of 150 each).  Perry's test case does work,
   but it wasn't what Helen was dealing with.  For example, see the
   extension of Perry's code below where we finally get truncation.

3) Bob's code didn't include a COMPRESS, which was my second point.
   However, this doesn't solve all the problems because the character
   string expression in the second argument of SYMPUT is, I believe,
   subject to the 200 byte limit imposed on data set character
   variables [ hopefully, I have this limit correct?  ;-) ]

Kernon Gibes


Modified test code:

Data temp;
  Input varnum $ possans $;
cards;
01 Jack
02 and
03 Jill
04 ran
05 up
06 the
07 hill
;
Run;

data longer;
  set temp temp temp temp temp temp temp temp temp temp temp;
run;

%let mvar = ;
Data test;
  set longer;
    Call Symput('mvar',Symget('mvar')||' '||compress(possans));
Run;

%put mvar = &mvar; run;
/*** end of test code ***/

Produces:

mvar =  Jack and Jill ran up the hill Jack and Jill ran up the hill Jack and
Jill ran up the hill Jack and Jill ran up the hill Jack and Jill ran up the
hill Jack and Jill ran up the hill Jack and Jill ran u
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.2 PL16]
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Sep 1992 11:47:00 CDT
Reply-To:     "R. Snyder" <rsnyder@LOBBY.TI.COM>
From:         "R. Snyder" <rsnyder@LOBBY.TI.COM>
Subject:      RE: Lo...ng macro variables
Comments: To: gibes@SWIRL.MONSANTO.COM
Comments: cc: sas-l@uga.cc.uga.edu
              92 10:38 am

SUBJECT:   Lo..ng Macro Variables
SUMMARY:   Getting past 200 characters
E-ADDR:    rsnyder@lobby.ti.com
NAME:      Bob Snyder
COMPANY:   Texas Instruments, Sherman, TX
PHONE:     (903) 868-5799
FAX:       (903) 868-7240
>
> 2) No, Bob's code does not work fine.  Try testing it on the ACTUAL
>    situation; that is, where POSSANS has length of 200 characters.
>    (Or, say, two records of 150 each).  Perry's test case does work,
>    but it wasn't what Helen was dealing with.  For example, see the
>    extension of Perry's code below where we finally get truncation.
>
> 3) Bob's code didn't include a COMPRESS, which was my second point.
>    However, this doesn't solve all the problems because the character
>    string expression in the second argument of SYMPUT is, I believe,
>    subject to the 200 byte limit imposed on data set character
>    variables [ hopefully, I have this limit correct?  ;-) ]
>
> Kernon Gibes
>
The test code below addresses the 200 character limit on the expression
symget('mvar')||... .

As for point 3, my intent was to suggest a method of concatenating macro
variables in a data step. I was not trying to write the whole program.

Regards,
Bob

/* ------------------- Test Code -------------------- */

%macro concat;

  %do i = 1 %to &vars;
    %let mvar = &mvar%str( )&&mvar&i;
  %end;

%mend concat;

Data temp;
  Input varnum $ possans $;
cards;
01 Jack
02 and
03 Jill
04 ran
05 up
06 the
07 hill
;
Run;

data longer;
  set temp temp temp temp temp temp temp temp temp temp temp
      temp temp temp temp temp temp temp temp temp temp temp
  ;
run;

  %let mvar = ;
Data test;
  set longer;
    Call Symput('vars', left(_n_) );
    Call Symput('mvar'||left(_n_), compress(possans));
Run;

%concat;

%put &mvar; run;
/*** end of test code ***/

The result:

 Jack and Jill ran up the hill Jack and Jill ran up the hill Jack and Jill
ran up the hill Jack and Jill ran up the hill Jack and Jill ran up the hill
Jack and Jill ran up the hill Jack and Jill ran up the hill Jack and Jill
ran up the hill Jack and Jill ran up the hill Jack and Jill ran up the hill
Jack and Jill ran up the hill Jack and Jill ran up the hill Jack and Jill
ran up the hill Jack and Jill ran up the hill Jack and Jill ran up the hill
Jack and Jill ran up the hill Jack and Jill ran up the hill Jack and Jill
ran up the hill Jack and Jill ran up the hill Jack and Jill ran up the hill
Jack and Jill ran up the hill Jack and Jill ran up the hill
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Mon, 14 Sep 1992 17:54:00 EDT
Reply-To:     Phil Bardsley <UPHILB@UNC.BITNET>
From:         Phil Bardsley <UPHILB@UNC.BITNET>
Subject:      Re: compressed needs more space

Cindy Kester writes:

>I was surprised to get this message when I compressed a large dataset.
>I expected the file to take much less space than before.  Has anyone
>else had this happen?

NOTE: Compressing data set OUT1.PRICES increased size by 22.43 percent.
      Compressed is 23797 pages; un-compressed would require 19438 pages.
NOTE: The DATA statement used 192.87 CPU seconds and 3744K.

In a recent SUGI paper by Beatrous and Stokes, the authors noted that
it is possible for a compressed file to be larger than a noncompressed
file.  This is because in release 6.07 (MVS) SAS introduced the lean-
file format, which has an overhead of 1 bit per obs.  However, when
compressing a file, they have to add 12 bytes per obs.  So, presumably
with very short observations (which give little to compress), the
12-byte overhead will be larger than any savings due to compression.
They say the 12-byte overhead is necessary to manage compressed data.

Phil Bardsley, UNC-Chapel Hill
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Sep 1992 15:49:44 EDT
Reply-To:     Howard Schreier <HIS@NIHCU.BITNET>
From:         Howard Schreier <HIS@NIHCU.BITNET>
Subject:      PRINT Col. Width

CONTENT:  Comment
SUMMARY:  Interaction of FORMAT & PRINT Seems Curious

> From:         "Nelson R. Pardee" <SASMAINT@SUVM.BITNET>
>
> About a month ago I wrote to SAS-L:
> > Without a format, PROC PRINT prints vars using BEST12.-
> > almost! If it doesn't need 12 columns, it uses fewer.  It's
> > nice that if the values falling on a given page are small,
> > it uses fewer columns. I have a variable with a wide range
> > of values- sometimes more than 12 digits, so they are
> > printed in exponential format, which is unacceptable.  I
> > don't want to use a format statement like format var
> > BEST15.; since then the variable will be printed using 15
> > columns even if it doesn't need that many.  Any suggestions
> > on how I can get it to not use exponential format for larger
> > values, but still use the minimum number of columns?
>
> [stuff deleted]
>
> 31         proc format;               *Now- the solution;
> 32          value x (default=20) ;
>  ------------------------------------------------------------------
> 34         proc print data=x;
> 35          title 'Print numbers w/special format. All digits printed';
> 36          format x x.;
>
> OBS          X           N
>  1                 10    1
>  2       123456789012    2
>  3      1234567890123    3
>  4      12345678901.3    4
>  5     123456.7890123    5
>  ------------------------------------------------------------------
> 39 proc print data=x(where=(n=1));
> 40 title 'Print 2 digit number w/special format. Uses minimum columns';
> 41          format x x.;
>
> OBS    X     N
>  1     10    1

I'm glad that Nelson wound up  with  a  good  solution  (the
thoughts  I  shared  with  him  at  the  time were basically
pessimistic), but I'm not quite  sure  I  understand  what's
going on.

I had dismissed the DEFAULT option as  a  possible  solution
because  I  interpreted it to mean that "FORMAT X X.;" would
be processed like "FORMAT X X20.;", which would  force  PROC
PRINT  to use 20 columns, which is of course the opposite of
what Nelson wanted to do.

Also, it's curious that "VALUE X (DEFAULT=20) ;" is accepted
as  a complete VALUE statement, since the FM (SAS Procedures
Guide, V.6, 3rd Ed.) says  (p.   291,  bottom):   "You  must
specify one or more ranges in the VALUE statement."

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\   Howard Schreier, U.S. Dept. of Commerce, Washington    /
/                     MVS 5.18 & 6.07                      \
\   Voice: (202) 377-4180        BITNET: HIS@NIHCU         /
/   Fax:   (202) 377-4614      INTERNET: HIS@CU.NIH.GOV    \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-receipt-to: bl.stachoviak@UWMSG.HOSP.WISC.EDU
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Importance: normal
Priority: non-urgent
UA-content-id: NOTE 09/15/92 11:58:24 BLS0
X-Hop-count: 2
Newsgroups: bit.listserv.sas-l
Date:         Tue, 15 Sep 1992 12:05:14 -0600
Reply-To:     Brad Stachoviak <bl.stachoviak@UWMSG.HOSP.WISC.EDU>
From:         Brad Stachoviak <bl.stachoviak@UWMSG.HOSP.WISC.EDU>
Subject:      NOTE 09/15/92 11:58:24 BLS0
Comments: To: SAS-L@OHSTVMA.ACS.OHIO-STATE.EDU

---- SUBSCRIBE SAS-L BRAD STACHOVIAK
From: richardh@EPISUN.EPIDEM.UWA.EDU.AU (Richard Hockey)
Newsgroups: bit.listserv.sas-l
Subject: Re: numbers in SAS
Date: 10 Sep 92 02:00:56 GMT
Reply-To: Richard Hockey <richardh@EPISUN.EPIDEM.UWA.EDU.AU>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: Ezmail v3.8 <Thu Sep 10 08:39:08 1992 richardh>
Status: U
Comments: To: sas-l@ohstvma.acs.ohio-state.edu

In reply to the mail from <SAS-L@OHSTVMA.ACS.OHIO-STATE.EDU>...
-------------------------------------------------------------------------------
>Hi folks,
>  Can someone explain to me how numbers are represented in SAS?  I have a
>giant dataset and am trying to create a SAS dataset.  I want to save
>as much space as I can so I began defining numbers with fewer than
>8 bytes.  It appears that I will need at least 4 bytes if the number
>has several decimals.  Can someone verify this before I do something
>really stupid.  I ran a little test which is attached.  If someone
>could give me some guidelines on reading/storing numbers I would
>really appreciate it (the manual, Basics p. 157, has some information
>on the largest numbers, but nothing on decimals which most of my
>numbers have).

The best way we have found of saving space when creating large SAS datasets
containing short integers such as found in survey data is to save them as
character variables then depending on the max length of the integer you
may only require a length of 1.
If your data has decimal values then a numeric length 8 is required.
If any of your variables are integer but you intend to use them in procs
such as means, univariate etc you would need them to be stored as numeric
but at a shorter length (3 or 4 is usually sufficient), otherwise SAS does
the char to num conversion on the fly.

| Richard Hockey                    email:richardh@episun.epidem.uwa.edu.au   |
| Department of Public Health       phone:+61 9 389-3463        _--_|\        |
| University of Western Australia   fax:  +61 9 389-3648       /      \       |
| NEDLANDS WA 6009                                             *_.--._/       |
| Australia                                                          v        |
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.2 PL16]
Newsgroups: bit.listserv.sas-l
Date:         Thu, 10 Sep 1992 19:01:17 CDT
Reply-To:     "R. Snyder" <rsnyder@LOBBY.TI.COM>
From:         "R. Snyder" <rsnyder@LOBBY.TI.COM>
Subject:      Re: Creating a loooooong macro variable
Comments: To: STROTHHM%SNYONEVA.BITNET@uga.cc.uga.edu
Comments: cc: sas-l@uga.cc.uga.edu
              92 6:57 pm

SUBJECT:   Reply to Creating lo...ng macro variables
SUMMARY:   Concatenating macro variables in a data set
REL/PLTF:  6.07/HP300
E-ADDR:    rsnyder@lobby.ti.com
NAME:      Bob Snyder
COMPANY:   Texas Instruments, Sherman, TX
PHONE:     (903) 868-5799
FAX:       (903) 868-7240
>
> Hi all,
>         I am running SAS 6.07 under VMS.  I have a data set which contains two
> variables which is related to a dataset containing responses to a political
> questionnaire.  The first data set looks like the following:
>
> VAR             POSANS
> 0001            001002003004005
> 0002            001002003004005006007009
>
> VAR is the name of the variable in the questionnaire and POSANS are all the
> possible answers to that variable.  I won't go into why I need to do this, but
> I have a macro which generates all the possible combinations of answers to any
> two to five variables.  Everything was working fine until I discovered that
 the
> 200 length for character variables is too short to hold all the possible
> answers to some of the variables.  I create a macro variable to hold the
 values
> What I was wondering is if some of the variables took up two or three
> observations in the data set like:
>
> 0001            001002003004005006......
> 0001            201202203204205.....
>
> could I still get all the possible answers from the two observations into the
> same macro variable?  Any ideas?  By the way, if you're sick of reading my
> macro questions, I am currently begging my boss to send me to the SAS macro
> class.  In the meantime, I only have SAS-L.
>
> As always, thanks in advance.
>
>                 Helen Strother  STROTHHM@SNYONEVA
>
Helen,

Try something like this, although inelegant, I think it will work.

  call symput( 'mvar', symget( 'mvar' )||cvar );

Regards,
Bob
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Sep 1992 09:13:09 EDT
Reply-To:     Andy Norton <76350.1604@COMPUSERVE.COM>
From:         Andy Norton <76350.1604@COMPUSERVE.COM>
Subject:      Numerical precision in comparisons
Comments: To: SAS-L <SAS-L@AWIIMC12.IMC.UNIVIE.AC.AT>

----------------------------------------------------------------------
CONTENT:    Opinion
SUMMARY:   Wishlist item:  "FIXED DECIMAL" numeric variable type
REL/PLTF:  6.07.01/CMS, 6.04/PC-DOS
E-ADDR:    76350.1604@compuserve.com
NAME:      Andy Norton
ADDRESS:   Trilogy Consulting, 5228 Lovers Lane, Kalamazoo MI 49002
PHONE:     (616) 344-2191
----------------------------------------------------------------------

Phil Miller suggests

> There has been a good deal of discussion over the last few days
> about numeric comparisions and several excellent discussions about
> some of the underlying facts about how computers store floating
> point numbers and how SAS stores numbers.  I am interested in
> whether there is any consensus among the SAS-L users about whether
> there are things that could be changed and therefore that ought to
> be on the SASWARE Ballot or whether it is just an education problem.

If I let myself dream, I come up with a fixed decimal variable type (or
subtype of numeric).  This would not only allow us to do comparisons
with decimal values, but to do arithmetic and compare the results
(with no hassles).

I'm no expert on the implementation, and it's been done in many other
languages, but it would have properties such as (if I get this
right):
    Comparison between FIXED (m) and FIXED(n) or literal compares
       max(m,n) decimals.
    Comparison between FIXED and FLOAT converts the FIXED to FLOAT and
       you take your chances.
    Addition/Subtraction results have max(m,n) decimals
    Multiplication has m+n decimals
    etc.
Note that the "number of decimals" propagation is computed at compile
time.

In other words, rounding to a known number of decimals occurs
automatically.  Speaking for myself, I think I could live with the
value actually being stored as float, and rounded only at comparison
time.

This discussion has made it obvious that some of us work in "float"
environments and others of us are trying to emulate "fixed decimals".
I am in the latter camp, and over the years I have encountered a number
of angry users who insist "SAS has a bug" because 120.04-120 is not
.04.

I understand the desire to avoid unneeded complexity (that's why I am
in SAS not a traditional language), but the solution to this was known
back in 1960 or so.

                          Andy
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Organization: from SUNY College at Oneonta, NY 13820
X-Envelope-to: sas-l@uga.BITNET
X-VMS-To: IN%"sas-l@uga"
X-VMS-Cc: STROTHHM
Newsgroups: bit.listserv.sas-l
Date:         Thu, 10 Sep 1992 18:57:00 EDT
Reply-To:     Helen Strother <STROTHHM@SNYONEVA.BITNET>
From:         Helen Strother <STROTHHM@SNYONEVA.BITNET>
Subject:      Creating a loooooong macro variable

Hi all,
        I am running SAS 6.07 under VMS.  I have a data set which contains two
variables which is related to a dataset containing responses to a political
questionnaire.  The first data set looks like the following:

VAR             POSANS
0001            001002003004005
0002            001002003004005006007009

VAR is the name of the variable in the questionnaire and POSANS are all the
possible answers to that variable.  I won't go into why I need to do this, but
I have a macro which generates all the possible combinations of answers to any
two to five variables.  Everything was working fine until I discovered that the
200 length for character variables is too short to hold all the possible
answers to some of the variables.  I create a macro variable to hold the values
in posans as follows;

                 data _null_;
                    set convert.ftdes;
                    where var="&&reco&c";
                    call symput('pans',posans);
                 run;

&&reco&c holds the variable number, for example 0001.

What I was wondering is if some of the variables took up two or three
observations in the data set like:

0001            001002003004005006......
0001            201202203204205.....

could I still get all the possible answers from the two observations into the
same macro variable?  Any ideas?  By the way, if you're sick of reading my
macro questions, I am currently begging my boss to send me to the SAS macro
class.  In the meantime, I only have SAS-L.

As always, thanks in advance.

                Helen Strother  STROTHHM@SNYONEVA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Pmrqc:      1
X-Mailer:     Pegasus Mail v2.3 (R3).
Newsgroups: bit.listserv.sas-l
Date:         Thu, 3 Sep 1992 13:12:25 EDT
Reply-To:     Tom Frenkel <FRENKEL@CPMAIL-AM.CIS.COLUMBIA.EDU>
From:         Tom Frenkel <FRENKEL@CPMAIL-AM.CIS.COLUMBIA.EDU>
Subject: Re: SAS WHERE feature
Comments: To: SAS-L@uga.cc.uga.edu

> Date:          Thu, 3 Sep 1992 11:14:54 EDT
> From:          Howard Schreier <HIS%NIHCU.BITNET@uga.cc.uga.edu>

>                              The global SAS WHERE, as useful
> as it is, is restricted in terms of  the  expressions  which
> can  be  coded; for example, functions cannot be used.

This *was* true in 6.06, but as I understand it, in 6.07 the SAS
WHERE statement and data set option *will* accept functions.
                                            --Tom
-------
Tom Frenkel,    Columbia-Presbyterian Medical Center,
161 Ft. Washington Ave.,  DAP-1310,  New York, NY 10032-3784  USA
Internet:  FRENKEL@CPMAIL-AM.CIS.COLUMBIA.EDU
<<< Opinions expressed not necessarily those of my employer >>>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU