Readers comment on 64-bit issues.

This is a selection of comments by readers responding to our survey of attitudes towards 64-bit SPARC-based systems. (Reminder: SunWorld Online is not a Sun company but an independent publication.)

Our biggest problem is rounding errors for financial information, 32-bit Unix computers can not handle longs large enough to carry the information as integers and floats are not accurate enough. Other alternatives, writing our own math sub-system, is not practical for performance and compatibility with C.

I think all Unix computers for financial applications will be 64-bit in just a few years from now. Selling 32-bit computers will be about like selling 286's now.

This was tough to fill out because I work for Sun as a technical resource for large ISV's, specifically EDA vendors. I tried to answer for *my* needs, but I think the more interesting answers would have been for my customers needs (i.e. the reason that I exist in this company).

Specifically, my customers write EDA software, and in particular, the simulation and IC verification software is pushing the 32-bit limits. In both areas, the vendors I've worked with have had to work-around some minor problems in order to help their customers exceed 2GB of data, and they expect to push up against 4GB within the next year.

For what it's worth, I'm not aware of any EDA customers who have actually hit the 4GB limit, however, I do know of some who have surpassed 2GB.

So far it's only been a very few end-users who have presented these problems to the vendors I support, however, they also tend to be the *big* customers. They point is that the EDA vendors have a strong desire to address this niche (which will only grow).

So, I hope your survey reaches, for example, Mentor Graphics and Cadence.

The article did catch my interest and hope in a unified API for a 64 bit unix, besides the spec 1170 standard. Due to database constraints, speed and the future viability of a Unix industry. its about time.

Sun MUST roll this systems out as quickly as possible. Even in the face of shrinking HW margins, they must get out the door.

Sometimes previous generation code passes 32 bit pointers to another machine to use as a handle. It is *very* important that the compiler support a switch that makes all pointer data types 32 bits even in a 64 bit environment. This will allow us to port our applications quickly and generate the revenue that we need to do a proper job. DEC did the job half way -- their compiler supported a switch that guaranteed that only the 32 lsb of a pointer would be used. This was a start, but it still didn't do the job for us because common header files are used to develop software for dissimilar architectures.

The decision to stay with Sun SPARC systems is not up to me. My experience and current technology say it's too little too late.

Sun was a good solid workstation. But that is not enough when you are dead slow.

6. Please characterize your organization's use of SPARC computers in the next 12 months: How about "Add NEW SPARC workstations"

Our computer lab began with two DEC VAXStations (about 5 years ago), added three SPARCStations (1 & 1+'s), then "discovered" HP-9000/700 series systems. Four HP's later, we added an SGI Iris Indigo.

Our last three additions (in the past 90 days) have been two SPARC 20's and a DEC Alpha workstation. We may add one more SPARC 20 (new 75 MHz model) in the next 30 days.

In short, SPARC's have a presence, but facing stiff competition from HP, DEC and SGI. The performance of the new SPARC 20's against the DEC Alpha and older HP's (9000/730's) will be crucial for Sun's survival in our Operations Research Lab (ORLAB).

The excellent behavior of Solaris 2.4 has been a big plus. SGI's IRIX (5.3) is a royal pain, and HP-UX 9.0.5 has been problematic. I'm about to test-upgrade one HP to version 10.0. Our DEC Alpha is currently running Windows-NT, so I have no feel for their Unix flavor yet. I will also be installing Solaris x86 shortly on a Pentium.

This company creates prototype sonar system. As such, we process and store large amounts of data. Data throughput, processor speed, and addressing space, I believe, are our major concerns. Being at the bottom of the food chain, it is sometimes hard to tell. :)

It will also be especially important to have good support tools (compilers, debuggers, etc.) for development on the new 64-bit OS's. Code that was developed for 32-bit systems should be backwards compatible and should only require a re-compile to run.

Our primary uses for workstations are software development and some circuit design and simulation. We don't have a need for lots and lots of data. We always want our compiles to go faster but we also need to balance the speed with the number of seats we can afford.

I want to remain a mostly Sun shop but SPARC, I fear, has fallen so far behind they may not be able to recover.

We are looking forward to 64-bit systems for us to expand our data warehousing products. We are having to do quite a bit of work to accommodate large (2gig) files. Hopefully, this limit will go away when the 64-bitness hits. Several vendors that we deal with now are providing large file support. In addition, we are helping to drive the large file issue to many more vendors. I can get you more information on the "Large File Summits" if you like. It may be of interest to your staff.

