Re: Question - UUID Approach for Mainframes in Japan
Hello again Leonardo,
I just found this
https://www.ibm.com/support/knowledgecenter/SSSH27_8.0.1/com.ibm.rational.clearcase.cczose.doc/topics/r_cce_ibm930.htm
The first paragraph reads:
*Because IBM-930 does not support lowercase alphabet characters, TSO client
does not support them either.*
So, I guess IBM-930 just does not provide support for lowercase alphabetics.
On Thu, Nov 28, 2019 at 9:56 AM Leonardo Vaz wrote:
> Wow, thanks for replying, that is interesting and I'd love to know if you
> get to any conclusion. Maybe a feature lack on the emulator you are using,
> the emulator I use doesn't even has IBM-930 so I can't even test it here
> but comes to show that support for that code page may be lacking overall.
>
> Regards,
> Leo
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Thursday, November 28, 2019 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question - UUID Approach for Mainframes in Japan
>
> Hello Leonardo,
> I am sorry I took so long, but I wanted to get all my ducks in line.
> The link you provided shows lower case English letters with hex values
> x'62'-x'69', x'71'-x'78', x'8B', x'9B', x'AB', and x'B3'-x'B9'.
> I created a small file with all the 256 EBCDIC hex combinations, and
> browsed it after setting my emulator Host CodePage to IBM-930. (IBM PCOM)
> All of the above listed hex values show a blank character displayed.
>
> When I browse the same file after setting my PCOM emulator Host CodePage to
> EBCDIC IBM-037, I see lower case English Letters in hex positions
> x'81'-x'89', x'91'-x'99', and x'A2'-x'A9'.
> These hex positions are occupied by SBCS Katakana characters in the EBCDIC
> CodePage 930 display.
>
> Then I took my little file, and transformed it from IBM-930 to UTF-8.
> When I browse that file as a UTF-8 encoded file, I can see lower case
> English letters.
>
> I hope this all makes some sense to you.
> I tried to be as diligent as possible in gathering the information.
>
> What this actually means is a bit beyond me. Characters really are
> converted as per the chart, but never displayed... hm.
> I think that the emulator may be doing something, or perhaps something
> happens within the 3270 datastream.
> In any event,my emulator does not render any displayable characters for the
> hex positions indicated by the lower case English values, as if they do not
> exist.
>
> This is interesting. And I need to do some more thinking on this, but I
> already have an approach to deal with the UUID as per Charles and Attila.
>
> Thanks
>
> On Mon, Nov 25, 2019 at 4:05 PM Leonardo Vaz wrote:
>
> > Hello Cameron!
> >
> > I see all lowercase letters on
> > http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
> >
> > Why do you say there is no support?
> >
> > Regards,
> > Leo
> >
> >
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Cameron Conacher
> > Sent: Monday, November 25, 2019 3:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Question - UUID Approach for Mainframes in Japan
> >
> > Hello folks,
> > I am here with another question today.
> > We are a large international company with a market presence in Japan.
> > We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> > 930.
> > This CodePage has no support for lower case English letters.
> >
> > If I were a distributed platform and I generated a UTF-8 encoded UUID
> > value, and sent this value to the mainframe, it would be then transformed
> > into EBCDIC CodePage 930.
> > If the UUID were to be generated with any lower case English values ("a",
> > "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> > conversion/transformation time, since the underlying EBCDIC CodePage
> cannot
> > support the value.
> > However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> > or "F"), everything would flow and transform politely.
> >
> > So, my question is whether in the Japan world, mainframe application
> expect
> > Consumers to send only upper cased values, or if an intermediate step
> prior
> > to message transformation occurs close to the mainframe side of things to
> > force upper casing of the UUID.
> > Or some other technique?
> > Similarly, if a UUID were to be sent from the mainframe to the middle
> tier
> > somewhere, should I expect
Re: Question - UUID Approach for Mainframes in Japan
Wow, thanks for replying, that is interesting and I'd love to know if you get
to any conclusion. Maybe a feature lack on the emulator you are using, the
emulator I use doesn't even has IBM-930 so I can't even test it here but comes
to show that support for that code page may be lacking overall.
Regards,
Leo
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Thursday, November 28, 2019 9:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question - UUID Approach for Mainframes in Japan
Hello Leonardo,
I am sorry I took so long, but I wanted to get all my ducks in line.
The link you provided shows lower case English letters with hex values
x'62'-x'69', x'71'-x'78', x'8B', x'9B', x'AB', and x'B3'-x'B9'.
I created a small file with all the 256 EBCDIC hex combinations, and
browsed it after setting my emulator Host CodePage to IBM-930. (IBM PCOM)
All of the above listed hex values show a blank character displayed.
When I browse the same file after setting my PCOM emulator Host CodePage to
EBCDIC IBM-037, I see lower case English Letters in hex positions
x'81'-x'89', x'91'-x'99', and x'A2'-x'A9'.
These hex positions are occupied by SBCS Katakana characters in the EBCDIC
CodePage 930 display.
Then I took my little file, and transformed it from IBM-930 to UTF-8.
When I browse that file as a UTF-8 encoded file, I can see lower case
English letters.
I hope this all makes some sense to you.
I tried to be as diligent as possible in gathering the information.
What this actually means is a bit beyond me. Characters really are
converted as per the chart, but never displayed... hm.
I think that the emulator may be doing something, or perhaps something
happens within the 3270 datastream.
In any event,my emulator does not render any displayable characters for the
hex positions indicated by the lower case English values, as if they do not
exist.
This is interesting. And I need to do some more thinking on this, but I
already have an approach to deal with the UUID as per Charles and Attila.
Thanks
On Mon, Nov 25, 2019 at 4:05 PM Leonardo Vaz wrote:
> Hello Cameron!
>
> I see all lowercase letters on
> http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
>
> Why do you say there is no support?
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> 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
>
Re: Question - UUID Approach for Mainframes in Japan
Hello Leonardo,
I am sorry I took so long, but I wanted to get all my ducks in line.
The link you provided shows lower case English letters with hex values
x'62'-x'69', x'71'-x'78', x'8B', x'9B', x'AB', and x'B3'-x'B9'.
I created a small file with all the 256 EBCDIC hex combinations, and
browsed it after setting my emulator Host CodePage to IBM-930. (IBM PCOM)
All of the above listed hex values show a blank character displayed.
When I browse the same file after setting my PCOM emulator Host CodePage to
EBCDIC IBM-037, I see lower case English Letters in hex positions
x'81'-x'89', x'91'-x'99', and x'A2'-x'A9'.
These hex positions are occupied by SBCS Katakana characters in the EBCDIC
CodePage 930 display.
Then I took my little file, and transformed it from IBM-930 to UTF-8.
When I browse that file as a UTF-8 encoded file, I can see lower case
English letters.
I hope this all makes some sense to you.
I tried to be as diligent as possible in gathering the information.
What this actually means is a bit beyond me. Characters really are
converted as per the chart, but never displayed... hm.
I think that the emulator may be doing something, or perhaps something
happens within the 3270 datastream.
In any event,my emulator does not render any displayable characters for the
hex positions indicated by the lower case English values, as if they do not
exist.
This is interesting. And I need to do some more thinking on this, but I
already have an approach to deal with the UUID as per Charles and Attila.
Thanks
On Mon, Nov 25, 2019 at 4:05 PM Leonardo Vaz wrote:
> Hello Cameron!
>
> I see all lowercase letters on
> http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
>
> Why do you say there is no support?
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> 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
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question - UUID Approach for Mainframes in Japan
Thanks everyone
This is great.
Sent from my iPhone
> On Nov 26, 2019, at 5:23 PM, Charles Mills wrote:
>
> Yeah, sorry, I fully admit I have zero real-world experience with UUIDs on Z
> -- Japanese or otherwise. And relatively little elsewhere: I have used them
> for version signing on Visual Studio -- that's it.
>
> I would certainly think (hope!) that any reasonable code would be using the
> underlying 128-bit binary value, and whether you used abc, ABC or some
> mixture would be irrelevant.
>
> I think the standard is pretty clear: the 128-bit binary value *is* the UUI,
> the character string is just a representation thereof, and upper-case hex
> values are acceptable.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Tuesday, November 26, 2019 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question - UUID Approach for Mainframes in Japan
>
> Thanks Charles,
> I was hoping someone with a Japan background would weigh in to say
> something along the lines of "have the Consumers upper case the UUID BEFORE
> they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
> BEFORE the strings arrive in the mainframe". or something else.
>
> If a Consumer were to send me a UUID in Lower Case and I return a reply
> with the UUID Upper Cased, does this cause some inconsistency on the
> Consumer's side of the fence?
> I mean, functionally, the UUIDs are the same, but the actual string values
> are different.
> Does this create issues?
>
>
>> On Mon, Nov 25, 2019 at 4:30 PM Charles Mills wrote:
>>
>> UUID letters as generated are all lower case, so you could translate them
>> to upper case without losing any information.
>>
>> Anything that accepts UUIDs must be prepared to accept upper case, so you
>> would be good to go.
>>
>> -- https://tools.ietf.org/html/rfc4122#section-3
>>
>> Charles
>>
>>
>> -----Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Cameron Conacher
>> Sent: Monday, November 25, 2019 3:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Question - UUID Approach for Mainframes in Japan
>>
>> Hello folks,
>> I am here with another question today.
>> We are a large international company with a market presence in Japan.
>> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
>> 930.
>> This CodePage has no support for lower case English letters.
>>
>> If I were a distributed platform and I generated a UTF-8 encoded UUID
>> value, and sent this value to the mainframe, it would be then transformed
>> into EBCDIC CodePage 930.
>> If the UUID were to be generated with any lower case English values ("a",
>> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
>> conversion/transformation time, since the underlying EBCDIC CodePage cannot
>> support the value.
>> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
>> or "F"), everything would flow and transform politely.
>>
>> So, my question is whether in the Japan world, mainframe application expect
>> Consumers to send only upper cased values, or if an intermediate step prior
>> to message transformation occurs close to the mainframe side of things to
>> force upper casing of the UUID.
>> Or some other technique?
>> Similarly, if a UUID were to be sent from the mainframe to the middle tier
>> somewhere, should I expect that the mainframe would only pas along upper
>> cased values in the UUID area?
>>
>> I believe I can handle things on the mainframe side by transforming the
>> entire message to UTF-16BE, and then upper casing the UUID, and then
>> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
>> Not sure if this is a "good" way, but it would work.
>>
>> Any thoughts?
>>
>> Thanks
>>
>> ...Cameron
>>
>> --
>> 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 messag
Re: Question - UUID Approach for Mainframes in Japan
Yeah, sorry, I fully admit I have zero real-world experience with UUIDs on Z --
Japanese or otherwise. And relatively little elsewhere: I have used them for
version signing on Visual Studio -- that's it.
I would certainly think (hope!) that any reasonable code would be using the
underlying 128-bit binary value, and whether you used abc, ABC or some mixture
would be irrelevant.
I think the standard is pretty clear: the 128-bit binary value *is* the UUI,
the character string is just a representation thereof, and upper-case hex
values are acceptable.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Tuesday, November 26, 2019 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question - UUID Approach for Mainframes in Japan
Thanks Charles,
I was hoping someone with a Japan background would weigh in to say
something along the lines of "have the Consumers upper case the UUID BEFORE
they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
BEFORE the strings arrive in the mainframe". or something else.
If a Consumer were to send me a UUID in Lower Case and I return a reply
with the UUID Upper Cased, does this cause some inconsistency on the
Consumer's side of the fence?
I mean, functionally, the UUIDs are the same, but the actual string values
are different.
Does this create issues?
On Mon, Nov 25, 2019 at 4:30 PM Charles Mills wrote:
> UUID letters as generated are all lower case, so you could translate them
> to upper case without losing any information.
>
> Anything that accepts UUIDs must be prepared to accept upper case, so you
> would be good to go.
>
> -- https://tools.ietf.org/html/rfc4122#section-3
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> 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
>
--
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
Re: Question - UUID Approach for Mainframes in Japan
The UUID specification requires accepting both lowercase and uppercase
letters as input, so changing lowercase to uppercase does not change the
value of the UUID.
That same specification specifies that only lowercase is allowed for output
(to make it more human readable), however many implementations in the past
have generated mixed case.
This behaviour is sensible as the UUID is actually a 128 bit hex number
being represented as hex letters (0-9, a-f) and only used as the 128-bit
number internally.
Bottom line is there is no issue for Japan for any codepage that you might
be using (or if the codepage is changed).
On Wed, Nov 27, 2019 at 1:01 AM Cameron Conacher wrote:
> Thanks Charles,
> I was hoping someone with a Japan background would weigh in to say
> something along the lines of "have the Consumers upper case the UUID BEFORE
> they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
> BEFORE the strings arrive in the mainframe". or something else.
>
> If a Consumer were to send me a UUID in Lower Case and I return a reply
> with the UUID Upper Cased, does this cause some inconsistency on the
> Consumer's side of the fence?
> I mean, functionally, the UUIDs are the same, but the actual string values
> are different.
> Does this create issues?
>
>
> On Mon, Nov 25, 2019 at 4:30 PM Charles Mills wrote:
>
> > UUID letters as generated are all lower case, so you could translate them
> > to upper case without losing any information.
> >
> > Anything that accepts UUIDs must be prepared to accept upper case, so you
> > would be good to go.
> >
> > -- https://tools.ietf.org/html/rfc4122#section-3
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Cameron Conacher
> > Sent: Monday, November 25, 2019 3:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Question - UUID Approach for Mainframes in Japan
> >
> > Hello folks,
> > I am here with another question today.
> > We are a large international company with a market presence in Japan.
> > We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> > 930.
> > This CodePage has no support for lower case English letters.
> >
> > If I were a distributed platform and I generated a UTF-8 encoded UUID
> > value, and sent this value to the mainframe, it would be then transformed
> > into EBCDIC CodePage 930.
> > If the UUID were to be generated with any lower case English values ("a",
> > "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> > conversion/transformation time, since the underlying EBCDIC CodePage
> cannot
> > support the value.
> > However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> > or "F"), everything would flow and transform politely.
> >
> > So, my question is whether in the Japan world, mainframe application
> expect
> > Consumers to send only upper cased values, or if an intermediate step
> prior
> > to message transformation occurs close to the mainframe side of things to
> > force upper casing of the UUID.
> > Or some other technique?
> > Similarly, if a UUID were to be sent from the mainframe to the middle
> tier
> > somewhere, should I expect that the mainframe would only pas along upper
> > cased values in the UUID area?
> >
> > I believe I can handle things on the mainframe side by transforming the
> > entire message to UTF-16BE, and then upper casing the UUID, and then
> > transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> > Not sure if this is a "good" way, but it would work.
> >
> > Any thoughts?
> >
> > Thanks
> >
> > ...Cameron
> >
> > --
> > 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
> >
>
> --
> 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
Re: Question - UUID Approach for Mainframes in Japan
Thanks Charles,
I was hoping someone with a Japan background would weigh in to say
something along the lines of "have the Consumers upper case the UUID BEFORE
they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
BEFORE the strings arrive in the mainframe". or something else.
If a Consumer were to send me a UUID in Lower Case and I return a reply
with the UUID Upper Cased, does this cause some inconsistency on the
Consumer's side of the fence?
I mean, functionally, the UUIDs are the same, but the actual string values
are different.
Does this create issues?
On Mon, Nov 25, 2019 at 4:30 PM Charles Mills wrote:
> UUID letters as generated are all lower case, so you could translate them
> to upper case without losing any information.
>
> Anything that accepts UUIDs must be prepared to accept upper case, so you
> would be good to go.
>
> -- https://tools.ietf.org/html/rfc4122#section-3
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> 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
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question - UUID Approach for Mainframes in Japan
UUID letters as generated are all lower case, so you could translate them to
upper case without losing any information.
Anything that accepts UUIDs must be prepared to accept upper case, so you would
be good to go.
-- https://tools.ietf.org/html/rfc4122#section-3
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Monday, November 25, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
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
Re: Question - UUID Approach for Mainframes in Japan
Hello Cameron!
I see all lowercase letters on
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
Why do you say there is no support?
Regards,
Leo
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Monday, November 25, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
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
Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
