problems with memset in Metal C

Question

I’m trying to initialize the Metal C environment with the following code, but get the following errors on the memset line. ERROR CCN3275 IMIJWS0.METAL.SAMPLIB(MEM):6 Unexpected text ')' encountered. ERROR CCN3045 IMIJWS0.METAL.SAMPLIB(MEM):6 Undeclared identifier ___MEMSET. ERROR CCN3277 IMIJWS0.METAL.SAMPLIB(MEM):6 Syntax error: possible missing ')' or ','? CCN0793(I) Compilation failed for file //'IMIJWS0.METAL.SAMPLIB(MEM)'. Object file not created. Below is my code


   #include &lt string.h&gt
   #include &lt stdlib.h&gt
   #include &lt metal.h&gt
   void mymtlfcn(void)  {
   struct __csysenv_s mysysenv;
   memset ( &mysysenv, 0, sizeof ( mysysenv ) );
   mysysenv.__cseversion = __CSE_VERSION_1;
   mysysenv.__csesubpool = 129;
   mysysenv.__cseheap31initsize = 131072;
   mysysenv.__cseheap31incrsize = 8192;
   mysysenv.__cseheap64initsize = 20;
   mysysenv.__cseheap64incrsize = 1;

You have some #include issue. Try moving string.h to be after stdlib.h. — i_am_jorf, Jun 03 '09 at 17:52
Shuffling the order of standard headers will do nothing useful. — David Thornley, Jun 03 '09 at 17:57
Actually, could we have some details on Metal C? What you did looks fine in standard C, so either you're messing up on something you aren't showing, or what we're seeing isn't what you actually typed, or Metal C is a defective or pre-Standard compiler. — David Thornley, Jun 03 '09 at 18:00
Metal C contains a very limited set of the standard c library, and is designed for mainframe system programming. I think it's a nonstandard compiler since I've had had issues with things like // not working as a comment and the placement of [] in declerations. Here's a link to more info on it. http://www-03.ibm.com/systems/z/os/zos/metalc/ — Jared, Jun 03 '09 at 18:06
The z/OS XL C compiler is a standard compiler. If you want // comments to work provide the SSCOM option in your exec parm. — Robert Groves, Jun 09 '09 at 13:32

score 3 · Accepted Answer · answered Jun 09 '09 at 16:14

3

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/)

answered Jun 09 '09 at 16:14

Jared

39,513
29
110
145

That's why I included Wc,nosearch in my compiler parms above. I learned about that "feature" the hard way early on. – Anthony Giorgio Jun 10 '09 at 11:27

score 1 · Answer 2 · answered Jun 03 '09 at 23:55

So, I have no idea. But some suggestions:

You might try copying/pasting this code here from this example just to make sure it works 'as expected'
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.)
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.
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.
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?

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, Jun 04 '09 at 12:25

Anthony Giorgio · Answer 3 · 2009-06-05T12:31:38.220

1

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

edited Jun 05 '09 at 12:31

answered Jun 04 '09 at 14:09

Anthony Giorgio

1,844
1
15
17

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 Jun 04 '09 at 15:34
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? – Anthony Giorgio Jun 04 '09 at 17:07
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 used FSUM3401 The assemble step ended with rc = 20. I can't move onto the link step until the assemble works. – Jared Jun 04 '09 at 17:41
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. – Anthony Giorgio Jun 05 '09 at 12:32
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 Jun 05 '09 at 16:13
So you're saying that as -mrent -mgoff -a=foo.list -o foo.o foo.s doesn'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? – Anthony Giorgio Jun 05 '09 at 19:43

Robert Groves · Answer 4 · 2009-06-09T13:23:31.913

0

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.

edited Jun 09 '09 at 13:23

answered Jun 09 '09 at 05:00

Robert Groves

7,574
6
38
50

problems with memset in Metal C

4 Answers4