IBM Corp 1997
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(*) Compiler News
March 1997 Volume 5 Number 1
Welcome to the March, 1997 Issue of the C/370 Newsletter
Building and managing reusable applications and component parts across development teams is now much easier thanks to the announcement of IBM TeamConnection Version 2(V2).
IBM TeamConnection V2, a collaborative LAN-based client/server development environment, offers businesses returns on their investments by helping teams of programmers to manage and control joint development projects, thereby increasing productivity and improving software quality. Expanding the impressive portfolio of IBM software products for Windows(**) NT, TeamConnection V2 now includes platform support for Windows NT as well as UNIX(**).
Also new in Version 2 is a Tool Builder's Development Kit and extended support for MVS programmers.
"Great technology results from effective teamwork," says John Swainson, general manger, IBM Application Development Solutions. "TeamConnection simplifies and accelerates complex development tasks by managing the process of software developers working together. This gives our enterprise customers a competitive edge and allows them to quickly take advantage of new technologies and market opportunities, while reducing costs."
Recently, the State of California built a new, object-based 4GL application called the Integrated Statewide Information System (ISIS) to help manage one of the state's largest nutrition service programs, the Supplemental Nutrition Program For Women, Infants and Children (WIC). The State of California uses IBM TeamConnection to help manage this application and their development environment.
"We need an environment that allows us to make substantial changes to applications quickly, while providing increased change management and version control," says Mike Virga, staff programmer and analyst and WIC ISIS application design project leader. "IBM TeamConnection enables us to accomplish these goals and more. We are particularly happy with the way the product helps us manage our entire development environment."
TeamConnection V2 combines a single repository for development data and comprehensive software configuration management, allowing any type of file or object to be stored and reused, such as OpenDoc, OLE(**), ActiveX(**), C++, C, COBOL and Java. The product also assists web developers in keeping web-sites up-to-date by versioning and managing web content. TeamConnection provides the centralized storage and multi-language build facility for enterprises wishing to archive all development data in one centralized store, even for cross-language applications or development based on multiple languages and tools.
In addition to the extended platform support in Version 2, OS/2(*) server environments and OS/2, Windows NT and Windows 3.1 client platforms will also continue to be supported along with OS/2 and MVS build platforms.
For more information about TeamConnection, visit the World Wide Web at http://www.software.ibm.com/software/ad/teamcon
The OS/390 C/C++ Model Tool provides on-line help for developers using the C/C++ MVS compiler and the Language Environment(*) for MVS & VM runtime library. You can start the Model Tool from an ISPF edit session on MVS. You can obtain help for library functions and pragma directives. You can also access the standard menu that provides help for ISPF functions.
Note: The following menus are for C applications. There are similar menus for C++ applications. Whether C or C++, help is displayed depending upon the low-level qualifier of the data set you are editing. Refer to "Additional Information about the OS/390 C/C++ Model Tool" later on in this article for more information.
There are several ways to obtain help for library functions using the Model Tool. These methods are described below. Method 1 is the fastest if you already know the name of the library function that you want.
Method 1: Enter MODEL funcname (where funcname is a function name, such as fopen), on the command line of your edit session. Read-only information is then dropped into your edit session. For example, if you enter MODEL fopen, information is displayed as shown in Figure 1:
File Edit Confirm Menu Utilities Compilers Test Help
------------------------------------------------------------------------
EDIT TS22512.C(TEST) Columns 00001 00072
Command ===> Scroll ===> PAGE
********************************* Top of Data ***************************
=NOTE= #include <stdio.h>
=NOTE= FILE *fopen(const char *filename, const char *mode);
********************************* Bottom of Data ************************
Figure 1. Function information
The read-only information is marked with NOTE in the prefix area. To make it disappear enter RESET on the command line, or end the edit session. If you want to keep any of the read-only information, use the MD command in the corresponding prefix area.
Method 2: Enter MODEL (without a function name) on the command line of your edit session. The main Model Tool menu is displayed, as shown in Figure 2.
------------------------ C/C++ for MVS/ESA MODEL TOOL -------------------
OPTION ===> _
F LIBRARY FUNCTIONS SUPPORTED BY C
P PRAGMA DIRECTIVES SUPPORTED BY C
I ISPF FUNCTIONS AVAILABLE UNDER C/C++
Enter END command to cancel MODEL command.
Figure 2. Main Model Tool menu
Next, enter F in the option field of the menu. An alphabetical menu is displayed, as shown in Figure 3:
----------------- Functions Supported by C-Alphabetical List ------------
OPTION ===> _
Functions are grouped according to the first character of the function
name. Select the menu for that character (for instance, for the
fopen function, select option 6).
1 function names beginning with a 15 function names beginning wit
2 function names beginning with b 16 function names beginning wit
3 function names beginning with c 17 function names beginning wit
4 function names beginning with d 18 function names beginning wit
5 function names beginning with e 19 function names beginning wit
6 function names beginning with f 20 function names beginning wit
7 function names beginning with g 21 function names beginning wit
8 function names beginning with h 22 function names beginning wit
9 function names beginning with i 23 function names beginning wit
10 function names beginning with j 24 function names beginning wit
11 function names beginning with k 25 function names beginning wit
12 function names beginning with l 26 function names beginning wit
13 function names beginning with m number
14 function names beginning with n
Enter END command to return to previous menu.
Figure 3. Alphabetical menu
From this menu, you can select a menu that contains all of the functions whose names start with a particular letter. For example, selecting option 1 displays the menu containing functions whose names begin with the letter a, as shown in Figure 4:
------------------------ function names beginning with a -----------------
OPTION ===> _
More:
1 abort-Stop a program
2 abs-Calculate integer absolute value
3 accept-Accept a new connection on a socket
4 access-Determine whether a file can be accessed
5 acos-Calculate arccosine
6 acosh-Calculate hyperbolic arccosine
7 advance-Pattern match given a compiled regular expression
8 alarm-Set an alarm
9 asctime-Convert time to character string
10 asin-Calculate arcsine
11 asinh-Calculate hyperbolic arcsine
12 assert-Verify condition
13 atan-Calculate arctangent
14 atan2-Calculate arctangent
15 atanh-Calculate hyperbolic arctangent
16 atexit-Register program termination function
17 __atoe-Perform ISO8859-1 to EBCDIC string conversion
18 __atoe_l-Perform ISO8859-1 to EBCDIC conversion
Enter END command to return to alphabetical menu.
Figure 4. Menu of functions whose names begin with letter a
You can then select an option, or enter the name of a function that appears on the menu. Read-only help is dropped into your edit session. Proceed as in method 1.
Method 3: Enter a function name in the option field of the main Model Tool menu. Read-only help is dropped into your edit session. Proceed as in method 1.
Method 4: Enter a function name in the option field of the alphabetical menu. Read-only help is dropped into your edit session. Proceed as in method 1.
For complete information about library functions, refer to the OS/390 C/C++ Run-Time Library Reference.
You can obtain help for #pragma statements in one of several ways. Method 1 is the fastest if you already know the name of the pragma that you want.
Method 1: Enter MODEL pragname (where pragname is a pragma name such as chars), on the command line of your edit session. Modifiable #pragma statements and read-only help is dropped into your edit session, as shown in Figure 5:
File Edit Confirm Menu Utilities Compilers Test Help ------------------------------------------------------------------------- EDIT TS22512.C(TEST) Columns 00001 Command ===> _ Scroll ===> ****** ***************************** Top of Data ************************ =NOTE= The #pragma chars directive specifies that the compiler is to t =NOTE= all char objects as signed or unsigned. =NOTE= 000001 #pragma chars(unsigned) 000002 #pragma chars(signed) =NOTE= =NOTE= This pragma must appear before any statements in a file. =NOTE= Once specified, it applies to the rest of the file and cannot b =NOTE= turned off. =NOTE= =NOTE= If a source file contains any functions that you want to be =NOTE= compiled without #pragma chars, place these functions in a =NOTE= different file. =NOTE= =NOTE= The default character type behaves like an unsigned char. ****** **************************** Bottom of Data **********************
Figure 5. #pragma information
Modifiable information is highlighted. You can alter or delete it to suit your program. You will be given multiple versions of a #pragma statement if different options are available for the pragma.
Read-only information is marked with NOTE in the prefix area. Read-only information disappears when you enter RESET on the command line, or end the edit session, as shown in Figure 6:
File Edit Confirm Menu Utilities Compilers Test Help ------------------------------------------------------------------------- EDIT TS22512.C(TEST) Columns 00001 Command ===> _ Scroll ===> ****** ***************************** Top of Data ************************ 000001 #pragma chars(unsigned) 000002 #pragma chars(signed) ****** **************************** Bottom of Data **********************
Figure 6. Saved #pragma information
If you want to keep any of the read-only information, use the MD command in the corresponding prefix area. The read-only information is not exhaustive; for complete information about a pragma, refer to the IBM OS/390 C/C++ Language Reference.
Method 2: Enter MODEL (without a pragma name) on the command line of your edit session. Enter option P in the option field of the main Model Tool menu that appears. A menu containing a list of pragmas is then displayed, as shown in Figure 7.
--------------------------- Pragmas Supported by C ---------------------- OPTION ===> _ The following #pragma preprocessor directives may be used with the OS/390 C compiler: 1 chars 14 options 2 checkout 15 pack 3 comment 16 page 4 csect 17 pagesize 5 environment 18 runopts 6 export 19 sequence 7 filetag 20 skip 8 inline 21 strings 9 langlvl 22 subtitle 10 linkage 23 target 11 longname 24 title 12 map 25 variable 13 margins Enter END command to cancel MODEL command
Figure 7. pragma menu
From this menu, you can select an option, or enter the name of the pragma. Modifiable #pragma statements and read-only help is dropped into your edit session. Proceed as in method 1.
Method 3: Enter a pragma name in the option field of the main Model Tool menu. Modifiable #pragma statements and read-only help is dropped into your edit session. Proceed as in method 1.
Refer to the OS/390 Program Directory for more information about installing and customizing the model tool.
This book provides practical experience on how to use IBM VisualAge C++ for OS/2, Version 3.0. It serves as a guide to full-function application development, explaining all steps from requirements specification to implementation while adhering to modern programming techniques, such as object-orientation and visual programming.
The focus of the book is on practice rather than on the theory of object technology. Thus, the book provides the key concepts for developing well-structured, object-oriented applications with VisualAge C++. This book does not discuss or compare the various existing methodologies in detail. It applies the Visual Modeling Technique to VisualAge C++ to develop a real application from the ground up. This book will be useful for people involved in application development who want to exploit the newest trends in software engineering or find out whether VisualAge C++ will meet their needs.
ISBN 0-13-242447-9
Peter Jakab of the Lab's Product Services team, and Dale Nilsson of the OO Tools Development team in Raleigh, are the authors of a new book published by Prentice Hall. VisualAge for C++: Visual Programmer's Handbook is a fundamental tutorial on IBM VisualAge C++ for OS/2 and Windows. The book teaches C++ application developers how to build robust applications more quickly and easily than is possible with any other development package. It explains the leading-edge technology built into VisualAge for C++, especially its visual "construction-from-parts" paradigm. Readers learn how to use VisualAge to automatically generate C++ code using the Visual Builder tool, and how to build GUI applications without having to learn a complex class library. Techniques for dramatically reducing application development time are also presented. The book covers integration with existing databases, and outlines features available, which give applications the look and feel of Windows or OS/2. Extensive real-world examples and step-by-step instructions are included.
The VisualAge for C++: Visual Programmer's Handbook is targeted at C and C++ programmers; C++ application and GUI designers; multiple-platform developers; and faculty and students. It will also help developers prepare for the IBM VisualAge for C++ certification examination.
The book was adapted from a one-week intensive class developed to provide Proof-of-Concept Prototyping education to software services providers. It contains full-feature, trial versions of VisualAge for C++ and DB2, along with exercises and answers on 2 CD-ROMS, one for Windows'95 and NT and one for OS/2.
ISBN 0-13-614322-9
For more information visit Prentice Hall's Web page at: http://www.prenhall.com/allbooks/preface/ptr_pref_0136143229.html for VisualAge for C++: Visual Programmer's Handbook or http://www.prenhall.com/allbooks/preface/ptr_pref_0132424479.html for Object-Oriented Application Development with VisualAge C++.
The C/C++ feature of OS/390 Release 3 includes the following enhancements:
Interprocedural Analysis, through the IPA compiler option, can improve the execution time of OS/390 C/C++ applications. IPA is a mechanism for performing optimizations across the entire program. The types of optimization performed include:
The OPT(2) compile-time option instructs the compiler to perform global optimizations to produce faster running object code.
Note: Direct-to-SOM (DTS) Interface Definition Language (IDL) generation through the IDL compile-time option is now obsolete and IBM will withdraw support for it in the future. This option instructs the compiler to generate IDL, which is required for mixed-language or distributed object applications. Programmer coded IDL should be used to develop System Object Model (SOM) applications.
For more information about OS/390, visit http://www.s390.ibm.com/products/oe
These questions are culled from a variety of sources: various question and answer databases, customer calls, and our own experiences. If you have a question you'd like answered, please send it to IBMMAIL(CAIBMRXZ) or inetc370@vnet.ibm.com We'll answer your question and perhaps print your question and answer in the next newsletter.
Question - Blksize Question
I want to dump an MQSeries Message queue into a preallocated file that is BLKSIZE = 32K. When I run my job it changes the file to BLKSIZE = 6144. This is in agreement with the LE C/370 Programming Guide's specs on maximal blksize.
Can you see a way I can do this with C?
Answer
I believe 6144 is the default run-time BLKSIZE. Every run-time since AD/Cycle C/370 V1R2 supports a BLKSIZE up to 32760.
There are a couple of ways of doing this:
Alternatively, especially if you're coming from UNIX, you could consider using HFS files, in which case neither fopen() nor the programmer sees or cares what the block size is.
Question - C++ debugger
I can't get the debugger to step through my code. The way I'm compiling is I have six modules that include a lot of other source code, for example:
#include "../afpdoc/atxdoc.cpp" #include "../afpdoc/atxfdef.cpp" #include "../afpdoc/atxpage.cpp" #include "../afpdoc/atxpseg.cpp"
When I try to run debug it won't go into any of the included code. I specify TEST on the compile. Am I missing something or is this a restriction?
Answer
Header file debugging was supported with the C/C++ for MVS 3.2 compiler and above. There was a prerequisite debug tool ptf.
So if you are using C/C++ for MVS 3.2 or any of the OS/390 compilers and a fully serviced debug tool you can debug the header files.
Question - I/O one record at a time
I'm new to working with C in MVS. I'm trying to write a real simple program to read one record at a time from some QSAM datasets and write them out the same way. I've tried using the fopen(), fread(), and fwrite() functions. With this particular application, I will not know at compile-time what the LRECL of the input file will be. I've tried specifying a record length of sizeof(char) and a large count, as the manual seems to suggest, but that only causes the program to pull in as many bytes as it can from the dataset without stopping at a record boundary. Is there any way I can force the program to determine the LRECL dynamically, or to just read a single record at a time? Thanks.
Answer
This sounds like a job for ... "type=record" I/O. You could try:
/* ... */
fp = fopen("my.file", "rb,type=record,NOSEEK");
/* type=record enables reading/writing 1 record at a time */
/* NOSEEK enables QSAM */
record_size = fread(buf, 1, buf_size, fp);
/* buf_size should be as big as the largest record. */
/* This is the "sizeof(char), large count" referred to in */
/* the book. It needs "type=record" on the fopen() for */
/* it to work. */
/* ... */
Question - Misaligned data
I would like to find out how misaligned data is handled by IBM's MVS C++ compiler. One of our applications uses pointer variables to manipulate fields stored inside a database BLOB. These fields were dumped into the BLOB one after the other, with no attempt made to align them. Therefore, a 32-bit integer for example, may start in the last byte of a word, spanning across the first three bytes of the next word.
What are the mechanics used by the compiler when this situation arises?
Answer
The C++ and C compilers support misaligned data using the #pragma pack directive. #pragma pack will force char/short/int/float/double to be aligned on byte boundaries and bit-fields on bit boundaries. By default data is aligned on it's natural boundary (e.g. byte for char, half-word for short, word for float, double-word for double, quad-word for long double). There will be a performance degradation for packed data, but only for the objects that are packed, e.g. if your program only has one packed object only access to the members of that object will have a performance impact. The amount of performance penalty varies. You must consider the hardware you are using, intensity of data fetches that are misaligned, etc. The results we obtain might be significantly different than the customer if our hardware is different, since misaligned instruction fetch performance will vary (I imagine) from hardware to hardware.
Question - OpenEdition MVS Macros
I'm trying to port GNU make to MVS Open Edition. I'm looking at some VM OpenEdition porting notes and the author has VM OpenEdition specific C code in #ifdef __OPEN_VM conditional compile regions. Is there a similar predefined OpenEdition MVS macro?
Answer
This macro does not indicate OpenEdition MVS but simply MVS:
#ifdef __MVS__You could combine macros to see if you're compiling on MVS and are enabling OpenEdition services:
#if defined(__MVS__) && defined(_POSIX_SOURCE)You can also enable feature test macros relating to standards encompass POSIX such as _XOPEN_SOURCE or _XOPEN_SOURCE_EXTENDED.
Question - Delivering Products requiring IOSTREAM, APPSUPP, MATH
I would like to understand what IBM's position is regarding 3rd party software developers that write C++ based applications for OS/390, whereby the applications require the use of the IOSTREAM, APPSUPP, and MATH DLLs in their various incarnations.
Currently, the DLL library is not shipped as part of the runtime libraries in OS/390. They are only shipped as part of the C/C++ development packaging, and only if the CLB component is ordered. So it seems, that if someone ships an application, they either pre-req the C/C++ development environment in order to get the requisite DLLs, or they link them into their applications directly.
There is the possibility of using DLLRENAME to rename the DLLs in order to ship them with a product, but what are the licensing implications associated with this. Comments?
Answer
Currently, your options are:
For example: if your product ID is XYZ, the message files that are shipped with your product should have your product ID and an alias to the OLD name.
ICLBMSGT rename to XYZMSGT with alias to ICLBMSGT CLB3MSGE rename to XYZMSGE with alias to CLB3MSGE CLB3MSGK rename to XYZMSGK with alias to CLB3MSGK
GC09-2064-02 IBM C/C++ for MVS/ESA Version 3 Release 2 Program Number 5655-121 Licensed Program Specifications states on Page 5 (of 8): Redistribution Information: C++ Class Library DLLs: ... (You may redistribute the modules in) CBC.V3R2M0.SCLB3DLL, on condition that you rename the dataset, member, and alias names, and then use the DLL Rename Utility to update the references to the renamed DLLs in your application modules.
Question - C & REXX
Can I switch from C to REXX in an OpenEdition application?
Answer
An application written in a programming language such as C can now create an OpenEdition MVS REXX environment and directly call a REXX program. This is most useful in an application that wants to use REXX as a macro language. Of course, a REXX program could also be run by using the C system() function or through the exec() or spawn() functions, just like a program written in C. The documentation is in Using REXX and OpenEdition MVS, SC28-1905.
Question - C and PL/I
I'm a novice "C" programmer trying to adapt a PL/I program's functionality to a C program. My shop is all PL/I; no C at all. My task is to rewrite a PL/I program in C, which will be used later on a different platform. I hope to link the C program with other PL/I programs; I believe this is possible. How do I establish linkage? I know I need a pragma declaration. Do I need a main() ? I can't see how, I think I need void (mynewprog) followed by parameter list from the calling PL/I program. All reference material I have says main() is required.
Answer
Declaring a C entry point in a PL/I routine has the same syntax as declaring another PL/I entry point. A C routine can be replaced by a PL/I routine without altering the PL/I code that calls the routine. Likewise , if a C routine calls a PL/I routine, the PL/I procedure contains no explicit declaration indicating control is being passed from the C routine. The declaration is contained within the C routine.
In C, you must declare that the C entry point receives control from a PL/I routine. This declaration is in the form of a pragma. The body of the C function is the same as if the routine were called from another C function. Calling a PL/I routine and being called by a PL/I routine are handled by the same #pragma preprocessor directive.
If you're writing a function to be called from a PL/I program, you don't need main(). You only need main if you're writing a program which is to be called from the operating system ie JCL, OESHELL, TSO...
Declaration for C Calling PL/I
------------------------------|-----------------------------
C Function | PL/I Routine
------------------------------|-----------------------------
#pragma linkage(PLIFUNC, PLI)| PLIFUNC: Proc(arg)
| options(reentrant)
double PLIFUNC( double ); | returns (float binary(53));
| Dcl arg float binary(53);
int main() |
{ | Return (34.0);
double val,result; | End;
|
val=6.2 |
result=PLIFUNC(val); |
printf |
("val=%f\n",val result); |
} |
|
------------------------------|-----------------------------
Declaration for PL/I Calling C
-------------------------------------|------------------------
PL/I Routine | C Function
-------------------------------------|------------------------
PLIPROG: Proc | #pragma
options(main, reentrant);| linkage(CFUNC, PLI)
Dcl cfunc external entry | int CFUNC( int parm ) {
returns(fixed bin(31)); |
Dcl arg fixed bin(31); | return (5);
Dcl a fixed bin(31); | }
Arg = 10; |
A = cfunc(arg); |
End; |
|
-------------------------------------|------------------------
For more information on Interlanguage Communication please refer to Writing Interlanguage Communication Applications (SC26-8351-01) Chapter 7.
Question - Multiple includes
For a compilation unit which looks like this:
#include "blah.hpp" // First time #include "blah.hpp" // Second timewill the compiler attempt to open blah.hpp twice? I'm curious about both r3.1 and also r3.2 behaviour
If so, I will recode as:
#ifndef BLAH_HPP_SENTINEL #include "blah.hpp" // First time #endif #ifndef BLAH_HPP_SENTINEL #include "blah.hpp" // Second time #endif
I am attempting to speed up my compiles. Any other tips are appreciated.
Answer
For the 3.2 compiler (and the subsequent OS/390 compilers) we try to be smart and skip redundant includes. If you write your header file as:
#ifndef __<macro>__
#define __<macro>__
.
. <text of header>
.
#endif
We will be smart enough to skip redundant includes, e.g.
#include "blah.hpp" #include "blah.hpp"should only cause blah.hpp to be opened once. For 3.1, we don't catch this.
Another approach to speeding up your compiles is to use variable PDS members instead of fixed (that's if you are using PDS members and not HFS).
If reducing compile time is really important, you may wish to use PDS members instead of HFS files, since PDS I/O is faster than HFS. Using the HFS file system has numerous advantages when it comes to usability, porting, etc.
Using the NOTEMPINC option instead of TEMPINC will improve compile-time, but may cause code bloat (depends how big your templates are and whether they are marked as 'inline' or external). If your templates are predominantly inline templates, then they will be inlined and there will be little code bloat. If your templates are predominantly -not- inline, then the templates will be replicated across multiple text decks and the resultant module will be larger).
Question - Prelinker question
The documentation tells me that while building a large application, you must prelink all your object modules together into one module, however I can find no examples on how to do this. Does each object module get mentioned on the SYSIN to the prelinker (this abends) or is it done some other way.
What I really need to do is create a DLL from about 200 object modules.
Answer
There is an example of how to build a DLL in the OS/390 V1R2.0 C/C++ for User's Guide (SC09-2361-00) on pp 232-237. There is another example in the OS/390 V1R2.0 C/C++ Programming Guide (SC09-2362-00) on pp 287-290.
All your object modules (all 200 of them at the same time) must be passed as SYSIN to the prelinker to form one single prelinked object. The prelink step would also produce a file called the definition side deck (SYSDEFSD) that users of your DLL need. Your single prelinked object then needs to be linked to create the DLL.
Question - ARCH & TUNE Optimize Functions
I looked up the ARCH and TUNE options and suffice it to say I find them confusing when used together. What was the point of 2 parms? Can you give me a concise description of what happens to generated code for ARCH(n) and TUNE(n) combinations?
Answer
ARCH - Identifies the hardware feature that the optimizer can exploit in the generated code.
TUNE - Identifies the type of hardware for which the code should be optimized. This deals only with features common to all types of hardware (e.g. instruction scheduling).
TUNE(level) should not be set lower than ARCH(level).
Question - Codepages and a lot of Source
We want to compile a large amount of source code (OLD C/370 V2R1!). In former times we used in ISPF-Edit a form of translation. We didn't use at ISPF Settings as TERMINALTYPE 3278, we used a self-defined table C370. When we compiled out programs there was step in front of it. We translated it with a program. With the new compiler we want to use IBM-273 (German codes!) What codepage was used for the old compiler ? I wanted to translate the codes into the old codepage of C/370 (with out program) and afterwards use EDCICONV to translate the source into IBM-273. What do you suggest?
Answer
The old and new compilers use a 'base' codepage of IBM 1047. If you want to write your source in 273, use iconv to convert it to 1047 before passing it to the old (or new) compiler.
Question - fseek() function
I'd like some clarification about the use of fseek() function. I'm using the C/370 V2R1M0 compiler. I allocate a data set as follows:
//DBFILE DD DSN=EOU.xxxx.IXF, // DISP=(NEW,PASS), // UNIT=SYSDA,SPACE=(CYL,(10,5)), // DCB=(RECFM=VB,LRECL=6140,BLKSIZE=6144)
Then I open the file as follows:
fopen(dbfile,"rb, type=record")
After that, I try to use the fseek() function, as follows:
fseek(dbfile, last_row_written, SEEK_SET)where last_row_written is an integer.
The fseek() fails with "Invalid fseek offset" message. What am I doing wrong? Do the use of the ftell() function for getting the record position in the file is mandatory? Does exist any way for using fseek() in a record file?
Answer
This is a case of good news and bad news: The bad news is that C/370 V2R1 "type=record" I/O only supports fseek() offset values that are returned by ftell().
The good news is that this restriction was lifted in the C/370 V2R2 Library in 1993. For V2R2 (and LE1.3 and later), you can fseek() to a record offset of your choice, eg., fseek(dbfile, 17, SEEK_SET) will take you to the 18th record (since the first record is at offset 0).
Question - C/370 compile question
I am currently trying to compile a C/370 program. The compile options include reentrancy, long names, and csect. In the program itself I code the following:
#pragma csect(code,"CTEST1")
#pragma csect(static,"CTEST2")
When I compile the program, the csect CTEST1 is generated in the object code, but the csect CTEST2 is not. If I turn reentrancy off, I get both csects in my object code. I'm wondering if I can use #pragma csect(static,"CTEST2") with reentrancy turned on. Any help on this would be appreciated.
Answer
The static given in the CSECT pragma will be used to name the the CSECT containing no reentrant data. Use of the RENT option will modify where the compiler puts data and subsequently its creation of a non-RENT static section.
Question - fprintf won't print multiple fields per line?
Hope this is an easy one for the experts...when I use fprintf with a format string like "%s %s %s %d/n" (where /n is backslash n) I expected all the fields to print on one line, like this:
XXX YYYYYYYYYYYYYYYYYYYYYYYY ZZZZZZZZZZZZZZZZZZZZZZZZ 19.04However, the actual file looks like this:
XXX
YYYYYYYYYYYYYYYYYYYYYYYY
ZZZZZZZZZZZZZZZZZZZZZZZZ
19.04
I'd like all the fields on the same line. Output file is a member
of a PDS if this matters.
Answer
Your expectation that the output should appear on one line is reasonable.
The first thing that comes to mind is that the strings passed to fprintf() each have a \n at the end.
Question - Migration problem from C/370 v2.1 to LE V1.5
I have several c/370 v2.1 programs needed to be converted to LE/370. I have relinked the programs using le 1.5 linklib. When I run these programs, one program abended with message: CEE0802C Heap storage control information was damaged. From entry point FreeBlock at compile unit offset +00000068 at address 04924950. The rest programs running OK.
Is this because of different allocation of heap space? The program runs on AMODE 31 and contains many recursive calls. Do I need to set up a run time option of Heap instead of default value? I also considered the possibility that it could be a problem surface up during the migration. It runs well under c/370. If we overwrite the heap accidentally, the same problem should also show up in c/370.
Answer
My hunch is that you are writing past the end (or start) of some malloc'ed memory and you were getting lucky with the old runtime. The LE/370 runtime does have a different algorithm than the old 2.1 runtime for memory management hence the reason for the failure with the migration. There are a couple of thing to try: Use the STO(FE,FE,FE) runtime option with a small heap specified (see the LE HEAP run-time option).
Get the poor-man's debuggable malloc/free from our FTP site. You can get there from:
ftp://ftp.software.ibm.com/s390/c370and read the read-me then go to:
..../s390/c370/samples/debuggable_malloc/to get the code.
Question - Cobol II calling C/370
We have Cobol II V1.3.2 & C/370 Comp & Lib V2.1.0. I have problems when calling C/370 functions from Cobol. Depending on how many Cobol programs are called BEFORE the C function, the C environment will be re-created on each call. From CPU execution statistics we found that 52% of the time was spend in SVC008 (program load) loading IBMBLIIA.
I have made a test where two C functions each included a static variable. The test including 3 Cobol routines fails. When excluding Cobol routine COB3 things work. COB2 and COB3 are identical.
Cobol II COB1 WS:
01 DATA-F1 PIC X(0020).
Do 1000 times
CALL 'COB2' USING DATA-F1
Cobol II COB2 Linkage:
01 F1 PIC X(0020).
CALL 'COB3' USING F1
Cobol II COB3 Linkage:
01 F1 PIC X(0020).
CALL 'C1' USING F1
C/370 C1 #pragma linkage(C1,COBOL)
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
static long i = 0;
void C2(void);
void C1(char *data)
{
memset(data,'A',20);
i++;
printf("in C1 %li \n",i);
C2();
};
C/370 C2 #include <stddef.h>
#include <string.h>
#include <stdlib.h>
static long i = 0;
void C2(void)
{
i++;
printf("in C2 %li \n",i);
};
Each module is compiled separately and linked together with COB1 as MAIN with options 'AMODE=31,RMODE=ANY,RENT,REUS'. When this fails printf in C1 and C2 always prints variable "i" as 1. When successful it prints the incremented value. In the linkage MODULE MAP I noticed a $PRIVATE CSECT in front of COB2 and the two C functions. Does someone know the purpose of these?
Answer
Your application is working as designed. The C/370 environment is established on first call from COBOL routine, and it will remain active until its caller's caller is terminated. In your scenario:
B1 --> B2 --> B3 -->C1 --->C2
The C environment is established when COBOL B3 invokes C function, and C environment is terminated when B2 returns control to B1. Since your primary loop is in B1 COBOL routine, the C environment is established and torn down for every call. This is documented in the C/370 V2R1 Programming Guide.
To establish the C environment and keep it for the duration of your COBOL program, you should invoke a dummy C function from B1.
dummy() { }
Finally, under OS/390 (new version of C/C++ compiler and run-time library), the C environment is established once, even before COBOL B1 routine starts executing, and it remains active as long as the application is active, regardless of depth of your call chain.
Question - C++, LE 1.4 and C/370
Our product is compiled using the C++ CEE.V1R4M0 MVS libraries. We have setup SPA to do the MVS compile bridge. Our target product is for OS/390, that has the LE libaries in the base.
Is there anyway for customers to use the C/370 libraries when the modules are compiled using V1R4 LE libraries? When I try to linkedit using the C/370 libraries, I get a lot of unresolved external references.
Following is a part of the linkedit step
//STEP1 EXEC PGM=IEWL, // PARM='MAP,NCAL,LIST,LET,XREF,AMODE=31,RMODE=ANY', // REGION=512K //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(4,1)) //SYSPRINT DD SYSOUT=A //SYSLMOD DD DSN=SRVPSF.PW100.SANFLOAD,DISP=SHR //SYSLIB DD DSN=EDC.V2R1M0.SEDCBASE,DISP=SHR // DD DSN=PLI.V2R3M0.SIBMBASE,DISP=SHR ... missing some stuff ENTRY CEESTART NAME ANFIEQ(R)
Is there anything we can do to make these versions work together?
Answer
The C/370 family of compilers (C/370, AD/Cycle C/370, C/C++ for MVS/ESA, OS/390 C/C++) are designed to generate upwardly-compatible object decks and load modules. Thus, objects generated with a given compiler will, with very few exceptions, run on the corresponding release of the library, and on later libraries.
On the other hand, downward-compatibility of object decks and load modules is NOT supported. So objects generated with a given compiler will run on the corresponding release of the library, but NOT on earlier releases.
The only way your product can work with the V2R2 library is to compile it with the AD/Cycle C/370 V1R2M0 compiler. If your product is written in C, and doesn't use any LE-specific coding, this may be a possibility.
If your product is written in C++ I don't know of any way that you can support the C/370 V2R2 run-time, since there is quite a bit of C++-specific code in the LE V1R4M0 run-time that just isn't there in C/370 V2R2.
Question - Naming Objects
Can someone tell me a way to direct the compiler to place the object in a different directory than where it got the source (like you can do on virtually every other compiler I've run into)? The -o option on the cxx, cc, and c89 commands is used for naming executables only, that is, you can't use it to name objects.
I would like to be able to compile some source that physically resides on a read-only UNIX (non-OpenEdition-MVS) file system and place the resultant object in an file system and place the resultant object in an OE HFS file.
Answer
With OS/390 Release 2, the -o option on the cxx, cc, and c89 commands allows you to name objects. For earlier releases, do this: Make the directory where you want the object to go your current directory and specify a relative pathname to the source code when you compile. For example, instead of doing:
cc -c -o objdir/source.o source.cdo:
cd objdir cc -c ../source.c
Question - Prelinker
I'm trying to run my very small test case through the prelinker and having a problem. I've done this successfully on VM with a return code of 0 and absolutely no messages. Here's my JCL for the prelink step:
//PLNK EXEC PGM=EDCPRLK, // PARM='MAP', // REGION=4M //STEPLIB DD DSNAME=SYS1.CEE.SCEERUN,DISP=SHR //SYSMSGS DD DSNAME=SYS1.CEE.SCEEMSGP(EDCPMSGE),DISP=SHR //SYSIN DD DSNAME=D15RAV1.CTEST.OBJ,DISP=SHR //SYSLIB DD DSNAME=SYS1.CEE.SCEELKED,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSMOD DD DSNAME=D15RAV1.CTEST.LISTPLNK,DISP=(NEW,CATLG), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200), // SPACE=(32000,(30,30))
On MVS, using both the cataloged procedure EDC1CPLG and my own job, I keep getting a return code of 4 and this message:
WARNING EDC4015: Unresolved references are detected: IBMLLIST IBMBPIRA IBMBPIRB IBMBPIRC CEESG003SYS1.CEE.SCEELKED has the five (5) names flagged on the message. I've specified this library on SYSLIB and STEPLIB statements but I can't rid of the unresolved references.
Although a subsequent invocation of the linkage editor yields a return code of zero. If the rc=4 is acceptable, can someone please explain why I'm able to get a rc=0 on VM?
Answer
Those are the expected results from the prelinker - a RC of 4 and unresolved references to items that will be resolved in the subsequent link.
On VM, the Language Environment link-time library is a TXTLIB. The Prelinker processes TXTLIBs, and so everything is resolved at Prelink time.
On MVS, the Language Environment link-time library is a LOADLIB. The Prelinker cannot process LOADLIBs, and so not everything is resolved at Prelink time. The rest is resolved by the MVS Linkage Editor or Binder.
Question - Compile Options
When I compile a C program with the TEST compiler option, I specify TEST(ALL) on my compiler parm. The manual indicates that the suboption ALL is equivalent to TEST(SYM,BLOCK,LINE,PATH). However, my compiler listing shows that the result is TEST(NOSYM,NOBLOCK,NOLINE,NOPATH). I have also included two #pragma statements in my C program:
#pragma options (test(all)) #pragma runopts (test(,cmds,;,*) execops)
And here are the compiler options I specify
//COMPILE EXEC PGM=CBC320PP,
// PARM=('TEST(ALL),LONGNAME,SSCOMM',
// 'SHOW,OF,OPT,SOURCE',
// 'EXPMAC,LIST,NOMARG,NOSEQ')
Is there a possibility we have set an install option that is conflicting
with how I want TEST to act?
Answer
TEST and OPT are generally incompatible options. TEST should be used for debugging purposes only and OPT should be used as your final compile, but they should not be used together.
Question - C++ debugger?
Has someone developed a C++ debugger for Open Edition that has a decent end user interface? I used dbx in the mid-80s in a Sun environment, but UIs in commercial products have improved considerably over the last decade; I guess I've been spoiled.
Answer
The MFI debugger might be your answer. MFI stands for Mainframe Interface. It is an ISPF-like source level debugger with lots of nifty features. However, the support for POSIX C applications is restrictive to date. You can also use the dbx debugger for debugging MVS OpenEdition applications. For more information on the MFI debugger, take a look at http://www.software.ibm.com/ad/c370/debugger.
You can use the MFI debugger that comes with the OS/390 R2 compiler to do debugging of POSIX applications - however there are some restrictions:
Question - Determining external (versus static) functions
The build process for our product generates short names for all functions in a given compilation unit. With the existing C code, we scan the XREF section of the listing to look for the functions and the classification (external or static) to build the rename mappings.
In C++, the closest data we found that could be used to build the name map is the inline report facility. It appears that this report understands static versus external functions. The questions we have are as follows:
Thanks in advance for ANY assistance that anyone can provide...
Answer
If you did not get a copy of our previous editions, just let us know and we will send them to you.
You can download previous editions for on-line viewing from our anonymous ftp server (ftp.software.ibm.com). Directory /s390/c370 contains directories /news, /oldnews and /samples. /oldnews is broken down by year and /samples is broken into individual samples (eg. /codepage, /debuggable_malloc).
If you haven't already sent for your free subscription to this newsletter, now is the time to mail it in. If you prefer, mail or fax your business card to the address/phone number on the Reader's Comment Form. You can also send a message containing your name, full mailing address and phone number, in case we have to talk to you to inetc370@vnet.ibm.com or IBMMAIL(CAIBMRXZ).
Please keep those cards, letters, faxes and messages coming in to us so that we can continue to provide this service. We really thank the many of you who have already sent your comments and subscriptions in. It's a great help if you include your phone number with any correspondence. Thanks!!
In future issues, we'll have 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 newsletter was created and marked for processing using IBM BookMaster (*) (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 1997. In Canada - © Copyright IBM Canada Ltd. 1997.
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Please note:
____________________________________________________________________
Thank you for your cooperation and help. You can either mail this form to us, hand it into an IBM office for forwarding or send a message containing your full mailing address and phone number to IBMMAIL(CAIBMRXZ) or inetc370 @ vnet.ibm.com.
You can also fax the form to us. Our fax number is 416-448-2893. Please mark your fax for the attention of Gord Sinclair. Thanks.
Gordon Sinclair
Software Solutions Toronto Laboratory
IBM Canada Ltd
91/604/895/TOR
895 Don Mills Road
North York
Ontario, Canada
M3C 1W3
( ) Products marked (*) are trademarks or registered trademarks of International Business Machines Corporation, unless otherwise indicated. Company, product or service names marked (**) may be a trademark or service mark of others.