>We are in the middle of implementing our first home-grown application
>written JAVA app. It is stored in ZFS datasets. Our current mainframe
>change control doesn't support unix file systems. We have a separate
>change control process for the open systems(unix and windows) from IBM
>and is a combination of ClearCase, Clear Quest, and Build Forge. I
>installed the Buildforge agent on the mainframe. It is the conduit to
>these processes. In our case, the java app is compiled off platform,
>and all the parts and pieces are then pushed to the mainframe.
Does Buildforge support "classic" mainframe entities, like COBOL, MVS
datasets, etc.? Our current mainframe change control product doesn't
support the "UNIX-y stuff" yet; that's being investigated for "a future release"
of it.
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
1) use the Unix-based source control system (CVS, SVN, etc) and check
in and "version" your application project.
2) use a simple "build driver" ant script that:
- checks out a given project and version to a temp directory
- runs the "build.xml" ant script in the project to build the
application pax file (containing the jars (or wars/ears), properties
files, etc)
The build driver script can be automated so that it is (remotely) run
as part of a mainframe deployment process.
A couple of things to consider:
- your testing should be done on binaries built with this same process
(and same build JDK)
- you need to explicitly choose and control the build system JDK
version that you are using. If you build with a different JDK
version or patch level, then in theory you have a different binary
release and need to fully test it all over again.
This particular client takes things a little further and actually
checks in the application pax file as a binary dataset into their
mainframe control system, which then manages "deploying/promoting" it
through the different mainframe environments, even though the "build"
is done on a distributed platform.
Kirk Wolf
Dovetailed Technologies
In short - we were able to build the Java apps on a build server and
deploy it (the jar files) to the mainframe via a secure file transfer.
Java gives the flexibility that you do not have to compile it on the
mainframe. We simply copied the CICS jar file to the Linux build server
and were able to compile the applications. I am sure this approach will
also work for batch.
Thanks
Corneel Booysen.