Commercial Computing with C/C++

5 Posts tagged with the zos tag
2

This is my first post on our C/C++ Cafe that has been long in coming.

If you are like me, then you are a new zOS programmer. The learning ride has been quite turbulent and there are ways to go yet. If you are a devoted programmer then you feel quiet excitement of your new program almost working, tempered by the chance of another large manual being 'thrown' at you. zOS is one of those products that has too much of a good thing, that is there is a LOT of documentation. This fact very quickly becomes an advantage as one gains more experience.

No matter what design patterns you use, almost as soon as you start writing code, you will need to include other files, be it either your own include files or third party libraries. For efficiency purposes, these files will in all likelihood reside in datasets. To make things more interesting, the documentation might instruct to use directory based (HFS) #include, confusing the new-comers as to where files reside.

I want to discuss two tasks that come up when dealing with include files:

  • Finding the include files
  • Dealing with preprocessor macros

If the compiler already found the include file (i.e. successful
compile) and you are interested where the file is located (i.e. which version of the library you are actually using), both -qlist and
-qsource produce an includes section.

#Will list all included files:
xlc -qsource -c foo.c | sed -n '/I N C L U D E S/,/E N D O F I N C L U D E S/ p'
#Will list the path to NAME_OF_INCLUDE:
xlc -qlist -c foo.c | grep NAME_OF_INCLUDE

The grep command might not return anything because of some zOS specific file translations, hence be careful:

  • if NAME.OF.INCLUDE contains dots, the real file name might be translated to INCLUDE.OF.NAME or just NAME
  • if NAME_OF_INCLUDE contains underscores, it might get translated to NAME@OF@INCLUDE

If you are using V1R11 compiler, there is a new feature, -qmakedep (on USS only) that will produce a list of all included files. It is much easier to remember then the sed command above. For example if you compiled:

# previus invocation: 'xlc -c foo.c'
# Append -qmakedep
xlc -c foo.c -qmakedep
cat foo.u

For previous releases of zOS compiler, have a look at the makedepend utility. It contains some other options that might be useful for include file debugging.

-qshowinc is another particularly useful option, if you already have the include files. It shows the the contents of the included files. It is similar to what PPONLY (-E equivalent) option does, except it outputs to the listing and does not strip preprosessor directives. However, be ready to pipe the output to other programs to filter out the thousands of lines of code produced. Most of the time I use less and its search features. sed and grep sometimes are also be useful.

If you are trying to include a file, and the compiler cannot find it, there is more research involved. In a general case, the include files can be found, top to bottom in these places:

pwd
LSEARCH
DD:USERLIB
SEARCH
DD:SYSLIB


  • System includes can only be found in SEARCH and DD:SYSLIB.
  • DD: statements come from the JCL, hence you might need to know how the compiler was invoked.
  • SEARCH and LSEARCH come from the compiler options hence are easy to modify

SEARCH and LSEARCH both contain a list of directories and partial dataset qualifiers. The topic is discussed in detail in our Compiler User Guide in 'Chapter 7: Using include files'. I personally found the flowcharts in Chapter 7 and the Examples in the LSEARCH option explanation cleared up most of the most dataset questions that I had. It is worth noting for newcomers that terms 'z/OS Unix files' and 'HFS files' are equivalent and refer to directory based files (i.e. similar to organization Linux and Windows file systems) (as opposed to DATASETs that can be sequential or PDS in this discussion)

-qlist, -qsource options and -V and -v c89 and xlc flags provide a quick way to find out what the values of LSEARCH and SEARCH are.

As Visda has discussed before in her blog post, NOSEARCH() and NOLSEARCH() reset the respective option value back to empty.

Last topic I wanted to touch was preprocessor macros and what options are available when dealing with them.

Michael Wong has posted here a way to find compiler predefined macros on AIX using the SHOWMACROS option. zOS unfortunately does not have this option till V1R11. The best equivalent is to use the makedepend utility -Wm,list option and then view depend.lst. It will contain a list of predefined compiler macros. However, makedepend utility is being deprecated since V1R11 in preference to built-in -qmakedep option.

Nevertheless most macros should be mentioned in the zOS manuals related feature sections. Here is a small list from the manual.

If you already have the macro name you wish to use, have a look at the -qEXPMAC option. This option will show you the value of the macro in the source listing. It is most useful when combined with -qshowinc.

I hope this gets you started on the right track.

2 Comments Permalink
0

