On Sat, 13 Dec 2025 at 21:01, Farley, Peter < [email protected]> wrote:
> As part of a POC project I am trying to use the z/OS Unicode Services > subroutine CUNLCNV for character conversion from an Enterprise COBOL > program. Since IBM doesn't seem to support or provide an example or > parameter structures for using the service from COBOL, I have manually > converted the PL/X version of the parameter structure (CUNBCPRM inside > SYS1.MACLIB(CUNBCIDF)) to a COBOL copy member and I believe I have filled > in all the relevant bits correctly based on running a test with the IBM > HLASM sample in SYS1.SAMPLIB(CUNSMSMA), but that sample assembler program > statically links CUNLCNV from SYS1.CSSLIB. > > I am telling CUNLCNV the address, length and ALET (zero) of the source, > target, DDA, and work buffers, and have populated the version and parameter > length fields as is done in the HLASM version. > > I have set up a test COBOL program to use a dynamic CALL to CUNLCNV > instead of a static one, but I get S0C4 when it actually CALL's the > subroutine using the COBOL dynamic CALL mechanism. > 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.) 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? 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? 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. S_CUNSLOT EQU 60 CSR slot for CUN services O_CUNLCNV EQU 172 Character conversion L 15,16(,0) -> CVT L 15,544(,15) -> CSRTABLE L 15,S_CUNSLOT(,15) -> CSR slot L 15,O_CUNLCNV(,15) Address of the CSR routine LA 1,WRK_CALL_L -> local parm list LA 0,CUNBCPRM -> CUNBCPRM ST 0,0(0,1) set pointer into parm list OI 0(1),X'80' set end of list flag (probably unnecessary) BALR 14,15 call CUNLCNV Good luck. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
