System 1047 and 1048

[Eugene Perry]

How are these new system items used? I wrote a program to display
them and they are different each time I run the program even though I
did not log off - same session.

1047=78c18d22-8c05-4c40-b905-fd1d216bd633
1048=1
:DISP.1047
1047=02dc5984-6794-4708-9aa2-7b9b20cc49fe
1048=2
:DISP.1047
1047=6d49afd6-90ff-4d47-8c71-abe2ef5b24b5
1048=3
:DISP.1047
1047=573a6af0-886a-4724-8ed5-83cd4b1ef05f
1048=4

Thanks

Eugene

[Martin Phillips]

Hi Eugene,

Correct. Both are variants on the concept of generating a unique id. A new call returns a new key.

SYSTEM(1047) returns a GUID string as is commonly used by Windows but found in lots of other software too. See Wikipedia etc for
general information on GUIDs.

SYSTEM(1048) returns a numeric value that will be unique for all calls to this function until the next time QM is completely
restarted. It is an alternative to SYSTEM(19) which came from Pick but could return the same id (eventually) for two users in
different time zones.


Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To post to this group, send an email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openqm+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openqm?hl=en-GB.

[Kevin Powick]

On Monday, 7 May 2012 09:55:21 UTC-4, Martin Phillips wrote:

SYSTEM(1048) returns a numeric value that will be unique for all calls to this function until the next time QM is completely
restarted.

Does this mean that the call could  return a duplicate ID at some time after a QM restart?  

--

Kevin Powick

[Kevin Powick]

Never mind.  I see in the 3.0 release notes that 1048 resets to 1 after a QM restart. 

--

Kevin Powick

[Martin Phillips]

Hi Kevin,

 

Although you have found the answer, SYSTEM(1048) is only unique until QM is completely restarted. It is good for unique ids that do not need to survive a restart. On the other hand, GUID values are supposed to be globally unique for all time.

 

 

Martin

--

You received this message because you are subscribed to the Google Groups "OpenQM" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/openqm/-/MRynhcCuqnEJ.

[Eugene Perry]

Martin,

I noticed this note in the docs:" Platforms that do not support this
operation return a null string"

Does this mean that it is windows only?

This and the note on system(19) about time zones makes it quite
interesting for finding something to use as a unique key.

What would you suggest to use for a unique key?

On May 7, 9:55 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

[Martin Phillips]

Hi Eugene,

> I noticed this note in the docs:" Platforms that do not support this
> operation return a null string"
>
> Does this mean that it is windows only?

No. Currently the only platform not supporting this is AIX on RS6000.

> This and the note on system(19) about time zones makes it quite
> interesting for finding something to use as a unique key.
>
> What would you suggest to use for a unique key?

If you want a true globally unique key, GUID is the way to go but generating these is quite costly in performance terms compared to
other non-global solutions. I think it all depends on "how unique" the key needs to be:
Globally unique = Use GUID
Unique until QM completely restarted = SYSTEM(1048)
Unique for duration of QM session = QM user number
and so on.

[Eugene Perry]

Martin,

That would seem to create a minor problem. I am not running on AIX on
RS6000 nor do I plan to be.

However, it would be nice to be able to always be able to use
system(1047) and not worry about it. Is there anyway that QM could at
least return the equivalent of system(19) on the aix.

The reason that I suggest this is because that way we do not have to
go changing code to check to see if it returned something and then so
a system(19).

If you have some other idea, I am quite interested in hearing it.

My goal is to minimize having to code for what system we are running
on.

Eugene

On May 7, 11:23 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

[Tony Gravagno]

Developers need to be careful about relying on System(1048). If the power goes out you don't want that being used as the ID for a work file that isn't re-initialized on a job restart.

 

System(12) might still be the best option for a value which is unique to the system, as it survives a reboot. However, I think this is unreliable at least one per year for a period of one hour when Daylight Saving time kicks off and we "fall back".

 

Heck, even the combination of System(12):System(48) is not perfectly unique if the system crashes during that one hour of the year.

 

The only way to ensure unique item IDs is still to generate the ID, Read on the target file, and re-generate if the item exists. This is probably as painful as generating a GUID.

 

So at the risk of being too "picky" about this, what are other options for a reliable unique value that isn't as painful as a GUID?

 

Personally I prefer all-numeric values. I wish we had a version of System(12) that returned an incrementing numeric rather than alpha:

Now: 16772992C

Numeric: 16772992.3

 

For sorting purposes I also wish we had a System(12) that masked the time on zeros:

Now: 1677200992.3

 

(Might those be 1049 and 1050?)

 

 

Because I write cross-platform utilities, I don't rely on any system mechanisms in the application code itself. I call to a common Included or Called subroutine:

  GOSUB GET.UNIQUE

  KEY = PREFIX:UNIQUE ; * or similar

