XBase Part II

  By admin | May 20, 2012 - 12:43 am | Uncategorized
Leave a comment

As vendors continue to build in new features that depart from the original dbase standard, the chances increase that one or more will attempt to dominate the standard-setting process. Corporate developer Cary Prague, director of software productivity for The Travelers Corp. of Hartford, Conn., warns that X3J19 will fail if one vendor’s approach is allowed to dominate the standard.

Sources claim that one of the big three vendors has already tried to pack the committee with independent developers biased toward its product line. They also accuse Borland of taking something of a paternal attitude, as one might expect from the owner of the original dbase product.

Schnapp doesn’t deny that this sort of polarization might happen, despite it not being in the vendors’ best interests. He says that the best way to keep the vendors honest is for large Is shops to join the committee. The big three vendors all agree that they’d welcome Is participation.

Conversations with the leading Xbase suppliers indicate that a lowest common denominator standard will be fairly easy to achieve. Borland director of marketing for dbase David Kaplow says, “We’re willing to cooperate on creating a standard. We’re trying to drive the process forward and not politicize it.” At the same time he says that extensions such as object orientation will need to develop over time. “The ANSI committee is just trying to get to a base document,” he says.

Mark Sokol, CA vice president of languages, says that “there are many areas in which we’re willing to compromise.” But as for a future comprehensive standard, which includes object-extensions to Xbase, Sokol claims that CA stands alone. “We’re the only ones with an object-oriented syntax on the table, so I can’t tell you if we’ll have to compromise at all there.”

Todd Nielsen, Microsoft’s FoxPro product manager, also sounds cooperative. “We’ll make a good faith effort. I don’t think any one vendor is going to dominate.” And he agrees with Schnapp that the standard will exert an influence long before it’s finalized. “The standard committee will be a sort of shepherd,” he contends. “We’ll pay attention to the directions the committee is going in and try not to stray out of the fold too far.”

Committee leader Schnapp predicts that the completed standard will be published in 18 to 36 months, but he expects results long before that. Throughout the standard’s gestation process, he thinks that the group will shape Xbase product development from all the different vendors.

