COBOL FormPrint, The 100% COBOL Solution for Windows Printing
A Brief Summary of COBOL FormPrint
COBOL FormPrint is a Windows Printing Development tool which was designed specifically for professional COBOL programmers. COBOL FormPrint allows you to add Windows Print Manager support to your COBOL application using 100% native COBOL CALL USING statements and Working Storage parameters.
With COBOL FormPrint, your entire source program can be written in ANSI standard COBOL. The COBOL FormPrint CALL’s and form definitions are 100% portable across all the major COBOL compilers and even portable across all versions of Windows.
Your COBOL application written using COBOL FormPrint is a 100% true Microsoft Windows application. Our COBOL FormPrint 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 FormPrint
- A Form Editor which is an interactive window painting tool;
- A Code Generator which generates COBOL source code;
- A Runtime System for advanced form printing 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 FormPrint Form editor with a blank screen:
Create GREAT Looking Forms and Documents with COBOL FormPrint
This invoice form was created by Jorge García Zubia of i3 Aplicaciones Informáticas of Leioa, in Northern Spain. As you can see, Jorge is quite talented when it comes to creating a professional looking invoice form. You can contact Jorge by accessing his company’s web site: www.i-3.es and clicking on the Contacte option.
No Need to Write Windows API Calls or a New Programming Language with COBOL FormPrint
Application Program Interface code, or API code, is an option for printing through the Windows Print Manager in a COBOL application. Because COBOL FormPrint allows developers to continue writing in ANSI Standard COBOL 85 CALL USING statements to control form printing, 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 FormPrint is a Superior Alternative to API Code for Printing in a COBOL Application
There are a number of reasons why COBOL FormPrint is a much better solution than API code for Windows printing in a COBOL application.
COBOL FormPrint allows you to control printing with a 100% COBOL programming interface. API code is not at all like COBOL. It is more like C Language code than COBOL. Using API code in a COBOL application is like writing a mixed language program. Maintenance costs will accelerate in the future because program modification and debugging become much more difficult. In addition, your COBOL source debugger may not even work with embedded API code in your COBOL program.
COBOL FormPrint is 100% portable across many environments. API code is not portable across different environments. The API code which works in one version of Microsoft Windows may work very differently in other versions of Microsoft Windows. In addition, there is no API code for UNIX or Linux character-based environments. This means that your programming staff must support multiple versions of your source program if you want to run the software in more than one environment. You may also decide to change environments in the future. This means that your staff must re-write the API code for the new environment.
COBOL FormPrint uses familiar COBOL for the programming interface. API code requires significant re-training for your programming staff. API code is very cryptic which makes it difficult for large groups of programmers to maintain applications.
COBOL FormPrint 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 FormPrint copybook, named QPR.CPY, contains all of the supported FormPrint 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.
Increase Your Productivity with COBOL FormPrint
It’s much faster using a Windows form painting tool than writing Windows printing 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 FormPrint helps you simplify your programming task by allowing you to avoid writing API code.
Form design is a time consuming and very necessary task in the COBOL application development process. By using the COBOL FormPrint Test Print Facility to test the functionality and appearance of your printed documents and forms, the design stage is accomplished in less time, with much greater ease.
After the design work is completed, the form definition file may be handed directly from the designer to the programmer. The programmer doesn’t have to write code for the form layout, because it’s already completed.
End users are demanding more sophistication from their application documents and forms, yet the job of hand coding continues to become more complex and tedious.
A professional form printing development tool produces advanced forms in a fraction of the time it takes to hand code such forms.
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 FormPrint
Some Windows 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 FormPrint 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 FormPrint.
No Requirement to Re-write Your Code if You Switch COBOL Compilers in the Future
COBOL FormPrint is 100% COBOL compiler independent. The COBOL programmer uses the same COBOL source code and COBOL FormPrint form 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 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 FormPrint:
COBOL Compilers Supported by COBOL FormPrint
- Acucobol 85
- Acucobol GT
- Acucorp Extend Compilers (All versions)
- CA-Realia COBOL
- CA Realia II Workbench
- CA Advantage Realia Workbench
- Data General ICOBOL
- Fujitsu COBOL (All Windows versions)
- Fujitsu .NET COBOL
- IBM Visual Age COBOL
- mbp Visual COBOL
- Micro Focus COBOL (All Windows versions)
- Micro Focus Object COBOL
- Micro Focus NetExpress (All versions)
- Liant RM COBOL (All Windows versions)
Note: FormPrint can also be used in a UNIX, Linux or VMS server environment and print to remote Windows PC’s across a TCP/IP network when you incorporate Flexus’ Thin Client product. Because your COBOL would reside on the UNIX, Linux or VMS server, this means FormPrint also support UNIX, Linux and VMS servers as well, when used in conjunction with Thin Client.
No Requirement to Re-write Code if You Switch Environments in the Future
COBOL FormPrint is 100% Windows version independent. If you use Thin Client with FormPrint, you can still use the same form definitions and source code with a new server operating system. The COBOL programmer uses the same COBOL source code and COBOL FormPrint form definitions regardless of which operating system is used. This allows the COBOL programmer to support more operating systems with only one set of forms 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 FormPrint.
Operating Systems Supported
- Windows 95, 98, ME, 2000, NT, XP, Windows 7 and Windows 8 (32 bit Windows; 32 bit COBOL compiler required)
- Windows 7 and Windows 8 (64 bit Windows; 64 bit COBOL compiler required)
- Intel based UNIX and Linux (Thin Client server license required)
- Proprietary UNIX (AIX, HP-UX, DG-UX, Digital UNIX, etc.) (Thin Client server license required)
- VAX/VMS and Open VMS (VAX COBOL or Acucobol required) (Thin Client server license required)
- IBM Mainframe OS/390 UNIX System Services (Thin Client server license required)
- IBM Mainframe Linux (Thin Client server license required)
As mentioned earlier, you can even run your COBOL program on a UNIX or Linux based platform and print your documents and forms 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 and Maintain One Set of Source Code with Thin Client
COBOL FormPrint supports the Windows Print Manager, but can actually be used in conjunction with UNIX or Linux. The Flexus Thin Client allows the COBOL program to be run on a UNIX or Linux server environment and print forms using remote Windows PCs across a TCP/IP network.
The COBOL programmer uses the same COBOL source code and COBOL FormPrint form definitions regardless of whether the application must run on a UNIX server, Linux server, VAX/VMS server or Microsoft Windows server. If you do need to run your COBOL application on non-Windows machines and want to print on remote Windows client machines, then Thin Client and FormPrint are a great solution.
COBOL FormPrint’s Powerful Dynamic Form Creation Capability
COBOL FormPrint offers the ability to create and modify documents and forms directly from your executing COBOL application. This makes COBOL FormPrint one of the most powerful and flexible COBOL printing tools available. With the dynamic form creation capability:
- You don’t have to paint your forms in a form painter in advance as forms can be built directly in memory as the COBOL program executes.
- You still have the ability to paint forms in advance and then dramatically modify them on the fly in your COBOL application.
- If you are migrating an older COBOL program to a modern Microsoft Windows platform, you can use the Flexus ADVLINEP add-on product to keep your line printing source code and still print directly to the Microsoft Windows Print Manager. You should contact Flexus for more details.
- You can create a single printable form and then add or delete certain fields based upon user security level. In some instances this will allow you to create a single form which is dynamically modified rather than dozens or even hundreds of custom forms.
Create Adobe Acrobat PDF Files, JPG Image Files of Send Faxes Using FormPrint
Because FormPrint writes directly to the Windows Print Manager, you can designate any Windows printer driver as the target printer. This can include all of the following:
- Stand-alone printer connected to your PC
- Network printer
- Remote printer across a TCP/IP network, such as the Internet (Requires Thin Client)
- Any fax printer driver, such as WinFax
- Adobe Acrobat PDF Writer
- Adobe Acrobat Distiller
- Any other standard windows printer driver
Scan Pre-printed Forms and Embed the Image into a FormPrint Form Definition
COBOL FormPrint supports the ability to embed a background image into the form definition. This allows you to scan a pre-printed form and easily place it into your form. You can then overlay data fields on top of the scanned form data areas. You can also establish transparent backgrounds for the COBOL FormPrint data fields so that if the data has to print in a colored or shaded area of the scanned form, the color or shade will not be hidden by the data field when printed.
This is a great feature for putting a watermark on your COBOL FormPrint forms as well.
The Type of COBOL Programmer Who Should Use COBOL FormPrint
COBOL programmers who fit the following criteria would benefit greatly from the use of FormPrint. This includes programmers who are interested in:
- Increasing their productivity
- Creating advanced Windows form printing without learning a new language
- Adding sophisticated document printing to their COBOL applications
- Reducing future maintenance efforts
- Migrating their COBOL printing to other operating systems
- Having the greatest amount of flexibility in a Windows printing productivity tool
The Benefits of Using COBOL FormPrint
- COBOL FormPrint supports quick and easy development of advanced printable forms without re-training.
- COBOL FormPrint supports the ability to run a program on many operating systems without change.
- COBOL FormPrint supports the ability to switch COBOL compilers without changing form-handling source or form definitions.
The Hazards of Using Visual BASIC, C++ or Java for Windows Printing
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.
The Acronym, BASIC stands for “Beginners All-purpose Symbolic InstruCtion Language.” Your programs must meet the demands of a mission critical application. It doesn’t make sense to use a “beginners” language for printing documents and forms in a professional application. In addition, Microsoft has a rich history or requiring programmers to re-write substantial portions of a Visual Basic application when upgrading from one version of Visual basic to the next. You should never be forced to re-write your business application simply because a programming tool vendor decides to make dramatic changes to their programming tools.
Java is very similar in nature to C++. It is event driven, far more cryptic than COBOL and interpretive.
Using C, C++ Java or Visual Basic with COBOL results in the same headaches as using API code with COBOL. For example:
- Using C, C++ Java or Visual Basic 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++ Java and Visual Basic compilers which support Windows printing use event driven methodologies, not procedurally driven methodologies.
- Using C, C++ Java or Visual Basic for your Windows printing will result in extensive and costly staff re-training.
Reusability of COBOL FormPrint Forms in Other COBOL applications
You can copy existing forms with COBOL FormPrint, so future COBOL programs can have documents and forms which are 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 forms.
Risks Associated with Purchasing a Printing Tools from Your COBOL Compiler Company
The primary reason you should purchase COBOL FormPrint instead of a printing 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 a rich history of completely re-writing their COBOL tools every few years without providing upward compatibility. Can you afford to completely re-write your COBOL printing routines next year, when your compiler company changes to a completely different printing 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 printing 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 Printing 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 tools business against source program obsolescence.
COBOL FormPrint offers the most portable, adaptable form printing available. Some compiler companies have introduced COBOL tools only to discontinue support for those tools later. That means their customers were forced to re-create a lot of work. We don’t do that to our customers. Any forms, documents or source programs developed with any version of our printing tools has always been upwardly compatible and adaptable:
- across operating systems,
- across different versions of the Windows Print Manager
- across COBOL compilers.
Because you can create and modify forms dynamically, FormPrint allows you full access to the form definition files, so you’re not even locked into FormPrint. COBOL FormPrint frees you from proprietary systems, instead of locking you in.
Flexus, An Uninterrupted History of Continuous Software Upgrades
Ever since our first COBOL 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 uneccesary to expend time and money in major source code re-writes.
NO OTHER COBOL tool vendor can make the same claim! Some COBOL tool vendors waited for many years to release new versions of their products. Others performed a complete re-write of their COBOL 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 programming tools?
- Since the initial release of your product, have you ever allowed a year or more to pass without a new release?
- What year did you first release your Windows printing solution?
- Did you provide an automated and seamless upward migration from your line printing version to your Windows printing version?
- Does your company provide Internet client/server tools for printing across a TCP/IP network which use the existing forms and source code unchanged? If so, what year did you release the product?
- Does your company provide Internet Web Browser tools which use the existing forms and source code unchanged? If so, what year did you release the product?
- Does your company offer sophisticated Windows Print Manager tools?
COBOL FormPrint has been continually enhanced to provide new features.
Future Upgrades and Enhancements to Existing Windows Printing Features
Flexus has always taken great pride in continually offering COBOL programmers real solutions for high level COBOL printing technology. Flexus has been a technological leader in providing new document and form printing features to COBOL programmers and supporting the latest environments. All Flexus products have constantly evolved to offer advanced 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 List Server
- 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.