| If You're Using... | |
This book is intended to help users of previous Micro Focus products to move to NetExpress 3.0, by guiding you through code and build changes that you might have to make in migrating applications.
It caters for people coming to NetExpress from:
Workbench is a superset of Object COBOL, containing the same compiler and basic tools, but a more sophisticated environment. V3.4 and V4.0 are functionally more-or-less equivalent, but V3.4 is 16-bit and V4.0 is 32-bit.
You should read the NetExpress Getting Started book before reading this or any other documentation provided with NetExpress.
The rest of this chapter briefly describes how the approach to creating an application in NetExpress differs from the approach in your previous system. The remaining chapters are reference chapters where you can look up particular features and find outline advice on migrating them.
Product differences that do not require you to make any changes are not in general mentioned in this book. For a list of enhancements in this version of NetExpress compared to earlier versions, and a list of changes needed when moving an application to this version from an earlier version, see the Readme Help.
If you've come from Object COBOL V4.0, you're probably used to Animator Version 2 for editing, compiling and debugging. NetExpress's Integrated Development Environment (IDE) is similar, though the menus are different as the IDE has more features. In particular, its facilities for setting breakpoints and interrogating data while debugging are more advanced.
However, central to the way you use NetExpress are projects. A project defines all the files in your application, how they are related and how they are linked, and so its biggest impact is when you are packaging your application. But it's useful at all stages, and we recommend that when creating an application you create its project as the first thing you do. You keep it loaded all the time you are working on the application.
This is useful in several ways. For example, it ensures the correct directory - where you create all the files for your application - is kept open; also, you can load source files quickly by double-clicking on their names in the project window. Creating the project first helps you design your application, and you can easily add or delete filenames if you decide to change anything.
Even for a tiny application, consisting of one small program intended only for your own use, it's worthwhile to create a project. If you don't, NetExpress creates a project automatically when you animate the program, since it's needed for animation.
In NetExpress, all the facilities you're used to - notably source-level debugging, or animation - can be used on an .exe file. The entire process of compiling and linking is done by one click of the mouse, and is known as building (unlike in Object COBOL, where building means building .int/.gnt files into a library). During building, you might see informational messages showing that the familiar utilities cobol and cbllink are being automatically called.
You may have been using the character-mode tools Animator and Editor in Object COBOL V4.0. These are not in NetExpress. Like Animator V2, the IDE provides most of what these two do, and more. In particular, the graphical interface gives multiple windows that you can easily rearrange and resize, much more powerful data monitoring, and close integration between editing and debugging so that correcting and recompiling code while debugging is the work of a moment.
If you've come from Workbench V4.0, you may be used to any of the methods referred to in the section From Object COBOL V4.0. You may also be used to projects. Projects in NetExpress are different from those in Workbench V4.0 - read about them in the online help for details.
Also, there is no equivalent of the Organizer or Advanced Organizer. All features are integrated into the IDE, and accessed from its menus.
If you've come from Object COBOL V3.4, everything said in the section From Object COBOL V4.0 applies, but in addition you're moving from a 16-bit system to a 32-bit one. Differences between 16-bit and 32-bit are covered in the chapter Migrating from 16-bit.
If you've come from Workbench V3.4, everything said in the section From Workbench V4.0 applies, but in addition you're moving from a 16-bit system to a 32-bit one. Differences between 16-bit and 32-bit are covered in the chapter Migrating from 16-bit.
Visual Object COBOL V1.0 was the precursor of NetExpress, and the basic design is similar. The IDE is very similar. Projects are very slightly different, in that the project window in NetExpress includes a second pane listing the source files.
The biggest change is in the method of creating forms for your application to display. In place of the resource editors and Resource Manager, you have Form Designer and Dialog System.
Form Designer is for creating applications for the World Wide Web or your intranet. It has a screen painter in which you design your forms, and it produces files defining the form in HTML and generates a COBOL source program to handle the I/O of the forms. You insert your business logic in this program.
Dialog System is for creating applications with a Windows-style GUI. It has a screen painter in which you design your windows and dialog boxes, and a language in which you write procedures (dialogs) to handle events on them. Your windows, dialog boxes, and dialogs are stored in a screenset, which you call from the COBOL program you write containing your business logic.
If you've come from the Embedded SQL Toolkit for Microsoft SQL or from Dialog System V2.5 (32-bit or 16-bit) see the appropriate chapter for details on migration.
Source code written for Object COBOL or Workbench should compile cleanly on NetExpress. However, .gnt and .obj code produced by these systems is not compatible with NetExpress - you need to recompile. .int code is compatible unless it contains object-oriented code.
If an application does character-mode input/output using ANSI ACCEPT/DISPLAY you must set the link type for its project to Character. Right-click the project's .exe file in the project window and, on the Build Settings dialog box that appears, click the Link tab. Then select Character and click Close. Without this, your application will run but you will get no output.
This does not apply to Micro Focus's full-screen Enhanced ACCEPT/DISPLAY.
The value returned by some COBOL operations is specified in the Language Reference as undefined; for example, dividing by zero, or using data that does not conform to a picture clause. If you were to examine the values actually returned by these operations, you would find that they differ according to the executable file format and the COBOL system on which the program was compiled.
For example, a divide-by-zero operation might return a different value in an intermediate code program to that returned in a generated code program. Similarly, the value returned in a program compiled on the 16-bit COBOL system might be different from the value returned in the same program compiled on a 32-bit COBOL system.
You should ensure that the results or logic of your program do not
depend on the results of operations specified as giving undefined results.
For example, as the result of a divide-by-zero operation is unpredictable,
you should always use the ON SIZE ERROR phrase if you want a
specific action or procedure to be performed depending on this result.
If you are converting a Windows GUI application into a Web application, you need to consider the structural differences between GUI and Web applications.
In a GUI application, events happen at the individual controls on a window or dialog box. These events are sent to the program, which stays loaded all the time. All processing is in one program (possibly with subprograms), which identifies and processes each event as it comes, and so program data survives from one event to the next.
In contrast, in a Web application an entire form is sent to the Web server when the user clicks the Submit button. The Web server software then starts the program. The program processes the data in the form, sends back a form in response, and then finishes. Typically you have a separate program for each type of form. Thus each time a form is received, a new program is invoked, and so program data does not survive from one invocation to the next.
You can reproduce the GUI application style in a Web application, by using ActiveX controls instead of ordinary HTML ones, and writing event handlers in JavaScript. These are executed at the Web browser, and handle events on the controls without going back to the main processing programs at the Web server. However, ActiveX and JavaScript are advanced facilities, and we don't recommend this route for converting your GUI application.
Instead we recommend that you restructure your application as described above. This means you will not simply replace each window or dialog box by an equivalent Web form. In general, your new design will have more and simpler Web forms than you had windows and dialog boxes.
Although program data does not survive between invocations, there are ways of passing data from one invocation to another. Three useful ways are hidden fields on your forms, files on disk, and cookies. NetExpress has some features to make it easier to do this - see the online book Internet Applications for details.
Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| If You're Using... | |