The Travelers’ Prague, who also happens to be a noted dbase book author, hopes that the committee’s influence extends beyond setting a low-level Xbase standard. He feels that a de facto standard for base code in character mode already exists in the form of dbase III. “The one place with the most divergence is CUA [IBM's Common User Access specification] Windows interface commands,” he says. “Those kinds of things, like radio button commands, need to be standardized.” The buttons themselves don’t need to look the same; just the commands that work them.

According to Schnapp, X3J19 will address Prague’s concerns. It will become “a multilevel standard even in its first iteration.” One new level the committee hopes to achieve with Xbase lies in the area of embedded SQL. Schnapp calls it “part of our project scope” and sees it of particular interest to Is managers.

While Prague wants a comprehensive standard encompassing embedded SQL and more, he doesn’t want to see Xbase lose its accessibility. “I think most good dbase programmers want to program in an English-like, dBasetype language rather than in C.” For that reason, he would hate to see Xbase gravitate toward C ++ -like constructs or to assume a BASIC-like identity. Prague contends that this could happen, especially if Borland is tempted to migrate its C++ knowledge over to dbase or if Microsoft chooses to evolve FoxPro along the lines of Visual Basic.

Schnapp concurs with Prague in seeing the need for strong “English-like, self-documenting languages. Most intelligent business managers could look at an Xbase program and get a good general sense of what’s going on in there. No so with C and C ++ ,” he says.

In the final analysis, Prague values good tools over the language. “This game is not going to be won on the language front [alone] but by the tools you hook into it.” Microsoft sources concur with this assessment, as should be obvious from its huge success in attracting third-party tool development to Visual Basic.

The first round of Windows-based Xbase products is already too far along to be much affected by the Xbase committee’s efforts. All such products already out or in the pipeline use at least some proprietary extensions to handle Windows’ event-driven model. Servers are typically better equipped for potential data disasters or the need to recover hard drive data. It works well, as noted here. But the interactive elements of these packages are excluded from the Xbase standard. And, in many cases, the underlying language’s commands and syntax could be changed without changing the interactive elements appreciably.

Industry observers like InfoCorp senior analyst Chris Le Tocq think that the interactive elements are rapidly becoming more important than Xbase itself. “The development of graphic front ends for doing database application design reduces the importance of the underlying language,” he says. On the other hand, Schnapp notes that “almost $1 billion has been invested in Xbase acquisitions by the three big players. I don’t think they’ll drop it.”

ANSI committee X3J19 gives the Xbase vendors Windows of opportunity, if they can avoid the internecine wars of UNIX and other struggling standards. This year should tell whether an Xbase standard will fly or not.

XBase – A New Vision For dBase

  By admin | May 18, 2012 - 12:40 am | Uncategorized
Leave a comment

The logo is strong.

The word is Xbase: it means all the dBase-derived database application development languages, considered collectively in some way. But try getting a roomful of programmers, database suppliers and assorted gurus to all agree on just what Xbase stands for and you can imagine what it’s like for Bill Clinton to slash the federal deficit: tough, but not impossible.

Just ask Marc Schnapp. As chairman for the new American National Standards Institute (ANSl)-accredited committee charged with conjuring up a single Xbase standard, Schnapp knows both the potential rewards and political pitfalls facing the fledging X3J19 committee. Last fall, Schnapp’s committee met for the first time, attended by reps from three dozen member organizations. Included were all the leading vendors of dBase-type database languages and a variety of developer groups, from both the U.S. and abroad.

Just getting these people together was no small feat. Despite the many interests involved, the committee agreed to first develop the American standard with international participation, then to present that standard to the International Standards Organization (Iso). The standard is important in case of database or  hard drive crashes, and can prevent total data loss. There are a wide variety of hard drive repair companies that specialize in these kind of recoveries, such as this one. The group also settled on retaining, wherever possible, traditional Xbase practices. They met again last month to look at Xbase standard proposals from the leading suppliers.

So why bother? After all, dbase and related languages have been evolving quite well for more than 10 years without the blessing of a single standard. “The goal is both to define the common core as used but to also acknowledge where the language needs to go,” says Schnapp, who doubles as head of the Xbase Institute, formed to promote the Xbase standard. It is located at the offices of Schnapp’s database consulting firm, Primary Key Consulting, in El Sobrante, Calif.

Standardizing Xbase won’t be easy. In 1988, the standard was clearly defined by dbase III, the popular successor to the original dbase language from now-defunct Ashton-Tate. Because none of today’s big three Xbase vendors were in the game back then, it was relatively painless to settle on dbase III as a de facto standard. But that’s changed over the past three years as big software companies have entered the Xbase race. Today’s major players include Clipper bought last year by Computer Associates International Inc. of Islandia, N.Y.; dbase, acquired by Borland International Inc. of Scotts Valley, Calif.; and FoxPro, now owned by Microsoft Corp. of Redmond, Wash.

While each of these products claim Xbase compatibility, all had been diverging from the old norm even before the buy-outs. Each has added exclusive features and language elements, as have a half-dozen other Xbase vendors represented on the committee.

For example, Recital, from Recital Corp. of Danvers, Mass., boasts a data dictionary, which the others lack. It runs on Digital VAX and UNIX machines. SharkBase, from Sub Rosa Publishing Inc., of Downsview, Ontario, Canada, is an interpretive environment that runs Clipper code. Vulcan, from Emerald Bay Group of Montrose, Calif., is designed from the ground up as a DOS-based client/server environment. Force, an Xbase compiler from Dvorak Development Inc. of Littleton, Colo., produces unusually compact executables. And CA-dbFast and FoxPro For Windows, from big-three vendors CA and Microsoft, respectively, offer the only Windows interfaces. One. potentially significant product still in the works is CA’s Visual Objects For Clipper, which provides a more object-oriented development environment than anything else now shipping, according to CA.

Because of the wide range of options available, many developers now specialize in some flavor of Xbase, says Schnapp. Somewhat surprising, though, is the number of programmers who refuse to budge from familiar surroundings. Market research firm InfoCorp of Santa Clara, reports that 46% of all Xbase users still program in good old dbase III and III +.

Larry Dysert is one developer who considers himself specialized. A project control engineer for Eastman Kodak Co. in Rochester, N.Y., Dysert develops PC applications in Clipper.

“From my point of view,” Dysert says, “the standardization effort is needed. It helps to further legitimize Xbase development.” He speaks for many Is shops when he says that “a good standard would let us pick vendors on performance and service issues. And it would minimize training needs.” Dysert wants a standard– even if he has to give up some features to get there-that covers a high percentage of what any one Xbase product can do. He says that this is especially important given the mobility of application developers these days.

Fortunately for Dysert, Clipper, unlike other Xbase tongues, incorporates a preprocessor that lets it map new commands to its underlying language engine. A dbase IV compiler kit that does this is already available. Sources at Computer Associates promise a similar kit for any ANSI standard that emerges. This means that CA would not have to change the present Clipper commands and syntax, as the others would, to accommodate an Xbase standard. However, Borland and Microsoft officials insist that everything in their Xbase variants can be changed, as well.

Schnapp points out that “the vendors agree that there is little to gain in differentiating themselves in the language.” Executives at the big three concur. Vendors have substantial leeway for differentiating the interactive elements of their products and are free to optimize for maximum performance (see diagram, “The Xbase Agenda”). Other areas where vendors can distingnish themselves include cross-platform capability, licensing strategies, development tools and vertical products.

Quicktime Innovates

  By admin | May 17, 2012 - 7:56 pm | Uncategorized
Leave a comment

When Apple Computer Inc. introduced its QuickTime 1.0 time-based file format for Macintosh computers two years ago, the company also created a new resource, the “pnot.” pnot gives QuickTime-savvy applications the ability to include as part of a file a thumbnail image of that file. But the original pnot did not apply to text.

With Apple’s new QuickTime 1.5, pnot can include not only pictures but also sound, movies or text.

Image previews

pnot is one of many Mac resources, or attributes, that perform functions such as setting window position and identifying icon type.

When a user highlights a file name in the Open dialog box from within an application, pnot displays not only the file’s name but also a preview image of the file.

In addition to the original pnot graphic thumbnail preview, three new “use types” — description (Desc), keyword (KeyW), and preview (Prev) — enable files to store a variety of text information.

Unlike files or applications under other operating systems, which treat a file as simply a single ordered sequence of bytes, each Macintosh application or file has two sections called forks: a data fork and a resource fork. A resource fork contains a file’s resources, such as font information, window location, menus, dialog boxes and, in the case of an application, executable code. A file’s resource fork will also contain preference settings and icons, etc. A file’s data fork contains the file’s data, such as text, numbers and graphical information. pnot resides in the resource fork, and thus always remains with the file.

By including pnot elements within their Mac applications, developers don’t have to create or support a myriad of methods to store and display preview data. In addition, with pnot elements, developers can continue evolving their own private file formats without affecting another application’s ability to preview that document. pnot lets users save a tremendous amount of time: The ability to locate files by keywords in a pnot element lets users quickly search for files in a variety of ways.

Also, users of applications with the improved pnot will be able to view a virtually unlimited number of file types from within a single application. Because resource-based preview information is read independently of the data fork, when previewing large image files, only the preview information traverses the network. Network traffic is lessened because users can select files for downloading based on the preview information contained in the pnot element instead of downloading all files to find the one they want.

Unlike Finder comments — which reside in an invisible Desktop file — pnot data is retained when the user rebuilds the Desktop. This is particularly important to content providers, whose livelihood depends on copyright, credits and ordering information travelling with their images.

Apple has even provided for each pnot data item to have its own language code. This means a content provider — like a stock photo agency — could attach multiple keyword lists, each in a different language, to each image. Thus, only one version of a CD would need to be pressed for international distribution.

Each pnot element is tagged with a modification date to make it simpler for applications to determine when the data has been changed. Applications that provide file preview capabilities but don’t support pnot still need to “respect” the resource and not arbitrarily erase it when saving files.

Every application that creates graphic documents should allow users to attach pnot information from within the application. Storing images is quite easy with the system, which ensures there really is not much need for professional mac data recovery services like those offered here. The best time to describe an image is at the time of its creation by the user, and a simple user interface is all that is needed for adding and editing a description and specifying keywords.

Attaching pnot information does come with a price, however, file preview information adds bytes to a file’s size. For image previews, the extent of a size increase depends on things such as whether the preview is an object or bit-mapped image, bit depth, resolution and compression method.

Buying Computer Code Works

  By admin | May 16, 2012 - 12:53 am | Uncategorized
Leave a comment

I used to program for a living. However, given a choice between solving a problem by writing some code or buying the solution off the shelf, I’d take the store route every time. So should you.

With the variety of terrific tools available today, you can spend hundreds of dollars to save thousands more in unnecessary coding. Why not save your programming efforts for the critical pieces of your application development environment and buy the rest?

There are a number of catalogs containing tools for each graphical user interface (GUI) platform.

You’ll probably find more icon libraries, tool-bar utilities, data-validation dynamic link libraries (DLLs) and other goodies than you’ll ever need.

In addition to simple add-on tools, I think all corporate GUI programmers should consider adding testing, installation and computer-based training (CBT) products to their development tool box. Some tools that are popular time-savers among developers today are InstallShield, SQA:Robot and IconAuthor.

InstallShield, from The Stirling Group, of Schaumburg, Ill., is an installation utility that requires little programming expertise. It enables you to create Windows or OS/2 PM installation and distribution applications using a simple scripting language, while also providing file compression, easy editing of system files, access to DLLs and automatic generation of program groups.

You can plug in your own custom graphics — for example, a company logo — or tap the software to install third-party programs as well as network file management and user setup options. With InstallShield, you can create a common, consistent installation utility for all of your applications. International versions are available.

Client/server testing tool

SQA:Robot, from Software Quality Automation, of Lawrence, Mass., is a Windows client/server testing tool. Although you’ll probably use this tool for testing the performance and stability of applications, you can also use its recording feature to capture keystrokes and mouse clicks during usability testing. You can capture images, monitor Dynamic Data Exchange and play back a test script while in debug mode.

The software also furnishes a test repository (SQA:Test) and management utility (SQA:Manager); SQA:Test helps you manage and distribute your test database, while SQA:Manager provides decision-support capabilities for test planning, execution, reporting and software error tracking.

My last pick, IconAuthor, from AimTech Corp., in Nashua, N.H., is a multimedia authoring tool that I see most often used to create computer-based training materials. To develop an application, you drag and drop icons to create a flowchart — programming expertise is not necessary. An icon library of common events is provided.

After drawing your flowchart, you traverse a series of dialog boxes to provide content behind the chart icons. You can easily add animation, sound, full-motion video and graphics. IconAuthor is so robust that the tutorial documentation is over 250 pages long. I think there is a lot more to this tool than meets the eye.

Yet, so far as ease of use goes, I know a summer intern who created an intuitive and fun CBT program with IconAuthor in a few weeks.

With so many tools available, why code when you can shop?

Distributed Development Works

  By admin | May 15, 2012 - 12:36 pm | Uncategorized
Leave a comment

When you try building mainframe apps on little PCs, you can’t always get there from here. Follow these directions and you can arrive unharmed.

We’ve all seen the commercial. A concerned consumer wanders around an electronics store examining several thousand different video camcorders. The first question she puts to the salesperson:

“Will these tapes play in my VCR?” Development managers should be asking today’s vendors of distributed, PC-based development environments the same hard question: “Will your PC-generated COBOL source code compile and test out on my mainframe?”

The prudent manager always assumes the correct answer is: “Sometimes.”

What is distributed development? The opposite of monolithic development, yes. Monolithic development is the approach most IS shops are accustomed to using: developers work at terminals hardwired to a mainframe that builds, compiles and tests their mainframe applications right there on the hardware on which it is eventually expected to run, like at this website. This process-expensive, yes, and inefficient, unquestionably-nevertheless has the arguable advantage of actually working more often than not. The exception, of course, is the occasional glitch in the process of promotion to production.

Distributed development, however, assumes that no development will take place on the mainframe, even though the resulting applications are still expected to compile and run without a hitch in a comparatively alien mainframe environment.

Alien, that is, to the typical distributed development setting that now includes PC workstations, graphical user environments, local area networks, file servers and computer-aided software engineering (CASE) tools. For roughly $12,000, a programmer can be equipped with a PC workstation and the software tools needed to allow mainframe-compatible COBOL code to be written, compiled, debugged and unit tested without the execution of a single mainframe cycle.

The testing process can even include implementation of mainframe database calls via a database emulator running on the developer’s PC.

Once the developer tests the code on the PC, she can migrate it to the mainframe, recompile it there, system test it and promote it into production. This method of distributed development is undoubtedly more efficient and cost effective than the old mainframe-based model. But it is also rife with some potential–and often subtle–compatibility problems that may go undetected.

Naturally, many compatibility problems are obvious: a program call to a printer routine, for example, evokes a significantly different response on a PC than it does on a mainframe. These obvious compatibility problems are usually relatively trivial to manage, either during the recompile process or internally in the PC-based tool.

More serious, however, are what I call “ambiguous compatibility” problems. These subtle and often undetectable problems (undetectable until they are in production, that is) arise when things that should be compatible just are not. For example, modern science still hasn’t come up with an explanation for why the Buffalo Bills, a perfectly good football team in local competition, are so incompatible with the main event, the Super Bowl.

So, too, distributed development tool vendors may claim that their PC-based products generate 100% compatible mainframe code; but this claim doesn’t always turn out to be true in the main event–production (see table, “Distributed Development Creates Its Own Problems”).

What’s the source of these unexpected ambiguities? Most PC tools are extremely flexible and can generate code for a variety of target platforms. The generation of this code is controlled via compiler directives, which regulate everything from which version of COBOL to use to which compiler’s error messages should be ignored. But if the directives on the PC are not properly set to match the target compiler, code can be written that works fine on the PC but still fails to compile on the mainframe.

And if the project happens to be a transfer or modification of an existing system, the reverse situation can occur. Code that functions on the mainframe can be migrated to the PC for enhancement, where it ultimately fails to compile locally. A thorough understanding of both compilers is necessary to set the directives properly. Unfortunately, several iterations of the process may be required before the developer finds the two sets of directives that match.

One possible solution to this problem involves prototyping a preliminary exercise to test the compatibility of the directives. To do this, the developer should migrate several programs, each of which has successfully compiled on the PC, to the mainframe early in the development process to test the same code on the mainframe compiler. To ensure that a representative set of directives is tested, these programs should be nontrivial; don’t simply migrate the main menu of an application and assume that all other programs will work.

But even after the directives are properly set, other discrepancies can, and often do, occur. These discrepancies are often difficult to detect; the programmer may not be sure whether the problem is with the actual code, with the PC software or with the mainframe compiler. The programmer can also ensure that all data is safe, and that hard drive repair will never be necessary in order to get data back. This is of course confirmed by the data recovery experts here.

The problems listed in the accompanying table were all discovered on a distributed development project when code developed on a PC was migrated to the mainframe. These problems, although specific to a COBOL/IMS environment, are representative of the types of discrepancies that can occur. Vendors may provide a list of known incompatibilities, but new ones are certain to crop up unexpectedly.

The only way to plan for these subtle and unexpected problems is to allow extra time in the schedule for migration to the mainframe and to be aware that the problem can–and more than likely will–exist in either location.

Can you do anything else? Once detected, these incompatibilities can be resolved. But the, problems don’t end there. You may now have fully functional code but you need to manage and control that code in two locations. Version and library control difficulties compound the problem of software discrepancies, since the traditional development, test and production libraries exist on file servers, as well as on the mainframe. Many good articles that address the problems of version and library control exist.

Remember, however, that good procedures are required, and these procedures should work in both normal and crisis situations. The first time someone makes an “emergency fix” without following the proper procedures is the last time you can guarantee concurrence between your PC and malnframe libraries.

How to Repair an External Hard Drive

  By admin | May 14, 2012 - 12:33 am | Uncategorized
1 Comment

External hard drive can have a problem just like the internal drive. When this happens it undergoes through repair hard drive like every other disk. You first need to plug in the USB cable connecting your hard drive to the computer. At times the operating system may take some time before it recognizes the hard drive so you may have to wait a little bit. Once the hard drive has been recognized by the OS, you will go to the start key and click ‘All program’ button. To find more go to this website.

The ‘All programs’ button will display a list of programs for you to choose from. Click on ‘Accessories’ and then open the ‘command prompt’. This runs on a DOS mode and will need you to type in a command for checking the drive which will be ‘chkdsk’ to mean check disk. On this command we need to key in the command with x:/r together with but after the check disk command separated by a space between the two to run a scan on the external disk. This x is meant to represent the letter of your drive so for drive ‘f’ you key in f instead. Press enter to start command. The computer will scan and does a hard drive repair on your external disk.

Although you can repair your hard drive at home there are some problems that are better sorted out by an expert. It is good to try and do it yourself especially when the problem is minor and involves a hard drive repair to the external components.

When you suspect that the problem is an internal component problem it is advisable if you sort an expert’s advice in the matter. At times we may have an accident involving water on a computer and we think that trying to dry it may solve the problem. The experts would definitely not advice that because it will scratch the drive and cause more problems on the drive. The experts advise that the computer be taken just as it is or if possible when sealed to prevent water from draining. When you take the computer sealed it prevents it from collecting dust that may ruin the drive the more and cause it to be difficult to perform an hard drive repair and instead a change of the drive will be recommended.

On IBM’s Relationship With Sybase

  By admin | May 5, 2012 - 1:58 pm | Uncategorized
Leave a comment

It’s not as if Paul Hamel hadn’t been trying for God only knows how long to dump the frumpy old IBM’3270 dumb-terminal-based, on-line CICS/VSAM COBOL applications he and his staff had been nursing alone for years and replace them with some kind of high-powered, client/server setup.

IBM flavored soda, anyone?

Au contraire, as they say.

No surprise, then, that Hamel, vice president of systems and planning at Providence, R.I.-based Textron Financial Corp. Jumped at the chance last year to install a group of new network gateway and server products from Sybase Inc. that would let him restyle his day-to-day Customer Information Control Systerd(CICS) applications to run with IBM’S power-packed DB2 relational database management system (RDBMS) on as many as 250 PC workstations in a state-of-the-art client/server system-while still holding onto his old IBM mainframe applications and flat file databases.

Hamel’s tale about his escape from a rigid IBM master/slave system to the freedom of a flexible mainframe-based client/server architecture could fill a book.

Here’s the story board version.

For the past six years or so, Hamel had been harboring a recurring dream that went something like this: one day, Textron’s management would suddenly realize that the company’s is operations formed the basic foundation of its business, something Hamel already knew as fact.

After all, the company, with annual revenue last year of $208 million, has only two types of products to offer its retailer customers: the actual hard, cold cash it lends at market rates to finance, for example, retailers’ up-front purchases of big-ticket consumer items like golf carts, RVs and power lawn mowers for their display room floors (in the trade, the business is known as floor planning,” in fact) and the services connected to those loans, such as the development of special loan deals, rearrangement of credit terms and early payoff incentives, as well the speedy response to customer requests. Both types of products depend on is applications and systems to function smoothly.

If management would only realize the importance of is to the business, Hamel speculated, they would likely assign it the strategic role it deserved-and would also give him the OK to melt down the antique 3270 terminals, pull the plug on the 3174 cluster controllers, cancel the contracts for the old and not exactly industrial strength 9,600-baud leased lines and start spending the money needed to develop a state-of-the-art client/server system that would be fast, responsive to customers, easy to manage and simple to modify or expand as needed.

That was the dream, at least.

The Dream is Real

Last year, the dream got real. Textron Financial’s president, Steve Davis, did decide to go after the company’s biggest competitors-Chrysier Financial Corp., ITT Financial Corp., Bombadier-with innovative products and improved service, and he assigned a new strategic role to is to make it happen.

As part of that assignment, Davis and his top managers gave Hamel three goals for the is operation. First, get ready for a tremendous increase in transaction volume-a 100% jump over the next two to three years and annual increases of some 25% after that. Second, begin to increase the variety and complexity of features available to Textron’s customers and make it easier to vary those features as the market changed. Third, expand and automate the new system as much as possible while holding to the existing operating and wage costs. To make all this happen, management also agreed to a onetime boost in Hamel’s capital-spending budget by a factor of 20.

Just A Few Strings

Of course, Hamel was given a few constraints. For example, management gave him a back-busting 10-month time-table for the development of the new system. He successfully negotiated that up to 14 months.

But his biggest constraint was not negotiable. Even though he could build the new system from scratch, he was still anchored to the IBM mainframe data service provided by Textron’s Avco Financial Services division in Irvine, Calif. The old CICs on-line 3270 system (the Minneapolis-based “Floor Plan” operation) had been tied to Avco’s IBM 3090/200J mainframe with the umbilical cord of a leased line. The new system (called the “Inventory Finance System” or IFS) would be held to a similar relationship. But at the same time, issues with hard drive failure were holding the project back badly for engineers. That was true both for financial reasons-the company already owned the big 3090, which had a low marginal operating cost and still had plenty of available capacity-and for technical reasons-the existing applications and the database were already UP on the 3090. As part of the new IFS system, however, Avco agreed to upgrade to the latest version of IBM’s DB2 RDBMS.

So Hamel and his staff approached IBM to see what Big Blue could do to bring the mainframe into the client/server world. IBM had no problem meeting Textron’s hardware requirements. “They were excellent on that front-even coming up with some loaners when products were late stripping,” Hamel recounts. But the only software solution IBM offered was a 3270-gateway-based approach that used an Easel Corp. graphical user interface running on a PS/2 workstation to communicate with the CICS-applications 3270 on the mainframe. In Hamel’s view, that was kind of like painting a pretty face on a 3270 terminal and little more-not even close to what he had in mind.

A Loopy Legacy

That’s when Emeryville, Calif.-based Sybase came into the picture with its Open Server For CICS, Open Gateway For DB2 and NetGateway products. As a group, these products allowed Hamel to loop together the IBM mainframe and all those legacy applications and databases with his new, much more flexible workstation-based client/server applications. Plus, he could manage the migration process to DB2 without tying his stiff in mental knots.

The Sybase products, which began shipping late last year, act as programmable interfaces between applications running on local area networks and MVS applications and databases. They can work either by using Sybase’s own SQL Server RDBMS as the network database system or they can work without SQL Server, using the mainframe for all database needs. The three products do require that Sybase’s Open Client application, which contains the applications program interfaces (APIs) needed to communicate with the Sybase Open Server, run on each net-worked workstation.

Hamel discovered the Sybase products–which weren’t even on the market at the time–by accident. He knew right off the bat that if he wanted to get out of the master/slave world of IBM on-line CICS applications and 3270 gateways but still use his old IBM mainframe applications, he was going to have to find a way to run the 3090 mainframe itself as, in effect, a server in the PC LAN client/server system he was setting up. One possible solution would be to hand code a series of advanced program-to-program communication (APPC) interfaces for every workstation-based application so that it could gain access to the mainframe’s databases or call existing CICS applications for on-line transactions. “We thought about scratch building it-with APPC code-but we knew there had to be a better way,” he says.

Beta For The Data

Hamel’s development crew had already settled on the Sybase SQL Server RDBMS-the new name for what was formerly known as just plain old Sybase RDBMS-as the database to run on the network for the client portion of the database system. But, once he and the is development crew got deep into the process, they serendipitously discovered that Sybase was working on a new series of products that could manage all the APPCs for IBM CICS applications, plus a lot more. The products were just what his new system needed, he adds, “so we went beta with Sybase.

“I wanted to make it a state-of-the-art operation,” he recalls. “I wanted to put something in place that was at the beginning of the technology, that could handle a tremendous increase in transactions and inquiries both and that was flexible in its ability to vary applications and could still run in a top-end IBM environment. We wanted the best technology we could find.

“I wanted to keep the IBM mainframe both for its speed and its size-plus the move to DB2 was a priority for us. “Hamel adds. “We started calling the mainframe the ’3090 server’ because in this configuration it really is just another server.”

It’s SuperServer ! That’s exactly the role Sybase sees for the IBM mainframe of the future-as a superserver in a wide-ranging client/server system. Says Sybase executive vice president Robert S. Epstein: “We see the role of the mainframe as being used less and less for the minute-by-minute, or second-by-second, running of the business.” Instead, he says, the mainframe will function more as an information repository, which is updated less frequently. The minute-by-minute activities will be handled by more cost-effective workstations, off the mainframe.

Most companies want to be able to take today’s client/server technology and get the incredible price/performance that offers and integrate it with their legacy applications to preserve the investment they’ve already made in their development,” he adds.

Most large IBM shops have invested millions of man-hours and millions of dollars developing and maintaining hardware and software systems. And these systems are still performing all the critical activities for their enterprises perfectly well. So when they decide to downsize to the less costly client/ server structure for their new applications, they still want to hold onto those big-system investments. Modifying these large-system applications to run on workstations or in a distributed mode would cost far more than they could expect to save, and take far too long to justify the effort.

For these shops-and there are literally thousands of them-the best client/server structure is one that includes easy and invisible access between all types and brands of workstation platforms, applications and databases, and all types and brands of IBM mainframe-based applications and databases–just what Sybase claims its new products can do.

So, How’s it Work?

Here’s how the Sybase products work. A developer writes a new workstation-based application in Ada, C, COBOL, FORTRAN, Pascal, Sybase’s own fourth-generation language or one of several Sybase-compatible 4GLs available from several other vendors Focus, HyperCard, Nomad, Object/1, Prolog, etc.). The workstation application can run under whatever operating system the workstation supports-Macros, MS-DOS, OS/2, UNIX-and with whatever user interface the developer chooses to use-text, Easel, IBM Presentation Manager, Mac Windows 3.0 or any of several UNIX-based graphical user interfaces.

