Db2 Precompiler Contoken Format

Raymond Bell

Db2 Precompiler Contoken Format
Folks,

I'm struggling to find documented the various language-specific contoken formats. You know, the fact COBOL had the contoken split in half and inserted into the DBRM with the two halves in reverse order, one language had the contoken left unadulterated, one even had it cut into quarters before being reassembled in Lord knows what sequence, etc. We've noticed some COBOL 6 contokens being written in the 'correct' format i.e. ascending RBA, effectively, and I thought I'd try to find where the various contoken formats are documented - but I'm not having any luck.

Does anyone know where I can find the host language/contoken formats documented?

Cheers,


Raymond
PS: I'm ignoring the Db2 Coprocessor for the moment.

Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com http://www.rbs.com
Attachments

  • image001.png (6.7k)

Roy Boxwell

Db2 Precompiler Contoken Format
(in response to Raymond Bell)
I’ve ignored the coprocessor for decades...

I have also never found the docu as I dont think there is any! I did my own
stuff when our software changed to support the GOFF format a few years
ago... C is especially ugly!



Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: <mailto:[login to unmask email]> [login to unmask email]
Web http://www.seg.de http://www.seg.de

https://www.seg.de/corporate/rechtliche-hinweise/datenschutz Link zur
Datenschutzerklärung


Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich



