COBOL sp2, The 100% COBOL Solution for Graphical User Interface Development

A Brief Summary of COBOL sp2

COBOL sp2 is a Graphical User Interface (GUI) Development tool which was designed specifically for professional COBOL programmers.  COBOL sp2 allows you to add a GUI interface to your COBOL application using 100% native COBOL CALL USING statements and Working Storage parameters.

With COBOL sp2, your entire source program can be written in ANSI standard COBOL.  The COBOL sp2 CALL’s and screen definitions are 100% portable across all the major COBOL compilers and even portable from text mode to GUI mode environments.

Your COBOL application written using COBOL sp2 is a 100% true Microsoft Windows application.  Our COBOL sp2 Dynamic Link Library (DLL) which is CALLed from your COBOL application is written in C and directly invokes the Microsoft Windows APIs and utilizes the Microsoft Windows Resource Files.

The Components of COBOL sp2

• A Panel Editor which is an interactive window painting tool;
• A Code Generator which generates COBOL source code;
• A Runtime System for advanced screen display in COBOL programs; and
• A set of very powerful optional add-on tools to allow you to save more time and build the most modern applications possible.

Here is a screen capture showing the COBOL sp2 Panel Editor:

No Need to Write Windows API Calls or a New Programming Language with COBOL sp2

Application Program Interface code, or API code, is an option for displaying GUI screens from a COBOL application.  Because COBOL sp2 allows developers to continue writing in ANSI Standard COBOL 85 CALL USING statements to control screen handling, all of your applications can be written using ANSI standard COBOL instead of in much more complex and cryptic event driven code or a new programming language.

COBOL sp2 is a Superior Alternative to API Code for GUI screens in a COBOL Application

COBOL sp2 is superior to API code for GUI implementation in a COBOL application because COBOL sp2 allows you to control screens with a 100% COBOL programming interface.  API code is more like C Language code than COBOL. Using API code in a COBOL application is like writing a mixed language program. Using API code, maintenance costs will accelerate in the future, because program modification and debugging become more complex. In addition, your COBOL source debugger may not even work with embedded API code in your COBOL program.

COBOL sp2 is 100% portable across many environments, API code is not. Windows API code is very different than API code for other environments.  Additionally, there is no API code for UNIX character-based environments.  If you want to run the software in multiple environments, your programming staff must support multiple versions of your source program.  If you decide to change environments in the future, your staff must re-write the API code for the new environment.

COBOL sp2 uses familiar COBOL for the programming interface.  API code requires significant programming staff re-training.  API code is very cryptic which makes it difficult for large groups of programmers to maintain applications.  Likewise, COBOL sp2 programming is accomplished in a very comfortable and traditional procedural manner.  Using API code involves writing programs in an event driven fashion.  Event driven programs allow any event to occur at anytime during the processing of your application.  COBOL programmers are used to programming in a procedural fashion.  Trying to mix a process driven program with an event driven program is only going to result in program implementation delays and more headaches because of the increased complexity of the program.

The COBOL sp2 copybook named SP2.CPY contains all of the supported sp2 functions.  Microsoft Windows provides over 700 API CALL’s.  Even learning the commonly used API CALL’s is a difficult task for any programming staff.  Perhaps the biggest reason to avoid using API code is the fact that Microsoft has even dropped certain API functions or dramatically changed the way a particular function works.  We can insulate you from those types of headaches by giving you a COBOL programming interface which will not force you to re-write code in the future.

A Few Sample User Interface Screens Created Using COBOL sp2

Increase Your Productivity with COBOL sp2

It’s much faster using a Windows painting tool than writing Windows GUI API Code by hand.  In addition, learning to write Windows API code is like learning to write code in an entirely different language.  The API is fairly complex, so COBOL sp2 helps you simplify your programming task by allowing you to avoid writing API code.

User interface design is a time consuming and very necessary task in the COBOL application development process. By using the COBOL sp2 Test Facility to test the functionality and appearance of windows, the design stage is accomplished in less time, with much greater ease.

After the design work is completed, the panel definition file may be handed directly from the designer to the programmer. The programmer doesn’t have to write code for the screen layout, because it’s already completed.

End users are demanding more sophistication from their program screens, yet the job of hand coding continues to become more complex and tedious.

A professional user interface development environment provides advanced screens in a fraction of the time it takes to hand code such screens.

The Code Generation Facility reduces the amount of COBOL procedural code which must be hand written by generating a test program.

No Requirement to Re-write Substantial Portions of Your Application with COBOL sp2