The developer includes in that application remote procedure calls (RPCS) to mainframe applications or routines. The actual mechanism the RPCS can use to invoke the mainframe applications can be CICS queues; Intersystem Communications (ISC); Job Entry Subsystem (OES); or Multiregion Operaions(MRO).Or the RPCs can call a Sybase SQL Server routine, which itself can call predefined mainframe applications singly or in groups. Sybase NetGateway-running on a single IBM RT or RS/6000 workstation hooked into the IBM Systems Network Architecture (SNA) network-converts these RPCS, in transit to the mainframe, from the PC LAN’s TCP/IP communications protocol to IBM’s LU6.2 protocol for the mainframe.

The Sybase Open Server For CICS then routes the calls to the appropriate predefined CICS application on the IBM mainframe. Open Server For CICS can also route calls to other vendors’ database management systems-CA-Datacom, CA-IDMS, DL/1, Oracle. On the return route, CICS Server sends the response to the RPC back to the appropriate workstation application or to Sybase SQL Server, which bundles the response with other RPC responses to go back to the workstation as a package.

The Sybase DB2 Gateway product performs all the above routines, and, in addition, can send a predefined data request directly to the mainframe’s DB2 database (Sybase calls this “Turnkey DB2 access”). Or it can get at the DB2 data indirectly through workstation-initiated RPCs embedded in applications written with Sybase’s own Transact SQL With Extensions, or written with other DB2 Structured Query Language (SQL)-Compliant languages.