What's most important to folks will still be the raw speed and IO performance. Software availability is still important but is less of an advantage for Sun nowadays. 64 bit computing can help in some limited applications but tends to impose adverse side effects for the rest of us. We use DEC AXP machines as well and the first thing you notice is the fact that the object code generated is 2-6 times bigger than the same code in a SPARC machine. This puts more stress on the disk storage issue and IO performance. Also, we have run into many porting issues where code assumes a certain word size for long int (for example) so that special AXP versions of code are required.

I've been using Suns since the Sun 2 days (a MIP was a big deal). Now that these machines are screaming along at 100-500 MIPS the throttle is provided by IO (both disk and network) and memory management. People always talk about all this CPU performance but nobody ever sees it because they forget Amdahl's rule and buy them with only 32MB. I suspect this trend towards 64 bit computing will exacerbate the problem even more. The performance numbers being touted are based on small code snippets (e.g. benchmarks) which don't tell you much about the real world. These hot box DECs we have aren't much faster at compilation/linking than my old SPARCs; not at all in proportion to the SPECint ratings. In your future coverage of 64 bit computing please dig deeper than just regurgitating the companies SPECmarks.

Instrumented OS is needed so we can look inside and determine what is happening to properly tune our applications. Looking for a real time instrumented operating system that runs on the main workstation/server platforms, not on a single board computer.

I would expect that we would begin to use 64 bit addressing in the next 2 years, but it will take that long for our application people to catch up.

We have been a SPARC shop for several years. We are very pleased with the performance and reliability of SPARC desktops. Sun has provided a very solid foundation for our ENTERPRISE computing needs.

However, we have grappled with the problem of finding software for the Unix desktop. DOS and the INTEL market have caused a good many problems with attempting to deploy client/server technologies. The average user has no concept of what multi-user, multi-tasking is nor the benefits of distributed computing. In fact, many Intel users BELIEVE that MS Windows on Intel is multi-tasking!! Thus, the multi-tasking argument is wasted on them.

This falsehood is even propagated by many of my peers who manage and recommend systems for their enterprise!! We have attempted to integrate the Intel PC population but they are decidedly a problem. User support, hardware configuration, reliability and ease of integration are always a problem with this class of machine.

Larger addresses might help, except that our code still has to be compatible with 32-bit machines, so we won't optimize for 64-bit machines for some time. Primarily, we need performance. The biggest negative impact is having to fix bugs introduced by 64-bit data types, especially in device drivers, which may have to be rewritten completely.

-- We still use many SPARCs, but the workstation of choice (for price/performance reasons) has become Silicon Graphics for most of our in-house use. Virtually ALL of our software has been written so that all we really need is any workstation that can run SVR4, X11R5 or R6, and Motif 1.2.2 or better; we can just re-compile for Solaris 2.4/2.5 (on SPARC, x86, and PowerPC as of last week), IRIX 5.3 on SGI, and even OSF/1 (or DECunix, or whatever they're calling it this week). We try to keep an open mind, though, and if the new UltraSPARCs offer better price/performance than the SGIs, we'll purchase them.

64-bit addressing is not particularly useful to us today, though it may be in the future; we can make use of 64 bit math on occasion, though, if it is not a whole lot slower than 32 on a particular machine; the MIPS R4600/R4400/R8000s give us this, and the UltraSPARC should fall into the same category as the R8000s. We have tried DEC Alphas, and have one in house still, but the other side of our work is real-time image processing, and the images come in as 8-bit; the Alpha is not as good as other RISCs at handling 8-bit data.

Solaris sucks - has all the speed of CP/M. Sun hardware barely keeping up with Pentiums. Sun's in real trouble if they don't get their act together soon.

Perhaps the questions to ask of your own marketing staff are these:

1) If DCE becomes predominant, does your SPARC line offer adequate MIPS to run it.

2) If encryption becomes predominant, does your SPARC line offer ade- quate MIPS to run it (remember 45 to 150 Opcodes per word to encrypt or de-crypt using classical encryption).

Use of 64 bit computing for Mechanical drawing, Circuit design and simulation is pending availability of suitably mature applications, which is not expected next year.

Our organization is at the point that if we had 64 bit OS's and had in house apps ported to it, then I feel confident in saying that is what we would definitely be using (mainly for the speed increases).

Sun is on a delicate position with us. Currently we have all Sparcs running 4.1.x (except for 1 Auspex fileserver) but have recently been considering allowing other brands to enter the forum. With the Ultrasparc, Sun has bought itself some time with us. If it had been delayed any more, we would have been forced to go elsewhere in order to stay competitive with our competition.