Some GUI tools such as Visual Basic changed so dramatically each time a new version was released; a considerable amount of source code had to be re-written to use it.  Flexus has never done that to our customer base.  We believe that a business application is an asset and should last as long as possible in order to minimize costs for the programmer.  Every version of COBOL sp2 released has allowed the COBOL programmer to preserve the existing source code and continue forward adding exciting new enhancements to the business application being written with COBOL sp2.

No Requirement to Re-write Your Code if You Switch COBOL Compilers in the Future

COBOL sp2 is 100% COBOL compiler independent.  The COBOL programmer uses the same COBOL source code and COBOL sp2 screen definitions regardless of which compiler is used.  This allows the COBOL programmer to switch compilers more freely than if they were to use a proprietary solution, such as those GUI solutions offered by the compiler companies themselves.  This means that you aren’t locked in to a specific compiler in the event that you may have to switch compilers in the future.  Ask your COBOL Tools vendor if they support the entire list of COBOL compilers which are supported by COBOL sp2:

COBOL Compilers Supported by COBOL sp2

• Acucobol 85
• Acucobol GT
• Acucorp Extend Compilers (All versions)
• CA-Realia COBOL
• CA Realia II Workbench
• CA Advantage Realia Workbench
• COBOL IT
• Data General ICOBOL
• Fujitsu COBOL (All Windows and UNIX versions)
• Fujitsu .NET COBOL
• IBM Visual Age COBOL
• mbp Visual COBOL
• Micro Focus COBOL (All Windows and UNIX versions)
• Micro Focus Object COBOL
• Micro Focus NetExpress (All versions)
• Liant RM COBOL (All Windows and UNIX versions)
• Compaq VAX/VMS COBOL and OpenVMS COBOL

No Requirement to Re-write Your Code if You Switch Operating Systems in the Future

COBOL sp2 is 100% operating system independent.  The COBOL programmer uses the same COBOL source code and COBOL sp2 screen definitions regardless of which operating system is used.  This allows the COBOL programmer to support more operating systems with only one set of screens and one set of COBOL source code.    Ask your COBOL Tools vendor if they support the entire list of operating systems which are supported by COBOL sp2:

Operating Systems Supported

• Windows 95, 98, ME, 2000, NT, XP, 7, 8.x and 10 (32 bit and 64 bit Windows supported; compiler must have same bit depth)
• Intel based UNIX and Linux
• Other UNIX (various proprietary CPUs, AIX, HP-UX, DG-UX, Digital UNIX, etc.)
• VAX/VMS and Open VMS character mode (VAX COBOL or Acucobol required)
• IBM Mainframe OS/390 UNIX System Services
• IBM Mainframe Linux

In addition, you can even run your COBOL program on a UNIX or Linux based platform and display the user interface screens on remote Microsoft Windows PC’s with our Thin Client product.  Please see the Thin Client product information for more details.

Switch Between Windows and UNIX Character Mode and Maintain One Set of Source Code

COBOL sp2 is 100% text to GUI independent.  The COBOL programmer uses the same COBOL source code and COBOL sp2 screen definitions regardless of whether the application must run on a character mode system or under Microsoft Windows.  If you do need to run on a character mode system, you obviously will not be able to display graphical elements on your screens, but COBOL sp2 offers a number of ways to make your GUI screens look as modern and graphical as possible, while still allowing you to run your application in character mode.  One of these ways is for you to use the powerful COBOL sp2 dynamic screen creation capability.

COBOL sp2’s Powerful Dynamic Screen Creation Capability

COBOL sp2 offers the ability to create and modify user interface screens directly from your executing COBOL application.  This makes COBOL sp2 one of the most powerful and flexible COBOL user interface tools available.  With the dynamic screen creation capability:

• You don’t have to paint your screens in a screen painter in advance as screens can be built directly in memory as the COBOL program executes.
• You still have the ability to paint screens in advance and then dramatically modify them on the fly in your COBOL application.
• You can create screen conversion tools if you are migrating an older COBOL program to a modern Microsoft Windows platform.  Yes, character mode screens can be converted to GUI screens automatically.  You should contact Flexus first as we have already written a number of screen conversion tools.
• You can create a single data entry screen and then add or delete certain fields based upon user security level.  In some instances this will allow you to create a single screen which is dynamically modified rather than dozens or even hundreds of custom screens.

COBOL sp2’s Support for Integrating Your COBOL Application with Microsoft Office

With the COBOL sp2 Active X Control Add-on, you can launch Microsoft Word or Microsoft Excel and pre-load data into either application.  That allows you to automate your COBOL program to support helper applications such as modern word processor or spreadsheet applications.