Static On The Line

Sybase says the Open Gateway For DB2 is the only DB2 gateway that can call static complied) SQL, the industry standard method of speeding up DB2 performance on transaction-processing routines such as database updates or real-time data entry. Open Gateway For DB2 can also use the slower dynamic SQL access method for DB2 queries. At Textron, the new IFS system handles all its access to DB2 data-routine database update transactions, reads and writes, and prameter-driven queries-with high-speed precompiled static SQL embedded in COBOL/VSAM applications residing on the mainframe.

Although Sybase says its Gateway products don’t require the Sybase SOL Server RDBMS product in order to function, users who also have SQL Server running on their LANs will be able to take advantage of that product’s programmable server capabilities, which include enforcement of data integrity and security. Users can also write their own applications on the mainframe to provide these services, but most probably will let Sybase do the dirty work.

Explains “Rich Koch” administrator for telecommunications giant Contel Corp.’s record and design systems in St. Louis, “With the Open Server and SQL Server, programmers can go ahead with writing the applications themselves. I don’t want to sit here and write a program where I have to define every single piece of data in every location on the system in every application-I want to get on with it.”

Says Sybase marketing manager Perry Mizota: “We were the first company with a programmable server-before our product, database systems were just wimpy file cabinets.”

With a programmable server, workstation-based applications need not be modified when a company’s business requirements change; instead, these requirements can be defined in a library of reusable routines running on the LAN’S database server that are subsequent called by workstation applications.

