Using VMSTIMPESTAMP as part of an index - for processed please
read processid
Joe Boyle
atla38 at dsl.pipex.com
Wed Jun 8 04:41:57 CDT 2005
for processed please read processid, and if you might be looping sequential
writes to the table you could use three segments where the third is
populated from a local temp as follows,
temp unqtemp reset at startup
let unqtemp = unqtemp + 1
let third_table_seg = unqtemp
.
.
put unq_table reset
I can't believe that quick could move screens, or invoke a qtp run in less
than 100th of a second, so the processid, temp and vmstimestamp would always
be unique.
P.S. the typo came as a result of outlook auto spell-correcting -
incorrectly.
Regards, Joe.
_____
From: powerh-l-bounces at lists.sowder.com
[mailto:powerh-l-bounces at lists.sowder.com] On Behalf Of Joe Boyle
Sent: 08 June 2005 09:55
To: 'John Stires'; powerh-l at lists.sowder.com
Subject: RE: Using VMSTIMPESTAMP as part of an index
how about a two segment index, one of which is a vmstimestamp column, and
the other is set to the value of a getsystemval call to a logical/symbol
which contains the current processed; if anyone can remind me what the DCL
is to return the processed ( or probably which lexical ) I would greatly
appreciate it.
The logical/symbol could be determined and set by the first called screen
via a setsystemval call, rather than for each individual row write.
Regards, Joe.
_____
From: powerh-l-bounces at lists.sowder.com
[mailto:powerh-l-bounces at lists.sowder.com] On Behalf Of John Stires
Sent: 08 June 2005 01:36
To: powerh-l at lists.sowder.com
Subject: Using VMSTIMPESTAMP as part of an index
We have a history file that gets a tremendous number hits at various times
of the day. We have concerns about the accuracy of this history table and
that the order, sequence, the records are written to this table is
absolutely accurate.
We need to have a highly accurate (high precision) date/time stamp solely
for the purpose of sequentially retrieving records in an RBD database. A
value will never be used in this field to access any given record(s) in this
table. As I say, the only reason for this field is to force a unique key
and to facilitate their sequential retrieval.
We are running on a Vax running OpenVMS, V6.2, with PowerHouse version
7.10.E6.
We have a bit of a discussion as to whether VMSTIMESTAMP would be a viable
option to populate this field. Will VMSTIMESTAMP give us a reliable value
for this purpose? If it will not, does anyone have a better alternative?
Thanks,
pencarver
(John Stires)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20050608/53d141b8/attachment-0001.html
More information about the powerh-l
mailing list