IBM Corp 1995
370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370
370 370 370
370 370 370
370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 370 370 370
370 370 370 370 370 370 370 370 370 370 370 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
April 1995 Volume 3 Number 2
Welcome to the April, 1995 Issue of the C/370 Newsletter
Three important announcements from IBM for C/C++ developers have occurred so far this year. C++ for MVS/ESA(TM) is available, Object Oriented Programming on MVS and VisualAge(TM) C++ for OS/2 (TM), Version 3 have been announced. They're all described here.
The IBM C/C++ for MVS/ESA compiler is a state-of-the-art C and C++ development environment. Programmers can create, modify, test and debug C (C/MVS(TM)) or C++ (C++/MVS(TM)) applications.
The environment combines the C/370 technology with the object-oriented technology found in the C Set ++(TM) family of products. Since C/C++ for MVS/ESA is based on C/370, developers are assured of high-quality, mission-critical applications. Since it supports object-oriented technology, application programmers can reuse existing C++ objects to quickly create and modify applications.
C/C++ for MVS/ESA is a key product for the open, distributed MVS environment. C/MVS programs can use TCP/IP facilities for client/server and distributed application execution. In addition, OpenEdition(TM) MVS facilities, including the Distributed Computing Environment (DCE) Remote Procedure Call (RPC), are available with C/MVS in conjunction with the Language Environment.
C/C++ for MVS/ESA interlanguage call support allows use of functions written in assembler, COBOL, or PL/I. C/C++ for MVS/ESA provides access to data through DATABASE 2®, IMS/ESA(TM), the ability to invoke Query Management Facility(QMF(TM)) Services and transaction processing under IMS(TM) and CICS/ESA(TM).
C/C++ for MVS/ESA complements the existing set of C Set ++ products: C Set ++ for OS/2(TM), C Set ++ for AIX(TM), C Set ++ for Solaris(1). and C Set ++ for OS/400 (TM). Most C and C++ applications created with these products will behave consistently across all supported workstation and mainframe platforms. The source code will be portable between platforms. Programmers can choose both development and execution environments independently.
The IBM C Set ++ family support for language standards also enables code portability. The C/MVS compiler conforms to:
System Object Model (SOM) is an architecture for defining and managing binary object class libraries. With SOMobjects(TM) for MVS, C and C++ applications can be written using headers generated by the SOM Interface Definition Language (IDL).
Using the C++ Direct-to-SOM (DTS) feature, a C++ programmer can generate SOM objects directly from C++ without generating and processing the SOM IDL. DTS support simplifies the development of SOM applications. Programmers can write the same code in C++ and the compiler generates SOM objects.
Using DTS, programmers can write C++ code while exploiting SOM features, such as binary compatibility of application class libraries and objects and convenient coding of SOM-based objects.
With its base set of class libraries, C/C++ for MVS/ESA provides a consistent starting point for developers to build tailored objects for their applications. With this set of class libraries, development teams can quickly build objects that are reusable across projects.
The class libraries in C++/MVS far exceed those offered by other MVS C++ vendors. The libraries are consistent with those delivered in other members of the IBM C Set ++ family. They include:
View input and output (I/O) independent of physical I/O devices or data types. Using the I/O Stream Library can improve the maintainability and performance of programs that use I/O.
Manipulate and perform standard mathematical operations on complex numbers.
Use data abstraction to implement a wide variety of common data structures such as stack, tree, list, hash table and so on. With the Collection Class Library (CCL), programs can be developed starting with a high level of abstraction. Later on, the appropriate concrete implementation for an abstract data type can be selected. The 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.
Use the basic abstractions such as Date, String, and Time.
C/C++ for MVS/ESA enables programmers to build dynamic link libraries (DLLs). Programmers can use DLLs to split their applications into smaller units and direct these units to be loaded only when required. Programmers have more options to build, package, and redistribute their applications. DLLs also reduce load module size.
Programmers can eliminate coding errors faster by using the interactive mainframe debugging tool to debug applications in their native environment. The Debug Tool provides the following support and function for C applications with extensions for C++ syntax:
The C/MVS CHECKOUT facility to identifies potential problems and common programming errors quickly. The C++/MVS SRCMSG option instructs the compiler to include C++/MVS source lines with their diagnostic messages.
The OpenEdition MVS debugger, dbx, an optional feature of the MVS/ESA SP Version 5 product, provides debugging support for C/MVS applications running in the OpenEdition MVS environment.
Many thanks to the customers who participated in the C/C++ Joint Customer Study. The feedback from customers has been very positive. For example, Rich Way of Diversified Software Systems, Inc of Morgan Hill, California who develop JOB/SCAN(5), DOCU/TEXT(5), and INFO/X(5) ( ) says
"Having run both the IBM and another vendor's mainframe C++ product, we can say that IBM's implementation of C++ for the mainframe is significantly speedier than the other vendor's. Without the IBM product, continued development of this project would possibly not have been even feasible. In addition, we encountered no compatibility problems migrating C++ code from OS/2 to MVS. Everything compiled as coded. We are using some advanced C++ features and were very happy to find that those features worked identically in C/SET ++ for OS/2 and the MVS C++ product. Clearly IBM has proved that object technology has arrived on the mainframe. IBM C++ for MVS is a well designed, efficiently implemented product that we heartily recommend."
To learn more about IBM C/C++ for MVS/ESA, contact your IBM marketing representative or your local IBM office. If you have access to the Internet, you can find general information about IBM at the following World Wide Web address: "http://www.ibm.com". For more specific information on this announcement send an e-mail message to: "ibmc370@vnet.ibm.com".
Today's complex business environment has created an even more complex application development environment. Client/server and open computing demands, cost reductions, skills shortages, new technologies, and other factors add up to greater demands on application developers. To meet these demands many organizations have turned to object-oriented (OO) technology which provides the ability to:
With the IBM announcement of object-oriented technology for MVS, your enterprise can begin to realize the advantages of this productive new technology on its most powerful, high-performance platform. In fact, when object-oriented technology is combined with the robust characteristics of the MVS platform - integrity, availability, security, capacity and performance - it can actually enhance the value of your MVS investment. This combination also enables MVS programmers to develop new applications using OO technology while offering them the choice of host or client/server-based development models.
IBM's delivery of object technology for MVS will be an ongoing process. The initial stage introduces several key elements:
As in many enterprises, your application developers probably use a variety of programming languages. IBM will provide support for several key programming languages enabling the language that best fits your development environment.
Here are the language and tool offerings included in the initial stage.
You can use any of the products mentioned above to develop object-oriented C/C++ code, using many of the available class libraries and SOM, and then send the source to MVS to be compiled, fully tested and executed. Native MVS tools can also be used, such as ISPF for editing and the C/C++ interactive debugger which allows your programmers to debug applications in native MVS environments such as CICS/ESA or IMS/ESA.
To help deliver these capabilities, the next release of IBM COBOL for MVS, formerly IBM COBOL/370(TM), will include:
IBM COBOL for OS/2 provides a set of workstation-based tools to facilitate application development. If you use COBOL to develop SOMobjects for MVS applications, you can use these COBOL workstation-based tools in conjunction with the IBM COBOL compiler for MVS to support the applications.
As part of its continuing commitment to object-oriented technology, IBM plans to provide Smalltalk for MVS. This Smalltalk implementation will be designed to exploit SOM technology on MVS to ease reuse of object classes and interoperability across programming languages.
VisualAge is a client/server, object-oriented power tool designed to maximize programmer productivity. It combines OO technology with the simplicity of visually connecting prefabricated software components to facilitate rapid development of the client portion of client/server applications. Being a fully integrated solution, it eases the transition into object-oriented technology.
VisualAge is currently available on OS/2 and Windows(6) platforms. ( ) It can use both local and remote SOM objects, their location is transparent to the VisualAge application developer. IBM intends to further enhance the exploitation of SOM technology by providing the ability to use SOM objects that reside on an MVS system.
One of the keys to object-oriented programming on MVS will be SOMobjects for MVS. This product uses IBM's System Object Model as its architecture of defining and managing binary object class libraries.
SOMobjects for MVS allows applications written in different languages to use a common class library, while it libraries can be extended without affecting existing applications. As a result, programs can incorporate objects written in another language.
SOMobjects for MVS works with the programming languages to deliver the advantages of object-oriented programming, such as:
As a result, SOMobjects for MVS:
SOMobjects for MVS applications will run in the CICS(TM), IMS(TM) APPC, Batch and TSO environments.
As client/server computing becomes more important, it is critical for applications to be able to communicate and share data across platforms. In a subsequent stage, Distributed SOM (DSOM), will extend the power of SOMobjects for MVS, allowing applications to access and share objects that reside in different systems. What's more, location and implementation of the object are transparent to the user, since the client accesses the object as if it was stored locally.
To facilitate these capabilities, SOMobjects for MVS and DSOM will comply with industry-standard CORBA specifications defined by the Object Management Group.
IBM is offering a starter set of objects and several types of class library support on MVS. Among these are:
Over time, additional cross-industry and industry-specific classes will be provided.
The potential benefits of object technology on MVS are many. For example, you can enjoy more effective solutions to your business problems, reduced application backlog, reduced cost of application development and maintenance, accelerated time to market, the capability to reuse applications and construct new ones from existing components, and more. To learn more about object technology on MVS contact your IBM marketing representative. If you have access to the Internet, you can find additional information on IBM's World-Wide Web server at "www.ibm.com".
VisualAge C++ for OS/2? What happened to C Set ++ ?!!
The name of Version 3 has been changed to highlight the arrival of the next generation of C & C++ application development. New and very powerful visual programming tools are introduced. Many of the tools from C Set ++ have been completely re-written to make them faster and easier to use. The visual builder, data access builder, compiler, browser, editor, debugger, and performance analyzer work seamlessly together and are designed to help you through each stage of the development process.
With Visual Builder, you can rapidly prototype and build complete OS/2 applications, with all standard OS/2 controls such as menu bars, listboxes, etc, but in addition the builder lets you use the sophisticated IBM Open Class library extensions, such as canvases and graphic pushbuttons.
This advanced, but easy to use, object-oriented visual application development tool goes beyond the scope of a simple GUI builder. A powerful visual editor enables you to create complete applications, often without writing code. The builder provides an extensive library of prefabricated parts, and C++ language support for creating new parts.
The visual builder can connect the graphical interface to the application logic and data as well as generating the C++ source code.
The visual builder's capabilities are not limited to using just the supplied prefabricated parts. You can add your own reusable code to the parts palette or import/export parts from other applications. The parts are treated as classes by the visual builder. By developing a library of your unique parts, large and complex applications can be created simply by visually arranging and connecting parts.
The visual builder realizes the advantages of OO programming, the ability to reduce programming time and improve code quality, by making it easy and practical to reuse components.
The Data Access Builder allows you to create new object-oriented database applications quickly and reliably by generating the source code and embedded SQL for you. Add, update, delete, and retrieve methods are generated for each class.
These database parts can be used directly, or you can import them into the visual builder. By using visual builder to connect them to the GUI, or other parts, you can create high quality applications quickly. Some of the key features of Data Access Builder are:
The IBM Open Class Library supports consistent programming interfaces across the entire range of platforms supported by C Set ++; OS/2, AIX, Solaris and MVS/ESA. This makes cross-platform porting faster, easier and less error prone. And the C Set ++ family is growing. We'll soon be starting C Set ++ beta programs for Windows, OS/400, and the PowerPC. When re-compiling your application on different platforms, you don't need to modify source statements written to use the classes and member functions in the IBM Open Class Library. Use the powerful programming abstractions in the IBM Open Class Library rather than the system specific APIs.
The four parts of the IBM Open Class Library are:
The introduction of the OO paradigm in C++ has resulted in a marked shift in programming techniques and requirements. A C programmer deals with large collections of modules, data types, or functions. A C++ programmer deals with large and complex collections of interrelated classes in class libraries. The Browser helps you understand and use these class libraries with the following features:
A new and impressive editor has been integrated into VisualAge's suite of tools. This editor is fast, simple to use, powerful, helpful, and easily modified to meet your personal preferences.
You can compile, browse, make, build, debug or issue VisualAge commands without leaving the editor. It performs all the common editing tasks such as insert, delete, split and join lines, find, block and manipulate text, or undo changes, create and find marks, and move between different source file views. However, it does much more to make programming simple and error free:
Applications that perform well require tools that generate highly optimized code and make efficient use of disk and memory space. The compiler and linker represent state-of-the-art technology; the applications you write will be fast and won't 'hog' your systems resource. Code can be optimized for any Intel(7) architecture processor from the 386 to the Pentium(7). ( )
However, the benefits of efficient code can be reduced by inefficient use of memory resources. The new memory management algorithms used in the C and C++ runtimes are highly efficient in reducing the amount of memory overhead in your program.
VisualAge C++ now offers an "optimize for size" option that minimizes the size of the code produced, but still runs quickly. Disk space can also be reduced with our smart linking support that will remove unused code from your executable. Our new debug packing support can reduce the size of debug-ready executables.
Performance of applications is important, but you don't want to wait for a slow development environment. The compiler and linker are fast and highly usable. Compile time performance has been improved, especially with the use of precompiled headers. Also, our new 32-bit ILINK linker with automatic template resolution (without prelinking) can cut link times in half.
Memory leaks are a common problem in C and C++ programming, and very difficult to diagnose. We've enhanced our memory debugging support to help you find those persistent problems. VisualAge C++ V3 includes support for user heaps to give even more flexibility in implementing applications.
Direct-to-SOM (DTS) is an exciting new technology that combines familiar and powerful standard C++ syntax with the robustness and portability of IBM's System Object Model (SOM). DTS is a standard for implementing flexible and reusable objects, supported by the tools of VisualAge C++.
To build a SOM object, it was necessary to go through the time consuming process of:
DTS has several advantages over "native" C++ programs:
The experienced SOM user will welcome the power and flexibility that DTS provides. And, because you write C++ directly, you can use C++ features in your SOM classes that weren't available before DTS; features like templates, operators, constructors with parameters, default parameters, static members, and more.
This tool enables you to time and tune your applications, analyze program hangs and deadlocks, view multi thread interactions, and better understand your code. It gives you a view of your program's runtime behavior you just can't get through debuggers or browsers. By collecting execution trace data and presenting it in several graphical diagrams, Execution Trace Analyser can provide information on:
Efficiency comes from debugging at the source level which means that you can look at your code exactly as you wrote it and from an optimized user interface that provides access to all the common debugger functions with a single mouse click. These include step, run, set/reset breakpoints, monitor variables, display call stack, display registers, and display storage. The Debugger provides built-in tools to help locate problems and fix code quickly:
VisualAge C++ comes with clear, well-written online documentation, including examples and programming tips. User's Guides and reference information are provided for all the tools, languages, libraries, and APIs. All VisualAge manuals are online, with a powerful look-up tool to guide you to what you want to know. For example, when you need help for language keywords or library APIs, we can take you right to its description in the reference manuals. Just put your cursor on the word, and press CTRL-H.
VisualAge C++ for OS/2 is currently in beta release. The GA version will be available shortly. For more information, call 1-800-3IBMOS2.
Come and talk to the developers of mainframe C/C++ at GUIDE in Boston during July 16-21 and at SHARE in Orlando during August 13-18. Check the appropriate calendar for session numbers. The sessions currently planned are:
The information processing business has never been more complicated. We're trying to deliver products and related tools to help you simplify it. Come and hear what changes we've made, and are making, with C and C++, how C/C++ for MVS/ESA works with other products, and how you can leverage these powerful languages to satisfy your business needs across a variety of platforms.
C and C++ are known for their portability, but since the underlying operating systems are different, there may be changes to make to your applications to allow them to run on the mainframe. There are also a number of extensions to ANSI standards that could save you time and effort. If you're doing application porting to the mainframe, and want some coaching, please come and see us.
C and C++ have a number of capabilities that you can't always pick up on, except by using them. Since we use these languages and tools every day ourselves, we can show you real code to do what you need to do. There a number of 'tricks' to make your code run faster, as well as minimize maintenance costs.
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. We'll answer your question and perhaps print your question and answer in the next newsletter.
Question- dynalloc support ?
I am compiling a module using the C/370 compiler which I would like to use on any system which has either the C/370 V2R1/R2 or LE/370 R2/R3 libraries. So far I believe my load module is compatible with any of these libraries. I now need to utilize the dynalloc function. Does this function utilize any C/370 library routines? If so, are they compatible across the versions I have indicated?
Answer
dynalloc() IS a C/370 library routine.
From the AD/Cycle C/370 Library Reference (SC09-1761-00), under "dynalloc()":
"The __dyn_t structure has been changed for C/370 Library Version 2 Release 2, and for LE/370 Release 3. Code compiled with previous releases will still run correctly with the new libraries. However, because additional fields have been added to the __dyn_t structure, you should recompile existing source code with the latest dynit.h header file to access the new fields."
You may also want to look at the AD/Cycle C/370 Migration Guide (SC09-1359-03) for info on load module compatibility.
In general, C/370 load modules are upwardly compatible i.e., compile/link with version/release x, run on x and later version/releases. There are some special cases which require recompile/relink, although yours sounds ok.
In general, C/370 load modules are not downwardly compatible, i.e., compile/link with the latest, load module will not run on earlier versions (see TARGET(COMPAT) compile-time option for more on this).
Question- printf in the called function
I am "upsizing" a big chunk of C code (68 modules) from OS/2 to C/370 on MVS and I discovered that the printf outputs the printf variable of main() or fprintf does not write anything.
When I compile, I do a prelink and link NCAL and then do a general link of all 68 modules into one program. So I have no OBJ library, everything is stored as a member of the LOAD.
I thought I had found a solution, compile all 67 called modules as RENT and the main() as NORENT. This has worked, but after a few compiles and link, printf's and fprintf's do not show up anymore.
Answer
The prelinker need only be invoked when the either compiler options RENT or LONGNAME is used on the compile step. If you mix object decks with some compiled RENT and some compiled NORENT unpredictable things may occur. For an individual application compile all C source files with the same rent setting.
Question- User header files as system headers
What is IBM's position on defining user header files as system header files, i.e. ??=include <myhdr.h> ?
I'm running AD/Cycle C/370 1.2 with LE 1.3 under MVS and have been plagued with users defining their header files as: include <myhdr.h>. These user header file datasets have a RECFM of VB. Because they're defined as system headers, they must concatenate their header files to the products SEDCDHDR dataset, using the SYSLIB DDname (which is installed RECFM=FB and must be copied to RECFM=VB in order to support the users RECFM=VB header file dataset).
This incompatibility may cause:
What are the supported recommendations for:
Answer
Users should always include their user headers with "...". Library providers use <...> to include header files and they should use FB 80 format when creating header files (TCP/IP is an example of a library that expects to be included with <...>). In addition, I would strongly recommend that library providers either put all their code in columns 1-72, or that they put #pragma nomargins nosequence at the top of all their library header files.
When in doubt, use "..." to include header files, since the user includes will be searched first, followed by the system includes if necessary. For instance, #include "stdio.h" would be able to include the library header file stdio.h, as long as you didn't have your own stdio.h that would get picked up first.
Question- itoa() library function
I was unable to find any reference to the itoa() library function in either of the C/370 or AD/Cycle C/370 books. Is this function available on MVS?
Answer
It's not an ANSI C function and is not an IBM extension to ANSI, so it's not in C/370. Try sprintf().
Question- errno=91 after fopen
This code is failing with errno=91:
/* errno = 91 after fopen */
#include <stdio.h>
#include <errno.h>
main()
{
FILE *fp;
if ((fp = fopen("dd:HUGO","w")) == NULL) printf("Error %d - %s ??/n",errno,strerror(errno)); else printf("Open ok??/n"); } I use JCL like this to get to ESF (Extended Spooling Facility):
This JCL works fine with MVS utility IEBGENER, so it is valid in this environment.
I do not see any MVS messages (IEC...) so probably MVS never was asked to do the open. Errno 91 translates to
"Unable to perform function due to failure of a system utility"
Changing the JCL (no DEST, or output to disk) the error disappears. I was unable to recreate errno=91 on an IBM system, I suspect this might be related to the MVS environment.
Can you please explain under what circumstances errno is set to "91"?
Answer
The error indicates a system utility has unexpectedly failed. This would be due to the user using a subsystem. The C RTL has had APARs in the past related to the use of SUBSYS references. Better check to find the PTFs for your release of C (simply look for the keyword SUBSYS).
Question- QSAM vs BSAM file I/O
Anyone have any ideas on how to specify file I/O methods on MVS when doing an fopen? We've got several programs that read and write large files and these programs take over an hour of elapsed time to run in batch mode. Strobing these jobs revealed that between 40 and 60% of the elapsed time spent by them was in file i/o, specifically a system function "BSAM CHECK ALL". I was told that QSAM file i/o was quicker then BSAM. Is it possible to specify access type with fopen or any other method? Let me describe what our programs are doing. They perform sequential i/o of one fairly large file, with no fancy fseek, fsetpos, etc. type calls. The only mode parameter being specified to fopen is either "rb" or "wb". The JCL specifies recfm=FB in the dcb and we let the system default the block size for the output file.
Answer
If you're running on V2R2 or LE V1R3, try the "noseek" parameter, e. g.,
fp = fopen("my.file", "r+,NOSEEK");
See NOSEEK and Multiple Buffering in the Programming Guide for more info.
Your application does sound like QSAM would help you. Unfortunately,
"NOSEEK" in V2R1 doesn't have QSAM support - it was added to the
"NOSEEK" logic in V2R2 / LE13.
Question- Elapsed time in microseconds
This is my problem: I need to get the elapsed time in microseconds, starting from a given date and time.
The C SET/2 FTIME function gets the current time and stores it in a structure that gives the time in seconds since 00:00:00 GMT, Jan 1, 1970 and the fraction of milliseconds.
I need to know if AD/Cycle C/370 provides a function or a combination of functions that act as the C set/2 ftime function.
Even a function providing milliseconds, instead of microseconds, is acceptable to me.
Answer
AD/Cycle C/370 provides a function time() which does the same thing, but without the fraction of milliseconds. CEELOCT Service in Language Environment/370 which is callable by AD/Cycle C/370 applications provides the time as a 17 byte fixed-length character string in the form YYYYMMDDHHMISS999 representing local year, month, day, hour, minute, second and millisecond.
Question- Build a load module with same name
I am trying to create a C/370 load module that has functions a(P1,P2) and A(P1,P2,P3) the former is the external C-language api and the later is the corresponding COBOL/370 api. So far I have been unsuccessful in creating a load-module that when linked with a C/370, and a COBOL/370 test programs work correctly. If I create a load-module with both functions and try to linkedit and GO the two different language test programs, the C-language test case abends and if I comment out the A(P1,P2,P3) function the C-language testcase works and obviously the COBOL-language test case abends. I was able to rename A(P1,P2,P3) to AX(P1,P2,P3) and get both testcases to successfully execute.
I have a urgent need to get this code working from both languages with the same named api. Any sample JCL or required parameters etc will help.
Answer
What you need to do is use the LONGNAME compile-time option, which will preserve the case of your external names. Then, you need to prelink _all_ your text decks (excluding the COBOL decks) into one resultant text deck, which can then be linked with your COBOL code. This is required because the S/370 linker does not support long enough names for C/370 (C can have names up to 1024 characters long) and because the linker does not support mixed case names (so, in your case, a() and A() are being mapped to the same name. If you're still having problems, use the #pragma map directive so that the prelinker knows to leave your A() function alone, e.g.
Question- DSECT utility
Does anybody know if IBM/TPF have published anything on the use of the AD/CYCLE DSECT conversion utility?
I have been experimenting with the vanilla proc provided with the the MVS version of the compiler and it seems to work fine (as far as I can judge from very simple dsect/struct examples). While I understand the AD/CYCLE User guide explanations of options etc., I am not clear on what is relevant to TPF usage. A JCL example specifically for TPF would be welcome, if anybody would care to post one here.
Answer
The DSECT conversion utility comes with the C runtime ... it actually has nothing to do with TPF. The purpose of the utility is to help bridge the gap between assembler and C/370 programs. The utility will convert your assembler DSECTS into the corresponding C/370 structures required so that programs can converse, and, ultimately, have C code replace assembler code, where appropriate.
Question- Character Limits on Operands passed to CC EXEC
I'm using the VM/CMS C/370 V2R1 compiler (CC EXEC) and have encountered what appears to be a 256 character limit on the operands passed to the CC EXEC. I think this is because CC EXEC passes its operands to the EDCC210 module, which appears to be coded in C, and so is presumably subject to the 256-char limit on arguments passed to main(), documented in the C/370 Programming Guide.
What I can't find documented is the fact that this restriction exists on the CC command. Can anyone confirm that this is the case, and is it written down anywhere? Also, is there any general way of getting around it?
What I'm doing at the moment is passing all operands through another exec which compresses them to their minimum abbreviation, and deletes them altogether if they are the default value. This works, but is unsatisfactory because it is still possible to produce a well-formed (ie conforming to the documentation) list of operands (eg including lots of options and complex SEARCH and LSEARCH paths) which it is not possible to compress to 256 characters.
Answer
If you have a look at the C/370 Programming Guide (SC09-1384) in chapter 42 (system/370 extensions to SAA C), you will find the statement:
"There is a 256-character limit to the length of all the arguments passed to main in argv."
under the 'Command-Line Arguments' heading.
The compiler is written in C/370 also, and hence has the same limitations that the rest of the world has in parm length (ie. argv).
We do have #pragma options( ... ) that will accept a limited number of compilation options (see same chapter as noted above). This may not be of a great deal of help, depending on the options you choose. I presume you are already using the shortest form of each of the options, but you may want to have a look at this pragma as well.
Question- C/370 as an assembler substitute
Does anyone have an opinion on whether C/370 is a viable substitute for 370 assembler language? I'm thinking of MVS systems programming tasks such as writing exits and programs using MVS macros. Thanks.
Answer
C/370 has several system programming capabilities. First off, there is a compiler option (NOSTART) that will generate object code without the usual CEESTART entry point. You then have a choice of three different entry points to insert:
There are also 4 routines for persistent C environments:
There is no support for direct insertion of assembler code, due to the nature of our code generation routines, optimizations, etc., however the persistent C routines could prove very useful when you are using assembler to drive C.
Further details can be found in the C/370 Programming Guide, Chapter 46 .
Question- Passing pointer parameter from PL/I to C
I'm trying to pass a pointer parameter from PL/I to C and found table 75 in the Programming Guide. Code looks like
#pragma linkage (centry,PLI)
struct date ??(
int day;
int month;
int year; ??);
void centry(struct date **k)
??(
/* how do i address structure date here??? */
??)
Unfortunately this sample does not show how to access the passed structure within the c program. I could not figure out a printf statement to show the values passed from PL/I.
Answer
De-reference K pointer once and then use the arrow operator
(*k)->day = 123;
(*k)->month= 03 ;
Question- CPU instructions to execute C/370
Are there any IBM measurements of the performance of C/370 instructions, eg CPU instructions to execute typical C/370 commands, please? I come from a performance-sensitive Assembler background. I plan to measure the performance of my C/370 applications quite closely.
Answer
If you would like to know PRECISELY what assembler instructions are used for their program code (not our library code, of course), you can make use of the SOURCE and LIST options. SOURCE will show you the C source listing, while LIST will give a pseudo-assembly listing of the program.
This will tell you what instructions we generate. At the bottom of the list is a summary for the entire compile unit with counts for the number of instances of each instruction that we use.
When using this information, please keep in mind that it is NOT A PROGRAMMABLE INTERFACE, but can be used to know what we're generating for any given C statement. It may or may not be what your assembler programmers consider to be 'slick', but then it is not intended to be so. We do some things that might be considered to be wasteful, but in some cases are necessary for the support that we offer with other products, etc.
Question- getchar and putchar in loop
I keyed in a small example program and ran it in VM/CMS. This program uses getchar and putchar and seems to be in a loop. The program is:
main()
{
int c;
c = getchar();
while (c != EOF) {
putchar(c);
c = getchar();
}
}
For some reason when I run this, it never seems to hit EOF. It just keeps expecting more input.
Any help or thoughts appreciated !!
Answer
As foreground processing presents a 'unlimited length' file, you must indicate the end-of-file yourself. This is done by entering a slash, followed by an asterisk (/*) as the 'single character' to be read.
In your example (attached), you would enter the 3 characters x,y,z by:
x <enter>
y <enter>
z <enter>
/* <enter>
The slash-asterisk tells our library routine to set the end-of-file indicator, without passing the slash-asterisk to your program. The situation doesn't come up when processing 'regular files' because the system is able to tell when the end of file is reached - foreground EOF is a choice made by the user - totally beyond system (or our) control. The C language itself is rather byte-oriented - carriage returns, line feeds, etc. can be processed directly.
Question- Calling C functions from assembler
I am trying to call C functions from assembler routines. Do you have any hints or tips to get me started?
Answer
Below is a chunk of code, as well as the corresponding assembler code, to make a call from C to assembler, then assembler to C, and return to the original C program. I hope this helps ...
/* C code */
#include <stdlib.h>
#include <stdio.h>
/* callprtf is assembler code, called by C */
#pragma linkage(callprtf,OS);
/* PRINTF4 is C code called by assembler */
#pragma linkage(PRINTF4,OS);
int main(void) {
int testval=513;
callprtf("replacement format %d\n",testval);
}
int PRINTF4(char * str, int i) {
return printf(str,i);
}
/* ASM Code */
CALLPRTF CSECT
EDCPRLG * C/370 prolog
*
* passing two pointers from C:
* first is address of formatting string,
* second is pointer to replacement integer value
* for INTVAL. To ignore parms altogether, remove
* or comment out the lines between NS and NE
*NS
L 4,0(,1)
L 2,0(,4)
ST 4,ADDR_BLK
*
L 4,4(,1)
L 2,0(,4)
ST 2,INTVAL
*NE
LA 1,ADDR_BLK
L 15,=V(PRINTF4)
BALR 14,15
*
EDCEPIL * C/370 epilog
*
ADDR_BLK DC A(FMTSTR)
DC A(X'80000000'+INTVAL) * HOB - end of parm list
FMTSTR DC C'Sample formatting string'
DC C' which includes an int -- %d --'
DC AL1(NEWLINE,NEWLINE)
DC C'and two newline characters'
DC AL1(NULL)
INTVAL DC F'252'
NULL EQU X'00'
NEWLINE EQU X'15'
END
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 almost 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 via 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 bring 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 1995. In Canada - © Copyright IBM Canada Ltd. 1995. +------------------------------------------------------------------+
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
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, unless otherwise indicated.
(5) JOB/SCAN and INFO/X are trademarks of and DOCU/TEXT is a registered trademark of Diversified Software Systems, Inc
( ) (6) Windows is a trademark of Microsoft Corporation
( ) (7) Intel and Pentium are trademarks of Intel Corp.