The logo lives!

That way, ill, for example, a corporate tax-reporting requirement changes, the change only need be made on SQL Server’s library of routines that may relate to that tax change and not on every financial application in the enterprise. Competitor ASK/ingres now also includes a programmable server, and Oracle Corp. may announce a similar capability on the upcoming upgrade to its RDBMS.

For now, at least, the Sybase products seem to be the only way for client/server applications developers to get access to a whole suitcase of database products residing who knows where in the IBM data center-everything from those crusty sequential files of yesteryear right up to today’s most complex relational or network databases from Computer Associates International Inc., IBM, informix Software Inc. and Oracle-all with just a simple PC application written in C or with a fancy Apple Mac-based HyperCard routine.

The World Of Tomorrow

This puts Sybase products into a whole new world when is managers start looking for client/server enabling technology. Says Contel’s Koch: “In this world, Sybase stops being a relational database company. These products can take an RDB and make it a network database; they can talk to the old flat files on the mainframe and hook them into DB2, then bring them back to an application running on a Mac in a LAN.”

At the same time, the Sybase products offer developers an easy migration route to DB2 applications, since programmers can use the SQL Server and the Open Gateway For DB2 to access existing DB2 data without using a single line of DB2 SQL code.

Just StuffIt Already!

  By admin | February 14, 2012 - 2:13 pm | Uncategorized
