I can't help with the issue you are seeing, but I do have a curious question.
Have you looked at the intrinsic function support in COBOL to see if that would be of any help with your character conversion? Paul -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Farley, Peter Sent: Sunday, December 14, 2025 2:13 AM To: [email protected] Subject: Re: z/OS Unicode Services: Can CUNLCNV be invoked dynamically? Solved at least the first part of it. The 0C4 was because the field CUNBCPRM-Conv-Handle was initialized to SPACES instead of LOW-VALUES (X'00'). At least I have no more 0C4, but RC=8 means I still don't have all the parameter values quite right. Peter From: IBM Mainframe Discussion List <[email protected] <mailto:[email protected]> > On Behalf Of Farley, Peter Sent: Sunday, December 14, 2025 2:17 AM To: [email protected] <mailto:[email protected]> Subject: Re: z/OS Unicode Services: Can CUNLCNV be invoked dynamically? Responses interspersed below. > From: IBM Mainframe Discussion List <[email protected] <mailto:[email protected]> > On > Behalf Of Tony Harminc > Sent: Saturday, December 13, 2025 11:32 PM > To: [email protected] <mailto:[email protected]> > Subject: Re: z/OS Unicode Services: Can CUNLCNV be invoked dynamically? > > > On Sat, 13 Dec 2025 at 21:01, Farley, Peter < > > [email protected] <mailto:[email protected]> > wrote: <Snipped> > Interesting... I don't know modern COBOL, so I have nothing useful to > say about CALL issues. But... I have called CUNLCNV from assembler > code, and as I mentioned in reply to someone else a week or two ago, I > have as much as possible given up on all the stupid little stub > routines for various callable services, and instead use the offsets > from the CSR table. Not all are well documented. I have no idea if > this is possible from COBOL - does it have something like a function > pointer, and can you tell it the linkage style (e.g. "OS") to use? (I > guess that's C terminology.) COBOL dynamic call Is managed by Language Environment, I believe, and it always uses standard OS-style linkage, R1 -> PARM-list -> data area. Observation tells me that LE does a LOAD on first CALL and BALR/BASR on subsequent calls (second and subsequent CALL's take less time than first). > > It isn't documented in the FM as far as I can see, but MUST the > > CUNLCNV subroutine be statically linked to use it? > > > > I was going to say no, why would it matter, but I found just now to my > surprise that CUNLCNV is linked ONLY-LOADABLE, and when I try to LINK > to it I get a 406-04 abend. Well I'd never tried LINKing to it because > I use the code below. > > > TIA for any practical experience or RTFM you can provide. > > I know nothing of COBOL's dynamic CALL scheme, but if it issues a LINK > (rather than a LOAD + CALL) then I'd expect problems. But as you're > getting a S0C4, be sure that your argument list is OS-style, i.e. that > R1 points to a list of fullwords of which the first (and only) points > to the storage where you set up your CUNBCPRM structure. Do you have a > valid DDA of adequate size? Input and output pointers in CUNBCPRM all good? All good as far as I know. I debugged up to the CALL to CUNLCNV with Intertest Batch and CUNBCPRM looks good as far as I can tell. Normal COBOL CALL's (static or dynamic) all use standard OS-style linkage, R1 -> PARM-list -> data area. > And of course that you get as far as an S0C4 and don't get the 406 > suggests that COBOL is doing a LOAD and not a LINK for its dynamic CALL. > > Can you get an early dump? If so, where does it abend? I probably can get a SYSUDUMP/SYSMDUMP if I disable CA SYMDUMP processing, but I don’t know how "early" that will be. > If COBOL supports function pointers then you could try the equivalent > of this bit of code, which avoids the stub routine entirely, but is > probably not supported by IBM. And I doubt it will help directly with your S0C4. Modern COBOL does have a function pointer (they call it a "procedure-pointer"). I've experimented with those and it's POSSIBLE (but certainly NOT supported by IBM) to construct a "procedure-pointer" from an address obtained from storage like your assembler code does. I did that for a set of hex strings in COBOL WORKING-STORAGE that held hardware-level instructions (a VERY short piece of code) and was able to execute that storage as a subroutine from COBOL. Fun, but not production-stable enough to put into the wild (not to mention my managers would have a set of fits about it if I did). My problem is not whether it CAN be done with a procedure-pointer, but will it survive future incompatible COBOL enhancements (i.e., is it robust). I need code that ALWAYS works. I can always craft a small assembler routine to do the actual CALL, but that is increasingly frowned on as we assembler nerds slowly fade away, and I can’t say that I blame them - who will support it when we are no longer around? ChatGPT? I actually just tried making the CALL static (COBOL option NODYNAM and literal "CUNLCNV" for the CALL program name; binder MAP confirms it is part of the program object), and I STILL got the 0C4, so I am going to have to examine my population of CUNBCPRM more closely to make sure it has "the right stuff in the right places". If I must I'll get a SYSMDUMP and struggle through using IPCS to look at it (I REALLY miss having z/XDC; we no longer license the product <*Sigh*>). > <Snipped> Thanks, I think I need it. >Good luck. > >Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] <mailto:[email protected]> with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] <mailto:[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