So many times we get clients complaining to us that their code used to work on an older release but it's broken using the new release of the compiler. After closer look at the sample test case provided, we find out they have been lucky to have a working copy of the code. You see, the breakage is expected because they have broken the ansi-aliasing rules.

Not many of us follow the rules defined in C and C++ standards^1^ religiously. Although, the aliasing rules encourage accessing an object by lvalues of types compatible, we often have to break this rule in order to make the code "work".

By default, the xlc on z/Os compiles with ANSIALIAS. Based on the assumption that pointers in the source file access objects of the same type, the compiler determines storage locations that is accessed in two or more ways, i.e. aliased. If, for example, we have a struct s with two members s1 and s2, the storage for s overlaps with storage for both s.s1 and s.s2. But the storage of the s.s1 and s.s2 don't overlap. This knowledge is critical to aggressive compiler optimization. It allows some loads to move up and stores to move down. The rearrangements in the sequence of execution is desirable and increases executing more of the code in parallel.

Casting a pointer to point to a different object is a common C practice. For each type mismatch, xlc generates a warning and/or an informational message, which you may not notice if you have set the level of diagnostic messages to error or higher, -qflag=E, S, or U, or if you are redirecting all compiler messages to a hardly-ever-looked-at log file. Often the first time you notice a problem is when you execute the code and get an incorrect result.

You have broken the rules, now what?

You can compile routines that are not ansi alias compilant with low levels of optimization, e.g. at OPT0. The higher the level, the more aggressive the optimizations based on aliasing information. You can turn off optimization per routine, by #pragma option_override(func,"OPt(LEVEL,0)").

You can use -qnoansialias compile option or use cc utility which passes noansialias to the compiler by default. This may not be desirable because it usually results in significant performance degradation, e.g. gcc compiled at -O3 with -qnoansialias runs 20% slower.

You can fix the non-compliance in your source code.

1ISO/IEC 14882:1998(E), Section 3.10, Paragraph 15 states:

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types thebehaviour is undefined:

  • the dynamic type of the object
  • a cv-qualified version of the dynamic type of the object
  • a type that is signed or unsigned type corresponding to the dynamic type of the object
  • a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object
  • an aggregate or union type that includes one of the aforementioned type among its members (including, recursively, a member of a subaggregate or contained union)
  • a type that is a (possibly cv-qualified) base class type of the dynamic type of the object
  • a char or unsigned char type

Example:

/*alias.c*/
int foo(char *c)
{
char a[100];
char *cptr = a;
*(int *)cptr = *(int*)c;
return 0;
}
xlc -c alias.c -O3 -qlist=./ -qflag=i -qinfo

INFORMATIONAL CCN3495 ./alias.c:5 Pointer type conversion found.
INFORMATIONAL CCN3374 ./alias.c:5 Pointer types "int*" and "char*" are not compatible.
INFORMATIONAL CCN3495 ./alias.c:5 Pointer type conversion found.
INFORMATIONAL CCN3374 ./alias.c:5 Pointer types "int*" and "char*" are not compatible.
INFORMATIONAL CCN3415 ./alias.c:7 The external function definition "foo" is never referenced.

0 Comments Permalink
1

A quick one on SEARCH/NOSEARCH

Posted by Visda Jul 25, 2009

Search.jpg I think this option's name, (especially the negative one), is pretty confusing. Be that as it may, NOSEARCH wipes out all the previous search specifications and SEARCH sets them.

In METAL C a subset of standard C libraries have been defined, in this context this option becomes pretty handy.

In short, if strcpy is used in the user code, to avoid unexpected compile time messages complaining about strcpy syntax, incorrect run time behavior or what not, its declaration and definition should be pulled in from the METAL string.h header file.


cat foo.c


#include <string.h>
int main() {
char s[10];
memset(s,0,sizeof(s));
strcpy(s,"hello");
return 55;
}



xlc -S -c -qmetal foo.c -qlist=./
grep 'string.h' foo.lst



1 /usr/include/string.h wrong!!!

xlc -S -c -qmetal -qnosearch -I/usr/include/metal foo.c -qlist=./
grep 'string.h' hello.lst



1 /usr/include/metal/string.h correct!!!


The End!

1 Comments Permalink
0

Compilers are expected to make volatiles immune to optimizations that result in incorrect access to the volatile variables e.g. reducing the load/stores, re-ordering them, and etc.

A recent study on volatiles identified a few bugs with GCC 4.3.0 and LLVM-GCC 2.2. We put our compiler to test and found none of the three bugs identified in this paper applies. Not bad!