Leave a comment

Small is big… Whether it’s miniskirts or miniburgers, there’s big business in getting small — and that’s especially true when it comes to data. With files frequently reaching multimegabyte sizes, data compression is a hot topic and the acronym of the momemt is JPEG (Joint Photographic Experts Group). *JPEG compression is an international standard for still images that’s platform-, hardware-, and software-independent, so a JPEG- compressed file can be decompressed with any system that supports the standard. These compression ratios are as high as 50:1. Of course, when you squeeze your bytes that hard, some of them can get squeezed out permanently, but that’s part of how the JPEG standard works: It eliminates redundant color information that your eyes can’t distinguish anyway. With the JPEG specification nearing final revision, the first JPEG products are hitting the market.

Radius’ ImpressIt is a software-only package. Until now, software JPEG has been considered far too slow to be usable, but this package from Radius ([408]434-1010) is nearly as fast as hardware JPEG and costs significantly less — $179. ImpressIt lets users selectively preview the effects of compression and even select areas within an image to compress.

Storm Technology ([415] 322-0506) straddles the hardware/software line with PicturePress and the PicturePress Accelerator. Although the PicturePress software can do the job alone, adding the accelerator makes it much faster. The accelerator card is unique in that there are no custom chips on it. The card is a pair of AT&TDSP (digital-signal processor) chips that aren’t dedicated to compression. The 60-megahertz DSP chips are software-programmable, so if the JPEG standard changes — as it has frequently over the course of its development — Storm has only to change its software, meaning that users never have to worry about hardware upgrades. (Micron Technology [(208) 383-4000] also sells the Storm products as the ICDP-II.)

StuffIt Deluxe, Aladdin System’s compression standard, is now in version 2.0. Improvements include self-extracting files and automatic application launching from a compressed document. $99.95. *VideoQuill, the type-manipulation package from Data Translation, now includes an optional FontPack that formerly doubled the cost of the package.

*Transform, Spyglass’ data-visualization package, has been upgraded to version 2.0. The enhancements include color contour, surface, and vector plots and support for fast Fourier transforms.

Software Support Is Always A Good Call

  By admin | January 3, 2012 - 2:26 pm | Uncategorized
Leave a comment

The software market is the only one in which customers have no legal recourse if the product they have just bought does not work.

When a PC develops a fault, the remedy is straightforward — you take it back to your dealer or manufacturer, which will repair or replace the goods. However, software users have few rights if they buy a product which stops working, unless it is covered by the manufacturer’s warranty or they have a support agreement.

Jeremy Holt, head of the Computer Law Group at Charles Russell solicitors, points out that: “Users have no legal comeback if they do not have a maintenance contract, unless they can sue a company on the grounds that the product was not suitable for the purpose it was sold.”

Instances of software houses charging dealers or users for technical support and fix-disks are rising. One software manufacturer referred to this as an “optional insurance policy” which makes up for the lack of statutory consumer rights. These charges tend to be passed on from dealers to users, even if the developer gives support free.

Waaaay past its best before date.

These problems were highlighted by the Multisoft General Ledger bug, which refused to accept dates involving 1992. This made the package virtually unusable for those who had entered the 1992 financial year. However, for those ‘insured’ by a maintenance agreement the fix was readily available — others had to buy the package again.

Multisoft leaves all user support to its dealers, but in order to improve the level of support it has raised the maintenance charges to between two and three per cent of each end-user sale. This is considerably more than dealers were paying previously. As a result the dealers claim that despite the actual fix being free, they cannot afford to offer it to users who refuse to take out a support agreement.

Many dealers feel that, especially with networked or Unix solutions, clients are not respecting their investment if they refuse support. And with depressed margins forcing a shift to value-added sales, many dealers need to impose support as a way of differentiating themselves from those operating in the cheaper grey market.

