You can see the Java code implementation here
https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/UUID.java.
On 2019-11-14 3:15 PM, Timothy Sipples wrote:
Frank Swarbrick wrote:
The SWIFT payments network has a field called the UETR
(Unique End-to-end Transaction Reference), which is a
Version 4 UUID. Will the new Enterprise COBOL feature
be able to generate a Version 4 UUID?
You can already generate version 4 UUIDs via INVOKE to a small -- really,
really small -- bit of Java code. Here's a basic Java sample to generate a
version 4 UUID:
import java.util.UUID;
class UUIDSample
{
public static void main(String arg[]) throws
UnsupportedOperationException
{
UUID v4uuid = UUID.randomUUID();
// Then do what you want with v4uuid here
// (Return it, for example)
}
}
SWIFT may or may not need something more than a IETF RFC 4122 version 4
UUID.
This approach works with all z/OS and Enterprise COBOL releases that are
still in service, plus some past releases that have reached End of Service.
java.util.UUID was introduced all the way back in Java 5, for example. (The
Java 5 SDK for z/OS was released on December 16, 2005, and reached End of
Service on September 30, 2013.) I can't remember when INVOKE was first
introduced, but it was a long time ago.
Moreover, if you're concerned about entropy, my understanding with this
code sample is that it'll automatically benefit from the True Random Number
Generator (TRNG) included in the IBM z14 and later processors, just as long
as your Java Runtime Environment is recent enough (which is not
particularly recent at this point) to be aware of the TRNGs. On earlier
models you could presumably ask Crypto Express to provide a TRN to the JRE,
with a few more Java Cryptography Extension (JCE)-related lines of code I
imagine.
In short, while UUID (including UUID version 5) functions in Enterprise
COBOL and/or Language Environment would be most welcome in my view, you
don't have to wait, and you shouldn't wait. Solve the problem you have, and
it's very easy to solve, right now.
If somebody wants to raise an objection such as "Oh, I can't do that --
that's another language," then my basic response is "Don't be silly." JCL,
DL/I, and SQL are also languages that aren't COBOL, and so what? A COBOL
programmer would hardly be a competent one without knowing a little bit
about some other languages, enough to be useful and productive anyway. Two
of those three aren't included in the base z/OS operating system, as it
happens, but Java is. Did the English language wait to arrive at some
consensus alternative instantiations of the words sushi, taxi, and detente,
as examples? INVOKE is there for a reason (and has been for well over a
decade), so use it!
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
--------------------------------------------------------------------------------------------------------
E-Mail: sipp...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