The first test case loads a volatile variable in the loop. Although invariant, we expect the compiler to leave x in the loop. The generated pseudo assembly code at O2 and O3 confirm this.

Here is the source code:
const volatile int x;
volatile int y;
void foo(void)
{
for(y=0; y>10; y++)
{
int z=x;
}
}

The assembly listing of the source code above at O3, below, shows the load of x in each iteration of the unrolled loop:

@1L3 DS 0H
L r0,x(r15,r1,0)
L r0,y(r14,r1,0)
AHI r0,H'1'
ST r0,y(r14,r1,0)
L r0,y(r14,r1,0)
CHI r0,H'10'
BNH @1L5
L r0,x(r15,r1,0)
L r0,y(r14,r1,0)
AHI r0,H'1'
ST r0,y(r14,r1,0)
L r0,y(r14,r1,0)
CHI r0,H'10'
BNH @1L5
L r0,x(r15,r1,0)
L r0,y(r14,r1,0)
AHI r0,H'1'
ST r0,y(r14,r1,0)
L r0,y(r14,r1,0)
CHI r0,H'10'
BNH @1L5
L r0,x(r15,r1,0)
L r0,y(r14,r1,0)
AHI r0,H'1'
ST r0,y(r14,r1,0)
L r0,y(r14,r1,0)
CHI r0,H'10'
BH @1L3

The second test accesses a volatile variable on the fall through path of a condition.

Source is:
extern in qux();
volatile int w;
int bar(void)
{
if(qux())
return 0;
else
return w;
}

In the pseudo listing, below, w is correctly accessed when qux() returns zero. This listing generated at O3 is:

L r15,=V(qux)(,r3,66)
L r2,_CEECAA_(,r12,500)
BASR r14,r15
LTR r15,r15
L r1,=Q(w)(,r3,70)
BE @1L1
LA r15,0
B @1L3
@1L1 DS 0H
L r15,w(r1,r2,0)
@1L3 DS 0H

In the last source code a volatile variable is incremented inside the loop.

volatile int a;
void baz(void)
{
int i;
for(i=0; i<3; i++)
{
a += 7;
}
}

We unroll and the loop by three and access "a" three times. The listing of compile at O3 looks like below.

L r0,a(r14,r1,0)
AHI r0,H'7'
ST r0,a(r14,r1,0)
L r0,a(r14,r1,0)
AHI r0,H'7'
ST r0,a(r14,r1,0)
L r0,a(r14,r1,0)
AHI r0,H'7'
ST r0,a(r14,r1,0)

0 Comments Permalink
0

RENT or NORENT

Posted by Visda Jan 11, 2009

Here we are eleven days into a new year; and I would like to wish all of you a happy belated 2009! May this be a year of making technology less complex, more intuitive, friendlier and greener.

Is it clear why we have RENT|NORENT compiler option? Do you know that C++ always uses constructed re-enterancy? Can you imagine how applications can benefit most from this?

Recently, I developed a greater appreciation for RENT option, that is after I banged my head against the wall to REALLY understand what RENT is all about in order to fix a related bug. :8}

Reentrancy becomes important when a rather large application have multiple users who may access it concurrently, for example Oracle. Oracle applications developed to run on z/OS will access Oracle interface which is a reentrant code.

Per z/OS Language Environment Programming Guide the following routines must be reentrant.

  • Routines to be loaded into the LPA or ELPA
  • Routines to be used with CICS
  • Routines to be preloaded with IMS

Furthermore, a large application with many concurrent users will benefit from reentrancy, ie runs faster, because there is less paging to auxilary storage --variables are placed in writeable static area.

This is done for you, if your application is written in C++ or is a DLL. Compile with "-qlist" and you see RENT in the Compiler Option Listing. A C program, however, can be naturally reenterant, that is the user code doesn't change the static storage.


For example:

extern int x;


int main()


{

return x;

}

is naturally reentrant because the value of x is not changed by main.

A C program can be made reentrant, constructed reenterancy by specifying

a. -qRENT on the command line (in HFS) or RENT in CPARM (in BATCH)
b. #pragma variable(x,RENT) in the source

There you have it. In a nutshell: reentrancy comes for free with C++ and DLL code, for the rest you have ways to make the code reentrant; if your code is big and is called/used by multiple users at the same time you want to take advantage of this feature because it will improve the run time performance of your application.

0 Comments Permalink
Bottom Banner