On the other hand, users should not have to insure themselves against manufacturers’ errors. Even when users do take maintenance contracts, it is rarely clear what they cover. They usually consist of a limited helpline service and a general undertaking to fix bugs and issue updates.

Accounting software developer Pegasus supports its users through a network of 800 dealers. Users are charged a yearly fee for maintenance, even though the dealers are not charged by Pegasus. Support to the dealers consists of a free telephone support line and fix disks.

AMA Business Systems, one of Pegasus’ dealers, charges 295 pounds a year to support single-user packages. This gives users access to a technical support line and a callout service. Update disks cost extra. Managing director Alistair Moir said: “If Pegasus was to introduce a charge to its dealers, we would have to pass the charge onto users, but would probably provide free upgrade disks.”

A common argument among software houses and dealers is that software support must be paid for by someone, and it is logical that users should foot the bill.

Roger Smolski, director of the IBM PC User Group, claims: “When users take the cellophane off a product, they are concerned more about future updates than hotline support.” But even when support is taken out, the service is not always up to scratch. Smolski feels that for users, “the cost of support is not an issue, it is the quality that counts”.

Sage does not charge its dealers for software support. Direct support for users is available, but at a price. This entitles them to things such as regular technical bulletins, update disks and a technical helpline.

If users can choose between paying for support from their dealer or the developer, it is better to get information direct from the horse’s mouth. And if software houses are offering free support, there is little point in paying extra for the same service.

Microsoft charges neither is users nor its dealers for technical support, but the dealers can charge users. Microsoft users are entitled to bug fixes and new printer drivers which are mailed directly, free of charge. The only service for which Microsoft charges is an on-line dial service which provides users with access to the text support database.

Many software houses try to discourage users from contacting them directly. As one of the few companies that users can contact directly with a problem, Microsoft has often come under fire with complaints that customers can not get through to the support hotline.

But a Simon Narracott, marketing manager for two of the business units at Microsoft, points out: “People phone us directly instead of contacting their dealers when they have a problem. We have 60 support people, but it wouldn’t matter if we had 300 — people would still complain that they couldn’t get through. It is a no-win situation.”

Progress In Financial Software

  By admin | August 9, 2011 - 2:10 pm | Uncategorized
Leave a comment

You know the story. Budget time is fast approaching and-Surprise!-everybody is breathing down your neck for the latest data on expenditures-to-date, last year’s spending level, year-over-year comparisons, the list goes on and on.

If only...

Sure, you’ve probably got a module in your mainframe financial management package that can chunk out those reports as fast and furiously as Frank Perdue can pluck chickens. Only one problem, though: when the system is busily plucking all those data out of the financial database, manipulating them, processing them and printing up the results, not much else can happen.

Now, it’s not like there aren’t solutions to this problem, but some of them border on the extreme. Dayton, Ohio-based Mead Corp. used to solve its own ballooning financial information needs during budgeting time manually-by bringing in the accountants with their adding machines.

They’d spend hours and hours figuring out the impact on sales, revenue and income of, say, a 5% price increase over last year or the year before, says Vicki Walkup, senior systems analyst at the giant paper products purveyor.

“They could have used the system,” says Walkup, who regularly worries about the need to shave cycles off the company’s mainframe, “but only at the price of multiple batch runs to create transactions confined to the ledger and then to create other transactions.”

Walkup began to solve Mead’s budget crunch problems when she installed a cooperative-processing upgrade to the budgeting component of Harmonix, the mainframe-based integrated financial application used at Mead. Mead had been a long-time user of Raleigh, N.C.-based Global Software Inc.’s Harmonix general ledger application, which in addition to the budgeting module, includes purchase order management, accounts payable and accounts receivable modules.

Cooperative Tidal Wave

For Walkup “the main thing that we look at in cooperative processing is taking cycles off the mainframe.”

Cooperative processing, where actual processing takes place across multiple platforms-a portion on a PS/2 or equivalent workstation and a portion on a mainframe or midrange computer host-frees the host to become the guardian of data integrity. The newly powerful PC becomes the workhorse for resource-intensive calculations, validations and user friendliness.

Firstest With The Mostest?

Some vendors of financial software have started to offer products with limited forms of cooperative processing. But Global is generally considered to be a step ahead of the competition with the cooperative-processing upgrades to its Harmonix products. Global’s president Ronald J. Kupferman even claims Harmonix is the “world’s first commercially available, true cooperative-processing system” for financial applications.

