 ntroduction
WorkFrame provides the integrated development environment for VisualAge for
COBOL (VA COBOL). It uses a project metaphor to organize the files and tools you
need to build your application. The WorkFrame project is in essence an enhanced
Windows folder with object-oriented attributes and behavior. It is also the
point at which you integrate your favorite development tools, making these
accessible in addition to the ones provided with VA COBOL . Thus, WorkFrame is
extensible. In this issue, I will show you the steps I used to extend WorkFrame.
I assume you have used WorkFrame and have a conceptual understanding of the
WorkFrame environment. If not, please refer to the VA COBOL
Tools Guide for Windows. But first, some essential WorkFrame information
to facilitate understanding of those steps.
Project and Files and this thing called Build
The files that make up a WorkFrame project have actions associated
with them. Part is one term used to refer to these files. There are
different types of part, categorized by their file extension. For example, a
file with the extension cbl is defined to be a COBOL source file. There
are actions that are appropriate for COBOL source files. You can edit
or compile a COBOL source file but you cannot run
nor debug this. Another example will be a file with the
extension exe which is defined to be an executable. You can thus run
or
debug this file but you cannot compile nor link
this.
By default, a WorkFrame project is set up to build one target
part. This target part is usually an executable like an exe or dll
file, which is created from the other parts that make up the project. There
are two actions available on a project to create this target part. One is Build
normal and the other is Rebuild all. Those familiar with the make
(nmake in the VisualAge family) facility should readily grasp the
meaning of these actions.
Build normal examines the dependencies for the target part to determine
which ones require updating and updates only those parts. Rebuild all updates
everything regardless of its status. For example, you have multiple COBOL source
files that are needed to create an exe file. Since the last time you
built the executable, you modified one of the source files. Invoking the Build
normal action on the project will result in only the compile of the modified
COBOL source file to generate the
.obj file and the link of all the .obj files to generate the executable.
Performing the Rebuild all action will result in the compile of all the
COBOL source files and the link of the resultant .obj files.
From the foregoing discussion, you can observe two types of actions. One is
file-scoped and the other is project-scoped. Any customization
we make to WorkFrame will be in either of those two contexts.
One additional note about the build process. As I mentioned earlier,
WorkFrame by default is set up to build one target part. This probably suffices
for most projects where it is feasible to organize parts in nested projects. If
you want to organize all your parts in one project but need to generate multiple
target parts then you have to control the build process by hand crafting your
own makefile (with an extension of mak). You can then invoke either the
Make or the Make all action on that file.
Name that .IWx File
Whenever you create a project, there may be up to four files associated with
that project. One is the project type specification file, with the extension
iws. Think of this as the project template where you specify the file
types, file-scoped actions, and project-scoped actions. All projects are
associated with an iws file. The iws file is coupled with an
options file with the extension iwo. This file contains the default
options for some of the tools available to the project, like the compiler and
the linker. These two files are default specifications. A third file, with the
extension iwp and your project name as the file name, contains
information specific to your project. For example, it has an entry indicating
which project type is being used and an entry marking where the source
directories are (see figure eoo.IWP). The fourth file, with the extension iwo
and your project name as the file name, will be created when you modify options
for the tools.
VA COBOL ships with four different project types and their corresponding
options file. These are usually located in the \IBMCOBW\MAINPRJ directory and
are as follows:
1. VACOBOL.IWS and VACOBOL.IWO - COBOL Non-GUI project
2. VACOBVB.IWS and VACOBVB.IWS - COBOL Visual Builder project
3. MVSCOBM.IWS and MVSCOBM.IWO - MVS project with name mapping
4. MVSCOBL.IWS and MVSCOBL.IWO - MVS project without name mapping
We will use VACOBOL.IWS to illustrate the customization process. Before
modifying the supplied VACOBOL.IWS, I advise the standard cautionary step of
creating a backup copy.
Anatomy and Customization of an IWS File
An iws file is divided into the following sections: type
definitions, project scoped actions, file scoped actions, items in the options
menu, items in the tool bar, and standard set of filters.
The type definitions section is where you define the type of files
your project will handle. For example, the input to the COBOL compiler is
defined as having the file extension cbl. This is defined in the
VACOBOL.IWS file as follows:
-Types::CompilerIn
+mask=*.cbl
This is a paired definition specifying the name of the file type and the
file masks applicable to this file type. -Types::
is a keyword followed by a user defined name, in this case CompilerIn.
Any file with a file extension of cbl is a CompilerIn file. CompilerIn
can be referenced when we define our file scoped actions. It is referenced as
the input for the C++ Compiler file scoped action. (WorkFrame initially
came out with VisualAge for C++. For technical reasons, the compiler file scoped
action had to be defined as C++ Compiler even though it will invoke the COBOL
compiler for VA COBOL). Currently, file masking is only enabled for the file
extension. Thus, you cannot specify a mask of a*.cbl.
For our exercise, let us add an additional type called TextFile that
represents files with the extensiontxt. To do this, we add the
following paired definition:
-Types::TextFile
+mask=*.txt
The next section is where you define the project scoped actions. This is
done with a set of statements beginning with the following statement:
-ProjectTools::tool name
The -ProjectTools:: keyword delimits the beginning of a new
definition and the termination of the prior definition (if any). The following
is the supplied definition for Build Normal:
-ProjectTools::Build normal
+title=Build normal
+program=iwzwbld1.exe
+runmode=Mon
+accelerator=B
+helpCmd=iview cppug %TOPIC%
+topic=Building Your Target
+optionsDll=IWZWDLL1
+entryPoint=BUILD
If say you have VisualAge TeamConnection installed and would like to launch
the TeamConnection client from your project, you can add the following:
* My definition for the TeamConnection client
-ProjectTools::TeamConnection
+title=TeamConnection
+program=teamcgui.exe
+accelerator=T
and the TeamConnection action will show up as one of the project
selectable items from the Project pull-down menu. We used a subset of the
statements specified for the Build Normal action. For end user customization,
this is sufficient. Most of the statements used are self-explanatory. Comments
in an iws file starts with the * character. The +accelerator
keyword defines the Ctrl+Shift+key key combinations that will launch
the defined action. In this example, pressing the Ctrl+Shift+T combination will
launch the TeamConnection client.
The third section is where you define additional file scoped actions.
Similar to the project scoped action, the definition is limited by the -FileTools::
followed by a set of specification statements as in the definition of the
LPEX editor:
-FileTools::LPEX editor
+title=Edit
+program=evfwlx21.exe
+accelerator=E
+helpCmd=iview lpexhdi %TOPIC%
+topic=Use the Editor
+input=Editable
+parm=%a %z /p %p /cm mult ;set browse off ;set readonly off
+setenv=no
The input to the LPEX editor is something called Editable. This is
defined in VACOBOL.IWS as something that is not a binary file, which will
include the TextFile that we defined earlier. Thus, by default we have a
file scoped action defined for TextFile. However, if you feel more at home using
the NotePad editor to edit ASCII text files, you can add the following
definition:
* My definitions for the NotePad editor
-FileTools::NotePad editor
+title=NotePad edit
+program=notepad.exe
+input=TextFile
+parm=%a %z
Again, most of the statements should be self-explanatory. The +parm
keyword specifies the parameters to the NotePad editor which for most file scope
action definitions will include the location of the file. The following is a
list of valid substitution variables that can be specified for the
+parm keyword:
- %a %z - Is replaced by the names of all the selected files,
separated by a space. If the space between the 'a' and the '%' is replaced by a
string, the names are separated by that string. For example, if the selected
files are d:\eye.obj, d:\on.obj and d:\object.obj the substitution
variable %a+%z produces the string d:\eye.obj+d:\on.obj+d:\object.obj. The only
substitution variables allowed within the %a %z substitution variables are %%
and %d.
- %d - Is replaced with the project's working directory.
- %e- Is replaced by the extension (including the period) of the
first selected file.
- %f- Is replaced with the fully qualified name of the first selected
file. Specifying %f is the same as specifying %q%n%e.
- %n - Is replaced by the file name (without an extension and path)of
the first selected file.
- %o - Is replaced by the target file name specified for the project
in its Settings notebook.
- %p - Is replaced by the fully
qualified project file name.
- %q - Is replaced by the path
of the first selected file.
- %t - Is replaced by the fully
qualified file name (without an extension) of the project's target.
- %% - Is replaced by the % symbol.
The last section I want to discuss is the definition of the standard set of
filters. The following is supplied:
*
* Standard set of filters
*
-StdFilters
+filter1=*
+filter2=*.cbl
+filter3=*.cpy
+filter4=*.cpy;*.cbl
+filter5=*.obj
+filter6=*.exe;*.dll;*.lib;*.exp
+filter7=makefile;*.mak
+filter8=*.def
+filter9=*.ico;*.bmp
+filter10=*.iwp
+filter11=*.adt
+filter12=*.lst
These are predefined file filters or masks that limits the files shown in
your WorkFrame project. By default, all the files in your source directory are
shown because
filter1 is defined first and thus the default. If I wanted a filter for
files with an extension of txt or either readme
then I can add the following filter to the list:
+filter13=*.txt;*.readme
I hope I have provided you with sufficient insights on WorkFrame to enable
you to integrate some of your favorite tools into a project.
| 
