In addition to allowing traditional z/OS® host
language components to be built, IBM® SCLM
Developer Toolkit extends the ability of SCLM to build Java and J2EE projects. An understanding of
SCLM build processing is required to adequately use these services.
Host languages still use the standard SCLM build translator services
whereas the Java/J2EE build translators are not part of standard SCLM
and are shipped within SCLM Developer Toolkit. These translators will
need to be included in each SCLM project definition building J2EE
applications.
Note: The SCLM administrator should refer to the SCLM Developer
Toolkit Installation and Customization Guide for customizing
SCLM for Java/J2EE applications.
Host members can be built directly or by using an ARCHDEF with
standard SCLM build translators. The SCLM Developer Toolkit provides
a view of SCLM that allows you to utilize SCLM services, including
build, against SCLM members. In this way, remote development of host-based
languages and applications can be supported from the same Eclipse
Workbench. The Explorer and Developer modes of the SCLM Developer
Toolkit allow this capability by providing a form of remote
portal to
SCLM using the Eclipse interface. Applications can be built in the
same manner and with the same services as those available within the
ISPF interface. In this way, host- based developers should have little
trouble using the SCLM services through this interface. SCLM build
services on existing host language components is covered in detail
in the
Software Configuration and Library Manager (SCLM) Guide
and Reference . Use the following for a description of the
various build settings available:
- Build mode settings
- You can specify the following build mode:
- Conditional
- Compiles and link-edits all changed modules, or modules affected
by a change to an included part. Processing stops on the first build
error.
- Forced
- Compiles and links all modules whether they need to be built or
not.
- Report
- Build determines what would take place if you were to request
a conditional or unconditional build without actually running the
build.
- Unconditional
- Similar to conditional, but the build continues processing all
modules despite errors.
- Information
- Returns information in XML format that describes the translators
such as compilers that will be used to build the selected part. This
information contains the translator names, the options specified,
and the data sets that are allocated for each translator. If you
use this mode with an architecture definition, the information is
returned for each member that will be built. Like report mode, this
mode does not actually run the build.
Note: For Java/J2EE build processing, the unconditional
mode might not behave predictably as with Host language components
due to the nature of Java/J2EE compilation and archive file generation.
It is recommended that you use conditional mode for Java/J2EE build
processing. Conditional mode still reports on all Java compile errors.
- Build scope
- You can specify the following build scope:
- Limited
- Compiles and link-edits all required modules directly referenced
by the specified architecture.
- Normal
- Compiles and link-edits all modules covered by LIMITED scope as
well as the Ada-type upward dependencies.
- Subunit
- Compiles and link-edits all modules covered by NORMAL scope as
well as the directly referenced Ada-type downward dependencies.
- Extended
- Compiles and link-edits all modules covered by NORMAL scope as
well as the Ada-type upward and downward dependencies.
Note: For Java/J2EE build processing, all scope selections
are treated as NORMAL.
- Additional settings
- You can also specify the following settings:
- Build at group
- Specifies the SCLM group to build at. (For example, if source
resided at a higher test group and you selected your lower development
group to build at the resultant load module/objects/listings and build
maps would be generated at your lower development group.)
- Error Listing only
- Allows you to specify whether you want all of the listing outputs
from the build processor or only those for translator steps completing
with an unacceptable return code. (These will be returned in the operations
log.)
- Produce report
- Indicates whether a build report is produced. This report is returned
in the operations log but is stored in the sequential data set referenced
by build report data set name if specified.
- Build message
- If set to yes, this returns build messages in the operations log
or in the Batch output if a batch job is requested. If a Build message
data set name is specified then the messages are also included in
this data set.
- Build listing data set name
- If specified, results in the build listings being included in
this data set.
- Build exit data set name
- If specified, results in any build exit messages being included
in this data set
- Batch build
- Select if you want to submit a JES batch job (Build in background)
on z/OS to process the build
request. The jobname and jobid are returned to the client. If Batch
monitoring has been selected under the SCLM preferences the Developer
Toolkit client will monitor the batch job and automatically notify
you when the job completes allowing you to retrieve the job output
back to the client. The default SCLM Build skeletons on the host are
employed to file tailor the Batch Build job. Additionally, a job card
can be entered by selecting the Job Card JCL... button
in the Build dialog. By selecting the Job Card JCL... you
can also edit the job card in the dialog box. To save the changes,
click Ok. Default Build job cards can also
be used. To recreate a default job card after it has been edited,
save an empty job card, re-edit it and click Retrieve.
This restores the default job card that existed when the dialog was
first displayed.
Default build jobcards can be specified in the
SITE.conf file or the project.conf file for your SCLM project. For
more information on the Site and Project configuration files, see
the section on SITE and project-specific options in the SCLM
Developer toolkit Installation and Customization guide.
For J2EE application build processing it is recommended
to use a minimum region parameter REGION=512M in the Build job card
to avoid out of memory errors.
Use SCLM builds to compile and link-edit a complete application
in a single job or as parts of an application.
Refer to the Building Java/J2EE applications topic for detailed
information on building Java/J2EE applications.