John LePere, Global’s director of product planning, says that other vendors moving to cooperative-processing systems are essentially trying to give their mainframe products the look and feel of cooperative processing by merely using some P(:based tools to build graphical interfaces that make screens look better.

LePere maintains that, in capabilities and function, Global’s Harmonix products go far beyond these screen painters.

“When we talk about cooperative processing, we talk about the host and the PC truly cooperating,” LePere says. “For example, in accounts payable or invoice editing done on a PC [under Harmonix], what gets sent later to the host-based database is a record updated into a master file that doesn’t undergo edits again.”

And, whether the transaction is PC-based or host-based, it is invisible to the end user, he adds. “Our cooperative-processing applications will automatically go to the host to do certain kinds of validations and other kinds of data look-ups.” The user then can access those data on the PC, “but the user doesn’t know whether he or she retrieved it from the host computer or from some locally stored information.”

Total Rewrite Time

Early this year, Global launched a complete cooperative-processing rewrite of its original 15-year-old integrated financial management application suite. First to hit the streets was the budgeting module, soon to be followed by the purchase order module and then the remainder of the modules in the Harmonix package. Global will also enable all modules to run under Windows 3.0 later this year.

The handful of users who have been able to try early versions of the cooperative-processing modules for Harmonix sing their praises. “The purchase order package looks good, especially for somebody who wants to use a lot of EDI [Electronic Data Interchangel," explains Jim Holmes, operations manager in McIntyre, Ga., for Englehard Corp. Holmes assesses new technology for the Edison, N.J.-based chemicals manufacturer and precious metals management provider.

Holmes says the newly cooperative purchase order package permits use of better vendor analysis methods on the PC, which reduces traffic on the company's IBM System/38 mainframe.

"By bringing down a segment of our purchasing environment [from the mainframe database] such as commodities, we can pull that into the purchasing environment and match it to different contract rates to get the better price rates out of a deal,” he says. Holmes adds that he has been pushing Global to get it into users’ hands.”

The price of Harmonix and its upgrades varies according to configuration, but basically, Global charges $15,000 to $25,000 for cooperative-processing upgrades to its applications, bringing the general ledger package, for example, to around $160,000 for new users. Its purchase order and accounts payable cooperative-processing packages will be priced in the range of $75,000 to $100,000. Global–which has been in business for 10 years–saw revenue of $25.9 million last year, an increase of nearly $3 million a year since 1988.

Pushy,Pushy,Pushy

According to LePere, the company moved to offer cooperative processing as a response to customer pressure. “Our customers probably pushed us like we’ve never been pushed before,” he says. But software industry analysts wonder if enough customers have a real understanding of the advantages of cooperative processing to push other vendors into action. Some argue that many users and vendors are somewhat befuddled over how a lot of the new technologies associated with cooperative processing fit their needs and markets.

Adds John Landry, veteran software technologist, who recently joined Global competitor Atlanta-based Dun & Bradstreet Software Services Inc. as chief technology officer: “You must make sure you don’t wipe out their [customers'] investments by coming out with a complete new architecture that in no way allows them to use the old systems that they have come to know and love. The easiest way to solve that problem is [for them] to do nothing.”

But Global doesn’t see it that way. Global’s customers, says LePere, “recognized that they can buy a lot of MIPS very cheaply on a PC, that they can save some host cycles, that they can get a better interface and better productivity.”

Of course, D&B isn’t doing nothing itself-, the company has long offered workstation development tools that allow customers to build cooperative-processing applications. Landry says these tools are but starters along the way in a long-range D&B plan to offer a cooperative-processing applications suite.

Environmental Jumble

Considering the sprawling jungle of diverse hardware and software systems operating in most shops, Landry explains, a key element of D&B’s cooperative-processing strategy is that the server components will be interchangeable. “They can be either IBM mainframes, because there’s such a huge investment in them, or we will provide customers with the capability of moving to a RISC-based server like an IBM RS/6000, as well as perhaps the vAx or a Compaq 486. That’s the type of thing you get with cooperative processing-systems that you couldn’t really do in the more centralized environments,” Landry says.

Global, in contrast, follows IBM’s Systems Applications Architecture (SAA), where cooperative-processing I/O is handled by a central mainframe- or minibased set of modules. The modules can manage a wide variety of user input, whether on a PC or a 3970 terminal or a batch stream, LePere explains. “Our products look the same whether you’re on an IBM mainframe or an IBM midrange system.”

D&B will begin to offer its cooperative-processing product before the end of the year, says Landry. Economic arguments are getting strong for cooperative processing,” he adds. Mead’s Walkup thinks the user community will be watching closely for any new cooperative-processing financial application products. “If you get behind, it’s hard to catch up. ”

Did He Just LISP?

  By admin | June 8, 2011 - 2:17 pm | Uncategorized
Leave a comment

When developing complex graphical applications, it is essential to work in an interactive development environment, according to developers. LISP, they say, offers a superb interactive environment that far outshines other languages.

Lookin' Good. Sounding? Uh, hmm.

“I have investigated all languages and, because it is self-modifying, LISP is the most powerful in existence,” said Al Bugay, a computer scientist at the Space Technology Labs of Orbital Sciences Corp., a spacecraft manufacturer in Boulder, Colo. “LISP is a symbolic front end that allows you to have global control over your application.

“With LISP, you can describe very complex processes in a small amount of code,” he added. “This is five to 10 times an improvement over C.”

Bugay uses Gold Hill Inc.’s GCLisp Developer 4.0 for the development of a multiwindowed graphical user interface (GUI) application for use in real-time analysis of spacecraft data.

Bugay chose GCLisp because it is the only LISP system that will run smoothly on DOS-based 386 systems, he said.

“I have worked with other LISP products that run on Unix, but I have had no luck getting good performance on a 386 machine,” said Bugay. “Gold Hill has been able to support the 386 platform and Windows. This is a breakthrough, because now you get robust mainframe workstation capabilities on a 386 machine.”

For a complete interactive environment on the Macintosh, users such as Douglas Currie, vice president of technology at Flavors Technology Inc., a software development firm in Amherst, N.H., are choosing Apple Computer Inc.’s Macintosh Allegro Common Lisp 1.3.2 for its flexibility.

“We like to work in a mode where we can do incremental development,” said Currie. “All of our workstation software is written in LISP, and we use the Macintosh as a platform for all of our development tools that we supply with our products.”

Currie stressed the importance of being able to offer customers demonstrations of a product as it is developed. Macintosh Common Lisp lets users mix compiled code with code that’s still under development.

“LISP offers a very flexible environment where we are able to make incremental changes and still have something working,” Currie said.

“I have found that it is very difficult to develop in languages like C and Pascal because they, unlike LISP, offer very little visibility into the process,” he added. “When you are working in a complex windowing environment in LISP, you can go in and see directly what it’s doing and be able to experiment with it.”

Orbital Sciences’ Bugay also finds GUI development in GCLisp more manageable than with other languages.

“Because it is such a robust language and GCLisp offers users the total LISP environment, GUI development is much more straightforward than with other languages,” he said. “With other development environments, you can get lost in details.”

Ken Krohn, vice president of development at ComputerWare, a software-development firm in Cambridge, Mass., also uses GCLisp Developer 4.0, but he said the GUI support isn’t its strongest feature.

“GUI development is probably not the best feature of GCLisp, because it is not a true graphic-oriented implementation. It seems to me that it is kind of tacked on [to the product],” Krohn said. “Although I find the graphic-development support to be adequate in GCLisp, I don’t think it is where the focus of the language is.”

Krohn uses GCLisp to develop special communications software. He said he chose LISP as his development language because of its flexibility.

Krohn was attracted to GCLisp because of its extensive implementation of LISP features, he said. However, he added, GCLisp is slower than he would like.

Speed is one of the stronger features of Macintosh Common LISP 1.3.2, according to Ron MacNeil, principal research associate at the Visible Language Workshop at the Media Labs of the Massachusetts Institute of Technology in Cambridge, Mass.

“GUI development with [Macintosh Common LISP] is very fast because changes happen right away, without a lot of recompile time,” MacNeil said. “When you are making a small change, you only have to recompile that portion, and then you can test the interface again.”

MacNeil and Currie both stressed the value of having a large community of LISP users to communicate with.

“LISP is a common language that I can always find programmers to work with,” Currie said.