COBOL sp2’s Support for Highly Advanced Embedded Controls

COBOL sp2’s Active X Control support can also be used to invoke and control just about any type of Active X Control available.  This gives you the capability to add additional 3^rd party controls to significantly enhance and modernize your application.  Just a few examples of the types of controls which you can add include:

• Image Processing Controls
• Fax Distribution Controls
• E-mail Controls
• Serial Port Device Controls
• Graphing Controls
• Charting Controls
• Multimedia Controls
• Word Processor Controls
• Spreadsheet Controls
• Tab Controls
• Grid Controls
• …and hundreds of other types of powerful controls

The sky is the limit with COBOL sp2 and embedded external controls through the use of the COBOL sp2 Active X Control add-on.  There are literally tens of thousands of sophisticated Active X Controls which support a myriad of highly advanced functions.  Because COBOL sp2 supports embedded Active X Controls through our add-on tool, you can create the most sophisticated and powerful screen you can imagine.  This allows you to save a considerable amount of time, because the complexity of the embedded control has already been written for you.

Complex controls are managed easily because everything is controlled using COBOL sp2 CALL USING statements.  In addition, COBOL sp2 generates the COBOL copybook to allow you to communicate directly with the control and offers the ability to register the control when your application is installed on one of your customer’s PCs.

Here are some screen shots showing a variety of Active X controls which have been embedded into a COBOL sp2 panel:

COBOL sp2’s Support for Advanced External Peripheral Devices

COBOL sp2 supports bar code scanners and readers, touch screens and other advanced peripherals which provide a software driver to communicate through the keyboard buffer.

COBOL sp2’s Support for Sending E-mail from a COBOL Application

Yes.  With the COBOL sp2 SMTPSimple add-on, you can send e-mail messages directly from your COBOL application.  This includes the full range of recipients (To, From, CC and BCC) as well as body text and file attachments.

The Type of COBOL Programmer Who Should Use COBOL sp2

COBOL programmers who fit the following criteria would benefit greatly from the use of sp2.  This includes programmers who are interested in:

• Increasing their productivity
• Maintaining one source program for text & GUI (Graphical User Interface) environments
• Developing GUI systems without learning a new language
• Adding advanced screen handling to their COBOL applications
• Reducing future maintenance efforts
• Migrating their COBOL user interface to other operating systems
• Having the greatest amount of flexibility in a user interface productivity tool

The Benefits of Using COBOL sp2

• COBOL sp2 supports quick and easy development of advanced character mode windows or GUI windows without re-training.
• COBOL sp2 supports the ability to run a program on many operating systems without change.
• COBOL sp2 supports the ability to run an application in a character mode or GUI environment without change.
• COBOL sp2 supports the ability to switch COBOL compilers without changing screen-handling source or screen definitions.

The Hazards of Using C++ or Java for GUI Implementation

COBOL was designed to make business applications easier for large programming staffs to maintain. The acronym COBOL stands for “COmmon Business Oriented Language.” The C language was developed by system software experts for developing system software. The C language is generally considered a lower level language. Most large companies have worked very hard to avoid the use of lower level languages in application development because of maintenance difficulties.

Java is very similar in nature to C++.  It is event driven, far more cryptic than COBOL and interpretive.

Using C, C++ or Java with COBOL results in the same headaches as using API code with COBOL. For example:

• Using C, C++ or Java with COBOL results in “mixed language” maintenance and debugging headaches.
• Your mixed language source program may not be as portable as your COBOL source program.
• C, C++ and Java compilers which support GUI window development use event driven methodologies, not procedural driven methodologies.
• Using C, C++ or Java for your user interface will result in extensive and costly staff re-training.

Reusability of COBOL sp2 Screens in Other COBOL applications

You can copy existing screens with COBOL sp2, so future COBOL programs can have an interface consistent with all previous applications. It also means that future programs will be written in less time, because the design has already been created and tested. Program development productivity will increase as more programs are written with similar screens.

Risks Associated with Purchasing User Interface Tools from Your COBOL Compiler Company

The primary reason you should purchase COBOL sp2 instead of a user interface tool from your COBOL compiler company issue is that your compiler company specializes in COBOL compilers, not the associated toolsets. Flexus has always specialized in COBOL development tools, NOT compilers.  Most people wouldn’t ask their attorney to perform surgery nor would they allow their surgeon to represent them in court.  Why would you rely on a company which specializes in COBOL compilers to provide you with the best development tools?  Many of the compiler companies have gone through 2, 3 or more different user interface tools in the past few years.  Can you afford to completely re-write your COBOL user interface next year, when your compiler company changes to a completely different user interface tool?  Compiler companies have also come and gone.  One company, for example, started selling a COBOL compiler a few years ago, and eventually discontinued it.  The company then licensed a compiler from a second company and sold it.  Eventually that COBOL compiler was also discontinued.

