Re: Strange LRSN value in DB2 Log Records
The LRSN delta can be the equivalent of years. Do not get the LRSN delta confused with the leap second or time zone offsets. As Wayne said, the output from DSNJU004 will show you what the delta is. There is at least one known case where the LRSN delta is over 25 years. There are other installations where the delta is 10+ years. This was one of the motiviations for the 10 byte RBA and LRSN support in DB2 11. Dave Levish DB2 Design and Development Arie Kremer wrote: We send them the corresponding request. But I really think this is not the issue. STCK to LRSN Delta is usually defined as no more than a number of seconds, and we are dealing with years. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange LRSN value in DB2 Log Records
Huge differences usually come from going out of data sharing that uses a special value to jump out of DS. This causes LRSN delta to be generated. Isaac Yassin IBM Gold Consultant IBM Champion - Information Management IBM Certified Solution Expert IBM Certified System Administrator - DB2 10, 11 - for z/OS IBM Certified Database Administrator - DB2 9, 10, 11 - for z/OS IDUG Israel RUG co-Chair IDUG GMC -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Levish Sent: Friday, August 22, 2014 9:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strange LRSN value in DB2 Log Records The LRSN delta can be the equivalent of years. Do not get the LRSN delta confused with the leap second or time zone offsets. As Wayne said, the output from DSNJU004 will show you what the delta is. There is at least one known case where the LRSN delta is over 25 years. There are other installations where the delta is 10+ years. This was one of the motiviations for the 10 byte RBA and LRSN support in DB2 11. Dave Levish DB2 Design and Development Arie Kremer wrote: We send them the corresponding request. But I really think this is not the issue. STCK to LRSN Delta is usually defined as no more than a number of seconds, and we are dealing with years. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- I am using the free version of SPAMfighter. SPAMfighter has removed 2734 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange LRSN value in DB2 Log Records
Many Thanks Wayne, We send them the corresponding request. But I really think this is not the issue. STCK to LRSN Delta is usually defined as no more than a number of seconds, and we are dealing with years...Moreover, as well as I understand some (described below) inputs, this is not a clock at all. I compared the different between some DB2 events (INSERT operation to a table with TIMESTAMP column setting to CURREMT_TIMESTAMP) and between LRSN in these events. The different in the column was 2.8 seconds when in LRSN - 1.5 second... On Wed, Aug 20, 2014 at 9:24 PM, Wayne Driscoll wdri...@us.ibm.com wrote: You will want to check in the BSDS of the DB2 data sharing group (using offline utility DSNJU004) to determine if there is a STCK to LRSN Delta defined for the data sharing group. This delta is required when a DB2 subsystem is converted to data sharing with a (then) current log RBA that was greater then the high order 6 bytes of the STCK value. If this value is non-zero, it will need to be subtracted from the LRSN value prior to converting it to a timestamp field. == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com All opinions are mine, and do not represent IBM Corporation. == IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 08/18/2014 09:34:06 AM: From: Arie Kremer arie...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/18/2014 09:34 AM Subject: [IBM-MAIN] Strange LRSN value in DB2 Log Records Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We use IFI to analyze DB2 logs. lrh_time field in the log record header is assumed to contain LRSN in SYSPLEX environment, when LRSN is usually derived from the Coupling Facility clock, i.e. may be be used as a clock. In most cases, this works perfect. We have a customer that their Coupling Facility clock and the clock of other processors are different (5 hours). In their DB2 environment, we get LRSN that being converting to the timestamp means the year 2038, and seems as not a clock. The values are acceding, and seems as the problem is only when interpreting LRSN as a timestamp. Does somebody know what does it mean? What is this LRSN means and how to convert it to the real time? Many thanks Arie Kremer -- 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: Strange LRSN value in DB2 Log Records
You will want to check in the BSDS of the DB2 data sharing group (using offline utility DSNJU004) to determine if there is a STCK to LRSN Delta defined for the data sharing group. This delta is required when a DB2 subsystem is converted to data sharing with a (then) current log RBA that was greater then the high order 6 bytes of the STCK value. If this value is non-zero, it will need to be subtracted from the LRSN value prior to converting it to a timestamp field. == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com All opinions are mine, and do not represent IBM Corporation. == IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 08/18/2014 09:34:06 AM: From: Arie Kremer arie...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/18/2014 09:34 AM Subject: [IBM-MAIN] Strange LRSN value in DB2 Log Records Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We use IFI to analyze DB2 logs. lrh_time field in the log record header is assumed to contain LRSN in SYSPLEX environment, when LRSN is usually derived from the Coupling Facility clock, i.e. may be be used as a clock. In most cases, this works perfect. We have a customer that their Coupling Facility clock and the clock of other processors are different (5 hours). In their DB2 environment, we get LRSN that being converting to the timestamp means the year 2038, and seems as not a clock. The values are acceding, and seems as the problem is only when interpreting LRSN as a timestamp. Does somebody know what does it mean? What is this LRSN means and how to convert it to the real time? Many thanks Arie Kremer -- 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
Strange LRSN value in DB2 Log Records
We use IFI to analyze DB2 logs. lrh_time field in the log record header is assumed to contain LRSN in SYSPLEX environment, when LRSN is usually derived from the Coupling Facility clock, i.e. may be be used as a clock. In most cases, this works perfect. We have a customer that their Coupling Facility clock and the clock of other processors are different (5 hours). In their DB2 environment, we get LRSN that being converting to the timestamp means the year 2038, and seems as not a clock. The values are acceding, and seems as the problem is only when interpreting LRSN as a timestamp. Does somebody know what does it mean? What is this LRSN means and how to convert it to the real time? Many thanks Arie Kremer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
