Conversion of Existing Programs

Introduction

In an effort to take full advantage of the workstation environment, the SAS/C C and C++ cross-platform compilers have been designed to be very similar to a UNIX C compiler. Because of this, some changes may be needed when you first move your application from a native compilation environment to a cross-development environment. These suggested changes do not alter your application's ability to be built in the native environment.

Source Code Changes

The SAS/C C and C++ cross-platform compilers support the same set of digraphs supported by the SAS/C Compiler on the mainframe. However, to aid in portability, it is advisable to replace these digraphs with characters that are readily available on the host workstation. The mf2unix and unix2mf utilities described later in this chapter can assist with this conversion.

Also, when moving source code from the mainframe to the workstation, any sequence numbers must be removed, since the SAS/C and C++ cross-platform compilers do no support sequence numbers.

Filename Changes

The SAS/C C and C++ cross-platform compilers do not translate filenames found in #include statements. These filenames are case-sensitive and no truncation occurs. Unlike the mainframe, no special consideration is given to case in include-file processing; therefore, source code that contains uppercase filenames in #include statements will probably require alteration.

Utility Programs

The cross-platform compiler provides the following utilities to help you port applications from the mainframe to the workstation:

TABLE 18. Utility Programs

----------------------------------------------------------------
| Utility   | Description                                      |
================================================================
| mf2unix   | translates source code from mainframe format     |
|           | to UNIX format.                                  |
----------------------------------------------------------------
| unix2mf   | translates source code from UNIX format to       |
|           | mainframe format.                                |
----------------------------------------------------------------
| etoa      | translates text from EBCDIC to ASCII.            |
----------------------------------------------------------------
| atoe      | translates text from ASCII to EBCDIC.            |
----------------------------------------------------------------
| objdump   | prints out a mainframe object file for viewing   |
|           | on the host workstation.                         |
----------------------------------------------------------------

Each of these utility programs is described in the following sections.

Note: If your object code is currently stored in a PDS on the mainframe, you may also find the updte2ar utility useful. For details, see Appendix C, "ar2updte and updte2ar Utilities" on page 103.

mf2unix and unix2mf

The mf2unix utility program translates source code from mainframe to UNIX format, and the unix2mf utility program is used to translate source code when porting in the opposite direction, that is, from UNIX to mainframe format. The syntax for invoking these utilities is as follows:

 mf2unix [option...]
 unix2mf [option...]
Both utilities take source code from standard input, perform the translation, and then print the output to the standard output. The translations performed by the two utilities are different:

mf2unix Options

The following option arguments can be specified to modify the translation performed by the mf2unix utility:

TABLE 19. mf2unix Options

----------------------------------------------------------------------------------
| Option              | Description                                              |
==================================================================================
| -lbl                | leave trailing blanks.                                   |
----------------------------------------------------------------------------------
| -offdi              | do not change digraphs to brackets.                      |
----------------------------------------------------------------------------------
| -recfm format-type  | specifies the record format of the input file.           |
|                     | format-type can be either a v to indicate                |
|                     | variable-length records, or f to indicate fixed-length   |
|                     | records.                                                 |
----------------------------------------------------------------------------------
| -noseq              | do not remove sequence numbers.                          |
----------------------------------------------------------------------------------

unix2mf Options

The following option arguments can be specified to modify the translation performed by the unix2mf utility:

TABLE 20. unix2mf Options

----------------------------------------------------------------------------
| Option   | Description                                                   |
============================================================================
| -l num   | defines the output line length, where num is the maximum      |
|          | number of characters in a line. The default line length is    |
|          | 72 characters.                                                |
----------------------------------------------------------------------------
| -t num   | specifies the number, num, of blank space characters used     |
|          | in place of the tab character. If num is not specified, the   |
|          | default is 8.                                                 |
----------------------------------------------------------------------------
| -offt    | do not replace tabs with blank space characters.              |
----------------------------------------------------------------------------
| -offdi   | do not replace brackets with digraphs.                        |
----------------------------------------------------------------------------

Examples

In the following example, the mf2unix utility is used to translate the source code contained in native.c from mainframe to UNIX format, redirecting the output to cross.c:

 mf2unix -lbl < native.c > cross.c
The -lbl option specifies that trailing blanks should not be removed. (Notice that the < and > redirection operators are used to redirect the input and output of mf2unix.)

In the next example, the unix2mf utility translates the source code contained in the file cross.c from UNIX format to mainframe format:

 unix2mf -t 10 < cross.c > native.c
Output is redirected to native.c and the -t 10 option specifies that tabs should be replaced with 10 blank space characters instead of the default of 8.

etoa and atoe

The etoa utility performs an EBCDIC-to-ASCII translation, and the atoe utility performs an ASCII-to-EBCDIC translation. Both utilities read from standard input, perform the translation, and then write to standard output. No assumptions about input file format are made, with regard to new-lines or any other record format. The utilities simply copy the bytes while performing the translation. Also, both utilities use the same translation tables used by the SAS/C C and C++ cross-platform compilers. (IBM code page 1047 standard).

Examples

The etoa and atoe utilities do not accept input or output filename arguments; therefore, the most effective way to use these utilities is to redirect the input and output files. For example, the following command redirects the input from native, performs an EBCDIC-to-ASCII translation, and then redirects the output to cross:

 etoa < native > cross

Another way to effectively control input is with a pipe. For example, the output from the operating system's cat command can be piped to the atoe utility as follows:

 cat native | atoe > cross
In this example, the input file, native, is copied to the standard output file, cross, with ASCII-to-EBCDIC translation performed by atoe.

objdump

The objdump utility prints out a mainframe object file (either MVS or CMS) for viewing on a host workstation. Output from the utility is directed to the standard output file and is printed in 80-column lines, with EBCDIC characters translated to ASCII. (objdump uses the same translation tables as used by etoa and atoe.) The resulting output is similar to what you would see if you were to browse the file using the ISPF editor under MVS.

The syntax used to invoke objdump is as follows:

 objdump [option...] object-file
The input file is specified by the object-file argument, and the option arguments can be either of the following:

TABLE 21. objdump option Arguments

------------------------------------------------------------
| Option  | Description                                    |
============================================================
| -h      | specifies HEX ON. Each line of the output is   |
|         | followed by two lines representing the         |
|         | hexadecimal values of the bytes; as if the     |
|         | HEX ON command had been given in the           |
|         | ISPF editor.                                   |
------------------------------------------------------------
| -n      | specifies numbered output. Each 80-column      |
|         | line of output is preceded by a line number.   |
------------------------------------------------------------

Example

Assuming that foo.o is the output of the cross-platform compiler, the following command directs a dump of that object file to stdout.

 objdump -h -n foo.o
In this case, both hexadecimal values and line numbers are displayed in the output.