|
View previous topic :: View next topic
|
| Author |
Message |
prem_ibm
New User
Joined: 15 Sep 2007
Posts: 31
Location: Chennai
|
|
|
|
During run time both consistency token will be compared,But i did't found Consistency Token in Load Module where as i found Consistency token in DBRMLIB & SYSIBM.SYSPACKAGE.
Now as per the DB2 theory its saying run time Cosistency token will be matched from Load lib and SYSIBM.SYSPACKGE (Consistency Token extracted from DBRM and stored in SYSIBM.SYSPACKGE)
My question is if Consistency token is not found in LOADMODULE then how it will compare during run time to ensuer both belongs to same source
Thanks |
|
| Back to top |
|
 |
Pandora-Box
Global Moderator
.jpg)
Joined: 07 Sep 2006
Posts: 1592
Location: Andromeda Galaxy
|
|
|
|
My questions
1.Did you execute your program?
2.Whats the SQL code you got after execution?
3.Is this just before very first run or is this program getting executed with the same load even before? |
|
| Back to top |
|
|
Stefan
Active User
Joined: 12 Jan 2006
Posts: 110
Location: Germany
|
|
|
|
The consistency token within the load module is stored slightly different to the DB2 catalog or the DBRM.
If for example the DB2 catalog has X'18111A4611239DE8' as consistency token, you have to split this data right in the middle and switch the two parts to build the string that you'll find in the load module.
In this example, split the token into X'18111A46' and X'11239DE8' and put them together again in reverse order, so it will be X'11239DE818111A46'.
You will find this token in the load module. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
Stefan, do you know if that is universal, or language-dependent? I know that Cobol does it that way, but I am not sure about other languages.
And, many years ago, OS/VS Cobol did not flip the contoken the way you described. I remember being surprised when I first saw the flipping behavior, but now it seems normal. The change in behavior broke an old tool of mine that used to search load modules for DBRM contokens. |
|
| Back to top |
|
|
Stefan
Active User
Joined: 12 Jan 2006
Posts: 110
Location: Germany
|
|
|
|
Don, I was not aware of the fact that it is compiler-dependent. I checked a PL/I load module now. It seems you are right. The consistency token mentioned in the DB2 catalog appears in the load module WITHOUT any change. So obviously the COBOL compiler does the trick with interchanging the two halfs of the token.
As I haven't found any documentation about this oddity, I have no clue about how other compilers work. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| It's probably not documented because, to the Cobol compiler, there is nothing special about the consistency token: it is just another literal in the program. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
the pre-compiler (which is language dependent) generates the consistancy token.
pl1 generates a 'straight' token for both load and dbrm.
cobol has the halved/reversed
c has a quarters reversed.
so, i guess one would need to look at the documentation for pre-compilers. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
To figure out where the consistency token comes from, first look at your compiler listing:
| Code: |
01 SQL-PLIST8.
05 SQL-PLIST-CON PIC S9(9) COMP-4 VALUE +2654208.
05 SQL-CALLTYPE PIC S9(4) COMP-4 VALUE +30.
05 SQL-PROG-NAME PIC X(8) VALUE 'PXXXAM '.
05 SQL-TIMESTAMP-1 PIC S9(9) COMP-4 VALUE +370984864.
05 SQL-TIMESTAMP-2 PIC S9(9) COMP-4 VALUE +414679900. |
If you convert SQL-TIMESTAMP-1 and SQL-TIMESTAMP-2 to hex and concatenate them together, you get a string that looks like a consistency token:
SQL-TIMESTAMP-1 = X'161CC7A0'
SQL-TIMESTAMP-2 = X'18B7835C'
These hex strings appear in the DBRM text and in the CONTOKEN column of SYSIBM.SYSPACKAGE in the order shown above.
In the load module, as has been mentioned, the strings also appear, but SQL-TIMESTAMP-2 appears before SQL-TIMESTAMP1. This is entirely due to how the Cobol compiler chooses to store literal values. Also as mentioned, other languages follow their own rules.
If you go back to the compiler listing, you will also see that SQL-TIMESTAMP-1 and SQL-TIMESTAMP-2 appear several times in the Data Division. In each case the value is exactly the same. Why then don't you see these values several times in the load module?
The reason is that the Cobol compiler stores only one instance of a literal value in the object code. This is more efficient than storing multiple copies of the same value in several places. |
|
| Back to top |
|
|
|
|
