MVSFORUMS.com

[ST]

Kolusu,
Thx for ur info reg Timestamps...But When we get Timestamp mismatch how do we fix that?

Suppose after the BIND,if the pgm is abended then do we really need to start from PRECOMPILE again? if not if we just REBIND the program then obviously we get TIMESTAMP mismatches I think..Correct me if am wrong and pls let me know the solution..

Thanks,
ST

[Manas Biswal]

Hi ST,

You can do a bind as many number of times as you can but you will not get a timestamp mismatch. You get a timestamp mismatch when the DBRM and the load are not in sync. After you have generated the DBRM, you can bind it as many number of times as you can but won't get a timestamp mismatch.

Regards,
Manas

[Nila]

Normally I am facing this problem while using ENDEVOR.

In ENDEVOR, after updating a program we have to move the program into the ENDEVOR( it automatically compiles while moving) and generate the Bind plan also. Without generating the plan if we execute the program it will abend with timestamp mismatch.
_________________
Cheers Nila..

[ST]

Manas,
Thanks a lot...


ST

[ajeykumar]

Just as an afterthought, the entire process of a timestamp mismatch occuring is:

When the precompile is done, the timestamp is placed in SYSIBM.SYSDBRM when the DBRM is created. Also, this same timestamp is written down for each of the sql call statements (each sql is also assigned a unique sqlid) which appear in the output of a precompile. Now for a plan to run without any problems the dbrm timestamp and the timestamp associated with each sql in the precompile output must be equal.

So, in case you take the precompile output and make changes to purely cobol statements, your program will still run after cobol-compiling & linkediting this version.

In most cases that I have experienced, the timestamp mismatch occurs when you are dealing with multiple versions of the program residing in concatenated libraries.

Hope this gives a good idea of the overall picture regarding timestamps.

Thanks