COBOL requires exact input and output description. HEX-OF (what)? Also, HEX-TO-CHAR(what)? are the arguments single character or are the arguments strings?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But never mind, I'm writing them from scratch, I will share them when are ready - Newer USAGE made them easier to write than with ancient COBOL 74 I used to work with in the 80s.
Regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Strange that GNU COBOL does not support them. Did you try to do a test using flag "-std=ibm-strict"? This should be compatible with IBM Enterprise Compiler.
Thank you for sharing the code in advance.
If nothing else works for you, here is a sample I coded quickly, it is not well tested and variable sizes need to be adjusted for your case:
IDENTIFICATIONDIVISION.PROGRAM-ID.HELLO-WORLD.DATADIVISION.*>-------------------------------------------------*>PROGRAMTOCONVERTASTRINGTOHEX.*>SEE:https://www.rapidtables.com/convert/number/hex-to-decimal.html*>Codeisnotoptimized-Makesureyoucheckthevariablesizes*>hardlytestedusingGNUCOOBOL*>-------------------------------------------------WORKING-STORAGESECTION.*>-------------------------------------------------01LPICS9(4)COMP.01IPICS9(4)COMP.01JPICS9(4)COMP.01HEXPICS9(9).01MSGPICX(10).01MSG-WRKPICX(10).01CHARPICX.01SGNPICS9.01LM1PICS9(4)COMP.01F.02HEX-0-FPICX(16)VALUE"0123456789ABCDEF".02FREDEFINESHEX-0-F.03BOCCURS16TIMESINDEXEDBYIXPICX.*>-------------------------------------------------PROCEDUREDIVISION.*>-------------------------------------------------DISPLAY"--------------------- Hello"MOVEZEROTOMSG.PERFORMP1*>0MOVE9TOMSG.PERFORMP1*>9MOVE12TOMSG.PERFORMP1*>18MOVE"F1"TOMSG.PERFORMP1*>241MOVE"-FF"TOMSG.PERFORMP1*>-255MOVE"-C3F1"TOMSG.PERFORMP1*>-50161MOVE"+2EEE"TOMSG.PERFORMP1*>12014MOVE"-e"TOMSG.PERFORMP1*>12014STOPRUN.*>-------------------------------------------------P1.*>-------------------------------------------------IFMSG=SPACESORLOW-VALUESDISPLAY"STRING IS EMPTY-1"STOPRUNEND-IFCOMPUTEL=FUNCTIONLENGTH(FUNCTIONTRIM(MSG))*>THISBETTERBEEVENCOMPUTELM1=L-1MOVESPACETOMSG-WRKMOVEFUNCTIONUPPER-CASE(MSG)TOMSGIFMSG(1:1)="-"THENMOVEMSG(2:LM1)TOMSG-WRKMOVE-1TOSGNMOVELM1TOLELSEIFMSG(1:1)="+"THENMOVEMSG(2:LM1)TOMSG-WRKMOVE1TOSGNMOVELM1TOLELSEMOVE1TOSGNMOVEMSGTOMSG-WRKEND-IFEND-IFIFL=0THENDISPLAY"STRING IS TOO SHORT-2"STOPRUNEND-IFMOVEZEROTOHEXCOMPUTEJ=LPERFORMVARYINGIFROM1BY1UNTILI>LMOVEMSG-WRK(I:1)TOCHARSETIXTO1SEARCHBATENDDISPLAY"BAD INPUT VALUE:"CHARWHENCHAR=B(IX)COMPUTEIX=IX-1COMPUTEJ=J-1COMPUTEHEX=HEX+IX*(16**J)*>DISPLAYIXSPACEJSPACEHEXEND-SEARCHEND-PERFORMCOMPUTEHEX=HEX*SGNDISPLAYMSGSPACEHEXDISPLAY"---------------------".*>-------------------------------------------------ENDOFCODE
Last edit: Emmad 2021-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We strive to include as many extensions as volunteer time and attention permit. Will take a peek at HEX-. At the moment, this laptop doesn't want to show those IBM doc pages...likely on my end with noscript or ublock.
By the by. The 202x Standard now includes FUNCTION BASECONVERT. That new feature will be going in as soon as feasible.
The current draft Standard limits inbase and outbase to 2-16. arg1 can be an unsigned integer, if inbase is 2-10, otherwise expects a usage DISPLAY item, with "0-F" allowed. Exception codes set for invalid character for base, and what not. Returns character data "0-F".
I'm probably going to pester Simon about a strict mode for the 2-16 check, and open up the base range for default GnuCOBOL. We can support up to base36 "for free", and other base ranges after arguing over a few things. I'm a fan of base64 support for instance, but it'll require explicit docs about what character matches what number, etc. And I might argue, we at first only support base32, and purge ambiguous pairs, 1, one, l, little-ell, 0, zero, O, capital O, q, g, and something I'm forgetting. Far more human friendly than base36. But that's dreaming, Standard will be base-2 to hexadecimal range.
Won't be in GnuCOBOL in time to suit any immediate needs though, Sergio, but I don't think it'll be too long.
I've done this with built in libgmp functions and CALL, with C source code helper and as a user defined function.
Code is attached to the above link. It's old code, before the days of doing more low level things in straight up COBOL, ergo the C support code. Arbitrary precision in terms of the size of the numbers allowed.
Due to my limited understanding of UDF back then, convert-base is limited to an output of 256 "digits" in the returned output buffer. I picked a fixed length return buffer for the UDF, but the CALL version can handle arbitrarily long strings of digits, both for input and output.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@btiffin Could you please try to integrate the 202x function into GC soon? It sounds that most of the actual work is already done, isn't it?
And a note: I've already added the two IBM functions (were requested by some people working on an IBM codebase conversion shortly before my vacation), this addition should be included very soon (I've already started to write the test cases, so possibly this week, still a lot mails to sort out before doing "actual" work). So don't mind those two intrinsic functions for now; I'll post a reference for the implementation here, too, so people can apply the patch to a local version of whatever GnuCOBOL (2.x+), too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ssamayoagt HEX-OF and HEX-TO-CHAR (along with BIT-OF and BIT-TO-CHAR) are now implemented with [r4323] and will be available with 3.2 RC-1 this month.
@btiffin: Is there any option that you can have a look at adding the missing pieces for COBOL 202x based on that?
Hi guys,
I need intrinsic functions HEX-OF & HEX-TO-CHAR and find out that they didn't exists yet in GNU COBOL.
I don't want to invent the wheel so, does someone has implemented in COBOL who can share with me?
I'm very rusty in COBOL :S
TIA.
COBOL requires exact input and output description. HEX-OF (what)? Also, HEX-TO-CHAR(what)? are the arguments single character or are the arguments strings?
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=functions-hex
But never mind, I'm writing them from scratch, I will share them when are ready - Newer USAGE made them easier to write than with ancient COBOL 74 I used to work with in the 80s.
Regards!
Strange that GNU COBOL does not support them. Did you try to do a test using flag "-std=ibm-strict"? This should be compatible with IBM Enterprise Compiler.
Thank you for sharing the code in advance.
If nothing else works for you, here is a sample I coded quickly, it is not well tested and variable sizes need to be adjusted for your case:
Last edit: Emmad 2021-08-24
Here are mine -
Regards!
We strive to include as many extensions as volunteer time and attention permit. Will take a peek at
HEX-. At the moment, this laptop doesn't want to show those IBM doc pages...likely on my end with noscript or ublock.By the by. The 202x Standard now includes
FUNCTION BASECONVERT. That new feature will be going in as soon as feasible.Basically,
The current draft Standard limits inbase and outbase to 2-16. arg1 can be an unsigned integer, if inbase is 2-10, otherwise expects a usage DISPLAY item, with "0-F" allowed. Exception codes set for invalid character for base, and what not. Returns character data "0-F".
I'm probably going to pester Simon about a strict mode for the 2-16 check, and open up the base range for default GnuCOBOL. We can support up to base36 "for free", and other base ranges after arguing over a few things. I'm a fan of base64 support for instance, but it'll require explicit docs about what character matches what number, etc. And I might argue, we at first only support base32, and purge ambiguous pairs, 1, one, l, little-ell, 0, zero, O, capital O, q, g, and something I'm forgetting. Far more human friendly than base36. But that's dreaming, Standard will be base-2 to hexadecimal range.
Won't be in GnuCOBOL in time to suit any immediate needs though, Sergio, but I don't think it'll be too long.
I've done this with built in libgmp functions and CALL, with C source code helper and as a user defined function.
https://sourceforge.net/p/gnucobol/discussion/contrib/thread/031203b3/
Basically
or
Code is attached to the above link. It's old code, before the days of doing more low level things in straight up COBOL, ergo the C support code. Arbitrary precision in terms of the size of the numbers allowed.
Due to my limited understanding of UDF back then,
convert-baseis limited to an output of 256 "digits" in the returned output buffer. I picked a fixed length return buffer for the UDF, but the CALL version can handle arbitrarily long strings of digits, both for input and output.Cheers,
Blue
@btiffin Could you please try to integrate the 202x function into GC soon? It sounds that most of the actual work is already done, isn't it?
And a note: I've already added the two IBM functions (were requested by some people working on an IBM codebase conversion shortly before my vacation), this addition should be included very soon (I've already started to write the test cases, so possibly this week, still a lot mails to sort out before doing "actual" work). So don't mind those two intrinsic functions for now; I'll post a reference for the implementation here, too, so people can apply the patch to a local version of whatever GnuCOBOL (2.x+), too.
@ssamayoagt
HEX-OFandHEX-TO-CHAR(along withBIT-OFandBIT-TO-CHAR) are now implemented with [r4323] and will be available with 3.2 RC-1 this month.@btiffin: Is there any option that you can have a look at adding the missing pieces for COBOL 202x based on that?
Related
Commit: [r4323]
COOL :)
Now included in the PG manual.
On 02/09/2021 13:22, Simon Sobisch wrote:
Related
Commit: [r4323]