Since the UltraSPARCs are "forceably coercing" us to have to support another OS (Solaris 2.4) there is no reason why we *shouldn't* consider other brands/vendors/Unixes especially if we can get faster performance for similar/better prices.

We are considering and benchmarking Pentiums running Unix since the performance is fairly close and lots cheaper.

Our computer aided drug design group wants the performance. We are heavily going to Alpha and Microsoft servers ala NT.

The UltraSPARC's performance had better be well above the usual factor-of-2 performance improvement over the previous generation, or we will loose interest in Sun hardware (we've already lost interest in their software...).

64-bit addresses isn't important, but 64-bit calculations are.

Price/performance is more of an issue at this time. Our near-future acquisition decisions include the requirement for high-speed system, but also are balanced against cost (acqn price, admin cost, on-going support/maintenance costs, etc.). HP has an exceptional pricing structure for Lockheed Martin, but Sun's upgrade pricing structure keeps them competitive for upgrades.

64 bit is the future! Don't waste time on 32-bit. Leapfrog the Wintel bunch and win big. This can be the big lever Sun needs to regain market share quickly.

I'd go to DEC Alphas but my mgmt are Sun-crazy.

Optimizing speed/cost is more important than just speed.

Speed is like memory and disk: you can never have too much. My personal concern has been that Sun is lagging other workstation vendors in speed considerations. A 64 bit operating system will be important to the company when the software in use can take advantage of it. Otherwise, I can't see alot of value in it at this time.

As a small developer who has been with Sun since the *very* beginning, I'm pretty near on my way out - can't get any support from Sun and other platforms have better speed and audio i/o. 64-bit is mostly interesting for use of memory-mapped files and similar techniques (many of which have been around since Multix).

We have been talking to Sun about performance problems in the current line of products. SGI is very seriously courting us and has offered an attractive trade-in of all Suns for SGIs. We have very seriously considered it, but decided to give Sun one more chance with the new product line. Hope we made the right choice. Once again, we are concerned almost entirely with performance, as it pertains not only to CPU but backplane, I/O, etc., and not the 64-bit address capabilities.

Please release an Ultra-SPARC workstation before we all collapse from holding our breath!

I will continue to use SPARC in future for larger commercial apps. like Matlab, ProEngineer, Ideas, etc.

Graphics capabilities and performance will remain our major requirements. Our use of HP's is due to the fact that the National Weather Service is currently using HPs. I would like our software systems to run on SPARC machines as well. Our ability to do this successfully will depend on graphics and performance. It is a relief to see, for example, that Sun will be supporting OpenGL.

Hurry up with UltraSPARC! We just purchased a Power Challenge system from SGI because Sun wasn't a 64-bit player and DEC's situation (OS, sales force, support, finances, etc.) is soooo unstable. We are a big-time Sun house that is sliding to SGI, even though their arrogance and pricing are hard to swallow.

I don't believe the 64-bit capability will affect us for quite some time. 5 years?

We are as you say 'gone'.

Sun hardware is too expensive and software that is virtually unsupported - OS,Compilers, inter-operating with non Sun TCP/IP network and internet. The anything but smooth transition from one 'type' of licenses to the 'new Sun' type for the same __ __ product on next version of the OS. Leaving us almost dead while SUNs 'lawyers' decide what we can do. -- lot of BULL!!

We may be small. But I don't think Sun remembers where it started - small research/engineering groups that need good price/performance and treatment like corp. when transition from one kind/version of license to the 'replacement' type. A lot of Educ./Research groups can afford that cost in maintenance and software issues.

Efficient access to large relational databases is the most important feature for us

You are not very clear about what you mean by 'larger address space'.

To my company, what is important is disk-based address space; i.e. how big can a file (or file system) be? Most implementations of Unix only support file systems and therefore files of up to 2Gb, and with a few customers looking at building operational ISAM databases of 500Gb or more, it's a bit inconvenient to arbitrarily chop it up into 2Gb chunks.

Most of our work tends to be network-bound, rather than CPU-bound.

Useful, but no real rush -- we buy whatever is appropriate, regardless of vendor. Loyalty-shmoalty.

We love Solaris. The SPARC is a mediocre piece of hardware. It is costly and not that fast. The high-end SPARCs are REALLY expensive and don't hold up against other boxes in their class.

We have 125 DG/UX systems (11 servers, 114 workstations) DG/UX has excellent features for managing the enterprise model. I understand they are working with Sun on the OS for the 64-bit Ultra SPARC.

