There is a way around this - but it depends on the purpose of the clist in the first place. You could, for example, run a btach UCF job which has a number of lime mode IO tasks in the input stream. If any task fails subsequent tasks will still run - as each time a task ends Enter-Next-Task-Code is presented. Note - our last task is always either SIGNOFF or BYE because the batch UCF terminal can become disabled if it does not encounter a so long and see you later task before the end of the job stream.
If we knew how and why the CLIST was invoked in the first place there may be other options available - but without more information I would not be game to suggest them ?
Cheers - Gary
Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:
gary.cherlet@sa.gov.au
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Arithmetic on FORMAT=(DTS) date from #GETIME
"#GETIME FORMAT=3D(DTS) returns a 64 bit date/time stamp (same as the SQL da=
te/time stamp) in registers 0 and 1. Does anybody know if you can perform a=
rithmetic on, for example, successive values of a FORMAT=3D(DTS) date/time =
stamp.
In this instance all I am after is differences, often measured in nanoseco=
nds and rarely across minutes, between two times.
If I can get the time difference by simply getting successive values of FOR=
MAT=3D(DTS) and subtracting - then all is beautiful - I could use IDMSIN01 =
to give me DISPLAY values of the resultant time difference.
The main reason for asking is that this solves all of the problems with fir=
st time in one day (or year) and the second time being in another day (or y=
ear). It also means I don't have to write my own formatting in assembler - =
but that's been done before 8-)
TIA - cheers - Gary
Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
~~ MailTo:
gary.cherlet@sa.gov.au
Gary says: Grab them by their data - and their hearts and minds will follow=
!
This e-mail message and any attachments are qualified as follows: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Arithmetic on FORMAT=(DTS) date from #GETIME
"#GETIME FORMAT=(DTS) returns a 64 bit date/time stamp (same as the SQL date/time stamp) in registers 0 and 1. Does anybody know if you can perform arithmetic on, for example, successive values of a FORMAT=(DTS) date/time stamp.
In this instance all I am after is differences, often measured in nanoseconds and rarely across minutes, between two times.
If I can get the time difference by simply getting successive values of FORMAT=(DTS) and subtracting - then all is beautiful - I could use IDMSIN01 to give me DISPLAY values of the resultant time difference.
The main reason for asking is that this solves all of the problems with first time in one day (or year) and the second time being in another day (or year). It also means I don't have to write my own formatting in assembler - but that's been done before 8-)
TIA - cheers - Gary
Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
~~ MailTo:
gary.cherlet@sa.gov.au
Gary says: Grab them by their data - and their hearts and minds will follow!
This e-mail message and any attachments are qualified as follows: Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents. Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services. Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: Arithmetic on FORMAT=(DTS) date from #GETIME
"Rm9yIHNvbWUgdW5rbm93biByZWFzb24sIGEgbnVtYmVyIG9mIHllYXJzIGFnbyBJIHdvcmtlZCBv
dXQgdGhlIGZvcm1hdCBvZiB0aGUgSURNUyBEVFMuIEkgcHVsbGVkIG15IG9sZCBub3RlcyBhbmQg
dGhpcyBpcyB3aGF0IEkgaGFkIGZvdW5kOg0KDQpCaXRzIDAtMjYgKDI3IGJpdHMpIGlzIHRoZSBk
YXRlLiBJdCBpcyB0aGUgbnVtYmVyIG9mIGRheXMgc2luY2UgMS8xLzAwMDEuIEUuLmcuIDcyOCw4
MjcgaXMgMDYvMTkvMTk5NiAoc2hvd2luZyBob3cgbG9uZyBhZ28gSSBkaWQgdGhpcyA6LSkgKQ0K
DQpCaXRzIDI3LTQzICgxNyBiaXRzKSBpcyB0aGUgdGltZSBpbiBzZWNvbmRzLiBJdCBpcyB0aGUg
bnVtYmVyIG9mIHNlY29uZHMgc2luY2UgbWlkbmlnaHQuIEUuZy4gMSAtIDAwOjAwOjAxIC0gMSBz
ZWNvbmQgYWZ0ZXIgbWlkbmlnaHQuIDg2LDM5OSAoeCcxNTE3RicpIGlzIDIzOjU5OjU5IHdoaWNo
IGlzIGFsc28gdGhlIG1heCB2YWx1ZSB5b3UnbGwgc2VlLg0KDQpCaXRzIDQ0LTYzICgyMCBiaXRz
KSBpcyBhIG51bWJlciB0aGF0IHJlcHJlc2VudHMgdGhlIHN1YiBzZWNvbmQgaW4gMS8xLDAwMCww
MDAncyBvZiBhIHNlY29uZC4gTWF4IHZhbHVlIGlzIG9mIGNvdXJzZSA5OTksOTk5IG9yIHgnRjQy
M0YnLg0KDQpVbmZvcnR1bmF0ZWx5IHdpdGggdGhpcyBmb3JtYXQgeW91IHdpbGwgaGF2ZSBwcm9i
bGVtcyBkb2luZyBkaXJlY3QgYXJpdGhtZXRpYyBiZXR3ZWVuIHR3byB2YWx1ZXMgYXMgc29vbiBh
cyBvbmUgZGF0ZS90aW1lIHN0YW1wIGlzIGluIG9uZSBzZWNvbmQgdGhlIG90aGVyIGluIGEgZGlm
ZmVyZW50IHNlY29uZCAtIGxldCBhbG9uZyB3b3JyeWluZyBhYm91dCBkYXlzIG9yIHllYXJzLiAN
Cg0KVGltZSB0byBicmVhayBvdXQgdGhlIGFzc2VtYmxlci4NCg0KUmVnYXJkcywNClN0ZXZlDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRE1TIFB1YmxpYyBEaXNjdXNzaW9u
IEZvcnVtIFttYWlsdG86SURNUy1MQExJU1RTRVJWLklVQVNTTi5DT01dIE9uIEJlaGFsZiBPZiBD
aGVybGV0LCBHYXJ5IChKVFMpDQpTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAxOjI5IFBN
DQpUbzogSURNUy1MQExJU1RTRVJWLklVQVNTTi5DT00NClN1YmplY3Q6IEFyaXRobWV0aWMgb24g
Rk9STUFUPShEVFMpIGRhdGUgZnJvbSAjR0VUSU1FDQoNCiNHRVRJTUUgRk9STUFUPShEVFMpIHJl
dHVybnMgYSA2NCBiaXQgZGF0ZS90aW1lIHN0YW1wIChzYW1lIGFzIHRoZSBTUUwgZGF0ZS90aW1l
IHN0YW1wKSBpbiByZWdpc3RlcnMgMCBhbmQgMS4gRG9lcyBhbnlib2R5IGtub3cgaWYgeW91IGNh
biBwZXJmb3JtIGFyaXRobWV0aWMgb24sIGZvciBleGFtcGxlLCBzdWNjZXNzaXZlIHZhbHVlcyBv
ZiBhIEZPUk1BVD0oRFRTKSBkYXRlL3RpbWUgc3RhbXAuDQoNCkluIHRoaXMgaW5zdGFuY2UgYWxs
IEkgYW0gYWZ0ZXIgaXMgZGlmZmVyZW5jZXMsICBvZnRlbiBtZWFzdXJlZCBpbiBuYW5vc2Vjb25k
cyBhbmQgcmFyZWx5IGFjcm9zcyBtaW51dGVzLCBiZXR3ZWVuIHR3byB0aW1lcy4NCg0KSWYgSSBj
YW4gZ2V0IHRoZSB0aW1lIGRpZmZlcmVuY2UgYnkgc2ltcGx5IGdldHRpbmcgc3VjY2Vzc2l2ZSB2
YWx1ZXMgb2YgRk9STUFUPShEVFMpIGFuZCBzdWJ0cmFjdGluZyAtIHRoZW4gYWxsIGlzIGJlYXV0
aWZ1bCAtIEkgY291bGQgdXNlIElETVNJTjAxIHRvIGdpdmUgbWUgRElTUExBWSB2YWx1ZXMgb2Yg
dGhlIHJlc3VsdGFudCB0aW1lIGRpZmZlcmVuY2UuDQoNClRoZSBtYWluIHJlYXNvbiBmb3IgYXNr
aW5nIGlzIHRoYXQgdGhpcyBzb2x2ZXMgYWxsIG9mIHRoZSBwcm9ibGVtcyB3aXRoIGZpcnN0IHRp
bWUgaW4gb25lIGRheSAob3IgeWVhcikgYW5kIHRoZSBzZWNvbmQgdGltZSBiZWluZyBpbiBhbm90
aGVyIGRheSAob3IgeWVhcikuIEl0IGFsc28gbWVhbnMgSSBkb24ndCBoYXZlIHRvIHdyaXRlIG15
IG93biBmb3JtYXR0aW5nIGluIGFzc2VtYmxlciAtIGJ1dCB0aGF0J3MgYmVlbiBkb25lIGJlZm9y
ZSAgICA4LSkNCg0KVElBIC0gY2hlZXJzIC0gR2FyeQ0KDQpHYXJ5IENoZXJsZXQNCkp1c3RpY2Ug
VGVjaG5vbG9neSBTZXJ2aWNlcw0KRGVwYXJ0bWVudCBvZiBKdXN0aWNlLCBTQSBHb3Zlcm5tZW50
DQoNCiIiIiIgICAgIFRlbGVwaG9uZSArNjEgKDApOCAgODIyNiA1MTk5DQogQEAgICAgICBGYWNz
aW1pbGUgICs2MSAoMCk4ICA4MjI2IDUzMTENCiAgPiAgICAgIE1vYmlsZSAgICAgICArNjEgKDAp
NDEgMzMzIDE2MTMNCiB+fiAgICAgIE1haWx0bzpnYXJ5LmNoZXJsZXRAc2EuZ292LmF1DQoNCg0K
R2FyeSBzYXlzOiBHcmFiIHRoZW0gYnkgdGhlaXIgZGF0YSAtIGFuZCB0aGVpciBoZWFydHMgYW5k
IG1pbmRzIHdpbGwgZm9sbG93IQ0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo
bWVudHMgYXJlIHF1YWxpZmllZCBhcyBmb2xsb3dzOiBBZGRyZXNzaW5nOiAgSWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBhZHZpc2UgYnkgcmVwbHkgZS1t
YWlsIHRvIHRoZSBzZW5kZXIuICBQbGVhc2UgYWxzbyBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFu
c21pc3Npb24gYW5kIGl0cyBjb250ZW50cy4gQ29uZmlkZW50aWFsaXR5OiAgVGhpcyBlLW1haWwg
bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIHdoaWNoIGFsc28gbWF5IGJlIGxl
Z2FsbHkgcHJpdmlsZWdlZC4gIE9ubHkgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBtYXkgYWNj
ZXNzLCB1c2UsIGRpc3RyaWJ1dGUgb3IgY29weSB0aGlzIGUtbWFpbC4gSW5kaXZpZHVhbCBWaWV3
czogIFVubGVzcyBvdGhlcndpc2UgaW5kaWNhdGVkLCB0aGUgdmlld3MgZXhwcmVzc2VkIGFyZSB0
aG9zZSBvZiB0aGUgc2VuZGVyLCBub3QgSnVzdGljZSBUZWNobm9sb2d5IFNlcnZpY2VzLiBDb21w
dXRlciBWaXJ1c2VzOiAgSXQgaXMgdGhlIHJlY2lwaWVudCdzIHJlc3BvbnNpYmlsaXR5IHRvIGNo
ZWNrIHRoZSBlLW1haWwgYW5kIGFueSBhdHRhY2hlZCBmaWxlcyBmb3IgdmlydXNlcy4NCioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0
aGlzIG1lc3NhZ2UsIGluY2x1ZGluZyBhdHRhY2htZW50cywgbWF5IGNvbnRhaW4NCnByaXZpbGVn
ZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgZGVs
aXZlcmVkIG9ubHkgdG8gdGhlDQpwZXJzb24gaWRlbnRpZmllZCBhYm92ZS4gSWYgeW91IGFyZSBu
b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgdGhlIHBlcnNvbg0KcmVzcG9uc2libGUgZm9y
IGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIFdpbmRz
dHJlYW0gcmVxdWVzdHMNCnRoYXQgeW91IGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFu
ZCBhc2tzIHRoYXQgeW91IGRvIG5vdCByZWFkIHRoZSBtZXNzYWdlIG9yIGl0cw0KYXR0YWNobWVu
dHMsIGFuZCB0aGF0IHlvdSBkZWxldGUgdGhlbSB3aXRob3V0IGNvcHlpbmcgb3Igc2VuZGluZyB0
aGVtIHRvIGFueW9uZSBlbHNlLg0K
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: Arithmetic on FORMAT=(DTS) date from #GETIME
"For some unknown reason, a number of years ago I worked out the format of the IDMS DTS. I pulled my old notes and this is what I had found:
Bits 0-26 (27 bits) is the date. It is the number of days since 1/1/0001. E..g. 728,827 is 06/19/1996 (showing how long ago I did this :-) )
Bits 27-43 (17 bits) is the time in seconds. It is the number of seconds since midnight. E.g. 1 - 00:00:01 - 1 second after midnight. 86,399 (x'1517F') is 23:59:59 which is also the max value you'll see.
Bits 44-63 (20 bits) is a number that represents the sub second in 1/1,000,000's of a second. Max value is of course 999,999 or x'F423F'.
Unfortunately with this format you will have problems doing direct arithmetic between two values as soon as one date/time stamp is in one second the other in a different second - let along worrying about days or years.
Time to break out the assembler.
Regards,
Steve