There has been message formatting in TSO for half a century. Not as powerful as 
I would like, but it works well for what it does.

-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Rick Troth <[email protected]>
Sent: Friday, October 3, 2025 9:17 AM
To: [email protected] <[email protected]>
Subject: Re: Anyone using XL C?


External Message: Use Caution


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




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to