64-bit addressing capability doesn't significantly enhance our applications directly, but 64-bit file pointers and 64-bit OS support would make a difference. Performance is always an issue.

We have a bunch of Sun 3/80s, which we are quite happy with. We would buy more if there was are more current OS release for them. For a networking equipment manufacturer, SunOS 4 is a dream platform: We can get at the networking APIs easily, to quickly set up ad hoc tests, and we can tinker with stuff by recompiling individual modules of network code and rebuilding the kernel. We just wish there was a current release with the bugfixes installed... or that Solaris 2 was available for the Sun 3 platform.

---

There is no particular reason you can't put 64-bit file addressing in an operating system on a 32-bit platform. (It won't happen, of course).

It will be interesting to see how much the performance advantage shifts back to Sun from DEC and HP.

Response on #7 is dependent upon our software application vendors delivering tools which utilize this addressing. We would definitely make use of it.

In the IC design business, speed is *very* important.

We resell both refurbished Sun SPARC and new compatible SPARC. The 64 bit systems will be for leading edge sales.

Incidentally, 64 bit systems on Unix are not new. UCB and LBL both ran Unix on CDC 6xxx and 7xxx (Cyber) 64 bit computers in the 70s.

We're doing integrated circuit CAD/EDA. 32 bits seems to be plenty of address space; from the hardware side we need more speed/bigger caches, from the OS side, we need reliability and LESS BLOAT.

Faster SPARC machines are far more important to us than the need for 64bit addressing. HP and DEC have to be considered when we need raw compute speed. We are currently using about 280 SPARC workstations running SunOS 4.1.3 but we have only 2 systems running Solaris 5.4. All of the servers we have bought recently have come from HP (6ea-755's and 2ea-T500's), because we need the speed, and Sun has not really competed, here. We would gladly welcome higher speed SPARC systems, but we will regret having to use Solaris.

We test integrated circuits. As wafers get larger (just started testing 200mm wafers) and circuits sizes are reduced the chip density is getting so high many of our systems are breaking down because of exceeded limits.

Always want more speed. Circuit test times must be reduced for manufacturing. Designers, process engineers, and product engineers always want more data. The compromise always involves available resources. We always purchase with speed a key decision point. Have a lot of HP and DEC Alpha! There are users of those who push us to go into their camps.

Cost/Price reduction is more important than the above.

I hope that Sun realizes that its in the fight-for-life against NT and Intel/HP...might be too little, too late. Sun has the same look that DEC did - before the bottom dropped out...

Our organization is in need of a SPARC system that will run a 2-D mechanical drafting software faster than what we have now. We are currently using: SPARC 10, SPARC 5, and SPARC LX's.

Fast, high precision Floating point is very important, as is fast high precision integer arithmetic. A 64bit ALU and an even wider FPU would be useful.

Too engineering oriented a survey. We use SPARCs for business... We are looking at 64bit technology to get us out of the performance problems we have whether we go w Sun/DEC/other...

If our applications go virtual our performance falls apart. Thus, a larger address space means little to us until there is real memory behind it. Right now 64 bit address pointers are a waste of precious real memory space. Perhaps our customers may use larger database managers for their design data, but that is not in our problem space. If the 64 bit machines are inherently faster, that only helps our applications. Note: we're in the EDA (Electronic Design Analysis) industry.

Along with 64bit wide systems, we also need improved cache coherency and crossbar switches instead of busses, and other parallel processing features to make large scale multiprocessing effective on SPARC's. We are currently looking at Convex Exemplar and SGI Power Challenges for this role.

