DB2 Precompiler error

Don Cross

DB2 Precompiler error
I am trying to compile some embedded sql in C but can't get aroung
precompiler errors. This is the closest I have gotton. Our language is
Cobol but I am overriding it with HOST(C). Any ideas where I have erred? We
are OS390v2.9 DB2 v6.

tapi is a stored procedure(not yet created) with one input variable.

main(){

EXEC SQL BEGIN DECLARE SECTION;
char actype??(4??);
char qstring??(100??);
EXEC SQL END DECLARE SECTION;
EXEC SQL INCLUDE SQLCA;

EXEC SQL WHENEVER SQLERROR GO TO HANDLERR;
EXEC SQL WHENEVER SQLWARNING GO TO CONTINUE;
EXEC SQL WHENEVER NOT FOUND GO TO NOTFOUND;


printf("\n Enter the name of the new aircraft type ..");
scanf("%s",actype);

strcpy(qstring,"EXEC SQL CALL tapi(?)");

EXEC SQL PREPARE ctapi FROM :qstring;

EXEC SQL EXECUTE ctapi USING :actype;


*********************************************************
DSNH080I E DSNHSM3D LINE 27 COL 31 STRING VARIABLE "qstring" IS NOT
"VARCH
AR" TYPE
PREPARE ctapi FROM:qstring



James Campbell

Re: DB2 Precompiler error
(in response to Don Cross)
Quoting from the SQL Reference Manual section on the PREPARE
statement "[i]n C, the host variable must not be a NUL-terminated
string."

There is a sample program in Appl Prog and SQL Guide.

James Campbell

On 19 Jul 2002 at 15:14, Don Cross wrote:

> I am trying to compile some embedded sql in C but can't get aroung
> precompiler errors. This is the closest I have gotton. Our language is
> Cobol but I am overriding it with HOST(C). Any ideas where I have erred? We
> are OS390v2.9 DB2 v6.
>
> tapi is a stored procedure(not yet created) with one input variable.
>
> main(){
>
> EXEC SQL BEGIN DECLARE SECTION;
> char actype??(4??);
> char qstring??(100??);
> EXEC SQL END DECLARE SECTION;
> EXEC SQL INCLUDE SQLCA;
>
> EXEC SQL WHENEVER SQLERROR GO TO HANDLERR;
> EXEC SQL WHENEVER SQLWARNING GO TO CONTINUE;
> EXEC SQL WHENEVER NOT FOUND GO TO NOTFOUND;
>
>
> printf("\n Enter the name of the new aircraft type ..");
> scanf("%s",actype);
>
> strcpy(qstring,"EXEC SQL CALL tapi(?)");
>
> EXEC SQL PREPARE ctapi FROM :qstring;
>
> EXEC SQL EXECUTE ctapi USING :actype;
>
>
> *********************************************************
> DSNH080I E DSNHSM3D LINE 27 COL 31 STRING VARIABLE "qstring" IS NOT
> "VARCH
> AR" TYPE
> PREPARE ctapi FROM:qstring
>
>
>

James A Campbell



Raquel Rodriguez

Re: DB2 Precompiler error
(in response to James Campbell)
Hello !!

I am coding my first CAF program (by the name
'DB2PLN1') in COBOL. I use the following Call to OPEN
a connection with DB2:

CALL 'DSNALI' USING FUNCOP SSNM PLAN RET REASON

Where:
FUNCOP is defined as PIC X(12) VALUE 'OPEN '
SSNM is PIC X(4) VALUE 'DSNT'
PLAN is PIC X(8) VALUE 'DB2PLN1'.

The program DB2PLN1 compiles fine (using precompile
option ATTACH(CAF) and compile option NODYNAM; with
Link-editing a //SYSLIB INCLUDE(DSNALI) ) but at run
time, it gives me a return code (RET in the above CALL
statement) of 8 and reason code (REASON in the above
CALL statement) of 0015925312. where do I find
explanation for this return
code/reason code??

Also, all the SQLs coded in the program DB2PLN1 after
this CALL statement fail with a SQLCODE -991 (CALL
ATTACH WAS UNABLE TO ESTABLISH AN
IMPLICIT CONNECT OR OPEN TO DB2).

Probably there is something simple I am missing.
Would appreciate pointers. If not, could someone post
a simple COBOL-CAF program. Can't find
one in the Application guide and SQL reference.

TIA
Raquel.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



Bernd Oppolzer

Re: DB2 Precompiler error
(in response to James Campbell)
Hello,

for PREPARE, the host variable must be of type VARCHAR, and in C, you declare
VARCHARs as structs, containing a length field of type short and a char array
of the desired maximum length, for example:

struct {short length;
char data [40];} HV0041_prodbs;

and later, for example:

EXEC SQL
FETCH CXX0041
INTO :HV0041_auftragsnr ,
:HV0041_prodbs ,
:HV0041_gevo ,
:HV0041_kzdbrm ,
:HV0041_jobdatum;

For PREPARE, you have to fill in the data and the length, and the data does not
need to be terminated with a hex nul, but if there is room for the hex nul, it
does no harm. DB2 uses only the characters up to the value of length.

On the other hand, if you fetch data into a varchar, as in the example above,
you don't get a hex nul from DB2, as you do with normal char strings. You have
to take care of that yourself (e.g. append a hex nul, if needed).

Regards

Bernd



Am Sam, 20 Jul 2002 schrieben Sie:
> Hello !!
>
> I am coding my first CAF program (by the name
> 'DB2PLN1') in COBOL. I use the following Call to OPEN
> a connection with DB2:
>
> CALL 'DSNALI' USING FUNCOP SSNM PLAN RET REASON
>
> Where:
> FUNCOP is defined as PIC X(12) VALUE 'OPEN '
> SSNM is PIC X(4) VALUE 'DSNT'
> PLAN is PIC X(8) VALUE 'DB2PLN1'.
>
> The program DB2PLN1 compiles fine (using precompile
> option ATTACH(CAF) and compile option NODYNAM; with
> Link-editing a //SYSLIB INCLUDE(DSNALI) ) but at run
> time, it gives me a return code (RET in the above CALL
> statement) of 8 and reason code (REASON in the above
> CALL statement) of 0015925312. where do I find
> explanation for this return
> code/reason code??
>
> Also, all the SQLs coded in the program DB2PLN1 after
> this CALL statement fail with a SQLCODE -991 (CALL
> ATTACH WAS UNABLE TO ESTABLISH AN
> IMPLICIT CONNECT OR OPEN TO DB2).
>
> Probably there is something simple I am missing.
> Would appreciate pointers. If not, could someone post
> a simple COBOL-CAF program. Can't find
> one in the Application guide and SQL reference.
>
> TIA
> Raquel.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
>
>



James Campbell

Re: DB2 Precompiler error
(in response to Raquel Rodriguez)
1) 0015925312 = x'00F30040'

2) Well yes. Having failed to create an explicit attachment, are you
_really_ surprised that you couldn't create an implicit attachment?

3) You might find it usefull, at least for debugging, to read the
Diagnosis Guide and Reference and put a
//DSNTRACE DD SYSOUT=*
into your job

James Campbell

On 19 Jul 2002 at 21:01, Raquel Rodriguez wrote:

> Hello !!
>
> I am coding my first CAF program (by the name
> 'DB2PLN1') in COBOL. I use the following Call to OPEN
> a connection with DB2:
>
> CALL 'DSNALI' USING FUNCOP SSNM PLAN RET REASON
>
> Where:
> FUNCOP is defined as PIC X(12) VALUE 'OPEN '
> SSNM is PIC X(4) VALUE 'DSNT'
> PLAN is PIC X(8) VALUE 'DB2PLN1'.
>
> The program DB2PLN1 compiles fine (using precompile
> option ATTACH(CAF) and compile option NODYNAM; with
> Link-editing a //SYSLIB INCLUDE(DSNALI) ) but at run
> time, it gives me a return code (RET in the above CALL
> statement) of 8 and reason code (REASON in the above
> CALL statement) of 0015925312. where do I find
> explanation for this return
> code/reason code??
>
> Also, all the SQLs coded in the program DB2PLN1 after
> this CALL statement fail with a SQLCODE -991 (CALL
> ATTACH WAS UNABLE TO ESTABLISH AN
> IMPLICIT CONNECT OR OPEN TO DB2).
>
> Probably there is something simple I am missing.
> Would appreciate pointers. If not, could someone post
> a simple COBOL-CAF program. Can't find
> one in the Application guide and SQL reference.
>
> TIA
> Raquel.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
>
>

James A Campbell



Mae Bruce

Re: DB2 Precompiler error
(in response to Bernd Oppolzer)
Look at the sample program DSN8CC supplied by IBM in the SDSNSAMP library.
This gives you a sample of how a CAF program should be set up. But what is
really helpful is that it also gives you a procedure to convert the reason
codes to a printable form. That code then can be found in the error message
manual or QuickRef.

Hope this helps.

Mae Bruce
State of Missouri
OA/Division of Information Services


-----Original Message-----
From: Raquel Rodriguez [mailto:[login to unmask email]
Sent: Friday, July 19, 2002 11:01 PM
To: [login to unmask email]
Subject: Re: DB2 Precompiler error


Hello !!

I am coding my first CAF program (by the name
'DB2PLN1') in COBOL. I use the following Call to OPEN
a connection with DB2:

CALL 'DSNALI' USING FUNCOP SSNM PLAN RET REASON

Where:
FUNCOP is defined as PIC X(12) VALUE 'OPEN '
SSNM is PIC X(4) VALUE 'DSNT'
PLAN is PIC X(8) VALUE 'DB2PLN1'.

The program DB2PLN1 compiles fine (using precompile
option ATTACH(CAF) and compile option NODYNAM; with
Link-editing a //SYSLIB INCLUDE(DSNALI) ) but at run
time, it gives me a return code (RET in the above CALL
statement) of 8 and reason code (REASON in the above
CALL statement) of 0015925312. where do I find
explanation for this return
code/reason code??

Also, all the SQLs coded in the program DB2PLN1 after
this CALL statement fail with a SQLCODE -991 (CALL
ATTACH WAS UNABLE TO ESTABLISH AN
IMPLICIT CONNECT OR OPEN TO DB2).

Probably there is something simple I am missing.
Would appreciate pointers. If not, could someone post
a simple COBOL-CAF program. Can't find
one in the Application guide and SQL reference.

TIA
Raquel.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com








Bob Davis

DB2 precompiler
(in response to Mae Bruce)
In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?



Mike Polley

Re: DB2 precompiler
(in response to Bob Davis)
Bob, how's it going other than the problem posed below? Making any
Abend-Aid XLS changes lately? About your question though, it would seem
that you may not get some of the performance differences available. I'm
sure you'll get more responses to your question. Just wanted to give you a
shout. Take Care and Happy Holidays to you and your family.

Mike Polley
Technical Specialist, Compuware GMCN Team



-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 2:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?








The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.



Jeremiah Eden

Re: DB2 precompiler
(in response to Mike Polley)
Good question? Maybe IBM will chime in. We also use Changeman. And we also
keep the precompiler and linkedit syslibs at the same maintenance level as
our Production DB2 system. I really don't think is a problem with V6 using a
V5 DBRM, but rather the other way around with a V5 system using a V6 DBRM,
especially with new bind options. However, Changeman gives you the ability
to have more than one DB2 instance to select from and associates a SDSNLOAD
library, and a different Job card where you can direct the final Bind
process. So when we migrated to V7 on our test machine, you could choose
the DB2 V7 system for the precompile and bind, or the V6 system for the
production precompile and bind. All of the changes to do we done with
through Administrative changes only, and not though rewriting Changeman
skeletons. FYI. We just installed Changeman V5R3M1 in our test environment,
and it has support for Stored procedures, User Defined Functions, and
Triggers. This includes Stored Procedure builder as well. I haven't got
everything set up yet, but it does it all including dropping, defining,
starting and stopping them. It also has a field to define Trigger firing
order. Cool! C support too.

-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?








Gerald Hodge

Re: DB2 precompiler
(in response to Jeremiah Eden)
Bob:

There is a version level indicator in the DBRM that tells which DB2 version
was used to create it. Generally speaking, you can go forward. You can not
go backwards. This is at least true with V5 and V6. You can not, of
course, use V6 feature / function with this approach. We do a lot of work
with DBRMs and I would be happy to talk with you off line of the list serve
about the DBRM issues.

Because you create the DBRM once there is an exposure. The bind process
will verify the DBRM against the target DB2 subsystem. But it only checks
for the feature / function being utilized. E.G., if someone does a select *
and there are differences in the table columns ( more in Production than in
test) then you will fail in execution. If there differences in the indexes
you should get performance variations. Even if you get by the bind process
DB2 should catch an error that would cause data corruption. DB2 is more
careful about updates / inserts than about reads.

As far as I know there are three products on the market that bypass a bind
in some circumstances: IBM's Bind Manager, CA's Bind Analyzer and our Avoid
Bind. BMC's Change Manager controls binding, but last I looked did not avoid
it. Bind Manager and Avoid Bind are the only products that I know of that
will allow you to take a DBRM down level in certain circumstances, say form
V6 to V5.

None of these products use the method you have described. I am not aware of
any other product that chooses the approach you credit to ChangeMan.

Discussion of the religious practices that are Change Control are beyond my
skill set.

If I can be of help off line call me at 281-265-3004.

Gerald Hodge
HLS Technologies, Inc.

-----Original Message-----
From: DB2 Data Base Discussion List
[mailto:[login to unmask email]On Behalf Of Bob Davis
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?








Ava Collins

Re: DB2 precompiler
(in response to Gerald Hodge)
B Davis ask:

> "In our shop, we use ChangeMan which does NOT compile as part of the
> migration process (i.e. from development into TEST, QA, Prod, etc.). <snip>
> Although we have never had a problem with this process, certain groups here
> feel that this could expose us to "data corruption" of the application data
> stored within DB2 or the DB2 catalog.
>
> Do we have anything to worry about? <snip>"

B Davis,

Our shop uses Changeman in the similar manner. Our programs have been
through conversions of DB2 from V3.? to 4, 5, 6, & 7.1 with no problems. We
usually convert the test platform first and regression our systems before
production is converted to the new version of DB2.

On what facts do these groups base their concern?

Jacquie

Bernd Oppolzer

Re: DB2 precompiler
(in response to Ava Collins)
I don't know exactly, but I guess, it should not be a problem to bind a lower
version DBRM into a higher level DB2 subsystem.

At our site, we are using the same approach, but with a home grown CCM system.
What I am curious about is: normally the development and test systems are
migrated first to a newer version of DB2, so the problem in my opinion should
be the other way round: BIND V7 DBRM to V6 subsystem. At least it was like this
at our site recently (without any problems).

Regards

Bernd


Am Don, 19 Dez 2002 schrieben Sie:
> In our shop, we use ChangeMan which does NOT compile as part of the
> migration process (i.e. from development into TEST, QA, Prod, etc.). This
> process utilizes the production-level DB2 precompiler rather than the
> latest / TEST version precompiler due to the fact that the programs are NOT
> recompiled / relinked into each environment. Although we have never had a
> problem with this process, certain groups here feel that this could expose
> us to "data corruption" of the application data stored within DB2 or the
> DB2 catalog.
>
> Do we have anything to worry about? Why would binding with a v5 DBRM into
> a v6 DB2 subsystem cause any problems?
>



Bob Davis

Re: DB2 precompiler
(in response to Bernd Oppolzer)
How do you prevent programs created with the DB2 v7 precompiler from entering your DB2 v6 production environment? Suppose a developer makes use of a v7 feature not yet supported in v6.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 3:52 PM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Good question? Maybe IBM will chime in. We also use Changeman. And we also
keep the precompiler and linkedit syslibs at the same maintenance level as
our Production DB2 system. I really don't think is a problem with V6 using a
V5 DBRM, but rather the other way around with a V5 system using a V6 DBRM,
especially with new bind options. However, Changeman gives you the ability
to have more than one DB2 instance to select from and associates a SDSNLOAD
library, and a different Job card where you can direct the final Bind
process. So when we migrated to V7 on our test machine, you could choose
the DB2 V7 system for the precompile and bind, or the V6 system for the
production precompile and bind. All of the changes to do we done with
through Administrative changes only, and not though rewriting Changeman
skeletons. FYI. We just installed Changeman V5R3M1 in our test environment,
and it has support for Stored procedures, User Defined Functions, and
Triggers. This includes Stored Procedure builder as well. I haven't got
everything set up yet, but it does it all including dropping, defining,
starting and stopping them. It also has a field to define Trigger firing
order. Cool! C support too.

-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?











Jeremiah Eden

Re: DB2 precompiler
(in response to Bob Davis)
Assuming your application programmers can only access production libraries
through Changeman, and can not bind to production DB2 systems except through
Changeman.. you would define DB2 Physical and Logical Subsystems to
Changeman like the sample below under Global and Admin Options. If you
select either system from this screen, it will have a job card which can be
modified to direct to the initiator class, or system affinity to your V6 or
V7 system. So if a user specifies a DB2 precompile he will be prompted to
select one of these systems (pre V5.3 changeman). If he chooses TEST you
will get a V7 DBRM and Bind and be installed in that system.
If you choose PROD, you will get a V6 DBRM and bind and it will be installed
in the PROD system.

DB2
SUBSYS SITE DB2 SYSTEM LOAD LIBRARY
'''' PROD ________ DB2.V6R1M0.SDSNLOAD_______
'''' TEST ________ DB2.V7R1M0.SDSNLOAD_______


-----Original Message-----
From: Davis, Bob (B.E.) [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 10:08 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


How do you prevent programs created with the DB2 v7 precompiler from
entering your DB2 v6 production environment? Suppose a developer makes use
of a v7 feature not yet supported in v6.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 3:52 PM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Good question? Maybe IBM will chime in. We also use Changeman. And we also
keep the precompiler and linkedit syslibs at the same maintenance level as
our Production DB2 system. I really don't think is a problem with V6 using a
V5 DBRM, but rather the other way around with a V5 system using a V6 DBRM,
especially with new bind options. However, Changeman gives you the ability
to have more than one DB2 instance to select from and associates a SDSNLOAD
library, and a different Job card where you can direct the final Bind
process. So when we migrated to V7 on our test machine, you could choose
the DB2 V7 system for the precompile and bind, or the V6 system for the
production precompile and bind. All of the changes to do we done with
through Administrative changes only, and not though rewriting Changeman
skeletons. FYI. We just installed Changeman V5R3M1 in our test environment,
and it has support for Stored procedures, User Defined Functions, and
Triggers. This includes Stored Procedure builder as well. I haven't got
everything set up yet, but it does it all including dropping, defining,
starting and stopping them. It also has a field to define Trigger firing
order. Cool! C support too.

-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?


















Phil Grainger

Re: DB2 precompiler
(in response to Jeremiah Eden)
This littleknown hole is actually fixed in V-next!

Phil Grainger
Computer Associates
Product Manager, DB2
Tel: +44 (0)161 928 9334
Fax: +44 (0)161 941 3775
Mobile: +44 (0)7970 125 752
[login to unmask email]


-----Original Message-----
From: Davis, Bob (B.E.) [mailto:[login to unmask email]
Sent: 20 December 2002 16:08
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 precompiler


How do you prevent programs created with the DB2 v7 precompiler from
entering your DB2 v6 production environment? Suppose a developer makes use
of a v7 feature not yet supported in v6.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338


Bob Davis

Re: DB2 precompiler
(in response to Phil Grainger)
Jeremiah,

1. As you know, this DB2 panel CMNSTG18, which allows the developers to
choose the DB2 subsystem, is presented during staging. Suppose the
developer chooses TEST (in your scenario), then installs the change package
without restaging using the PROD subsystem. You now have a DBRM built with
the v7 precompiler executing in the v6 (PROD) environment. How do you
prevent programs created with the DB2 v7 precompiler from entering your DB2
v6 production environment?

2. Suppose the DB2 precompile step is coded to use the production-level DB2
software library such that only the v6 precompiler program can be used.
This would prevent developers from using v7 features before production is at
v7. OK, but now the first time that the v7 precompiler is used is when
production is upgraded to v7. Suppose an emergency fix is made to a DB2
program. The DB2 v7 precompiler has not yet been tested. Could use of it
cause any data corruption issues in production? This is the real concern
with a certain group here.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 11:55 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Assuming your application programmers can only access production libraries
through Changeman, and can not bind to production DB2 systems except through
Changeman.. you would define DB2 Physical and Logical Subsystems to
Changeman like the sample below under Global and Admin Options. If you
select either system from this screen, it will have a job card which can be
modified to direct to the initiator class, or system affinity to your V6 or
V7 system. So if a user specifies a DB2 precompile he will be prompted to
select one of these systems (pre V5.3 changeman). If he chooses TEST you
will get a V7 DBRM and Bind and be installed in that system.
If you choose PROD, you will get a V6 DBRM and bind and it will be installed
in the PROD system.

DB2
SUBSYS SITE DB2 SYSTEM LOAD LIBRARY
'''' PROD ________ DB2.V6R1M0.SDSNLOAD_______
'''' TEST ________ DB2.V7R1M0.SDSNLOAD_______


-----Original Message-----
From: Davis, Bob (B.E.) [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 10:08 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


How do you prevent programs created with the DB2 v7 precompiler from
entering your DB2 v6 production environment? Suppose a developer makes use
of a v7 feature not yet supported in v6.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 3:52 PM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Good question? Maybe IBM will chime in. We also use Changeman. And we also
keep the precompiler and linkedit syslibs at the same maintenance level as
our Production DB2 system. I really don't think is a problem with V6 using a
V5 DBRM, but rather the other way around with a V5 system using a V6 DBRM,
especially with new bind options. However, Changeman gives you the ability
to have more than one DB2 instance to select from and associates a SDSNLOAD
library, and a different Job card where you can direct the final Bind
process. So when we migrated to V7 on our test machine, you could choose
the DB2 V7 system for the precompile and bind, or the V6 system for the
production precompile and bind. All of the changes to do we done with
through Administrative changes only, and not though rewriting Changeman
skeletons. FYI. We just installed Changeman V5R3M1 in our test environment,
and it has support for Stored procedures, User Defined Functions, and
Triggers. This includes Stored Procedure builder as well. I haven't got
everything set up yet, but it does it all including dropping, defining,
starting and stopping them. It also has a field to define Trigger firing
order. Cool! C support too.

-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?























Jeremiah Eden

Re: DB2 precompiler
(in response to Bob Davis)
The subsystem name you specify during the stage becomes the DB2ID for the
CMN21 job which performs the DB2 binds at Install time, along with the
SDSNLOAD at install. And it will use the DBRMLIB and BINDPLAN and
BINDPACKAGE libraries you defined for this system.

It is all tied together. This is right out of the box stuff, without
skeleton or exit mods.

I have gone through this same process from (DB2 V2x/Changeman V3x) to (DB2
V7x/Changeman V4x). And I just set it up for Changeman V5R3M1. Unless the
programmers have been allowed update authority to your production system
outside of Changeman you should not have a problem.

I will be leaving soon and won't be back till next year, but if you want
more details, you can contact me offline.

-----Original Message-----
From: Davis, Bob (B.E.) [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 11:27 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Jeremiah,

1. As you know, this DB2 panel CMNSTG18, which allows the developers to
choose the DB2 subsystem, is presented during staging. Suppose the
developer chooses TEST (in your scenario), then installs the change package
without restaging using the PROD subsystem. You now have a DBRM built with
the v7 precompiler executing in the v6 (PROD) environment. How do you
prevent programs created with the DB2 v7 precompiler from entering your DB2
v6 production environment?

2. Suppose the DB2 precompile step is coded to use the production-level DB2
software library such that only the v6 precompiler program can be used.
This would prevent developers from using v7 features before production is at
v7. OK, but now the first time that the v7 precompiler is used is when
production is upgraded to v7. Suppose an emergency fix is made to a DB2
program. The DB2 v7 precompiler has not yet been tested. Could use of it
cause any data corruption issues in production? This is the real concern
with a certain group here.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 11:55 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Assuming your application programmers can only access production libraries
through Changeman, and can not bind to production DB2 systems except through
Changeman.. you would define DB2 Physical and Logical Subsystems to
Changeman like the sample below under Global and Admin Options. If you
select either system from this screen, it will have a job card which can be
modified to direct to the initiator class, or system affinity to your V6 or
V7 system. So if a user specifies a DB2 precompile he will be prompted to
select one of these systems (pre V5.3 changeman). If he chooses TEST you
will get a V7 DBRM and Bind and be installed in that system.
If you choose PROD, you will get a V6 DBRM and bind and it will be installed
in the PROD system.

DB2
SUBSYS SITE DB2 SYSTEM LOAD LIBRARY
'''' PROD ________ DB2.V6R1M0.SDSNLOAD_______
'''' TEST ________ DB2.V7R1M0.SDSNLOAD_______


-----Original Message-----
From: Davis, Bob (B.E.) [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 10:08 AM
To: [login to unmask email]
Subject: Re: DB2 precompiler


How do you prevent programs created with the DB2 v7 precompiler from
entering your DB2 v6 production environment? Suppose a developer makes use
of a v7 feature not yet supported in v6.

Bob Davis
ADS Software Engineering Technologies
SCM - ChangeMan Specialist
iTek Building - E2J014
Phone: (313) 621-6918 FAX (313) 621-4338

http://www.serena.com
http://www.sdg.ford.com/scm/changeman.htm


-----Original Message-----
From: Jeremiah Eden [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 3:52 PM
To: [login to unmask email]
Subject: Re: DB2 precompiler


Good question? Maybe IBM will chime in. We also use Changeman. And we also
keep the precompiler and linkedit syslibs at the same maintenance level as
our Production DB2 system. I really don't think is a problem with V6 using a
V5 DBRM, but rather the other way around with a V5 system using a V6 DBRM,
especially with new bind options. However, Changeman gives you the ability
to have more than one DB2 instance to select from and associates a SDSNLOAD
library, and a different Job card where you can direct the final Bind
process. So when we migrated to V7 on our test machine, you could choose
the DB2 V7 system for the precompile and bind, or the V6 system for the
production precompile and bind. All of the changes to do we done with
through Administrative changes only, and not though rewriting Changeman
skeletons. FYI. We just installed Changeman V5R3M1 in our test environment,
and it has support for Stored procedures, User Defined Functions, and
Triggers. This includes Stored Procedure builder as well. I haven't got
everything set up yet, but it does it all including dropping, defining,
starting and stopping them. It also has a field to define Trigger firing
order. Cool! C support too.

-----Original Message-----
From: Bob Davis [mailto:[login to unmask email]
Sent: Thursday, December 19, 2002 1:21 PM
To: [login to unmask email]
Subject: DB2 precompiler


In our shop, we use ChangeMan which does NOT compile as part of the
migration process (i.e. from development into TEST, QA, Prod, etc.). This
process utilizes the production-level DB2 precompiler rather than the
latest / TEST version precompiler due to the fact that the programs are NOT
recompiled / relinked into each environment. Although we have never had a
problem with this process, certain groups here feel that this could expose
us to "data corruption" of the application data stored within DB2 or the
DB2 catalog.

Do we have anything to worry about? Why would binding with a v5 DBRM into
a v6 DB2 subsystem cause any problems?




























Bernd Oppolzer

Re: DB2 precompiler
(in response to Jeremiah Eden)
At our site, the time period between migrating the test and the prod systems
are only about 4 weeks. After that period, all systems are at the new DB2
version.

In the 4 weeks period with test on V7 and prod on V6, we simply don't teach the
developers about the new features of V7, so they hopefully will not try to use
them (we teach them after all systems are on V7). If someone uses the new
features anyway, we will get bind errors for the binds to the production
systems, which result in mails sent to us (the CCM team) and the DB2 admins, so
we have to care for these packages. The module containing the SQL is not
transferred to production.

Regards

Bernd


Am Fre, 20 Dez 2002 schrieben Sie:
> How do you prevent programs created with the DB2 v7 precompiler from
entering your DB2 v6 production environment? Suppose a developer makes use of
a v7 feature not yet supported in v6.
>
> Bob Davis
> ADS Software Engineering Technologies
> SCM - ChangeMan Specialist
> iTek Building - E2J014
> Phone: (313) 621-6918 FAX (313) 621-4338
>
> http://www.serena.com
> http://www.sdg.ford.com/scm/changeman.htm
>



Marcel Harleman

Re: DB2 precompiler
(in response to Bernd Oppolzer)
On Sat, 21 Dec 2002 17:11:04 +0100, you wrote:


>> How do you prevent programs created with the DB2 v7 precompiler from
>entering your DB2 v6 production environment? Suppose a developer makes use of
>a v7 feature not yet supported in v6.

We have looked (not implemented yet) at the approach our CICS-people
have adopted: when somebody wants to bring something into production
he has to go through a separate secured function. This function does a
precompiling, compiling and linking of the program. The result is
moved through the system. Precompiling is always done from a
load-library that has the production version of CICS (or DB2 in our
case). You try to use a new V7 function the system will not accept the
source.

Maybe an idea?

Marcel.
>>
>> Bob Davis
>> ADS Software Engineering Technologies
>> SCM - ChangeMan Specialist
>> iTek Building - E2J014
>> Phone: (313) 621-6918 FAX (313) 621-4338
>>
>> http://www.serena.com
>> http://www.sdg.ford.com/scm/changeman.htm
>>
>
>
>