Re: What is GUID format

IMHO, you should store this as a 16-byte character FOR BIT DATA, or perhaps
two 8-byte integers...

Especially if you plan to have an index over this field. (though I agree
with the side of the debate saying using GUID's as primary keys is a bad
idea. :)

You can display it, via UDF, in whatever hexadecimal string form you'd
like.

Ideally, you could create a user defined type to handle this.

The only problem is that your caller's may insist on passing the GUID/UUID
in as a 32 to 38 byte hexadecimal string with one of the
various formatting patterns as already mentioned included. I think if you
search the archives you'll find some posts on decoding a hex string...

It's amazing how many Windows/Linux developers mistake the hexadecimal
representation of a GUID/UUID for the actual 16 byte value. The tools they
use with built in support for GUID/UUID automatically convert between
internal/external representation (just like they do for
Date/time/timestamps)

Charles


On Fri, Nov 30, 2012 at 7:24 AM, Alan Shore <ashore@xxxxxxxx> wrote:

Morning everyone
Maybe I am showing my ignorance - but then that's nothing new.
I am involved in a brand new project and have been told that a parameter
is going to be passed to the as400 in GUID format.
I am googling "GUID format AS400" and even though its mentioned all over
the place, I am having trouble in locating how to store this data (maximum
size etc. ) on the as400 as this parameter will be needed elsewhere.
If anyone can help, it would be MUCH appreciated

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


Disclaimer: This message contains confidential information and is intended
only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake
and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
version. Any views or opinions presented are solely those of the author and
do not necessarily represent those of the company.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.