Date: Fri, 17 Apr 1998 09:04:33 +0000
Reply-To: "Karsten M. Self" <kmself@IX.NETCOM.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: "Karsten M. Self" <kmself@IX.NETCOM.COM>
Organization: Self Analysis
Subject: Linux version of SAS -- Technical issues
Content-Type: text/plain; charset=us-ascii
This message is being cross-posted to comp.soft-sys.sas and
comp.os.linux.development.apps. It's a continuation of an ongoing
thread in sas-l/c.s-s.s on the possiblity of a SAS port to Linux, I'd be
interested in notes from others with similar porting experience from
I am not closely familiar with development, C, SAS, or Linux, and am
looking for feedback from those who are. I know in particular that
several database products have been or are being considered for Linux,
including Oracle, Informix, and Sybase. I would imagine that many of
the binary compatibility and I/O issues would be similar for both SAS
and these products.
There has been user interest expressed recently in seeing a version of
SAS (http://www.sas.com) for Linux (http://www.linux.org). This is not
likely in the short term (6-9 months), but may be a possiblity in the
12-24 months (my assessemnt based on several contacts). The key issue
is ultimately commercial viability and initiative from SAS's management,
which is a seperate discussion. This post addresses technical aspects
of porting commercial software to Linux.
I spoke Thursday afternoon with SAS's manager of Unix hosting
development regarding technical issues involved in porting to Linux.
These are my comments based on my notes, see disclaimer below.
The Unix hosting group supports SAS for Unix under ABI, MIPS, SPARC,
HPUX, AIX, Digital Unix, and Alpha architectures in SAS Version 7.
Discussion focussed on x86 Linux only (I meant to ask about Alpha and
other platforms -- suspect that they would be treated as seperate
projects). Technical issues in porting to Linux are not thought to be
significant. The problem is less one of targeting any Linux and
creating a port, it's of limiting the required range of support which
would be required for Linux.
I couldn't get a cost estimate, but I would believe that it is
considerably below the $6m figure quoted at SUGI (annual user's
conference). A partial port, especially a non-GUI port, might
significantly reduce both development and testing time.
The primary issues surround SAS's support policy (all you can eat, and
generally quite good), and the liability that this might create should
Linux be supported.
The lack of a standard Linux was mentioned. I asked whether this
referred to the kernel, libraries, GUI/window manager/toolkits, or
what. My general impression that this impression is based on general
experience of issues in porting to various platforms but not with
specific known problems with Linux. There are significant concerns
which may depend on low-level and/or core Linux features, for which
variablility would be costly.
- How have other vendors addressed this issue?
- How much variance *is* there among production (stable) kernel
Cited examples of issues which might be confounded by non-standard Linux
- memory caching by the kernel
- various I/O issues (SAS applications tend to be very I/O intensive,
and SAS on Unix typically includes capabilities to read and write from
disk, tape, network (ftp, url), pipes, and FIFO named pipes). These
could be affected by drivers, by users/administrators modifying drivers
and/or kernel-level support. SAS would like to minimize any variability
in this area. A mentioned possibility is that SAS/Linux might only be
available if it shipped/bundled with *the* version of Linux the
customer was to use.
- GUI. SAS uses Motif for its Unix windowing interface, which isn't
typically found on Linux boxes. It is available for $50 - $150 from
Redhat and other vendors, if required.
- Large file/filesystem support. All Unixes supported by the next
release (V7) of SAS will have native support for files > 2 GB. I
believe this is accomplished through 64 bit addressing, I'm not
intimately familiar with the details. This is a requirement.
I've seen a number of usenet posts suggesting Linux is generally 64 bit
under Alpha, or under all HW, but this could stand to be clarified.
In particular, SAS requires the following capabilities:
o > 2 GB file size
o > 2/4 GB filesystem size
...I am not sure what the minimum addressable RAM is, but know that
SAS currently runs on machines with in excess of 12 GB for data
SAS participated in a Unix large file support group, conference papers
are available at
Large File Support".
- Binary standards. SAS is part of the IABI (Intel Application Binary
Interface) group, (http://www.metrolink.com/abi/index.html), which
provides a single standard for developing Intel architecture Unix
applications. IABI+ members include SAS, Metro Link, and Metaware on
the apps side, SCO and Sun on the OS side.
A similar group, 86Open (http://www.telly.org/86open) was organized last
year for the same purpose. This is thought to be a redundant effort.
86Open's target platform list is larger than IABIs. It is also
unimplemented (though work is in progress). Neither group charges
dues. SCO is a member of both groups. SAS has dropped support of the
SCO x86 platform.
Comments anyone? Is Linux IABI compliant? Apparently this would
greatly facilitate porting and support, and could be very attractive to
SAS and other vendors. Is this attraction enough? What other
application standards/organizations exist? Do they do any good?
Odds 'n' Ends:
- Specific hardware requirements (eg: HW compatibility list) would most
likely *not* be required. (Minimum system resources -- RAM, disk,
likely would. 16/80 should be sufficient).
- I mentioned the possibility of altering SAS's support agreement for
Linux (this would have to go through marketing). Possibilities (my
thoughts) include seperate support contract, Linux vendor support of OS
issues (maybe a "green line" dividing SAS from Linux issues?). Would
this be necessary?
- Do the recent TOG/XFree86 developments have any effect X Window
support? (Background: http://slashdot.org/articles/9841102444.shtml)
These are my words and views.
This is not a statement or policy of SAS Institute.
I am not an employee of SAS Institute, just an avid user.
I have taken myself too seriously.
Karsten M. Self (firstname.lastname@example.org)
What part of "gestalt" don't you understand?