If you buy a user interface tool from your compiler company, you are locked into their compiler. Can you take that risk?

Flexus designs and develops tools for PC, Mini and Mainframe COBOL programmers. We focus 100% of our energies on offering the best tools available to the COBOL programmer. COBOL tools are the only thing we do, so we have to do them better than anyone else. COBOL compiler companies specialize in what they know best… COBOL compilers. We specialize in what we know best… add on tools which are 100% COBOL oriented.

Flexus…In Business Since 1983 and Still Going Strong

Flexus was incorporated in 1983, so we’ve been around for a while and intend to be around for a long time. Flexus has thousands of licensees in over 30 countries around the world.

No Need to Re-write Your Source When a New GUI Environment Becomes a Standard

Nobody can provide you with a guarantee that their system won’t become obsolete. Flexus has the best track record in the COBOL user interface business against source program obsolescence.

COBOL sp2 offers the most portable, adaptable user interface tools available. Some compiler companies have introduced user interface tools only to discontinue support for those tools later. That means their customers were forced to re-create all of their source programs and screen definitions. We don’t do that to our customers.  Any user interface screen developed with any version of our user interface development tools has always been upwardly compatible and adaptable:

• across operating systems,
• across text to graphical user interfaces
• across COBOL compilers.

Because you can create and modify windows dynamically, sp2 allows you full access to the screen definition files, so you’re not even locked into sp2. COBOL sp2 frees you from proprietary systems, instead of locking you in.

Flexus, an Uninterrupted History of Continuous Software Upgrades

Ever since our first user interface tool was released back in 1986, Flexus has provided a continuous stream of major enhancements and major version changes each and every year.  In addition, Flexus has always provided an upward migration path for our customers so that it is unnecessary to expend time and money in major source code re-writes.

NO OTHER COBOL tool vendor can make the same claim! Some user interface tool vendors waited for many years to release new versions of their products. Others performed a complete re-write of their user interface tools which required their customers to completely re-write their source code.  We believe that customers should NOT have to wait years for major new enhancements, nor should they ever be forced to re-write their applications to take advantage of a new environment.

Here are some critical questions to ask a company who wants to provide you with their COBOL user interface tools?

1. Since the initial release of your product, have you ever allowed a year or more to pass without a new release?
2. What year did you first release your GUI version?
3. Did you provide an automated and seamless upward migration from your character mode version to your GUI version?
4. Does your company provide Internet client/server tools which use the existing screens and source code unchanged? If so, what year did you release the product?
5. Does your company provide Internet Web Browser user interface tools which use the existing screens and source code unchanged? If so, what year did you release the product?
6. Does your company offer sophisticated Windows Print Manager tools?
7. Does your company offer automated conversion tools for older, obsolete screen definitions?
8. Does your company offer a host of add-on products which allow the COBOL programmer to easily add E-mail support, Microsoft Office integration, and other important modern business application capabilities?

COBOL sp2 has been continually enhanced to provide new features

Future Upgrades and Enhancements to Existing GUI Screen Features

Flexus has always taken great pride in continually offering COBOL programmers real solutions for higher level screen handling technology. Flexus has been a technological leader in providing new screen handling features to COBOL programmers and supporting the latest windowing environments. All Flexus products have constantly evolved to offer advanced text and graphical user interface capabilities to the COBOL programming community.

Flexus Technical Support Services Programs

We offer great technical support services…..just ask any of our customers.  The following services are included in our standard license fee and available for renewal for a fixed annual maintenance fee 12 months after the initial; purchase:

• unlimited e-mail technical support services
• an online community of our customers which we refer to as the Flexus Forum
• an FTP server to allow you to download the latest version of our software 24 hours per day, 7 days per week

We believe that a software product is only useful if technical support is excellent. Ask any of our customers. They’ll tell you that we offer high-quality technical support.  We’re also on East Coast time……so you don’t have to wait until the afternoon for our technicians to respond to your e-mail inquiries.  You can usually get an e-mail reply from us very quickly. We always make every effort to respond to your technical support inquiries as quickly as possible during the normal Monday through Friday work week.

Please give us a call, send a fax or E-Mail if you have additional questions that we didn’t answer here.