So if I move the code to a different platform I can take advantage of new features like 1047 and 1048 without having to change any in-line app code. _That_ code might do a file lookup to ensure unique values, etc, removing this responsibility from the in-line code.

 

But we shouldn't need to do stuff like that… *sigh*

 

T

 

[Kevin Powick]

On Monday, 7 May 2012 11:56:04 UTC-4, Tony Gravagno wrote:

 

System(12) might still be the best option for a value which is unique to the system, as it survives a reboot.

You must be thinking of a different System() value, because System(12), is simply the number of seconds since midnight.  Pretty much useless for any type of an item ID.

Perhaps it was System(19)?

--

Kevin Powick

[Tony Gravagno]

Whoops, yeah, RU9999/12/19 - thanks. (Time for second cup of coffee…)

[Martin Phillips]

Hi Eugene,

I am reluctant for us to change SYSTEM(1047) to return something other than a true GUID or a null string where GUIDs are not
available. We are still investigating how to get a GUID value on the RS6000 system and this should appear in a future release. One
of our users had an urgent need for GUIDs so we released a partial soluiton.

The SYSTEM(19) value is known to be unreliable on systems that span time zones. SYSTEM(1048) is only unique up to a restart. Whether
this is a problem depends on why you want a "unique" id in the first place. Quite often, uniqueness only matters up to some point in
time (e.g. ids for temporary records that have no significance after the process terminates).

As Tony said in his response, the only other way to generate a truly unique id is to do it yourself.


Martin

[Tony Gravagno]

Random bits of information which may help someone on this topic...

The OS may not offer what we need, but until something better is
available we can easily shell out for the data - which might be
exactly what Martin is doing.

The AIX equivalent of a GUID is the Enterprise-Wide Unique identifier
(EWU):
http://www.ibm.com/developerworks/aix/library/au-enterprise_wide/index
..html

For my security code in AIX I use "uname" and get the unique system
identifier, then concatenate other values on to that. Unfortunately
uname works differently across AIX releases and needs to be tested. I
can provide more info here if really required but it would take some
time to check my code. Also, doesn't really apply here, for some
reason when Redback is running on U2 we've found that uname returns
different values on the same system than directly from shell or U2/SH.
I suspect this is related to permissions but worked around it after
Rocket was unable to diagnose the issue.

I don't know how reliable this is, but if you really need a GUID you
can load Perl to make use of Data::UUID.
http://search.cpan.org/~rjbs/Data-UUID-1.217/UUID.pm
For a similar solution with PHP, use function uniqid.
http://php.net/manual/en/function.uniqid.php
(Other developer contributions for UUID on that page might help.)
And in Java:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html
I'm not sure how "truly" "globally" unique these solutions are because
I think most of them they rely on randomness, which might not be truly
"unique" in the strictest definition.

What's good about the latter solutions here with Perl, PHP, or Java,
is that you can use the exact same underlying solution on any OS,
including Windows, Linux, Mac, and AIX.

HTH
T

[Ross Ferris]

There ARE easier ways to create an ID that is guaranteed unique
(WITHIN a known eco-system of interconnected systems, rather than
across ALL systems like a GUID ), doesn't suffer file contention
bottlenecks, has virtually no overhead, nor does it have an hour
window of possible failure each year with daylight saving ... and, if
it matters, you would end up with shorter @ID's.

We developed back in the VERY early days of R83, well before
SYSTEM(19) was a glimmer in someones eye

Whole routine is encapsulated as

CALL WRITE.UNIQUE(file,record,ID)

where file is the file variable of the file that you want to write the
record to, and the ID is returned, just in case you want to maintain
your own inversion files or something

Martin, if you are interested I can send you the 20 lines of code
(Hmmm, maybe I should package as a $20 routine that would work on
every MV platform ...? Nah, people would never buy it, and I don't
drink beer [odd for an Aussie I know])

On May 7, 11:55 pm, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

> Hi Eugene,
>
> Correct. Both are variants on the concept of generating a unique id. A new call returns a new key.
>
> SYSTEM(1047) returns a GUID string as is commonly used by Windows but found in lots of other software too. See Wikipedia etc for
> general information on GUIDs.
>
> SYSTEM(1048) returns a numeric value that will be unique for all calls to this function until the next time QM is completely
> restarted. It is an alternative to SYSTEM(19) which came from Pick but could return the same id (eventually) for two users in
> different time zones.
>
> Martin Phillips
> Ladybridge Systems Ltd

> 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England+44 (0)1604-709200begin_of_the_skype_highlighting            +44 (0)1604-709200

[Martin Phillips]

Hi Ross,

Thanks for your thoughts on this thread.

The motivation behind these two SYSTEM() keys was that they were requested by a user. The requirement was specifically for a GUID
and a simple rolling sequence number that would be unique across all running processes but had no validity after total restart of
QM.

Yes, there are alternatives that are "less unique". If any readers of this thread want to know more about your version, I am sure
that they will contact you.