IBM Corp 1994
370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370
370 370 370
370 370 370
370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 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
October 1994 Volume 2 Number 3
Welcome to the October, 1994 Issue of the C/370 Newsletter
We decided to put this issue together in October rather than September to give you some exciting new information on our recent announcement, IBM C/C++ for MVS/ESA (TM) . We know that a lot of you have been asking for C/C++ for the mainframe and what we intend to do about it.
IBM intends to introduce a new addition to the C Set ++ (TM) family of products -- C/C++ for MVS/ESA (TM). This announcement is designed to establish IBM as a leading vendor in the cross-platform C/C++ application development marketplace by providing a powerful set of object-oriented development tools for MVS. This new addition will complement the existing set of C Set ++ products which includes C Set ++ for OS/2 ® , C Set ++ for AIX ® , and C Set ++ for OS/400 ®.
IBM C/C++ for MVS/ESA is designed to be the state-of-the-art MVS-based, language-centered environment which application developers will use to create, modify, test, and debug mission critical C or C++ applications targeted to execute on the MVS/ESA platform. Building on the strengths of the existing C/370 product, C/C++ for MVS/ESA will add C++ language support and will feature the following set of application development tools:
The environment will combine the best of the technology inherent in the C/370 product with the object-oriented technology found in other members of the IBM C Set ++ family of products. Since it will be object-oriented, you will be able to reuse existing C++ objects to quickly create and modify applications. Considering that it will be derived from C/370, applications created with C/C++ for MVS/ESA will be of the high quality developers of mission-critical applications depend on. Most C and C++ applications created with the IBM C Set ++ development products will behave consistently across all supported workstation and host platforms. This means that applications created with C/C++ for MVS/ESA will not only behave as developers expect them to behave but the source code will be very portable between platforms. In addition, programmers will be able to optimize their applications to exploit MVS/ESA host characteristics. The result will be high optimization in terms of speed and utilization of computer resources.
HIGHLIGHTS
IBM C/C++ for MVS/ESA is designed to be an MVS-based, language-centered environment featuring:
OVERVIEW
IBM C/C++ for MVS/ESA will provide a standards-compliant, standards-enforcing, and in some respects, the standard-setting optimizing compiler. In addition to featuring a NIST-certified, ANSI-compliant C compiler, C/C++ for MVS/ESA will contain an ANSI draft X3J16 compliant C++ compiler. The compiler will feature the same complete implementation of the C++ language found in other members of the C Set ++ family of products including:
Exception handling lets you coordinate the flow of your program when an unexpected condition arises. By using the exception handling features, you can deal with error conditions and unusual situations more effectively.
Templates define families of related classes or functions, and can be used as blueprints to construct individual classes or functions. With templates, you can re-use code, so coding is faster and more productive.
System Object Model (SOM) is an architecture for defining and managing binary object class libraries. SOM is the core object-oriented technology of SOMobjects for MVS. With SOM, C and C++ applications can be written using headers generated by the SOM Interface Definition Language (IDL).
Direct-to-SOM will allow a C++ user to generate SOM objects directly from C++, thereby foregoing the need to generate and process the SOM IDL. This will simplify the effort required to develop SOM applications. With this support, C++ programmers will be able to write virtually the same code they presently do when creating C++ objects. The compiler will take care of generating the objects as SOM objects.
Using DTS, programmers will be able to invest in C++ code while exploiting features of SOM such as allowing for binary compatibility of evolving class libraries and objects, and convenient coding to SOM-based frameworks.
The compiler included in C/C++ for MVS/ESA will set the IBM C/C++ application development environment apart from other C/C++ language environments which offer merely translators or interpreters.
C/C++ for MVS/ESA is designed to offer the developer extensive runtime support. In addition to exploiting the standard C runtime libraries available in Language Environment/370 (LE/370) and in MVS/ESA SP Version 5 C/370 Language Support Feature, C/C++ for MVS/ESA will provide developers the means to easily build Dynamic Link Libraries (DLLs). DLL support will allow developers to split their applications into units and to direct these units to be loaded only when required. Dynamic Link Libraries provide developers with more options in the way they package their applications and can help programmers improve system memory usage by reducing load module size.
The C/C++ for MVS/ESA development environment will provide support for C++ applications running under CICS/ESA 4.1.
The mainframe interactive debugger to be featured in the C/C++ for MVS/ESA environment will allow programmers to debug their applications as they are executing in their native host environment such as CICS, IMS/ESA, DB2, and so on. The debugger will feature the following functions:
The C/C++ for MVS/ESA environment will feature a set of class libraries consistent with those found in the OS/2 and AIX members of the C Set ++ family of products. The suite of class libraries will include:
The Collection Class Library (CCL) uses data abstraction to implement a wide variety of classical data structures such as stack, tree, list, hash table, and so on. Collections are used in virtually all programs. With CCL, you can develop programs without having to define every collection yourself. Using CCL, programmers can start programming using a high level of abstraction. Later on, they can replace an abstract data type with the appropriate concrete implementation. Each abstract data type has a common interface for all of its implementations. CCL provides the programmer with a consistent set of building blocks from which application objects can be derived. The library is designed for extreme efficiency and exploits the latest C++ language features such as exception handling and template support.
The Application Support Class Library provides the rudimentary abstractions required during the creation of most C++ applications including: Date, String, and Time.
This library, a subset of what is provided in other C Set ++ products, consists of the Complex and I/O Stream class libraries:
The Complex library lets you manipulate complex numbers and perform standard mathematical operations on them. Complex numbers are used in scientific and technical fields.
The I/O Stream library lets you view input and output (I/O) as independent not only of physical I/O devices, but of data types too. You can code sophisticated I/O statements easily and clearly, and you can define input and output for your own data types. The I/O Stream Library can help improve both the maintainability and the performance of programs that use input and output.
The C/C++ for MVS/ESA development environment will allow programmers to create applications which access DB2 relational databases. The environment will feature a generator for data access class libraries. Based on a relational database schema a class library can be generated that allows application programmers to work with persistent objects the same way they do with transient objects. Developing applications accessing objects whose data are stored in DB2 will be possible without dealing with SQL and DB2 details. A generated data access class library will contain classes representing the persistent business objects.
The C/C++ for MVS/ESA development environment is designed to execute either within an LE/370 environment (requiring MVS/ESA SP Version 4.2 (or later)) or without LE/370 (requiring MVS/ESA SP Version 5). SOM, delivered in the SOMobjects for MVS product, runs on MVS/ESA SP Version 4.2 (and later).
Why do you want C++ on MVS/ESA?
C++ combines the technical and practical advantages of the C language with the benefits of object-oriented programming. The fact that C++ is derived from C, one of the world's most popular conventional programming languages, gives C++ two distinct advantages over other Object-Oriented Programming Languages (OOPLs):
By extending the existing C/370 product with C++ support while maintaining compatibility with existing C/370 applications, IBM will make it easy for developers to get started with C++ while providing the same robust C development environment customers, who are building mission-critical applications, have grown to depend on.
C/C++ for MVS/ESA will feature the same common implementation of both the C and C++ language found in every other member of the IBM C Set ++ family. This will allow the programmer to create code which behaves consistently across all major workstation platforms and MVS/ESA. Applications created with C/C++ for MVS/ESA will behave as developers expect them to behave. Developers, managers, and companies will feel confident using applications built with the IBM family of C/C++ application development products.
The C/C++ for MVS/ESA compiler is designed to generate highly-optimized S/390 code. While the environment will incorporate the same patented core technology as other products in the C Set ++ family, the C/C++ for MVS/ESA compiler will be specifically tailored to exploit the S/390 architecture such that developed applications get the best optimization in terms of speed and utilization of computer resources. The code optimization algorithms implemented in the C/C++ for MVS/ESA compiler will prove to be second to none in the industry, allowing your applications to unleash the full potential of MVS/ESA.
Direct-To-SOM is a feature designed to allow a C++ user to generate SOM objects directly from C++, thereby foregoing the need to generate and process the SOM Interface Definition Language (IDL). This will simplify the effort required to develop SOM applications. With this support, C++ programmers will be able to write virtually the same code they presently do when creating C++ objects. The compiler will take care of generating the objects as SOM objects.
The mainframe interactive debugger to be featured in C/C++ for MVS/ESA will allow programmers to debug their applications as they are executing in their native host environment such as CICS, IMS/ESA, DB2, and so on. This will allow programmers to ensure that the application is tested properly in the host environment before the application is put into production.
Developers who program in C++ rely heavily on the object-oriented concept of "inheritance". Inheritance is the property whereby an object can take advantage of behaviour defined in other objects. To provide a consistent base from which programmers can build tailored objects for their applications, IBM intends to provide in C/C++ for MVS/ESA a base set of class libraries. These class libraries will provide developers a consistent starting point from which they can tailor objects to meet their own specific needs.
The suite of class libraries to be contained in the C/C++ for MVS/ESA environment far exceeds that offered by any other MVS C++ vendor and is consistent with those delivered in the other members of the C Set ++ family of application development products. Whether you're a novice or an experienced programmer, you will be able to use these class libraries to extend and reuse existing code and consequently reduce your development time. By providing this starter set of class libraries, IBM will assist development teams to build objects which are reusable across many projects. This will position the development team to leverage a single development investment by allowing a single piece of code to be reused across many applications. Providing a base set of classes will also assist developers to quickly create new applications from scratch.
Programmers who have already invested in the IBM C Set ++ workstation products will notice a strong similarity not only in the compiler but in the set of compiler-related tools provided in C/C++ for MVS/ESA as well. From a programmer perspective, this means that C/C++ programming skills acquired on one platform of the C/C++ family of products will be transferable to other supported platforms. For large enterprises and independent software vendors, this offers the ability to:
Planned Availability Date
The C/C++ for MVS/ESA technology will be available on December 30, 1994 to a selected set of customers. These customers will participate in a beta evaluation and test, providing feedback on product function and quality. When these customers confirm that IBM has achieved functional and quality objectives, IBM will announce planned availability and detailed information regarding pricing and ordering.
Early Participation
IBM is currently participating in joint customer studies and will be extending them to include additional customers starting December 30, 1994, for a period of at least 6 months. Early versions of SOMobjects for MVS, C++ on MVS, and class libraries will be available through the course of this program. Customers will be able to begin analyzing, designing and prototyping applications before these products are generally available.
Consulting services will also be available during this program. These will be similar to the services being offered at general availability.
Customers should contact their IBM representatives for more information about this announcement or send a message electronically to the addresses at the end of this newsletter.
An OpenEdition C/370 application is one which executes in the POSIX (1) fork or the threading functions such as pthread_create are strictly limited to use within this environment.
Several of the C language functions available under the OpenEdition MVS environment, such as fopen, freopen, rename, and remove have been designed for interoperability, such that:
For example, with POSIX(OFF):
fopen("./parts.instock","r")
opens an HFS file named parts.instock, and
fopen("//parts.instock","r")
opens an MVS data set named user-prefix.PARTS.INSTOCK.
Changing the runtime option POSIX(OFF) to POSIX(ON) affects the environment in which these functions execute:
fopen("parts.instock","r")
opens the HFS File named if POSIX(ON) is in effect, but opens the MVS data set named if POSIX(OFF) is in effect.
Some of the C language functions that use OpenEdition MVS Services can be invoked from applications running in the non-POSIX MVS environment, as specified with the runtime option POSIX(OFF).
For example:
open("parts.instock",O_RDONLY)
opens an HFS file named parts.instock whether the application is running with POSIX(OFF) or POSIX(ON).
For more information, see "Performing Hierarchical File System I/O Operations" in the IBM SAA (TM) AD/Cycle ® C/370 Programming Guide, LE/370.
Application developers familiar with UNIX-like environments will find OpenEdition MVS/ESA Shell and Utilities a familiar C application development environment. Those familiar with existing MVS development environments may find that the OpenEdition environment can enhance their productivity. Refer to the OpenEdition MVS User's Guide for more information on the Shell and Utilities.
Paul Wilkins of UniTone Limited in England writes
"I read with interest the section You Ask, We Answer and in particular 'Reading PL/1 Decimal Fixed from C/370'.
I too have come across the same problem some 12 months ago using C/370 Version 2.1 and solved it in the following way. The trick is to get DB2 to do the conversion for you.
For example:
EXEC SQL
SELECT FLOAT(DATA1),
FLOAT(DATA2),
INTO :DCLTABLEA.DATA1,
INTO :DCLTABLEA.DATA2,
WHERE etc etc
Although, this may not be the most efficient way of using DB2, it certainly saves the programmer messing around trying to convert PACKED DECIMAL to a double or float data type and also saves the organisation in investing in a new language environment (sorry IBM, another lost sale!)"
Bruce Klenk of Programart Corporation in Cambridge, MA, USA writes
"I would like to receive the C/370 Compiler News and also inform you of our product, STROBE (2)
STROBE pinpoints the causes of excessive time and resource consumption in online and batch applications running in MVS."
Thanks Bruce, and please accept our apologies for the omission.
For those of you in the Atlanta area or for those of you fortunate enough to go to GUIDE in Atlanta, we invite you to come out, ask questions and tell your requirements directly to the C/370 development team.
Listed below are some of the C/370 related sessions. Please check the GUIDE agenda for sessions dates/times as they were not available at press time for this newsletter.
Although relatively new, C/370 is rapidly becoming the compiler of choice for the mainframe application development that is so critical to many companies. Find out why 'open' languages such as this are so important to customers and how you too can leverage this popular, powerful language for your mainframe application and assembler-replacement needs.
Recent trends in computing have led to a major dependence on object-oriented programming languages and applications. The C Set++ family of products addresses this need with class libraries and cross-system application portability. This session will help you understand the product family and what application portability could mean to your development shop.
Reports of the death of the mainframe were premature. In fact, there is increased demand in this market for not only the systems, but for the C/C++ languages as well. You've told us what you want; here's what we have lined up so far, and where we intend to go with it. If we've missed something, this would be a good opportunity to tell us.
For those of you in the Los Angeles area, we will also be at SHARE-84 in March, 1995. More details on that in the next C/370 Compiler Newsletter.
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'd like answered, please send it to IBMMAIL(CAIBMRXZ) or INETC370 @ VNET.IBM.COM.
Question- PDSE Usage
I am accessing PDSEs from C/370 programs while attempting to do member level sharing and am encountering some problems. The scenario is as follows:
Task A "fopens" a PDSE member rb+ (binary file for read and write). Task B comes along and wants to "fopen" the same member rb (binary file for read) while Task A still has the member open. This all appears to work unless Task A has written to the member extending it in size >4KB and Task A & B are in different jobs (works if in same job) In this situation Task B ABENDS.
According to the PDSE Usage Guide on p.29 If a first job has a PDSE member open for OUTPUT and a second job trys to open the same member for INPUT then this should work.
What does an FOPEN rb+ translate into in terms of an MVS OPEN on that member? (input, output, update)
Answer
For FOPEN rb+, it means UPDATE an member (you cannot extend the member's length).
According to the manual: MVS/DFP Version 3 Release 2, Managing Non-VSAM Data Sets (document no. SC26-4557-0) p.141, under the topics "Sharing PDSEs", it says
Member Level Sharing......
.
.
UPDATE: If a version of a member is accessed by a DCB
open for update, it cannot be accessed by any other DCBs
open for input"
For further detail,
please refer to the manual mentioned above.
Question- Portability
How portable is C code between MVS, OS/2, and AIX platforms? I am a COBOL person. Please enlighten me.
Answer
C is a portable, procedural-based programming language that is designed for general-purpose programming tasks including low-level system programming. The C run-time library (C RTL) consists of functions for I/O, mathematics, string manipulation, system and memory management, etc ... The use of the RTL makes a C program more portable since the function interfaces remain the same even though the underlying low-level implementations are different in different machine architectures. There are currently two most widely adopted standards for C known as K&R C and ANSI C. Typically, portability problems arise in porting programs written in K&R C (weakly-typed) to the more strongly-typed ANSI C. Common problems (usually minor) are function prototyping, initialized variables and types conversion. IBM extends the ANSI C standards further to SAA C. C programs developed natively using IBM compilers are therefore generally portable. Another common problem is unsupported library. For instant, C programs written specifically for OS/2 might make use of functions from the PM (Presentation Manager) system libraries. Certainly, these PM applications will not be portable to MVS or AIX. Similarly, for other system specific libraries that are not available in other platforms. On the other hand, user libraries that are written in C can be easily ported to other platforms by re-compiling the source. The latest IBM Open/MVS also allows C programs written for the UNIX environments to be easily compiled and executed on MVS as long as these programs comply to the POSIX standards.
Question- Gamma Function
Has anybody used the gamma function successfully? My small program fails with the strangest problem on VM.
/* Program: main */
main ()
{
float a,b;
a=1.7;
b= gamma(a);
printf("gamma of %f is %f\n",a,b);
}
Answer
You forgot to #include <math.h>.
Question- INSPECT
Answer
To let INSPECT recognize a compile unit name or source or listing or log, the PDS should be allocated and put in STEPLIB before invoking INSPECT. The following is a sample program:
For example,
Before invoking INSPECT, enter the following TSO commands to allocate and steplib datasets.
STEPLIB RESET
ALLOC FILE(MYSTEPL)
DSN('TSCTEST.V2R1M0.SEDCLINK'
'SYS1.V1R1M0.SEQALINK'
'TS12345.INSPECT.LOAD'
'TSCTEST.INSPECT.SOURCE') SHR REUSE
ALLOC FILE(INSPLOG)
DSN('TS12345.INSPECT.LOG') SHR REUSE
STEPLIB SET(MYSTEPL)
STEPLIB QUERY
Question- Packed data structures and performance
I have an application service routine which accepts data structures as parameters. The compiler adds pad to align the fields on the most efficient boundaries. Programs which call my service and are which are written in a language other than C/370 must be cognizant of the padding. I am considering packing my data structures to eliminate the padding. Does anyone know how performance may be impacted by packed data structures?
Answer
It's impossible to say what performance hit you would have - it depends on what is not aligned, how often you use it, and what it is used for. One thing to remember: whoever is passing this structure to you might also get a performance boost if you used natural 370 data type boundaries (which is what C/370 does when it pads structures).
If you do pass packed structures, make sure you pack the entire structure - for example:
struct Joe {
char a;
int b;
};
_Packed struct {
int char a;
struct Joe b; <------- not packed - 8 bytes in size
char c;
} a;
_Packed struct {
int char a;
_Packed struct Joe b; <------- packed - 5 bytes in size
char c;
} b;
Another suggestion is that you re-order the contents of your structures. Place the most strictly-aligned members first, and the least strictly aligned last. This alone may help reduce the size of the structure by minimizing the amount of inter-member padding, although it will probably still leave padding at the end of the struct. If you like, you can then pack the structure. By ordering your members in this way, you increase the probability that a member will (by chance) line up on its natural boundary, even if it is packed.
Question- fopen keywork parameters
While perusing the SAA C reference, I noticed that you can specify lrecl, recfm and blksize on fopen(), but there is no way to specify allocation size (primary, secondary, units) on fopen(). Am I right about this? And if so, is _dynalloc the only way to specify the allocation attributes of a dataset?
Answer
With C/370 V2R2 Library, and with LE V1R3, if you open by dataset name, you can now specify:
space=(unit,(primary,secondary),directory)
CYL n n n
TRK
or n
where n is a positive integer
See SC09-1841 or SC09-1840 (Chapter 9 in either one) for details.
Question- more fopen stuff
I can create a file, using fopen(), specifying recfm=U and lrecl=4000. In the C/370 Programming Reference, p199, there is a table specifying that when the file is created, the lrecl will be 4000, and that since the blksize wasn't specified, it will be 4000 also.
When I list this dataset with my code, it says that lrecl=blksize=4000. But if I use ISPF to show the information about this dataset, it says that lrecl=0 and blksize=4000. Why is ISPF not aware of the correct value for lrecl? I have to suspect that there is something that fopen isn't doing, but I don't know what it is....
Answer
Note that C/370 will reset your LRECL to 0 before opening the file. LRECL is meaningless for RECFM U.
Question- Character Definition
I'm just learning C and I'm trying to compile and run some programs from the SRA self study course on my local VM C/370 compiler. When I try declaring a character variable of length greater than one the complier returns the following error messages:
The character is not valid. Unexpected text integer constant ignored
The syntax I'm using to define the variable is as follows:
char name [7];
This is the same syntax used in the SRA text. What is the proper way, (if it's possible), to declare a character variable of length greater than one using the C/370 compiler?
Answer
It looks like the first message is referring to the character you have coded to represent the left bracket. The compiler did not recognize this character and ignored it. The integer intended to represent the array size then caused a syntax error. To confirm this, try the trigraph representation of the bracket characters:
char name??(7??);
If this works then you need to find a way to enter the brackets directly from your keyboard. The compiler recognizes hex AD and BD as the left and right bracket respectively.
Question- TTR Conversion
I have MVS/ESA 4.2 and C/370 2.0. I would like to know how to convert the TTR in a PDS directry entry to a number which can be passed to fseek?
Answer
PDS directory TTR is a relative track and record number for the starting location of a PDS member. 'Fseek' requires the byte offset within a file (in your case within a PDS member) that is already open. You cannot switch from PDS member to an alternate PDS member using 'Fseek'. If you want to switch to another member, you must use 'Fopen' or 'Freopen'. To use one DCB and POINT to a desired member at will you must use assembler.
Question- Packed decimal data in C
Has anyone dealt with packed decimal data in C? I have some old IMS data which has packed decimal data (where each byte represents two digits and last nybble is sign...'100C' could be 100 or 1.00). I am trying to avoid a lot of ugly code if someone can point me in the right direction. In PL/I this data is FIXED DECIMAL(x,x). Any help would be appreciated.
Answer
The packed decimal data type is available with the C/370 AD/Cycle 1.2 compiler that runs with either LE/370 version 1.3 run-time library or C/370 V2.2 run-time library. You must also include decimal.h header file.
The C/370 equivalent for PLI fix dec(n,p) is
decimal(n,p) var1;
where n is the number of digits
p is the precision.
In your example: 100.0 is the same as decimal(3,0)
1.00 is the same as decimal(3,2)
you can assign to a decimal variable as follows:
decimal(5,2) dec52 = 123.45d;
decimal(6,3) dec63 = -123.456d;
There is a complete chapter in the C/370 Programming guide(s).
Question- Code Page Mappings
I've been looking at the C/370 documentation , and I can't figure out which code page the C/370 compiler supports. I saw some code point mappings in an appendix to the IBM C/370 Programming Guide (SC09-1384-00). I looked at the 293 codepage (which happens to be the APL (USA) codepage) and I didn't see total compliance. For example, the code points x'8B' and x'9B' are supported by the C/370 compiler as curly braces. But, in the 293 codepage, those code points are in fact different characters (a downwards pointing arrow and a "U" on its side).
Answer
The C code point mappings were based on Code page 293 but there are some duplications due to historical reasons. All syntax significantly characters supported by C language are in there. The duplications such as 9B and D0 are treated as equivalents.
Question- Need help writing to tape!
I'm having a problem writing some data to tape. The data is mostly text but has some binary data in it (maybe that's the problem???). I am writing the data one byte at a time with fputc(). My DD statement for the file is:
//OUT DD DSN=LINEITEM.TBL,UNIT=3480,LABEL=(1,SL), // VOL=SER=P00917,DISP=(NEW,PASS), // DCB=(LRECL,223,RECFM=VB,BLKSIZE=32760)
My code looks like:
out = fopen("dd:out", "w,lrecl=223,recfm=VB,blksize=32760"); ... ... buf = (char*) malloc(32768); setvbuf(out, buf, _IOFBF, 32768); fputc() is returning an errno of 3 (Truncation of a record occurred during an I/O operation) on the 28th byte (a blank) of the 15th line of the data (the 2847th byte overall, including newlines). The data has varying lengths but no line is longer than 219 bytes. Help!
Answer
From your description, what you want is "wb,type=record". Build a complete record of the desired length in your own buffer, and call:
fwrite(buf, 1, len, fp);
You don't need to call setvbuf(), and you don't need a \n to indicate the end of line. fwrite() will just write a record of len bytes. This will be faster than the fputc() loop and will save you all that blank padding too.
Question- localtime
We have a simple program which used to display local time. But after we applied services to the C/370 Compiler+Library and AD/Cycle it now displayed GMT (or UTC). Can someone verify for me if this is unique to our installation? Or maybe there is an option we didn't set?
The program looks like this:
#include <time.h>
#include <stdio.h>
main(void)
{
struct tm *newtime;
time_t ltime;
time(<ime);
newtime = localtime(<ime);
printf("The date and time is %s",asctime(newtime));
}
Answer
Function localtime() converts a time_t value representing Universal Coordinated Time (UTC) into a broken down local time and returns it in the tm structure. It requires time zone difference and daylight saving information to convert UTC into an equivalent local time. The LC_TOD locale category is the only source of information that can be used to perform an accurate conversion. The time zone difference obtained from the system is only accurate for regions that do not observe daylight saving time, and only outside of the daylight saving range for regions that do. The reason is that the system provided local time includes daylight saving time shift, but there is no way to find out if daylight saving time is in effect. As a consequence, the results produced by C/370 V2.1 were incorrect in most cases (since most regions observe daylight saving time). This has been corrected by APAR PN49292 for the C/370 V2.1, which has been propagated to LE/370 V1.3 and C/370 V2.2. The fix requires that TNAME/timezone_name field in the LC_TOD locale category be set (default locales that are shipped with the product do not have this field set). This field must be set (e.g. "PST") even if the time zone difference is set to 1500, to force the time zone difference obtained from the system. Rather than continue to produce incorrect results when the TNAME/timezone_name field in the LC_TOD locale category is not set, the fix has altered the behavior of the localtime() function to return a UTC value (consistent for all time zones). This change in behavior requires locale customization, but is fair to users in all time zones (except, of course, those in the UTC time zone) as all are equally affected.
Question- float data type
I would like to try a client/server application between C/370 V2.1 application and MS-C application (under PC). However, my customer fails to handle float data from C/370 in MS-C application. MS-C supports IEEE-type float format.
Answer
C/370 doesn't support IEEE floating point formats. It uses the native 370 hex format for floating point, which of course would be incompatible with the IEEE formats used by MS.
Question- TCP/IP programming with C/370
I am currently coding some TCP/IP clients and servers to run on MVS hosts. I have a few questions.
Answer
Under LE/370 1.3, fork() and execve() are supported under OpenEdition/MVS. If you are using the C/370 Run-Time Libraries you can simulate these functions using the multitasking (MTF) facilities of C/370 as outlined below.
Question- Unable to use C/370 as a cross compiler
I compile my application under MVS, shipped the text deck to VM and use lked to build a loadlib. Under VM/ESA ® 1.1 it works, but not under VM/ESA 1.2 (I am using C/370 V210).
Answer
V210 does not support cross compiling. Cross compiling is supported with AD/Cycle C/370 V120.
Question- errno 3 (record truncation) on MVS
I can use my program to transfer a file from one VM system to another without problems. However, when I transfer the file to a MVS system, using the same attributes (binary tranfer, recfm V, lrecl 7943), I get errno=3 on an fwrite() call, and a comparison shows that the resulting file is 4 bytes shorter than the original. I am opening the file on both sides with "type=record". Any ideas?
Answer
On VM, a Variable lrecl refers to the data length of a record (i.e. V LRECL 70 means a variable file, largest record is 70 bytes). On MVS, LRECL for a variable file is slightly different because it contains a control block (known as an RDW) in its value. This control block which precedes every data record is 4 bytes long. Thus, if you were to specify an MVS V LRECL=70, you can only have 66 bytes of data.
In conclusion, add 4 to the VM LRECL to get the MVS V LRECL you must specify.
Question- Cobol invoking C and using long external names
We are writing C functions which will be invoked by Cobol and C programs. We have played around with the MAP and LINKAGE pragmas but with no success. I have a function as follows:
void my_function_name( long parm1 )
{
int x;
x = 1;
}
I would like to compile the above program into a link module, which then could be linked edited into my cobol program. Because the linkage editor only understand 8 characters, it seems that I must rename my function "my_function_name" to 8 characters or less. Then I could use the following statement in my function file: #pragma linkage( newname, COBOL ) Where "newname" is the 8 characters or less name of the function.
Answer
I'm not sure what experimenting you have done with #pragma map, but I wondered did you try including both:
#pragma map(my_function_name, "NEWNAME")
#pragma linkage(newname, COBOL)
in the C/370 source file, and then using my_function_name for
all calls within the C/370 source, and newname for the calls
from the COBOL program?
If you use newname() instead of my_function_name() for the name of the C function, do the calls work OK then, in the C program and the COBOL program?
The answer is described in the Programming Guide SC09-1384 in chapters 8, 11, and 42. Check out the LONGNAME compile option along with Prelinking Your Program (Ch.8), Creating an Object Library (Ch.8), and External Name Mapping (Ch.42).
In essence, you use LONGNAME to allow the long names in your object module and the C370LIB utility to create an object library which includes a directory member to map the long names to the members in which they are found (remember, the system has that same 8 character limit for members in a PDS). The Prelinker then maps the long names in your programs to short names the system can use for linking.
As for multiple functions within a single member, I'm guessing but I would expect it to work. It seems like just another way of describing a load module with multiple entry points.
Question- Comments past Column 72
I am compiling one of the APPC samples, AFILE, and it has comments which have the '*/' end of comment past column 72. This causes compiler errors. It was easy enough to move these over, but is there any compiler option to allow for this?
Answer
For recfm v files, you can have code and comments past column 72. For recfm f, code and comments must be in columns 1 - 72. The latter defaults are controlled by the MARGINS compiler option. You have to change SEQUENCE option as well. Try NOMARGINS NOSEQUENCE.
Question- Missing file I/O functions?
There are some file I/O functions like open(), read(), write(), lseek() etc. next to the standard fopen(), fread(), fwrite() etc.
Those functions are available on msdos, os/2, unix, vms, windows and other well known operating systems BUT not in C/370 on VM/CMS or MVS! (Those functions are coming with the include files io.h and fcntl.h) So here are my questions:
Thank you for your support!
Answer
We took the view originally that if it isn't ANSI, it isn't portable. Since ANSI wasn't complete in its definition of the language (from a user perspective), we added IBM extensions to the language. open() et al were not on the list of extensions that we chose to implement, partly because of the different nature of return types, etc.
Customers told us they wanted an 'open' version of C to be available on an 'open' MVS system. We implemented the POSIX-compliant AD/Cycle C/370 V1R2 with either LE/370 V1R3 or our V2R2 runtime with open() et al to run under OpenEdition MVS, with access to the Hierarchical File System (HFS) only. As we desire to be as portable as we (reasonably) can, it made sense to allow HFS-like applications to port to MVS as easily as possible. For new applications, it made sense to try to get everyone using the truly portable f-series functions (ANSI-defined), but allow them access to the HFS through those functions.
To get to open() etc., you can use AD/Cycle C/370 Compiler V1.2 and IBM's common library-based V2R2 or LE/370 V1R3 runtime libraries to get the truly integrated solution.
Question- When is EOF raised?
Answer
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. If you prefer, mail or fax your business card to the address/phone number on the Reader's Comment Form. You can also subscribe to this newsletter on INTERNET. Just 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).
For the many of you sending in the reply forms with your comments, we may need to call you to discuss your comments further. 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. 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 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, 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-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.
(1) POSIX is a trade-mark of Institute of Electrical & Electronic Engineers.
(2) STROBE is a registered trade-mark of Programart Corporation.