This is a case where you really should use a message formatter.
Think APPLMSG macro and 'XMITMSG' command in CMS. I was shocked years
ago to find that MVS lacked this.
I cobbled-up an 'xmitmsg' work-alike at a certain shop where I used to
work. Just sayin. (They required extensions beyond what APPLMSG/XMITMSG
would do. You may be familiar with the work of a particular retiree from
that shop, but my work was POSIX.)
I cobbled-up an 'xmitmsg' work-alike basically following APPLMSG/XMITMSG
and have used it in other projects. On its own it is callable from Rexx.
It's on GitHub and open for "issues" and/or contributions.
I realize this isn't answering your question ... but ...
When I was at BMC, I urged the Unix side of a certain multi-platform
team to use a proper message formatter. They were keen to use "gettext"
and friends, which has always struck me as a kludgey way to reformat
messages for I18N. Enumerated tokens inprintf() and friends smells like
same. But this:
> English: &1 &2 found
> French: &2 trouvee sont &1
... is exactly the kind of thing APPLMSG/XMITMSG/GENMSG is made for.
-- R; <><
On 10/2/25 5:07 PM, Phil Smith III wrote:
Thanks, Bernd and Rich! The 1$ etc. are key: that's where the number limitation
surely comes in. Those let you reorder substitutions, so if you're doing NLS,
you can have the substitutions in the appropriate order for the language you're
using. Of course now I can't think of a good, realistic example, but let's say
in English the message is:
&1 &2 found
e.g.
4 pineapples found
and in French, the syntax is "Ananas trouvee sont 4" (I think that's correct French, if
probably oddly worded--pretty sure you could say "4 ananas trouvee" just fine, but let's
assume you have to reorder). Your message processor uses the %1$d and %2$s:
English: &1 &2 found
French: &2 trouvee sont &1
Looks like a runtime library bug. Of course I can't report it since I'm not a
"real" IBM customer, but at least it's on (some form of) the record now...
I'd note that with optimization on and/or just because the original code
calling this is a lot more complex, it wasn't just failing to substitute--it
was S0C4ing. Nasty. My guy spent a LONG time trying to figure out what he was
getting wrong, of course.
Thanks again,
...phsiii
-----Original Message-----
From: IBM Mainframe Discussion List<[email protected]> On Behalf Of
Bernd Oppolzer
Sent: Thursday, October 2, 2025 4:52 PM
To:[email protected]
Subject: Re: Anyone using XL C?
I did some tests with the MVS variant of z/OS XL C (V3.1).
In the first run, I had problems with snprintf, because it is not part of the
ANSI cosmos, which I am accustomed to use, so I changed this to sprintf and
omitted the length parameter. Same result.
Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6: fffff P7:
ggggg P8: hhhhh P9: iiiii P10: P11: <
Then I omitted the 1$ flags etc., because they seem strange to me; I don't know
what they are doing.
I simply used %s everywhere. The parameter strings are NULL-terminated, after
all.
Now I get:
Test msg 10 parm P1: aaaaa P2: bbbbb P3: cccccP4: ddddd P5: eeeee P6:
fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk <
Here the modified source code:
#include<stdio.h>
int main( int argc, char **argv ){
char b[4096];
sprintf (b, "Test msg 10 parm P1: %s P2: %s P3: %s"
"P4: %s P5: %s \n P6: %s P7: %s P8: %s P9: %s"
"P10: %s P11: %s <",
"aaaaa","bbbbb","ccccc","ddddd","eeeee","fffff",
"ggggg","hhhhh","iiiii","jjjjj","kkkkk");
printf( "%s\n", b );
return 0;
}
HTH, kind regards
Bernd
Test msg 10 parm P1: aaaaa P2: bbbbb P3: cccccP4: ddddd P5: eeeee
P6: fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk <
Am 02.10.2025 um 22:21 schrieb Phil Smith III:
If so, can you try this trivial program from USS (or the MVS side, I don't
care, but it's easier from USS):
-------------------
#include<stdio.h>
int main( int argc, char **argv ){
char b[4096];
snprintf( b, 4096, "Test msg 10 parm P1: %1$s P2: %2$s P3: %3$s P4: %4$s P5: %5$s P6: %6$s P7: %7$s P8: %8$s P9: %9$s P10: %10$s P11: %11$s
<","aaaaa","bbbbb","ccccc","ddddd","eeeee","fffff","ggggg","hhhhh","iiiii","jjjjj","kkkkk");
printf( "%s\n", b );
return 0;
}
-------------------
* To build (assuming you named it bug.c):
c89 bug.c
-------------------
* Then:
./a.out
-------------------
* I get this output on my z/OS system:
Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6:
fffff P7: ggggg P8: hhhhh P9: iiiii P10: P11: <
* That should have been:
Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6:
fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk <
-------------------
It appears that the XLC runtime doesn't handle more than 9 arguments using the
%n$s format (at least). We found this because some new code was blowing up, and
we of course assumed it was something wrong with one of the many formats (they
aren't all just s-type).
The compiler listings say just:
15650ZOS V2.4 z/OS XL C
I'm hoping someone with a newer version can confirm that this is fixed. We're
going to have to work around it anyway, because it's not that hard (we only
have one such example) and I'd rather not require an IBM PTF for our customers.
Thanks...
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
--
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