From: Bell, Raymond (Hosting Services, Technology)
[mailto:[login to unmask email]
Sent: Tuesday, July 23, 2019 5:01 PM
To: [login to unmask email]
Subject: [DB2-L] - Db2 Precompiler Contoken Format



Folks,



I’m struggling to find documented the various language-specific contoken
formats. You know, the fact COBOL had the contoken split in half and
inserted into the DBRM with the two halves in reverse order, one language
had the contoken left unadulterated, one even had it cut into quarters
before being reassembled in Lord knows what sequence, etc. We’ve noticed
some COBOL 6 contokens being written in the ‘correct’ format i.e. ascending
RBA, effectively, and I thought I’d try to find where the various contoken
formats are documented – but I’m not having any luck.



Does anyone know where I can find the host language/contoken formats
documented?



Cheers,





Raymond

PS: I’m ignoring the Db2 Coprocessor for the moment.



Raymond Bell

Db2

Hosting Services, Technology

Royal Bank of Scotland Group

3rd Floor Regents House

40-42 Islington High Street

London N1 8XL

Mob: +44 (0) 7894 608214

Email: <mailto:[login to unmask email]> [login to unmask email]



The content of this email is confidential unless stated otherwise.






The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered
Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland
is authorised by the Prudential Regulation Authority, and regulated by the
Financial Conduct Authority and Prudential Regulation Authority. The Royal
Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche
Bank and has its seat at Amsterdam, the Netherlands, and is registered in
the Commercial Register under number 33002587. Registered Office: Gustav
Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V.
and The Royal Bank of Scotland plc are authorised to act as agent for each
other in certain jurisdictions.



National Westminster Bank Plc. Registered in England No. 929027.
Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster
Bank Plc is authorised by the Prudential Regulation Authority, and regulated
by the Financial Conduct Authority and the Prudential Regulation Authority.



The Royal Bank of Scotland plc and National Westminster Bank Plc are
authorised to act as agent for each other.



This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message from
your computer. Internet e-mails are not necessarily secure. The Royal Bank
of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank
Plc or any affiliated entity (RBS or us) does not accept responsibility for
changes made to this message after it was sent. RBS may monitor e-mails for
business and operational purposes. By replying to this message you
understand that the content of your message may be monitored.



Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will not
adversely affect its systems or data. No responsibility is accepted by RBS
in this regard and the recipient should carry out such virus and other
checks as it considers appropriate.



Visit our website at www.rbs.com http://www.rbs.com

-----End Original Message-----

Attachments

  • smime.p7s (5.1k)

Raymond Bell

Db2 Precompiler Contoken Format
(in response to Roy Boxwell)
Ah, is it C that gets drawn, quartered and hung in random order? Oh well, glad I'm not the only one. But as mentioned, it seems with COBOL 6 the contoken is now in the 'correct' order.

Always thought it stupid to have the contoken provide multipe functions. If it's this format the source language was blah, if it's that format then the source language was blah. Embedded 'intelligence'. I've always hated that. Mind you, when was the last time you saw a table that didn't start with T for Table? :o(

Bis Später,


Raymond

From: Boxwell, Roy <[login to unmask email]>
Sent: 24 July 2019 06:20
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 Precompiler Contoken Format

I've ignored the coprocessor for decades...
I have also never found the docu as I dont think there is any! I did my own stuff when our software changed to support the GOFF format a few years ago... C is especially ugly!

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Tuesday, July 23, 2019 5:01 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Db2 Precompiler Contoken Format

Folks,

I'm struggling to find documented the various language-specific contoken formats. You know, the fact COBOL had the contoken split in half and inserted into the DBRM with the two halves in reverse order, one language had the contoken left unadulterated, one even had it cut into quarters before being reassembled in Lord knows what sequence, etc. We've noticed some COBOL 6 contokens being written in the 'correct' format i.e. ascending RBA, effectively, and I thought I'd try to find where the various contoken formats are documented - but I'm not having any luck.

Does anyone know where I can find the host language/contoken formats documented?

Cheers,


Raymond
PS: I'm ignoring the Db2 Coprocessor for the moment.

Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com http://www.rbs.com
-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com http://www.rbs.com

Ruediger Kurtz

AW: Db2 Precompiler Contoken Format
(in response to Raymond Bell)
Hi Raymond,

to answer your question … just today. We got plenty of those, all coming from software vendors. The ones we design obey the rules … (Tables start with TA, Indexes with IN …

CU

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Mittwoch, 24. Juli 2019 09:52
An: '[login to unmask email]' <[login to unmask email]>
Betreff: [DB2-L] - RE: Db2 Precompiler Contoken Format

Ah, is it C that gets drawn, quartered and hung in random order? Oh well, glad I’m not the only one. But as mentioned, it seems with COBOL 6 the contoken is now in the ‘correct’ order.

Always thought it stupid to have the contoken provide multipe functions. If it’s this format the source language was blah, if it’s that format then the source language was blah. Embedded ‘intelligence’. I’ve always hated that. Mind you, when was the last time you saw a table that didn’t start with T for Table? :o(

Bis Später,


Raymond

From: Boxwell, Roy <[login to unmask email]<mailto:[login to unmask email]>>
Sent: 24 July 2019 06:20
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 Precompiler Contoken Format

I’ve ignored the coprocessor for decades...
I have also never found the docu as I dont think there is any! I did my own stuff when our software changed to support the GOFF format a few years ago... C is especially ugly!

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Tuesday, July 23, 2019 5:01 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Db2 Precompiler Contoken Format

Folks,

I’m struggling to find documented the various language-specific contoken formats. You know, the fact COBOL had the contoken split in half and inserted into the DBRM with the two halves in reverse order, one language had the contoken left unadulterated, one even had it cut into quarters before being reassembled in Lord knows what sequence, etc. We’ve noticed some COBOL 6 contokens being written in the ‘correct’ format i.e. ascending RBA, effectively, and I thought I’d try to find where the various contoken formats are documented – but I’m not having any luck.

Does anyone know where I can find the host language/contoken formats documented?

Cheers,


Raymond
PS: I’m ignoring the Db2 Coprocessor for the moment.

Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com http://www.rbs.com
-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com http://www.rbs.com
-----End Original Message-----

Roy Boxwell

Db2 Precompiler Contoken Format
(in response to Ruediger Kurtz)
Columns with COL.... LoL...



Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: <mailto:[login to unmask email]> [login to unmask email]
Web http://www.seg.de http://www.seg.de

https://www.seg.de/corporate/rechtliche-hinweise/datenschutz Link zur Datenschutzerklärung


Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich



From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: Wednesday, July 24, 2019 9:56 AM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - AW: Db2 Precompiler Contoken Format



Hi Raymond,

to answer your question … just today. We got plenty of those, all coming from software vendors. The ones we design obey the rules … (Tables start with TA, Indexes with IN …

CU

Rüdiger



Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg


Telefon:

09561 96-44148


Telefax:

09561 96-44104


E-Mail:

[login to unmask email] <mailto:[login to unmask email]>


Internet:

www.huk.de http://www.huk.de

_____

HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.

_____

Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.

_____

Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Mittwoch, 24. Juli 2019 09:52
An: '[login to unmask email]' <[login to unmask email] <mailto:[login to unmask email]> >
Betreff: [DB2-L] - RE: Db2 Precompiler Contoken Format



Ah, is it C that gets drawn, quartered and hung in random order? Oh well, glad I’m not the only one. But as mentioned, it seems with COBOL 6 the contoken is now in the ‘correct’ order.



Always thought it stupid to have the contoken provide multipe functions. If it’s this format the source language was blah, if it’s that format then the source language was blah. Embedded ‘intelligence’. I’ve always hated that. Mind you, when was the last time you saw a table that didn’t start with T for Table? :o(



Bis Später,





Raymond



From: Boxwell, Roy <[login to unmask email] <mailto:[login to unmask email]> >
Sent: 24 July 2019 06:20
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 Precompiler Contoken Format



I’ve ignored the coprocessor for decades...

I have also never found the docu as I dont think there is any! I did my own stuff when our software changed to support the GOFF format a few years ago... C is especially ugly!



Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: <mailto:[login to unmask email]> [login to unmask email]
Web http://www.seg.de http://www.seg.de

https://www.seg.de/corporate/rechtliche-hinweise/datenschutz Link zur Datenschutzerklärung


Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich



From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Tuesday, July 23, 2019 5:01 PM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - Db2 Precompiler Contoken Format



Folks,



I’m struggling to find documented the various language-specific contoken formats. You know, the fact COBOL had the contoken split in half and inserted into the DBRM with the two halves in reverse order, one language had the contoken left unadulterated, one even had it cut into quarters before being reassembled in Lord knows what sequence, etc. We’ve noticed some COBOL 6 contokens being written in the ‘correct’ format i.e. ascending RBA, effectively, and I thought I’d try to find where the various contoken formats are documented – but I’m not having any luck.



Does anyone know where I can find the host language/contoken formats documented?



Cheers,





Raymond

PS: I’m ignoring the Db2 Coprocessor for the moment.



Raymond Bell

Db2

Hosting Services, Technology

Royal Bank of Scotland Group

3rd Floor Regents House

40-42 Islington High Street

London N1 8XL

Mob: +44 (0) 7894 608214

Email: <mailto:[login to unmask email]> [login to unmask email]



The content of this email is confidential unless stated otherwise.






The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.



National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.



The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.



This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.



Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.



Visit our website at www.rbs.com http://www.rbs.com

-----End Original Message-----


The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.



National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.



The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.



This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.



Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.



Visit our website at www.rbs.com http://www.rbs.com

-----End Original Message-----



-----End Original Message-----

Attachments

  • smime.p7s (5.1k)

Ruediger Kurtz

AW: Db2 Precompiler Contoken Format
(in response to Roy Boxwell)
We wouldn’t go all *that* way really


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Boxwell, Roy [mailto:[login to unmask email]
Gesendet: Mittwoch, 24. Juli 2019 10:48
An: [login to unmask email]
Betreff: [DB2-L] - RE: Db2 Precompiler Contoken Format

Columns with COL.... LoL...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: Wednesday, July 24, 2019 9:56 AM
To: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Subject: [DB2-L] - AW: Db2 Precompiler Contoken Format

Hi Raymond,

to answer your question … just today. We got plenty of those, all coming from software vendors. The ones we design obey the rules … (Tables start with TA, Indexes with IN …

CU

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

[login to unmask email]<mailto:[login to unmask email]>

Internet:

www.huk.de http://www.huk.de

________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Mittwoch, 24. Juli 2019 09:52
An: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Betreff: [DB2-L] - RE: Db2 Precompiler Contoken Format

Ah, is it C that gets drawn, quartered and hung in random order? Oh well, glad I’m not the only one. But as mentioned, it seems with COBOL 6 the contoken is now in the ‘correct’ order.

Always thought it stupid to have the contoken provide multipe functions. If it’s this format the source language was blah, if it’s that format then the source language was blah. Embedded ‘intelligence’. I’ve always hated that. Mind you, when was the last time you saw a table that didn’t start with T for Table? :o(

Bis Später,


Raymond

From: Boxwell, Roy <[login to unmask email]<mailto:[login to unmask email]>>
Sent: 24 July 2019 06:20
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 Precompiler Contoken Format

I’ve ignored the coprocessor for decades...
I have also never found the docu as I dont think there is any! I did my own stuff when our software changed to support the GOFF format a few years ago... C is especially ugly!

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Tuesday, July 23, 2019 5:01 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Db2 Precompiler Contoken Format

Folks,

I’m struggling to find documented the various language-specific contoken formats. You know, the fact COBOL had the contoken split in half and inserted into the DBRM with the two halves in reverse order, one language had the contoken left unadulterated, one even had it cut into quarters before being reassembled in Lord knows what sequence, etc. We’ve noticed some COBOL 6 contokens being written in the ‘correct’ format i.e. ascending RBA, effectively, and I thought I’d try to find where the various contoken formats are documented – but I’m not having any luck.

Does anyone know where I can find the host language/contoken formats documented?

Cheers,


Raymond
PS: I’m ignoring the Db2 Coprocessor for the moment.

Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com http://www.rbs.com
-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 250 Bishopsgate, London EC2M 4AA. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (RBS or us) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com http://www.rbs.com
-----End Original Message-----

-----End Original Message-----

Michael Hannan

RE: Db2 Precompiler Contoken Format
(in response to Roy Boxwell)

In Reply to Roy Boxwell:

Columns with COL.... LoL...

 

We all know that some sites append the datatype to name, e.g. _DATE, _NUM, _AMT, etc.

Working at different sites, we have to just accept whatever naming schemes they use. 
I don't mind at all if table names start with T or not, but could be mainly useful to distinguish between Tables, MQTs, Views, Aliases, etc.that are used in similar context.

Someone asked me about typical naming used at sites for DB2 system libraries, but honestly I did not know, because I just use whatever is there without paying a great deal of attention.

The one thing I really hate when trying to understand an SQL, no matter how bad is the formatting (I can reformat), is column names like D13527, D45231, etc. Even a foreign language is somewhat easier, although I have not yet seen Chinese column names. Do they exist?

Michael Hannan,

DB2 Application Performance Specialist
CPT Global Ltd

Joe Geller

RE: Db2 Precompiler Contoken Format
(in response to Michael Hannan)

My pet peeve is column names with the data_type.  If you change the datatype you also have to rename the column (which of course doesn't happen).  But worse than a suffix of DATE, NUM etc. is a prefix of the datatype - N_AMOUNT, C_LASTNAME, DT_SHIPDATE.   That makes it harder to find all columns related to a business function (dt_shipdate, tm_shipdate, n_shippingcost, c_shipmethod) - they are no longer alphabetically close to each other.

Joe

In Reply to Michael Hannan:

In Reply to Roy Boxwell:

Columns with COL.... LoL...

 

We all know that some sites append the datatype to name, e.g. _DATE, _NUM, _AMT, etc.

Working at different sites, we have to just accept whatever naming schemes they use. 
I don't mind at all if table names start with T or not, but could be mainly useful to distinguish between Tables, MQTs, Views, Aliases, etc.that are used in similar context.

Someone asked me about typical naming used at sites for DB2 system libraries, but honestly I did not know, because I just use whatever is there without paying a great deal of attention.

The one thing I really hate when trying to understand an SQL, no matter how bad is the formatting (I can reformat), is column names like D13527, D45231, etc. Even a foreign language is somewhat easier, although I have not yet seen Chinese column names. Do they exist?

Michael Hannan,

DB2 Application Performance Specialist
CPT Global Ltd

Phil Grainger

Db2 Precompiler Contoken Format
(in response to Joe Geller)
It could always be worse

One of those databases that has TWO columns (“key” and a massive varchar called “data”)!

Phil Grainger
Principal Enablement Manager

[BMC Exchange 2019 - Global Event Series - REGISTER] https://www.bmc.com/ami

Direct

+44 1189 218 000

Mobile

+44 7808 643 479

Email

[login to unmask email]

E2, Eskdale Road
Winnersh
Berkshire
United Kingdom
RG41 5TS
[image001 (002)] [cid:[login to unmask email] [https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]



From: Joe Geller <[login to unmask email]>
Sent: 29 July 2019 16:25
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: Db2 Precompiler Contoken Format


My pet peeve is column names with the data_type. If you change the datatype you also have to rename the column (which of course doesn't happen). But worse than a suffix of DATE, NUM etc. is a prefix of the datatype - N_AMOUNT, C_LASTNAME, DT_SHIPDATE. That makes it harder to find all columns related to a business function (dt_shipdate, tm_shipdate, n_shippingcost, c_shipmethod) - they are no longer alphabetically close to each other.

Joe

In Reply to Michael Hannan:

In Reply to Roy Boxwell:
Columns with COL.... LoL...



We all know that some sites append the datatype to name, e.g. _DATE, _NUM, _AMT, etc.

Working at different sites, we have to just accept whatever naming schemes they use.
I don't mind at all if table names start with T or not, but could be mainly useful to distinguish between Tables, MQTs, Views, Aliases, etc.that are used in similar context.

Someone asked me about typical naming used at sites for DB2 system libraries, but honestly I did not know, because I just use whatever is there without paying a great deal of attention.

The one thing I really hate when trying to understand an SQL, no matter how bad is the formatting (I can reformat), is column names like D13527, D45231, etc. Even a foreign language is somewhat easier, although I have not yet seen Chinese column names. Do they exist?

Michael Hannan,

DB2 Application Performance Specialist
CPT Global Ltd

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (49.7k)
  • image002.png (6.7k)
  • image003.jpg (1.6k)
  • image004.png (<1k)

Craig Mullins

Db2 Precompiler Contoken Format
(in response to Phil Grainger)
Reminds me of an article I wrote several years ago that might be of interest to this topic…



https://www.datavail.com/blog/on-db2-naming-conventions/



Regards,

Craig S. Mullins

Mullins Consulting, Inc.

15 Coventry Court

Sugar Land, TX 77479

http://www.mullinsconsulting.com www.mullinsconsulting.com







From: Grainger, Phil <[login to unmask email]>
Sent: Monday, July 29, 2019 10:29 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 Precompiler Contoken Format



It could always be worse



One of those databases that has TWO columns (“key” and a massive varchar called “data”)!




Phil Grainger
Principal Enablement Manager

https://www.bmc.com/ami


Direct

+44 1189 218 000


Mobile

+44 7808 643 479


Email

[login to unmask email] <mailto:[login to unmask email]>


E2, Eskdale Road
Winnersh
Berkshire
United Kingdom
RG41 5TS







From: Joe Geller <[login to unmask email] <mailto:[login to unmask email]> >
Sent: 29 July 2019 16:25
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [EXTERNAL] [DB2-L] - RE: Db2 Precompiler Contoken Format



My pet peeve is column names with the data_type. If you change the datatype you also have to rename the column (which of course doesn't happen). But worse than a suffix of DATE, NUM etc. is a prefix of the datatype - N_AMOUNT, C_LASTNAME, DT_SHIPDATE. That makes it harder to find all columns related to a business function (dt_shipdate, tm_shipdate, n_shippingcost, c_shipmethod) - they are no longer alphabetically close to each other.

Joe

In Reply to Michael Hannan:

In Reply to Roy Boxwell:

Columns with COL.... LoL...



We all know that some sites append the datatype to name, e.g. _DATE, _NUM, _AMT, etc.

Working at different sites, we have to just accept whatever naming schemes they use.
I don't mind at all if table names start with T or not, but could be mainly useful to distinguish between Tables, MQTs, Views, Aliases, etc.that are used in similar context.

Someone asked me about typical naming used at sites for DB2 system libraries, but honestly I did not know, because I just use whatever is there without paying a great deal of attention.

The one thing I really hate when trying to understand an SQL, no matter how bad is the formatting (I can reformat), is column names like D13527, D45231, etc. Even a foreign language is somewhat easier, although I have not yet seen Chinese column names. Do they exist?

Michael Hannan,

DB2 Application Performance Specialist
CPT Global Ltd



-----End Original Message-----

BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.

-----End Original Message-----



---
This email has been checked for viruses by AVG.
https://www.avg.com

Michael Hannan

RE: Db2 Precompiler Contoken Format
(in response to Joe Geller)



In Reply to Joe Geller:

My pet peeve is column names with the data_type.  If you change the datatype you also have to rename the column (which of course doesn't happen).  But worse than a suffix of DATE, NUM etc. is a prefix of the datatype - N_AMOUNT, C_LASTNAME, DT_SHIPDATE.   That makes it harder to find all columns related to a business function (dt_shipdate, tm_shipdate, n_shippingcost, c_shipmethod) - they are no longer alphabetically close to each other.

Joe

A little surprised Joe. Does a DATE change? Does a NUM (number) change to be not a number. Does amoney AMT (amount) suddenly become not an amount? I know there are text type id numbers and other numbers suitable for arithmetic. I would have thought data type changes are quite rare unless original data type was a bad mistake, or maybe just to make the column bigger, but certainly column names should not reflect Smallint, Int, Dec, etc. That would indeed be silly. A more generic data type can maybe make SQL a slightly easier to understand, but I don't care too much really.

A few Tangents:
I hate to see a column as CHAR(80), in a table if length of the used portion of the 80 varies. It should usually be VARCHAR so if indexed can use the actual length. So CHAR is only for short character columns. Still see a long CHAR sometimes.

Was unfortunate in the old days we had Padded VARCHAR in indexes without the length. 

One curiosity. FLOAT (length 8 and high precision) is used infrequently, but REAL (FLOAT(4)) is very rarely seen. Yet it would be adequate for most measuring data. We rarely need huge significant digits.

I have seen sites store a date in DECIMAL column (or even an Integer rarely). That was hugely misguided, in my opinion. Just makes the SQL more difficult, for date arithmetic, and date oriented functions. It ran into problems with change of format for CHAR(Decimal_coded_date_column) back in V10. 

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Aug 01, 2019 - 09:15 AM (Europe/Berlin)

Ruediger Kurtz

AW: Db2 Precompiler Contoken Format
(in response to Michael Hannan)
Michael,

back home safe and sound?

Columns suffixed as _DT or _DATE do change sometimes, because some developers tend to put telling dates in there such as ’31.02.2020’.
Not my design, but still it happens.
Columns are more often than not misused. Columns such as FAXNO might have contents totally different from any fax number, Date-labeled columns are being misused for business logic.
A column holding a date should be of date format, period.
And I’d second Joe’s view anytime. The contents of a column (and therefore its format) do change, its name rarely (to avoid the ugly ‘never’) does.

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer, Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Michael Hannan [mailto:[login to unmask email]
Gesendet: Donnerstag, 1. August 2019 09:10
An: [login to unmask email]
Betreff: [DB2-L] - RE: Db2 Precompiler Contoken Format



In Reply to Joe Geller:

My pet peeve is column names with the data_type. If you change the datatype you also have to rename the column (which of course doesn't happen). But worse than a suffix of DATE, NUM etc. is a prefix of the datatype - N_AMOUNT, C_LASTNAME, DT_SHIPDATE. That makes it harder to find all columns related to a business function (dt_shipdate, tm_shipdate, n_shippingcost, c_shipmethod) - they are no longer alphabetically close to each other.

Joe

A little surprised Joe. Does a DATE change? Does a NUM (number) change to be not a number. Does amoney AMT (amount) suddenly become not an amount? I know there are text type id numbers and other numbers suitable for arithmetic. I would have thought data type changes are quite rare unless original data type was a bad mistake, or maybe just to make the column bigger, but certainly column names should not reflect Smallint, Int, Dec, etc. That would indeed be silly. A more generic data type can maybe make SQL a slightly easier to understand, but I don't care too much really.

I hate to see a column as CHAR(80), in a table if length of the used portion of the 80 varies. It should usually be VARCHAR so if indexed can use the actual length. So CHAR is only for short character columns. Still see a long CHAR sometimes.

Was unfortunate in the old days we had Padded VARCHAR in indexes without the length.

One curiosity. FLOAT (length 8 and high precision) is used infrequently, but REAL (FLOAT(4)) is very rarely seen. Yet it would be adequate for most measuring data. We rarely need huge significant digits.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

-----End Original Message-----