CCN5063 on parameter list

[ehodil]

I'm trying to set up a parameter list for an external function that I want to call from HLASM, and I keep getting this UNEXPECTED TOKEN error on the compile. The only way I can seem to get a clean compile is if I remove the parameters altogether! This is not really a solution for me because I need to pass information both to and from the function.

Any ideas?

Earl Hodil

[enrico-sorichetti]

the information posted is completely useless
maybe if You post the source involved You might get more help

it would be useful for you to read and meditate on
How To Ask Questions The Smart Way
http://catb.org/~esr/faqs/smart-questions.html
to make the most out of the questions You ask

[ehodil]

Here is an example of what I'm talking about

extern "os" int myFunc (*p1, *p2)
{
...
}

In this example, I would get a CCN5063 on the asterisk in *P1. In fact, I will keep getting CCN5063's until I remove the parmlist altogether! And that is an unacceptable solution.

[steve-myers]

The syntax appears to be incorrect. You cannot specify an untyped pointer, as you have done, though you can specify a "void" pointer. Void isn't really a type, but you can use it when you want to sort of defer the real type specification. You probably want to specify

extern "os" int myFunc (char *p1, char *p2)

or use whatever type that conforms to what the Assembler program is sending to myFunc.

I don't know what "os" means.

[ehodil]

I knew this would happen! That's why I didn't put code up there initially. I work for a software vendor so I can't post any of our code on a message board. I just cobbled up something quick and dirty. Suffice it to say, the real code has the right syntax. The problem is, the compiler doesn't want me to have parameters on an external function! Does anybody know why?

[enrico-sorichetti]

I knew this would happen! That's why I didn't put code up there initially. I work for a software vendor so I can't post any of our code on a message board. I just cobbled up something quick and dirty. Suffice it to say, the real code has the right syntax. The problem is, the compiler doesn't want me to have parameters on an external function! Does anybody know why?

plain unadulterated horse manure,
if the code had the right syntax the compiler would not complain and You would not be getting the message

since this is going to be a topic based only on Your interpretation of the manual and not fact themselves we are just wasting time

but spent/wasted some of my time running a simple test and ...

Code: Select all

92      extern "OS" short int dsntiar(struct sqlca        *,
93                                    struct error_struct *,
94                                    int                 *);


I confirm that the above declaration works well

[enrico-sorichetti]

follow on
I just ran a quick and dirty silly test for the other way around

Code: Select all

000004 //CPP     EXEC CPP,PARM='/CXX '
000005 //C.SYSIN   DD *
000006 #include <string.h>
000007 extern  "OS"  int myfun1(int a, int b)
000008  {
000009    return a + b ;
000010  }
000011 extern  "OS"  int myfun2(char *a,char *b)
000012  {
000013    return strlen(a) + strlen(b) ;
000014  }


the compilation ended wit a return code of 000

[enrico-sorichetti]

another follow on for the sake of completeness

Code: Select all

000015 //CPP     EXEC CPP
000016 //C.SYSIN   DD *
000017 #include <string.h>
000018 #pragma linkage(myfun1,OS)
000019 #pragma linkage(myfun2,OS)
000020 extern  int myfun1(int a, int b)
000021  {
000022    return a + b ;
000023  }
000024 extern  int myfun2(char *a,char *b)
000025  {
000026    return strlen(a) + strlen(b) ;
000027  }


[steve-myers]

The issue about working for a software vendor is quite true. Most software vendors don't want their code freely distributed.

I used to work for a software vendor. Several years ago (around 2005 I think it was) we ran into a problem with a couple of our products. This was discovered while testing a future release of one of our products, but it appeared it could affect the then current release of the product. I was handed this issue; it was really encountered by one of our developers. While analyzing the problem in detail I traced the problem to JES2, but I couldn't determine the root cause of the problem in the JES2 code. My initial theory was the root cause was in an extremely unusual ENQ in the JES2 code. This was so strange I had trouble finding the description of the ENQ in the manuals. Since I could not figure out a way to actually test this wierd ENQ, I decided the best I could do was write a small test program that sort of simulated what our product actually does to trigger the JES2 problem. Sure enough, it eventually encountered the same problem as our much larger product. Since we ran this test on a live, current z/OS system I could get our central support group to open a PMR with JES2. After a couple of weeks JES2 called me, and I agreed to turn over my test program. Fortunately, this test program failed in the JES2 environment. It took a couple of months, but JES2 constructed a very large APAR fix to correct their problem. I'm sure that having my test program available to them assisted them in working up the fix. We were able to persuade our central support group to install the APAR fix on the semi-production system we used when we encountered the problem, and it seemed to work, so we could close the APAR the PMR created, and IBM turned the APAR fix into a PTF.

That was all well and good; it had a better result than the only other APAR I had opened with JES2 more than 20 years previously. That APAR, which incorporated the code fix I had developed and given to IBM had been sent out as a PTF; the next month it had been PE'ed and effectively removed. The APAR was really a doc problem; JES2 NJE did not work as documented in the JCL manual, and as it had worked before JES2 NJE. We wanted it to work as documented. After some thought I decided JES2 had it right and the JCL manual needed to be fixed. I put my old fix back into the code, and that was that.

It turned out the new PTF was also PEed, though that fix was much smaller than the rather large initial PTF.

The best news was none of our customers ever encountered the problem. While IBM was building their PTFs we were able to provide at least two ways our customers could avoid this problem. In fact, one of these methods was inserted into the new release of our product!

[enrico-sorichetti]

my comment about unadulterated animal nitrogenated leavings was not for the whole sentence,
( after all rules are there and we have no right to judge them )
but about the general tone of the remark

I knew this would happen! That's why I didn't put code up there initially .... I just cobbled up something quick and dirty. Suffice it to say, the real code has the right syntax. The problem is, the compiler doesn't want me to have parameters on an external function! ...

as I said before ...
it' s a waste of time to debug something cobbled up, to find a solution we have to know the real thing or a <certified> obfuscation of it
or the TS after we have shown that he has no right to complain should work things out within the wall of his cubicle

if the TS has privacy concerns then the question should not be asked on a public forum
the only answer he will get is along the lines of my previous one
/repeat on
if the real code had the right syntax, the compiler would not complain

cheers everybody!
enrico