IBM Corp 1993
370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370
370 370 370
370 370 370
370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370
C/370(TM) Compiler News
March 1994 Volume 2 Number 1
Welcome to the March, 1994 Issue of the C/370 Newsletter
This issue represents the first issue for 1994 and we'd like to take this opportunity to tell you about the latest release of the C/370 Compiler. We have made some substantial improvements that people, like yourselves, have been asking us for. And while we're letting you know about these features, we thought it would be a good time to update you on some C/370 complementary products.
IBM SAA AD/Cycle C/370 Compiler Version 1 Release 2 provides features designed to satisfy customer requirements for usability and productivity. Some of the new features include:
Cohesive edit, compile and debug facilities are provided under LE/370 by the optional product CODE/370 (see following article). These debug facilities are similar to those provided by the IBM INSPECT for C/370 and PL/I (5658-995).
Here is a summary of supported compile-time and execution time environments for various compiler/library release combinations:
Library Product
+==================================+
| C/370 | C/370 || LE/370 | LE/370 |
| V2 R1 | V2 R2 || R2 | R3 |
|=======|=======||========|========|
At Compile Time: | | || | |
C/370 Compiler V2 R1 | Y | Y || N | N |
AD/Cycle C/370 Compiler R1 | N | N || Y | Y |
AD/Cycle C/370 Compiler R2 | N | Y || N | Y |
| | || | |
At Execution Time, applications | | || | |
compiled using : | | || | |
C/370 Compiler V2 R1 | Y | Y || Y(1) | Y(1) |
AD/Cycle C/370 Compiler R1 | N | N || Y | Y |
AD/Cycle C/370 Compiler R2 | | || | |
- with TARGET(COMPAT) | N | Y || N | Y(1) |
- with TARGET(LE) | N | N || N | Y |
+==================================+
(1) Applications compiled for execution on the C/370 Library Version 2
are subject to compatibility considerations when migrated to LE/370,
as documented in the AD/Cycle C/370 Migration Guide.
AD/Cycle C/370 Compiler in conjunction with LE/370 Release 3 supports:
Programming interfaces defined by the Institute of Electrical and Electronics Engineers (IEEE) Portable Operating System Interface (POSIX) standards are supported with OpenEdition MVS
Compiler support is provided for the use of the Hierarchical File System in addition to MVS datasets, for storage of compiler source and output. The compiler has been enhanced to support the POSIX search rules for include (header) files in the HFS.
AD/Cycle C/370 Version 1 Release 2 continues to support application development for the standard MVS environment. In conjunction with the LE/370 Version 1 Release 3 library, 'mixed' applications can be created which use facilities available under both traditional MVS and MVS/ESA OpenEdition environments.
The MVS/ESA OpenEdition Shell and Utilities Feature and dbx Debugging Feature provide a UNIX (TM) -like development environment on MVS:
Creates executable files from C/370 source code, using the AD/Cycle C/370 Compiler Version 1 Release 2. It invokes the compiler, the C/370 Prelinker and link-edits the program. It passes parameters specific to the OpenEdition environment for each of these phases.
Helps developers manage inter-dependent files and can be used to selectively invoke the c89 process for re-compilation of updated source files.
Enables programmers to create and manage collections of objects suitable for use by the linkage editor or binder, similar to the C/370 Object Library Utility (C370LIB).
Provides debugging capabilities for use with AD/Cycle C/370 compiled programs, under the OpenEdition MVS environment. The AD/Cycle CODE/370 Debug Tool remains the supported debugger for MVS applications not running under MVS/ESA OpenEdition.
New C/370 applications can be written and used in a POSIX conforming environment or ported from other platforms that conform to the supported standards. In addition, OpenEdition extensions and C/370 support for the standard MVS environment allow applications to be created that are uniquely suited to the MVS environment.
AD/Cycle C/370 Version 1 Release 2 provides facilities for recognizing various international EBCDIC coded character sets (codepages) used on different IBM systems worldwide. Together with either LE/370 Version 1 Release 3 or C/370 Library Version 2 Release 2, applications can be created, compiled and executed using national character sets.
A source-file tagging mechanism and an option to convert the coded character set for the compiler output is provided. This enables the compiler to recognize C syntax characters (such as square brackets) on different systems, regardless of which Latin-1 (US, Canada, Western Europe) encoding scheme is used. Listings and object can be generated for specific target coded character sets. In cases where the full C syntax character set is not available, editor macros and other considerations for source entry and display will still be required.
C/370 programmers can now create source files using characters that appear correct in their programming environment, without the use of trigraphs, alternate characters or by keyboard remappings to the APL IBM-293 character set. This makes the writing, reading and understanding of C/370 applications more natural and less error prone and makes C source more portable.
Optional character conversion for compiler output allows compiler listings and object to be generated for environments with specific coded character sets. However, as a rule, hardcoded dependencies on coded character sets should be removed for truly internationalized applications.
This support does not address the situation where keyboards do not provide the full C syntax character set for data entry. For example, on some 327x device keyboards there is no key that allows a square bracket to be entered; special editor macros, communications or device translation tables are needed to enter and display the characters. Under host terminal emulators, such as OS/2(R) Communications Manager, keyboard mappings may require modification to generate the correct characters for use with the new filetag mechanism.
Applications that will be developed and used worldwide need to be made sensitive to the differences in country, language and culture, such as sorting sequences in data or the formatting preferences for date, time and monetary units. Additionally, application development and execution often need to take into account the differences in data encoding schemes used in systems worldwide.
The locale definition utility enables the international characteristics of an application to be easily modified for different end users worldwide. This support reduces the cost and complexity of modifying an application to reflect end-user requirements affected by language, country, culture or data-encoding, allowing a business to provide application solutions more efficiently to international markets.
The locale definition utility enhances the support previously provided through assembler macros, and is consistent with the support provided under AIX/6000 and similar to the POSIX standard definition (Part 2, POSIX 1003.2 draft 12, with known exceptions as documented in the C/370 Programming Guide).
Specific improvements in the information available in the locales built with this utility, include:
Locales are now created to take account of different encoding schemes, to reflect the differences in coded character sets across IBM systems worldwide. Character mapping (charmap) files are provided as input to the locale definition utility. This enables the C library functions under C/370 Library Version 2 Release 2 and LE/370 Version 1 Release 3, to provide the correct results in character classification and collating functions, based on the coded character set of the locale chosen at execution time.
The National Language (NL) Resources component which is included with the library products, which contains:
C/370 functions for I/O have been enhanced in LE/370 R3 and C/370 V2 Library Release 2 as follows:
Migration of existing applications may require source changes where undocumented behavior was previously exploited by customer applications. I/O library function enhancements include:
AD/Cycle C/370 Compiler Version 1 Release 2 introduces a new native C data type fixed-point decimal (packed decimal), as an extension to ANSI C for use in business-oriented applications. This support is consistent with the packed decimal data type introduced in the ILE C/400 product and can be mapped to the COBOL data type, COMP-3, the PL/I data type, FIXED DEC and the Assembler data type, P.
Code compiled by the AD/Cycle C/370 Compiler with either the C library of the C/370 Library Version 2 Release 2 or LE/370 Version 1 Release 3 products, exploit the underlying packed decimal format machine instructions on the System/370 and System/390. The C/370 fixed-point decimal data type allows expressions with up to 31-digits of precision.
Support is provided for the compilation of code under either VM or MVS for link-edit and execution under the other operating system. Some restrictions apply for environment-specific considerations.
Support for cross-compiling from MVS or VM to the other operating system enables application developers to use the environment of choice for application development, library management and compilation.
The AD/C C/370 publications have been reorganized to improve usability. The AD/Cycle C/370 Programming Guide and the SAA CPI C Reference have been replaced with the following manuals:
Softcopy of a subset of the examples and samples in the publications are shipped with the product on the product tapes. This will enable programmers to easily incorporate these samples in their programs.
The AD/Cycle C/370 Compiler Version 1 Release 2 with both the AD/Cycle LE/370 Version 1 Release 3 and C/370 Library Version 2 Release 2 was designed to conform to the following standards:
MVS/ESA OpenEdition Support, in conjunction with LE/370 Release 3, is based on:
If you do not have electronic access to IBM announcements, contact your IBM representative. Otherwise, you can use the Reader's Comment Form at the back of this newsletter and we'll send you more information. ( )
AN INTEGRATED SET OF DEVELOPMENT TOOLS
IBM CoOperative Development Environment/370 (CODE/370) (Program No. 5688-194) is an integrated edit/compile/debug environment for application developers. The COBOL and C programmers in your shop can use CODE/370 to develop and maintain applications. CODE/370, together with the following products, forms a comprehensive set of tools for application development, test and maintenance:
LANGUAGE ENVIRONMENT/370 (5688-198)
COBOL/370 (5688-197)
C/370 (5688-216)
CODE/370 combines the richness of the S/370 subsystem environments and the power of Language Environment/370 to provide a host Debug Tool which allows programmers to find bugs, fix bugs and test their applications. The Debug Tool is available either as a standalone 3270 host debugger (for programming shops where workstations are not available) or with an optional graphical workstation user interface.
The workstation interface combines the Edit and Compile / Link functions together with the Debug Tool graphical user interface (GUI).
This method of workstation / host integration of tools combines the use of S/370 subsystem environments for "live" debug, with the power of the workstation GUI for edit. It also provides programming shops with the option of growing into the workstation application development of host programs at their own pace.
Workstation Edit / Compile
The CODE/370 editor off-loads the edit step of development off the host and utilizes the power of the OS/2 (TM) workstation for early detection of problems in application code. Workstation functions include:
Debug Tool
CODE/370 debugs the application program as it is executing on the S/370 in the native host environment (CICS (TM) , IMS (TM) , DB2). This ensures that your application is tested in the true host environment before the application is put into production.
Debug Tool functions include:
The debug session is also recorded in a log file, permitting edit and replay of a Debug Tool session. This allows the Debug Tool to be used to capture test cases (for future program validation) or to further isolate a problem within an application. This also allows both interactive and batch debugging of a programmers application.
C Set ++ for OS/2 Version 2.1 builds on the Best Selling Version 2.0 by adding tools to dramatically improve the productivity of programmers. These new tools include KASE:Set a graphic user interface builder provided by KASEWORKS, a new version of Workframe/2, the IBM open integrating development environment now designed to exploit the power of the OS/2 object-oriented Workplace Shell user interface and additions to the IBM User Class Library to support the drag/drop function.
"C Set ++ Version 2.1 represents the industry's most advanced integration environment for the design, creation, testing, and fine tuning of mission-critical applications." said Vivien Fong, Manager, IBM Language Technology Center. "The products intuitive, interactive interface and aggressive optimization schemes ensure that applications built with C Set ++ will be quick to build, quick to run and quick to modify."
The new release builds on the 2.0 version of C Set ++, with enhancements in in four major areas:
The IBM C/C++ compiler has been specifically tailored to exploit the speed and power of Intel 386, 486 and Pentium based computers, maximizing the performance of applications using OS/2. By providing you with extensive runtime library support, C Set++ not only allows you to exploit the functionality of the extensive 32-bit runtime libraries created by IBM, but allows you to call 16-bit code as well. By using this feature, your existing set of high-quality runtime libraries developed during previous projects can be reused. By conforming to industry standards, your development team can be assured that your current development environment will be protected as the language evolves evolves over time. Furthermore, by enforcing language standards, your team can be assured that code developed with today's C Set ++ will work with tomorrow's releases and on other platforms.
C Set ++ includes a class browser to assist you in creating C ++ objects. The browser is a C++ post compilation static analysis tool that allows you to search compiled code for program components (eg. files classes, functions, and variables) and view them within the context of other related components (e.g. the inheritance hierarchy, etc.) In addition, should you discover that something is amiss in the compiled code, you can edit the original source code through the browser. The C Set ++ class browser features an easy-to-use graphical interface. using individual windows, the browser allows you to simultaneously view any combination of list, graph, and text windows.
C Set ++ provides a complete starter set of class libraries to allow you to get up and running quickly. Class libraries assist you to build objects which are reusable usable across many projects. This enables you to leverage a single development investment by allowing a single piece of code to be reused across many applications. C Set ++ provides the most comprehensive set of class libraries available, including:
The service and support offered with C Set ++ is unparalleled in the industry. You can contact the IBM C Set ++ development team directly through the normal defect support channels, or through the major bulletin board systems such as Compuserve, INTERNET and TalkLink.
To order a copy of IBM C Set ++ V2.1, call 1-800-342-6672 in the US. For Fax Orders call 1-800-445-2426 in the US.
The newest release of C Set ++, the C and C++ language product for AIX, is now available. Release 2.1 includes an array of new features and improvements over its predecessor product, XL C++ Compiler/6000 version 1.1.1. The highlights and additions to version 2.1 include a new C compiler, a new memory usage debugging tool called HeapView Debugger, new class libraries, and new optimization routines which include a new optimization level and inter-procedural analysis.
Both C and C++ compilers in C Set ++ for AIX supports the following new features:
The C compiler conforms to the following standards:
It is fully integrated into a set of tools included in C Set++ for AIX v2.1 package. This means C users can now use the Browser to statically analyze their applications, the HeapView Debugger to tune memory usage, and the Test Coverage Analyzer to analyze test coverage of their applications.
The C++ compiler is based on the September 1992 draft of the ANSI C++ Standard Document (i.e., X3J16/92-00091). It supports all features described in the document, including Templates and Exception Handling. Besides improved performance, this release of the C++ compiler has improved on the way it interacts with the Browser, resulting in lower memory requirement and improved load time for program data.
This release includes a new tool called the HeapView Debugger which allows C and C++ programmers to interactively understand memory usage of their programs. This tool provides many views of a program's heap usage behavior in varying amounts of detail. The complex views can be filtered in many ways, allowing users to get the information easily and to quickly find memory leaks. HeapView also offers a number of ways to manipulate the heap during program execution to help find programming errors, such as when attempting to read through a a dangling pointer.
C Set ++ for AIX v2.1 comes with two new IBM class libraries: Collection Classes and Application Support Classes. The Collection Class library consists of an extensive set of commonly used data structures implemented as C++ template classes. Example classes include flat structures such as "bag", "deque" and "stack" along with tree-based structures. Classes are derived from the flat classes that implement sorted versions of their bases. An extensive set of methods are available for each class, allowing one to insert, delete, and find elements, and to find the properties of the object itself. The Application Support Class library consists of "string", "date" and "time" classes.
The Browser now supports browsing of both C and C++ code, making it possible to statically analyze C code compiled using C Set++ for AIX v2.1. The interface of the 2.1 Browser and the compiler has been enhanced, resulting in much faster query resolution and reducing load time by up to about 30 percent compared to Browser 1.1.1. Finally, the Test Coverage Analyzer now also works with both C and C++ code. Users can now perform test coverage analysis on both C and C++ applications.
With its wide range of new features and improved functions, C Set++ for AIX v2.1 is a new generation product worth a second look. For more information call 1-800-346-4699 in North America or contact your IBM representative.
This beginning C course on the main frame teaches the fundamentals of programming in C with lively lectures, informative in class reviews and challenging hands-on lab exercises. It instructs the experienced programmer how to develop and maintain ANSI C language programs in a main frame environment. All of the basic features of the language will be explored, including C data types, arrays and structures; operators and expressions; flow control constructs; I/O facilities; functions; storage classes; and preprocessor facilities. Extensive lab exercises on an MVS system using C/370 will reinforce the learned concepts.
This five day course is scheduled to be taught on May 16, 1994 at the IBM Skill Dynamics education facility in Atlanta. Additional offerings may taught upon request. To enroll, please call 1-800-IBM-TEACh (1-800-426-8322) in the US.
These questions are culled from a variety of sources: from various question and answer databases, from customer calls, and from our own experiences.
If you have a question you like to ask us, have a comment about C/370, or just want to subscribe to this newsletter, please use the Reader's Comment Form at the back of this newsletter.
Question- Time Granularity
Is there a C/370 function available that will allow you to get the granularity of time less than a SEC(i.e. mili or micro seconds)?
Answer
To get a resolution of less than one second, use the library function CLOCK. The function has a resolution of 1/10,000 of a second. It is described in the SAA CPI C REFFERENCE SC09-1308-02 on page 196.
There are several time functions available. The time() returns the current calendar time which would be the wall-clock time. The other clock functions modify this time in some manner such as gmtime() which corrects for universal time. The clock() function must have its return value divided by the CLOCK_PER_SEC macro to be converted into seconds. For the resolution that you are asking for, only the clock() function will meet your needs. To get the current wall-clock time, you will need to use the clock() func as an elapsed time counter added to a base time from the time() function . This will give a wall-clock with sub-second resolution. The absolute error in the displayed time will be the time needed to process and update the time value.
Question- Buffer Space
We have a program that, uses a lot of memory (approx 31M), then frees that memory. The program then opens for reading many (over 40) disk files, keeping them open and reading the next record from a 'randomly' chosen file. However the program fails when a fread of one of the files indicates an error and sets the errno to 7 implying than an I/O buffer could not be allocated. Do you know why this happened? Increasing the REGION size on our JCL cleared the problem, but does 40-50 opened files really need more than 31M of buffers? Can you give us some sort of guidelines as to how much buffer space is needed per opened file?
Answer
The first thing to look for is the ISA size. If you do not specify ISA size as a run time option, C/370 will allocate the maximum available storage and then return half of it to the system. If your ISA requirements are smaller than the half of your regions size, you can better utilize storage if you specify the required ISA through a run time option. Storage requirements for every open file can be roughly calculated as the sum of lrecl and blksize, so it is unlikely that your storage problems are due to file buffering. If some of those files are memory files, then this may be the reason for such memory requirements. If all else fails try to verify if the memory really got freed. This can be done by taking a slip dump after the memory was freed, and looking at subpools 0 and 4 for the amount of memory reported as free.
Question- #pragma inline
In a header file, I have
#pragma inline(CMcalloc)
static void *CMcalloc(size_t nelem,size_t size)
{
stuff;
}
However, C/370 V2R1 doesn't generate the code inline. The many places it is called in a particular module all have BALRs.
What are some possible reasons for this?
Answer
In conjunction with the 'pragma inline' you must also use the option 'inline(noauto,,,)' on either the command line or with the 'pragma options(...)'.
Question- isdst is -1
When I call localtime() on a date/time stamp, the tm_isdst value is returned as -1.
How do I fix this problem?
Answer
localtime() returns -1 for tm_isdst when the DSTNAME value in the LC_TOD locale category has not been set. This is the default in the locale provided by IBM (EDC$S370), so this is why in your case the value for tm_isdst is -1. To correct this, you have two options:
Question- ANSI Carriage control
Does C/370 support ANSI carriage control on MVS to a 3287 printer? We are having difficulty getting printout to format correctly on a 3287 device. A sample program looks like:
PRINTF("\fTHIS LINE STARTS WITH FORM FEED");
PRINTF("\fTHIS LINE STARTS WITH FORM FEED ALSO");
PRINTF("\nTHIS IS NEW LINE");
PRINTF("\n\nTHIS LINE STARTS WITH 2 NEW LINES");
PRINTF("\rTHIS LINE STARTS WITH A CARRIAGE RETURN");
PRINTF("\r\rTHIS LINE STARTS WITH 2 CARRIAGE RETURNS");
PRINTF("\r\nSTARTS WITH ANSI STANDARD CR/LF");
The result comes out:
THIS LINE STARTS WITH A FORM FEED THIS LINE STARTS WITH A FORM FEED
THIS IS NEW-LINE
THIS LINE STARTS WITH 2 NEW-LINES
THIS LINE STARTS WITH A CARRIAGE RETURN
THIS LINE STARTS WITH 2 CARRIAGE RETURNS
STARTS WITH ANSI STANDARD CR/LF
It appears form feed is not getting recognized and that carriage return and new line perform the same function. I thought new line starts print on next line in current column and carriage return starts in column 1 of current line, and that to get to column one of next line, both carriage return and new line were required. Can you explain how this works in C? Thanks a lot.
Answer
C/370 supports ASA print control characters. The library function uses stdout as the output device for your C/370 program. stdout is associated with the SYSPRINT ddname. In order to recognize the ASA print control characters try specifying the C/370 recfm extension A (e.g FBA) for the sysprint dd statement. The first column of each record in an ASA file will contain a control character (' ','0','-','1',or '+') for the escape sequence ('\n','\n\n','\n\n\n','\f','\r').
The escape sequence
'\n' translates to skip one line
'\f' translates to skip to new page
'\r' translates to overprint character
Question- Comment Delineator
Is it possible to change the delineator for comments to //? If so, is the procedure for doing so documented?
Answer
It is possible to use // as the beginning of a comment which will terminate at the end of the line. This is activated with the SSCOM compiler option. For more detail refer to C/370 Programming Guide SC09-1384 p.41.
Question- EDCSPC
EDCSPC
In C/370 V2.1 there is a txtlib called EDCSPC. We can find no reference to this in the manuals. What is the purpose of this txtlib and can/should we put it to use? Is it documented anywhere? Thanks.
Answer
Txtlib EDCSPC is used when linking applications written using Systems Programming Facilities (SPC). Please refer to Chapter 46 on page 465 of the C/370 Programming Guide (SC09-1384) for information about SPC.
Question- C/370 Version 2 in the TPF environment
Three questions regarding C/370 Version 2 in the TPF environment:
Answer
No changes were made to support the new version of the compiler.
Answers to specific questions:
Question- Binary I/O
I am using freopen() command to change the mode of a file from "wb" to "rb+". (the file is a PDS). I do this because of the restriction on I/O to a PDS on page 10 of the C Programming Guide V2 Release 1 that states that you must open the file "w" then close and reopen it "r+" to get the equivalent of "w+" mode.
Does this also apply to binary I/O? I think freopen would be an easy way to accomplish this.
Answer
Yes, this same PDS restriction applies to binary I/O. If you wish to perform the equivalent of the "wb+", you must first open the file as "wb", write to it, and then close it. Then you can perform updates by reopening the file in "rb+" mode. freopen is an easy way to accomplish these last two steps of closing a file and reopening it to a new open mode.
Question- Does IBM C/370 have a LINT-like capability?
Does IBM C/370 have a LINT-like capability?
Can anyone tell me if there is any LINT-like utility built within C/370 or as a separate tool?
Answer
Check out the CHECKOUT option.
Question- DFSORT
We have an C/370 application that executes in the C/370 environment of MVS. It is intended to replace an assembler application. The new program has presented us with a big performance degradation. Both products produce files in the format: RECFM=VB, LRECL=3121, BLKSIZE=6144 These files have up to several million records in them. These records need to be sorted using a key that is 443 bytes. The C program uses qsort() to do the sorting. But first it must read in a record, and build a key. It does this for a user specified number of records at a time. Then qsort is invoked to sort the keys and the records are written out to a temporary file. This is done until EOF on the input file. The temporary files are then merged by some C code. The old program used DFSORT, with keybuilding and key stripping routines being passed to it. The problem is that on the same file (with 1.8M records) the new C code takes 6 times longer to execute. Is there any C language access to call DFSORT? Or any way of affecting the performance of qsort()? We are looking into modifying the C code to do less disk accesses and anything else that we can think of.
Answer
C/370 documentation does not cover invocation of DFSORT or any other application, so here is a sample C program that demonstrates the use of system() function to invoke DFSORT, and a sample JCL that was used to run that program.
#include <stdio.h>
#define FOPENRET 0
#define FCLOSERET 0
main()
{
int rc, i;
FILE *fp;
char fname() = "TEST";
char sname() = "TEST.S";
char buf(80);
if ( !(( fp = fopen( fname, "r+" )) != FOPENRET ))
printf("Can't open file\n");
fseek( fp, 0, SEEK_END );
for( i=0; i<10; i++ )
fprintf( fp, "1234 - i\n", 10 - i );
if ( fclose( fp ) != FCLOSERET )
printf("Error closing data file\n");
else printf("File closed normally\n");
printf("Before calling SORT\n");
/*
* The system() function is described in the
* C/370 programming guide SC09-1384 p.411-413
*/
rc = system("PGM=SORT");
printf("rc from system = d\n", rc);
printf("After calling SORT\n\n");
if ( )!(( fp = fopen( sname, "rb,type=record" )) != FOPENRET ))
printf("Can't open sorted file\n");
fread( buf, 1, 80, fp );
for(;;) {
if( feof( fp )) break;
printf(" s\n", buf );
fread( buf, 1, 80, fp );
}
exit(0);
}
The following is a sample JCL used to run the test program listed above.
//useridA JOB (act#,dst#),'name',
// MSGLEVEL=(1,1),MSGCLASS=S,CLASS=A,NOTIFY=userid,
// TIME=1440
/*JOBPARM R=9T14,LINES=50
//*
//GO EXEC PGM=MYSORT
//STEPLIB DD DSN=userid.TEST.LOAD,DISP=SHR
// DD DSN=EDC.V2R1M0.SEDCLINK,DISP=SHR
// DD DSN=EDC.V2R3M0.SIBMLINK,DISP=SHR
//SORTLIB DD DSN=SYS1.SORTLIB,DISP=SHR
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=userid.TEST,DISP=SHR
//SORTOUT DD DSN=userid.TEST.S,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(1,1))
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(5,5))
//SORTDIAG DD DUMMY
//SYSIN DD *
SORT FIELDS=(1,25,CH,A)
/*
Question- ISASIZE Versus Region Size
Answer
Question- Is C/370 MVS C/370 library needed under VM?
Is C/370 library (MVS version) needed under VM to develop applications which will run under MVS?
I have C/370 installed under VM/ESA. I want to develop applications which can be run under MVS. I believe that, to do this, I must install the MVS C/370 library under VM and use it for linkediting the applications. How do I to do this (set up the MVS library under VM). Do I really need the MVS C/370 library under VM? Or can I develop applications using the VM C/370 library and just port them to MVS?
Answer
MVS and VM are not load module compatible. That is, you can not move a VM load module to MVS and expect it to run on MVS. At the most, you can move an object file (TEXT deck) from VM to MVS and create a load module using MVS linkage editor (this is known as crosscompiling). Applications can not be linkedited on VM and run on MVS, Applications must be linkedited on MVS if they are to be executed on MVS
Although not "officially" supported, a number of groups have cross compiled successfully. Here are a few things you may want to watch out for:
#pragma Runopts
Answer
Question- COBOL -> C Interlanguage call
The IBM C/370 Programming Guide SC09-1384 for Version 2.1 states in a sections titled 'Communicating with other languages; Restrictions and Considerations' that you cannot dynamically fetch a C function directly from COBOL. However, you can dynamically fetch a COBOL subroutine that has statically linked functions. With the new LE/370 common library and new AD/CYCLE C/370 and COBOL/370, has the above statement changed? Can you now dynamically fetch a C function directly from COBOL? Can the C routines called from a COBOL program be re-entrant?
Answer
The answer to the first question is yes. In LE/370, C functions can be dynamically fetched from COBOL. As for the second question, C routines called from COBOL must be naturally re-entrant (i.e. must not use writable static).
Question- C/370 resident program
I would like to know if it is possible to create and compile a C/370 program that would run entirely resident. I would like to do this so that the program could be run on several systems without the need for a C library on any but the creating system.
Beyond the technical "can I do it" question I would also like to know if this scenario creates any licensing problems. If I can create a C resident "run-time" program is it permissible to run it on multiple systems without additional licensing?
Answer
It is possible to create and compile a C/370 program that would run entirely resident, however, it would have a very limited choice of C/370 functions that it can use. This can be done using the Systems Programming Facilities (SPC) without run-time library. The functions that the application could use are limited to the set of built-in functions and SPC version of sprintf() and exit(). If it still makes sense to produce an application with the stated limitations, you can freely distribute the application.
Question- SVC99
Referring to manual sc09-1384-00 for use of SVC99 in c/370 2.1.0. The manual lists three uses for svc99 but does not give examples or parameter lists for all uses. Can you give us an example and the parameters for Concatenation/decatenation?
Answer
Examples in the manual SC09-1384-00 are intended to describe how to build interfaces for invoking svc99 services. Information on svc99 services can be found in the Application Development Guide, pub#: GC28-1852-0. Familiarity with svc99 services is a prerequisite for using the svc99 interface provided in C/370. Although the examples in the manual should be sufficient to understand how to build an svc99 interface, we are hoping that the following example will be easier to understand.
#include <stdio.h>
#include <string.h>
#define MASK 0x80000000
void main() {
FILE *fp;
char buf(80);
int rc;
int svc99rc;
__S99parms parmlist;
char *textunits(2);
char tunit(20);
unsigned short int s99key = 1;
unsigned short int s99num = 2;
unsigned short int s99len = 3;
/* the following memcpy calls generate text */
/* units with values expressed in hex: */
/* */
/* KEY # LEN PARM LEN PARM */
/* 0001 0002 0003 C4C4F1 0003 C4C4F2 */
memcpy( tunit, &s99key, 2 );
memcpy( tunit+2, &s99num, 2 );
memcpy( tunit+4, &s99len, 2 );
memcpy( tunit+6, "DD1", 3 );
memcpy( tunit+9, &s99len, 2 );
memcpy( tunit+11, "DD2", 3 );
memset( &parmlist, 0, sizeof(parmlist));
parmlist.__S99VERB = 3; /* CONCATENTATION */
parmlist.__S99FLAG1 = 0;
parmlist.__S99FLAG2 = 0;
parmlist.__S99ERROR = 0;
parmlist.__S99INFO = 0;
parmlist.__S99TXTPP = textunits;
parmlist.__S99RBLN = 20;
parmlist.__reserved = 0;
textunits(0) = tunit;
textunits(0) = (char *)((unsigned long int)(textunits(0)) | MASK);
svc99rc = svc99(&parmlist);
if (svc99rc != 0)
printf( " Error code = d Information code = d\n",
parmlist.__S99ERROR, parmlist.__S99INFO );
/* the following code will read concatenated*/
/* data sets (DD1 and DD2) and print their */
/* contents */
if( fp = fopen( "DD:DD1", "r" )) while( (rc = fread( buf, 1, 80, fp )) > 1 ) { printf( " .*s", rc, buf );
}
fclose( fp );
}
Question- Redirecting standard streams in SPC
In the C/370 2.1 Programming Guide, it says that standard streams is not supported under the Systems Programming Facility. However, I have been able to redirect standard streams with freopen(). Should this be avoided or is the restriction only related to redirecting standard streams with REDIR?
Answer
Redirection standard streams via the command line is not supported with SPC, because there is no logic to scan and analyze the "parm string" supplied with invocation of the program. The other way to redirect I/O, via freopen() and via JCL/FILEDEF's is of course available to SPC applications running with the library.
Question- Enum on union
I am having a problem with enum on union with the init count. The program is returning an unexpected value for a status field. This same code when done on PC returns the expected value. There seems to be a problem with the C/370 compiler and getting the expected results. Here is the code I am using with the console output. The expected status that should be return for married is 1 and the customer is getting 1,677,216. Is there a specific way the enum should be done to get the expected results?
#include <stdio.h>
#include <ctype.h>
#include <string.h>
struct birthday {
int day;
int month;
int year;
};
struct person {
int age;
char nameO20E;
struct birthday bday;
union }
int count;
enum {single, married = 1} status;
} martial;
};
struct person perO5E;
void getarg(char strgOE, int n);
void main(void)
{
int a=0,b,z=0;
char workO20E;
for ) a = 0; a < 5; a++)
}
printf("Enter name end with and 'end' \n);
getarg(perOaE.name,20);
if(!strcmp(perOaE.name, "end"))
break;
printf("Enter Martial Status\n");
getarg(work,2);
if(workO0E == 'm')
{
printf("married\n);
perOaE.martial.status + married;
}
else
perOaE.martial.status = single;
}
for(b - 0; b < a; b++)
{
printf("Na: s S d\n", perObE.name,perObE.martial.status);
printf("Na: s S d\n", perObE.name,perObE.martial.count);
z += perObE.martial.count;
}
void getarg(char strgOE, int q)
{
int b = 0;
while ( (strgOb++E = getchar()) != '\n' && b < q)
NULL;
strgO--bE = '\0';
}
*********** CONSOLE OUT PUT ******************************** c18#ken#m#end Enter name end with and 'end' Enter Martial Status married Enter name end with and 'end' Na: ken S 1 Na: ken S 16777216 Married 16777216
This what is being returned. The expected should only be a (1)one. What is causing this to happen?
Answer
The problem is that the smallest and the largest enumeration value can be represented in a char and that is what the compiler does. If you want to force the int type for representing enumeration, you can add a dummy enumeration constant at the end and assign it a large negative value, as in the following example: enum {single, married = 1, dummy = -70000} status; This behavior of the C/370 compiler is documented in the SAA Common Programming Interface C reference - Level 2 (SC09-1308-2) page 393.
Question- Accessing writable static storage
I am using the EDCDXD and EDCLA macros to access writable static storage from assembler programs linked in with their AD/Cycle C/370 programs. I am now writing a free-standing application that does not use the C runtime library, and having problems trying to use these same macros.
Specifically, in the free-standing environment, static storage used by C routines (the base address of which is stored in the TCA) is distinct from storage reserved with EDCDXD. The result of this is that the offsets of storage reserved with EDCDXD overlay the offsets of storage used by static C variables.
We can find no documentation of any problems or restrictions with accessing writable static storage from assembler programs in a free-standing environment. Is this possible, and if so, how can we do it?
Answer
EDCDXD is used to declare a writable static variable. EDCLA is used to load the address of the writable static variable into a register. For these macros to work, you need to compile the SPC program using the RENT option, and run the prelink utility to create the writable static module. You should also include EDCRCINT when you link your application.
The following example demonstrates how to use EDCDXD and EDCLA macros in a freestanding SPC application.
RENTSPCC C:
#pragma linkage(rentspca,OS)
void main() {
rentspca();
}
RENTSPC C:
#pragma linkage(rentspc,OS)
int rentv = 7;
int rentspc() {
exit(4320 + rentv);
}
The following EXEC compiles, prelinks, generates a load module
and executes it. The expected output is a return code of 4322.
'global txtlib edcspc ibmlib cmslib' 'cc rentspcc (nostart rent' 'cc rentspc (nostart rent' 'hasm rentspca' 'global txtlib edcspc ibmlib cmslib' 'cplink edcxstrt rentspcc rentspc edcrcint edcxexit edcxsprt (map' 'global txtlib' 'load cpobj (map reset edcxstrt' 'genmod rentspc (from edcxstrt' 'rentspc'
The following options are used to compile the assembler program:
RENT OSMACRO EDCLIB
The following assembler program is used:
RENTSPCA ASSEMBLE:
RENTSPCA CSECT
RENTSPCA AMODE ANY
RENTSPCA RMODE ANY
EXTRN RENTSPC
EDCPRLG
RENTV EDCDXD 0F
EDCLA 8,RENTV * note the use of 8 instead of R8!
LA R9,2(0,0) + pseudoregisters can not be used
STC R9,3(0,R8) + with EDCLA
L R15,=V(RENTSPC)
BALR R14,R15
EDCEPIL
LTORG
R8 EQU 8
R9 EQU 9
R14 EQU 14
R15 EQU 15
END RENTSPCA
Question- C Debuggers under CICS
C Debuggers under CICS
Do any of the C source level debuggers run under CICS/ESA?
Answer
Debug Tool, part of the product CODE/370, can debug C code under CICS/ESA. CODE/370 pre-reqs the AD/Cycle 1.1 C/370 Compiler as well as LE/370 1.1 (or later). CODE/370 also supports COBOL.
Question- Run Time Library Requirement
Run Time Library Requirement
I have written a C/370 program that has calls to various functions. Among them are: STRCPY, STRCHR, STRCAT and STRCMP. These subroutines are inline built-in functions and at link-edit time will be linkedited into the resulting object program. I have used the following subroutines: STRNCPY, STRNCAT, STRNCMP and STRPBRK, and it appears that these will be called from the run-time library at execution time, and that the link-edit only includes a stub to resolve the external reference. Is there any way these modules can be linked into the object program such that the resulting program can be executed in an environment that does not have the run-time library? I've looked through the reference manuals at compile and run time options to see if there was a way of specifying this, but I can see no way of accomplishing what the customer is looking for. I would suspect that the run-time library is required in this case. Can you verify this for me.
Answer
Only Free-standing Applications can execute without the C/370 run-time library. These application require the use of Systems Programming Facilities (SPC), and do not have access to C/370 run-time library functions. The functions available under SPC are built-in functions, and SPC version of exit(), sprintf(), malloc(), calloc(), realloc(), and free(). For further information on SPC please refer to the C/370 Programming Guide SC09-1384 p.465-508.
Question- Program attempting to call from assembler main
I have coded an Assembler program which in turn calls a C/370 program. I have followed the example in the programming guide for establishing a persistent environment, using the OS linkage conventions, but are having problems with an 0C4 abend. I have also taken the example in the manual, coded it, executed it and it runs fine. I have included the code statement for statement and am puzzled as to why they are having the abends. The abend occurs at the open for an input file (opened via assembler code), but before I initialize the C environment which is the next code after the open to be executed. I have compiled the assembler program with AMODE 31 and RMODE 24. If they change that to AMODE 24 & RMODE 24, the abend address changes to what appears to be an address within a module XBTCA. The question I have is what is the effect of the AMODE & RMODE specifications and could this be his problem, although other combinations haven't worked either. I'm stumped here as to where to go next to resolve this problem. The coding appears to be, as far as we can tell, OK.
PS I'm at 2.1.0 of C/370 and 2.2.0 of MVS/XA.
Answer
If the application is correctly coded and compiled with NOSTART option, and if the link-edit includes EDCXMEM and objects for the assembler and C program and sets the entry point to be the csect in the assembler module, then the problem may be in the logic of the application.
Question- Variable length argument list
How do I code a subroutine to accept variable length argument list - converting BAL to C?
I want to convert a subroutine from BAL to C. The subroutine is called primarily from COBOL, but could be used from other languages as well (I understand the host environment is picky about parameter lists when called from other host languages). C has been chosen as the lowest common denominator to allow the code to be ported across platforms.
Here's the problem: How do I rewrite this subroutine so that it will accept a variable length argument list, and how do I do this so that the original COBOL source does not have to be changed?
Example: A sort routine that will accept up to 10 sort fields (keys).
Calling statement:
CALL SORTRTN USING SORT-AREA NUM-ITEMS ITEM-SIZE
SORT-KEY-1 KEY-1-POS KEY-1-LEN ORDER-1.
OR:
CALL SORTRTN USING SORT-AREA NUM-ITEMS ITEM-SIZE
SORT-KEY-1 KEY-1-POS KEY-1-LEN ORDER-1
SORT-KEY-2 KEY-2-POS KEY-2-LEN ORDER-2
SORT-KEY-3 KEY-3-POS KEY-3-LEN ORDER-3.
Answer
Assuming that you know the calling convention from COBOL, you can create a small assembler routine to intercept the parameter list, and pass register 1 to the C routine that will replace your assembler code. In the C routine you can access all parameters using register 1 that was passed to it. Your C routine would have a single parameter that is a pointer to void e.g. C_rtn_type C_rtn_name( void * C_rtn_parm); You should also be aware of the potential performance problem if your C routine is called from multiple places in a deep calling hierarchy.
The following example illustrates this problem.
MAIN_COBOL_ROUTINE
|
+----------------+-----------------+
| | |
COBOL_SUB1 COBOL_SUB2 COBOL_SUB3
| | |
C_ROUTINE C_ROUTINE C_ROUTINE
In the example, every time C_ROUTINE is called, a new C environment will be established, and every time one of the COBOL subroutines terminates, the C environment will be terminated. To avoid this, you should call a dummy C program from the main COBOL Routine. This will establish the C environment for all invocations of the C_ROUTINE.
To access the parameters in your C program using the register 1 that was passed to it by the small assembler routine, you should use the appropriate casting of pointers pointed to by register 1. I assume that the parameters are always arranged in a know sequence, or that you have a method of identifying what the next parameter type is by knowing what is the type of the current parameter (in this case the first parameter must have a known type).
This method will work for other programming languages, but you may need to have a different assembler routine for every programming language if the calling conventions are different.
If you are using AD/Cycle C/370 and LE/370 you will not need to code the assembler routine for COBOL and PL/1, because LE/370 provides common ILC support, but you will have to use the ellipses and va_arg( ) to access the arguments.
If you did not get a copy of any of our previous editions, just let us know and we will be more than happy to send them to you.
If you haven't already sent for your free subscription to this newsletter, now is the time to mail it in. So far, we have been able to keep to our plan of 4 issues a year (even thought we may sometimes be a little late). Please keep those cards and letters coming in to us so that we can keep publishing. We really thank the many of you who have already sent your comments and subscriptions in. If you prefer, mail or fax your business card to the address/phone number on the Reader's Comment Form.
For the many of you sending in the reply forms with your comments, we may need to call you to discuss your comments further. It's a great help if you include your phone number. Thanks!
In future issues, we'll bring back some performance tips and answer some more of your questions. Thanks for reading; please let us know what you think of this newsletter.
+----------------------------------------------------------+This newsletter was produced by the IBM Software Solutions Toronto Laboratory. For further information on any of the products mentioned, please contact your local IBM office, or an authorized IBM Business Partner.
Numerous product references in this publication are registered trademarks or trademarks of International Business Machines Corporation, unless otherwise indicated. IBM Canada Ltd., a related company, is a licensee.
This news letter was created and marked for processing using IBM BookMaster(TM) (Program Number 5688-015) and IBM Document Composition Facility (DCF). (Program Number 5748-XX9).
The final copy was printed on an IBM 3825 Page Printer, an Advanced Function Printer.
This newsletter is © Copyright IBM Corporation 1994.
In Canada - © Copyright IBM Canada Ltd. 1994. +--------------------------------------------------------------+
Please note:
_______________________________________________________
_______________________________________________________
_______________________________________________________
_______________________________________________________
_______________________________________________________
Thank you for your cooperation and help. You can either mail this form to us, or hand it into an IBM office for forwarding.
You can also fax the form to us. Our fax number is 416-448-6057. Please mark your fax for the attention of Gord Sinclair. Thanks.
Gordon Sinclair Software Solutions Toronto Laboratory IBM Canada Ltd 23/148/844/TOR 844 Don Mills Road North York Ontario, Canada M3C 1V7
( ) Products marked (TM) or ® are trademarks or registered trademarks of the International Business Machines Corporation, unless otherwise indicated.
( ) UNIX is a trademark of X/Open Company, Limited.