COBOL development environment

grey_rule.gif


Editor's note: COBOL can call routines using standard MVS linkage conventions, so a COBOL program could make use of many of the OS/390 UNIX callable services.

However, If you have a UNIX COBOL program that never existed on S/390 before and was written with Micro Focus COBOL for UNIX or an X/Open-compatible COBOL compiler, the program may use COBOL syntax that is not supported by the IBM COBOL compiler. For example, Micro Focus COBOL for UNIX and other X/Open-compatible UNIX COBOLs have language for screen handling, for line-sequential files, and for record locking that the IBM COBOL compiler does not support. Prior to compiling such a program with the IBM compiler, any usage of these language elements must be recoded to use supported language.

In this report, Dale Wilson, of the Solution Partnership Center in San Mateo, California, describes an ISV's recent success in establishing a COBOL development environment within the OS/390 shell. They'd like to hear of any improvements you'd suggest for the process. If you have any comments or questions, send them to ldwilson@us.ibm.com.

If you want to get the package, you can download it.

grey_rule.gif
We now have established a COBOL development environment within the OS/390 shell for UNIX-experienced COBOL developers. It is a mostly automated hybrid solution with a makefile and a few C language utilities for moving things between MVS and HFS, submitting jobs and viewing the output directly from the shell. Most of the work was done by a "partner" ISV here, Tim Adam of Open Software Associates from Australia, with modest MVS assistance from me. Here's what Tim has to say:

"You run the MVS COBOL compiler to create an object file which can then be linked into an OE executable. The compiler can do ALL its I/O on OE HFS files: source, object, listing. We have a separate program to incorporate any COPY code into the source files before compiling, because we have not worked out any way to include COPY code directly from HFS directories.

The source file from the HFS must contain 80 characters per line includ- ing any "eol" (end-of-line) characters, so we have written a fixcob.c program to do that before compiling. Since the OEDIT editor removes trailing spaces from the ends of lines you must rerun fixcob each time you edit the source.

We have a standard JCL template to generate the JCL file for running the MVS compiler. We first copy the JCL file to an MVS partitioned dataset and then submit the job from OE.

If the job completes successfully, the object file will have been created and we use the OE linker(binder) to create an OE executable.

Most of these steps are automated (see the Makefile). Unfortunately, you must first run make with a .o file target; then, when you are notified that the job has completed, you can make the executable. We have not been able to get make to wait for job completion. It continues as soon as the job has been submitted.

When you run the job under OE you can call a C utility to dynamically allocate the file to a DD name referred to in the COBOL file SELECT statement. We have sample programs to demonstrate this and also one to demonstrate receiving command line arguments from the shell. "

The Makefile

LD = c89
SUFFIXES: .c .cbl .cbf .o .exe
#  Default target
all:  cname.exe
# Pad all lines out to 80 chars
.cbl.cbf:
    fixcob < $? > $@
#  Submit compiler job; "make" can't tell when it's done
#  The JCL tells the compiler to read from $*.cbf, creating the object
#  file $*.o and the listing $*.cbf.lst
.cbf.o:
  sed -e 's/XXINPUTXX/$?/' -e 's/XXOUTPUTXX/$@/' <$*.jcl > $*.jcl.make
  tso -t "oget '$*.jcl.make' 'P390D.JCL.CNTL(MAKE)'"
  tso -o "submit 'P390D.JCL.CNTL(MAKE)'"
#  Use this rule to build ddalloc.o
.c.o:
  cc -D_ALL_SOURCE -c $?
#  Use OE linker to make OE executable from object files
.o.exe:
  $(LD) $(LDFLAGS) -e $* -o $@ $? ddalloc.o $(CLIBS)

fixcob.c

#include 
main()
{  char buf[81]; while(fgets(buf, 81, stdin) != NULL)
  { int i = strlen(buf); while(i-- > 0)
    {  if (!isspace(buf[i]))
       { i++; break;} }
   memset(&buf[i], ' ', 80-i); fwrite(buf, 1, 80, stdout);
} }

The JCL template

   //OECOBOLJOB(),CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=$SYSUID
//COMPILE  EXEC PROC=IGYWC,
//     PARM=(RENT,TRUNC(BIN),OFFSET,PGMN(LM),TEST(NONE,SYM))
//*  Listing goes here
//SYSPRINT  DD PATH='/u/p390d/XXINPUTXX.lst',
//          PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
//          PATHMODE=
(SIRWXU,SIRWXG,SIROTH)  //* COBOL source
file     //SYSIN DDPATH='/u/p390d/XXINPUTXX',PATHOPTS=(ORDONLY)
//*  Object file
//SYSLIN    DD PATH='/u/p390d/XXOUTPUTXX',
//       (copy the PATHOPTS and PATHMODE from SYSPRINT above)

That's it, except for the C function called from the COBOL program to dynamically allocate a DD statement for a file SELECT, the COBOL sample program, and a COBOL sample program to accept command line input parms, and the utility to include COPY files into the source before compiling. I don't have the latter just now.

As usual, the above are sample programs to be used "as-is", not warranted by IBM or Open Software Associates. Shucks, I might have made a typing error in there somewhere.

 

Contact IBM

Browse z/OS