The UltraSPARC may be enough to keep us with SPARC, but the single accelerated head (can't have symmetric dual head systems except with the deskside unit) is going to be a limiting factor.

Seismic processing will benefit from the larger address space. We move around LOTS of data. Typical survey size is 1.2 gig and we would go larger if Sun allowed a mmap to be larger. We also need to have files larger.

We have a Cray J90 system that is 64 bit and some of our researchers would like 64 bit system for SPARC. Our purchases next year are Sun and Silicon Graphics. Sun had better make a good showing with their UltraSparc.

The current SPARC technology seems fast enough for us today, but we are having trouble getting optimum performance from it - that is, I would rather get better performance from my hardware today, rather than upgrade to new hardware.

Also, we have the requirement to support virtual machines within a single physical box. For example, I'd like to support two logical instances of Solaris on a single SPARC 2000.

Sun has not been competitive for serious research computing. We used Alliants in the past and currently use SGI, Convex, and IBM. Not everyone here will agree with me. Sun being more competitive would be nice since were are mostly a Sun shop.

At present time, speed is more of our concerns than addressing capability. But I believe that the virtually unlimited address space provided by the 64-bit architecture will eventually revolutionize the way we develop applications.

It will be nice when all of the major Unix vendors finally get to 64 bits so we can stop treating it like a special case.

Sun has hit the window for the great majority of users.

If we really needed 64 bit processing today, we would have bought some Alphas, which we did not.

I think it's ironic that Sun is sending out promotions saying "Your ability to survive HP's technology transitions hinges on one simple test...How much pain can you endure?" :-)).

2**64 ~ 10**19. That's a very large addressing domain.

5. Are you/your organization using non-SPARC Unix systems?

__Yes, for other reasons -- Politics

The speed will be important in the future but now we tend towards reliability and time tested methods.

1. Do you/does your organization use 64-bit systems now?

X __Not anymore. We used to use 72-bit systems when we used GOCS3 in the 1970's, and all the precision we needed when we used Multics which allowed us to ask for and get the 99 decimal-digit precision that was in the hardware.

2. How important to you/your organization is the larger address space of a full 64-bit system/OS?

X__very important

One can't do any decent programming without items such as high-precision easily -manipulated time-stamps. It makes the systems code fly. And when systems code isn't so kludgey, applications code goes whiz too.

3. How important to your/your organization is the *higher speed* of the new systems (aside from 64-bit-ness)?

Extremely important - We like power, we like being on the cutting edge. give me a Cray or give me death!

7. In which categories in the next year will you/your organization be using the *addressing* capabilities available in 64-bit computing, if any (check all that apply):

Other: Automated (rule based) database publishing (not desktop WYSIWYG publishing) we're talking phone books, insurance policies, bank statements, & bills here...

64-bit computing has a huge impact on software vendors. It is often difficult to post 32-bit software to 64-bit systems. DEC had a special compile/link flag that effectively hid the extra 32-bits. This is not a great thing to have to do, but it lets tools vendors provide tools without a major re-write or their code. Does Sun/Hal provide this? It seems that the 64-bit address space is key for large servers and essentially back-room operations. As memory prices keep dropping, I do see people hitting the limit for desktop computing with 32-bit systems.

Several of us (my consulting contacts) think that Sun will be "forced" to adopt PowerPC and PCI within 3 years, as another "arrow" in the quiver. Solaris for PowerPC is here, and Sun will have to ship the PowerPC/PCI hardware to stay in the *hardware* business. Of course, they could just become a SW company (Java, Hotjava, Solaris, Wabi, PC/NFS et cetera).

SPARC/Sun-OS(SOLARIS) is the best development environment but it lacks the price/performance other systems provide (e.g., RS6000, PowerPC, or *god forbidden* Pentium PCs and the future P6/P7 that Intel promises!)

6. Please characterize your organization's use of SPARC computers in the next 12 months:

_x_Replace SPARC with Pentiums

[NOTE: This is being mandated by a merger, management decision is that Unix boxes are boat anchors. I have no say in this, I will be moving on if this goes through.]

Definitely looking forward to a compiler/development system that generates code for ILP-64 (integers, longs, pointers are all 64-bit quantities). Its much easier to port code to ILP-64 than the DEC (and others) LP-64 model.

Our application is a large relational database. We can really benefit from the increased internal bus bandwidth of the 64 bit machines, but we really don't need the CPU power.

I worked at a software shop while DEC was cutting their teeth with many early releases of their 64-bit OSF/1. It was an interesting experience, since there really ARE a lot of technically fascinating software and compiler issues to resolve when porting to the 64 bit environment.

A whole lot of user code will need to be modified to work properly, and even more will have to be most thoroughly testing, until all of the 32-bit-isms are located and updated.

Networking bottlenecks and decisions are our biggest current issue.

I think a mini-white paper on why 64-bit applications/systems/buses make sense and how it fits into the overall performance equation for computing architectures. I mean, why do I need a 64bit OS if I'm stuck with a 32-bit BUS architecture? Let's talk about total system synergy and why that's the real bottom line.

We just recently ran into this problem because we needed to create a several single TIFF images which needed to be about 2.2 Gbytes. It took us several days to realize (duh!) that we just couldn't do it that way. This won't be the last time that this issue arises for us but it is only an occasional (several times a year) sort of a problem and there is an easy current work-around.

We are currently not in need of 64 bit processing, but I think that is an effect of affordable systems not being available. We used to have a Cyber 182, which had a 63 bit architecture, but of course it was obsolete many years ago. There are models and simulations of upper atmospheric phenomena that we create and run that would probably benefit from 64 bit architecture and OS, but so far, the need has not been recognized or at least not verbalized.

I suspect that eventually we will be using 64-bits. I would be interested in hearing any tips for current code development that will make the eventual transition easier.

We are getting "pushed" towards NT and Novell because of client-server issues and we ain't happy about it. Looking at SPARC mainly because of rep in Internet circles.

Digital Equipment Corp. has been shipping 64-bit systems, with a 64-bit Unix operating system and 64-bit optimized applications for some time. After having Sun representatives tell customers they don't need 64-bits for many years, it will be interesting to see how that message will change. On behalf of tens of thousands of 64-bit customers/users, and the leading 64-bit system supplier, welcome to the 64-bit world.

Regards,

Mark Silverberg

Group Manager - Unix Product Marketing

Digital Equipment Corp.

Hahahaha... FreeBSD or NetBSD will be ported to the UltraSPARC before Solaris 2.6 makes it out the door.. ha ha hah hahaHHa! ...and in the end be 10 times faster and more efficient! then again, an 8-way Pentium Pro with Solaris 2.5 will smoke any 4 or 2-way Ultrasparc for 1/3 the price.

For 64-bit applications, we use government Crays.

Sun (and the Unix community in general) needs to address the NT issue. I find Microsoft's endless crowing about "new" features in NT that Unix has had for years. However, Microsoft's marketing hype is so successful that users flock to it like lemmings even when it's a substandard product. The computing community, and users in general, will live to regret Microsoft domination of the software market just as they lived to regret IBM domination of the hardware market.

We are very anxious to see what Sun does in this arena - we recently leased HP K400s because of their performance in performing CPU intensive simulations and also need a Sun solution along these same performance lines.

Until last week, I would have had nothing to say on the subject of 64-bit systems. But something happened last week that made me more involved.

I was porting code from a sun SPARCstation to a DEC Alphastation. Unknown to me at the beginning of this adventure was the fact that the DEC runs a 64 bit OS. This will become important shortly.

After many hours of compiling, debugging, and theorizing about why the code (which came from a popular book) works on the Sun and not on the DEC, I finally found the answer. The DEC is using a 64 bit OS. This means that a long integer on the DEC is 8 bytes, instead of the usual 4.

The short story of this whole matter is that the following line of code did not do what was expected (or what it did under a 32 bit OS):

ptr += sizeof(long);

On any 32 bit OS, this code will increment the ptr by 4 bytes, where the program expects to find the next piece of data. On the DEC, it incremented by 8, at which point I had missed the next piece of data, and the program was failing miserably.

At the time that I realized what was wrong, I was pretty unhappy with 64 bit OS's. But, I was able to fix the code in a (hopefully) portable way, and I suppose now I will consider this a learning experience that I won't soon forget.
Some readers commented on other aspects of our survey or our publication:
Proof the survey before you send it out!

You forgot a "p" in question 6.

DO NOT USE YOUR EMAIL "REPLY" FEATURE: Send your reply directly to mac@sunworld.com.

Perhaps you should have used a Reply-To: header??

DO NOT USE YOUR EMAIL "REPLY" FEATURE: Send your reply directly to mac@sunworld.com.

**** Why not? Haven't you heard of the "Reply-To:" field?

Any decent mail-reader of 1978, when I started working at Honeywell, knew how to "reply" to a "Replay-To:"

Has understanding of and compliance with standards gotten so bad that one can't do a "reply" anymore?

This method of query beats the standard paperpushy way with 123 multi-response blocks to fill out, labeled by one word of which the meaning often is obscure without context. Now try it via WWW and the reply form facility.

Bring back the "paper" magazine! You should have sent this so we could just reply! I sure prefer my SPARC to the Intel stuff.

I like to stay informed with what is out there in all Unix environments. Things/Plans change the weather around here, so keep up the good info.

My favorite part of the magazine used to be Tog's on Interface column great The worst error message of the month contest was a riot.

I subscribe to you mailing because we are in the early stages of planning on a move to client/server computing within the next year. We are still not sure what direction we will move, but we want to keep our options open with Sun and Solaris. Thanks.

[(c) Copyright 1995 Web Publishing Inc.]

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-12-1995/swol-12-tcp.html
Last update: 4 October 1995