views:

432

answers:

5
A: 

Try including:

#include <memory.h>
#include <string.h>
anon
Metal C is a limited subset of standard C, and doesn't have memory.h
Jared
Maybe it doesn't implement memset() then?
anon
the manual uses memset in an example.
Jared
Good try, but this isn't applicable to z/OS
Nighthawk
+1  A: 

So, I have no idea. But some suggestions:

  1. You might try copying/pasting this code here from this example just to make sure it works 'as expected'

  2. Maybe try defining some of the macros here? (when I did C programming on zOS, I had to do include some weird macros in order to get stuff to work. I have no reasonable technical explanation for this.)

  3. You could try searching for memset() using "=3.14" (from ispf.) See if any other modules use that function, and then check the headers that they include (or macros that they define - either in the C files or H files) to make it work.

  4. Another thought: before the memset(), try doing putting a printf() in. If you get a syntax error on the same line (only for printf, rather than memset) then you can see if the problem is before line 6 - like a misplaced parenthesis.

  5. Finally, if i recall correctly, I had to compile my individual modules, and then link them manually (unless I wrote a JCL to do this for me.) So you might have to link once to link with your other modules, and then link again against the C library. Not to be pedantic, but: you're fairly certain that you're doing all of the link passes?

I realize that's a lot of hoops to try and you've probably already read the manuals, but maybe there is something useful to try?

Also, and you probably already know this, but this site (for looking up error codes) is infinitely useful. (along with the above links for full-text-searching the manual)

Edit: this page also talks about "built-in functions" - you could try (as stated at the bottom of the page) "#undef memcpy" to use the non-built-in version?

rascher
Metal C isn't like standard Z/OS C, it generates streight assembly language with no dependencys on LE. I've gotten programs to compile run with out memset, and including metal.h breaks stuff. I think it's an issue with my include search path causing conflicting headers to be included, I'll update the question when I do some research and know more.
Jared
+1  A: 

Can you show us your compiler arguments? You need to make sure that you're not pulling in the standard C header files in addition to the metal C ones. Here's an example:

xlc -c -Wc,metal,longname,nosearch,'list(./)'  -I. -I /usr/include/metal -I "//'SYS1.SIEAHDRV'" -S -qlanglvl=extended foo.c
as -mrent -mgoff -a=foo.list -o foo.o foo.s
ld -bac=1 -brent -S "//'SYS1.CSSLIB'" -o foo foo.o
Nighthawk
Do you have a JCL example? After looking at your example I think my CPARM line is the problem but am not sure how to fix it. // CPARM='SO,LIS,LONG,NOXREF,CSECT,METAL,SEARCH(/usr/include/metal/),',
Jared
Hmm...I don't think I've ever compiled C via JCL - would it be possible for you to fire up a shell and compile it that way?
Nighthawk
All this is from a shell. When I run this command xlc -c -Wc,metal,longname,nosearch,'list(./)' -I. -I /usr/include/metal -I "//'SYS1.SIEAHDRV'" -S -qlanglvl=extended foo.c I get foo.s and foo.lst When I try the second command as -mrent -mgoff -a=foo.list -o foo.o foo I get file foo doesn't exist. When I replace foo with foo.s or foo.lst I get the following errors.** ASMA935U One or more required files not available** ASMA434N GOFF/XOBJECT option specified, option LIST(133) will be usedFSUM3401 The assemble step ended with rc = 20. I can't move onto the link step until the assemble works.
Jared
Whoops! That was a typo on my part. The last argument in the "as" step should be "foo.s", not "foo". I have updated my answer above. That will generate the foo.o object file, which the call to "ld" will bind into a running executable.
Nighthawk
Still the same error, I'm thinking it's an issue with the way our site's set up and that I have some Environment variables set wrong or not set at all.
Jared
So you're saying that as -mrent -mgoff -a=foo.list -o foo.o foo.sdoesn't work? You said that you have a foo.s from the previous step, right? Why don't you paste the session here so we can look at it?
Nighthawk
A: 

Are you missing the closing brace '}' for the function? How about any missing semi-colon line terminators? When missing braces/semi-colons the z/OS C compiler throws some strange/misleading messages sometimes. I don't have it to try out, but I'm assuming Metal does as well.

Robert
+2  A: 

The issue was with the search order. Although I did search(/usr/metal/include) from with in my JCL I didn't proceed it with a nosearch option, so string.h was getting picked up from the standard system librarys instead of the version included with Metal C. I've pasted my optfile dataset I passed to the CPARM below for refference.

//OPTIONS DD *
 SO
 LIST
 LONG
 NOXREF
 CSECT
 METAL
 LP64
 NOSEARCH
 search(/usr/include/metal/)
Jared
That's why I included Wc,nosearch in my compiler parms above. I learned about that "feature" the hard way early on.
Nighthawk