By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,924 Members | 1,793 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,924 IT Pros & Developers. It's quick & easy.

8.1 and 8.2 "compiling"

P: n/a
just for grins, let's have a show of hands:

all those who think it's silly to not have a switch for stored
procedures written on 8.2 to compile through a C compiler.

^

we can't force all the clients to move at once to 8.2. nor can any
other VAR. it can't be all that difficult, can it?

BTDB
Nov 12 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
I miss the point,
but this is for my poor english ...

can you explain in different way your requirement?

Thanks.

Dario

Nov 12 '05 #2

P: n/a
"Dario" <db*****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
I miss the point,
but this is for my poor english ...

can you explain in different way your requirement?

Thanks.

Dario

I speak English very well, and I have no idea what the OP was asking?
Nov 12 '05 #3

P: n/a
Mark A wrote:
"Dario" <db*****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
I miss the point,
but this is for my poor english ...

can you explain in different way your requirement?

Thanks.

Dario


I speak English very well, and I have no idea what the OP was asking?

one cannot, according to the docs, use a 8.2 SP which is "compiled" to
DB2 bytecode in a 8.1 server. one *can* use a C compiled 8.1 SP in a
8.2 server. thus, one cannot have three things at the same time: SPs,
8.1 and 8.2. allowing an 8.2 developer to choose to have a SP compiled
from an 8.2 Dev Center by the C compiler permits staged upgrades to DB2.
one *cannot* do that now.

clear enough<G>?

BTDB
Nov 12 '05 #4

P: n/a
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:dP********************@rcn.net...

one cannot, according to the docs, use a 8.2 SP which is "compiled" to DB2
bytecode in a 8.1 server. one *can* use a C compiled 8.1 SP in a 8.2
server. thus, one cannot have three things at the same time: SPs, 8.1
and 8.2. allowing an 8.2 developer to choose to have a SP compiled from
an 8.2 Dev Center by the C compiler permits staged upgrades to DB2. one
*cannot* do that now.

clear enough<G>?

BTDB


No it is not clear. You said "three things " and I only count 2. But it is
hard to tell, because of your poor grammar. Please number them and use
punctuation between sentences. Please start each sentence with a capital
letter.

In DB2 8.1 and before, SQL SP's generated C code and were compiled.

In 8.2, newly created SQL SP's do not generate C code, instead they use DB2
bytecode.

Existing SP's that are left intact (that are not dropped and recreated)
during a migration from 8.1 to 8.2 are still in compiled C code.

These things have nothing to so with the client, they are determined by the
server release level.

I don't know if there are any issues with using a 8.2 Development Center
client with 8.1 server. In general, the DB2 only supports servers that are
at the same level or higher than the client.
Nov 12 '05 #5

P: n/a
Mark A wrote:
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:dP********************@rcn.net...
one cannot, according to the docs, use a 8.2 SP which is "compiled" to DB2
bytecode in a 8.1 server. one *can* use a C compiled 8.1 SP in a 8.2
server. thus, one cannot have three things at the same time: SPs, 8.1
and 8.2. allowing an 8.2 developer to choose to have a SP compiled from
an 8.2 Dev Center by the C compiler permits staged upgrades to DB2. one
*cannot* do that now.

clear enough<G>?

BTDB

No it is not clear. You said "three things " and I only count 2. But it is
hard to tell, because of your poor grammar. Please number them and use
punctuation between sentences. Please start each sentence with a capital
letter.

In DB2 8.1 and before, SQL SP's generated C code and were compiled.


********** In 8.2, newly created SQL SP's do not generate C code, instead they use DB2
bytecode. **********
and this *should* be at the developer's option; generate bytecode or
compiled C.

Existing SP's that are left intact (that are not dropped and recreated)
during a migration from 8.1 to 8.2 are still in compiled C code.
********** These things have nothing to so with the client, they are determined by the
server release level. **********
and since our clients (the companies) don't always upgrade right away,
we are left, if we want to use SPs, at 8.1. we can't avail ourselves of
8.2 stuff.

I don't know if there are any issues with using a 8.2 Development Center
client with 8.1 server. In general, the DB2 only supports servers that are
at the same level or higher than the client.


BTDB
Nov 12 '05 #6

P: n/a
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:dr********************@rcn.net...
**********
In 8.2, newly created SQL SP's do not generate C code, instead they use
DB2 bytecode.

**********
and this *should* be at the developer's option; generate bytecode or
compiled C.

BTDB


According to IBM the bytecode runs faster and they no longer want to support
the C generation, especially for the new features they add for SQL SP's.

I don't quite understand your requirement with respect to supporting your
customers. Make sure you use only 8.1 supported syntax in your SQL SP's.
When you install the code at a customer with 8.1 server you just move the SP
source code to the machine and do a create stored procedure command to
create it. On 8.1 the SQL SP will be generated C and compiled, and on 8.2 it
will be bytecode

You might be able to migrate SQL SP's from a 8.1 server to another server
and maintain the C code generation, but I am not sure about that. I do know
that if you upgrade a 8.1 database with SQL SP's to 8.2, the SQL SP's that
have generated C stay that way until you re-create them.
Nov 12 '05 #7

P: n/a
Mark A wrote:
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:dr********************@rcn.net...
**********
In 8.2, newly created SQL SP's do not generate C code, instead they use
DB2 bytecode.
**********
and this *should* be at the developer's option; generate bytecode or
compiled C.

BTDB

According to IBM the bytecode runs faster and they no longer want to support
the C generation, especially for the new features they add for SQL SP's.

I don't quite understand your requirement with respect to supporting your
customers. Make sure you use only 8.1 supported syntax in your SQL SP's.
When you install the code at a customer with 8.1 server you just move the SP
source code to the machine and do a create stored procedure command to
create it.


and that's the problem: our clients don't generally have the C compiler
(heck, i had to install gcc because... well). so we'll not be able to
ship source. thus the problem.

how common is this? can't say for sure, but i'll guess pretty much.
BTDB

On 8.1 the SQL SP will be generated C and compiled, and on 8.2 it will be bytecode

You might be able to migrate SQL SP's from a 8.1 server to another server
and maintain the C code generation, but I am not sure about that. I do know
that if you upgrade a 8.1 database with SQL SP's to 8.2, the SQL SP's that
have generated C stay that way until you re-create them.

Nov 12 '05 #8

P: n/a
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:AI******************************@rcn.net...

and that's the problem: our clients don't generally have the C compiler
(heck, i had to install gcc because... well). so we'll not be able to
ship source. thus the problem.

how common is this? can't say for sure, but i'll guess pretty much.
BTDB


You know, it would probably help most readers from a clarity standpoint if
you would use the term "customer" instead of "client" on this particular
forum. Hopefully you understand why that is the case.

True, some database servers don't have a C compiler, which is one reason IBM
made it so none is required for 8.2. As you mentioned, you can install gcc.

If you are on UNIX or Linux, you can have different versions of DB2 on the
same database server by using alternate fixpacks. Each instance can have its
own DB2 version/fixpack level, so if you need a 8.1 instance to generate SQL
SP's into C, then you do that on the same machine as you have 8.2 installed
on.
Nov 12 '05 #9

P: n/a
In article <kN********************@rcn.net>, (BobTheDataBaseBoy
<"xxx at rcn dot com">) says...
just for grins, let's have a show of hands:

all those who think it's silly to not have a switch for stored
procedures written on 8.2 to compile through a C compiler.

^

we can't force all the clients to move at once to 8.2. nor can any
other VAR. it can't be all that difficult, can it?

BTDB


Well, that's just the way it is. We upgrade our development
environment after all clients sides are upgraded to the requested DB2
level. If we want to use some new DB2 functionality we create a new
release and add the new DB2 version as a mandatory software
requirement before installing this new release.
Nov 12 '05 #10

P: n/a
"Gert van der Kooij" <ge**@invalid.nl> wrote in message
news:MP************************@news.xs4all.nl...
In article <kN********************@rcn.net>, (BobTheDataBaseBoy
<"xxx at rcn dot com">) says...
just for grins, let's have a show of hands:

all those who think it's silly to not have a switch for stored
procedures written on 8.2 to compile through a C compiler.

^

we can't force all the clients to move at once to 8.2. nor can any
other VAR. it can't be all that difficult, can it?

BTDB


Well, that's just the way it is. We upgrade our development
environment after all clients sides are upgraded to the requested DB2
level. If we want to use some new DB2 functionality we create a new
release and add the new DB2 version as a mandatory software
requirement before installing this new release.


You didn't read the whole thread. This guy is using the term "clients" to
mean his customers.
Nov 12 '05 #11

P: n/a
In article <-f******************************@comcast.com>, Mark A
(no****@nowhere.com) says...
"Gert van der Kooij" <ge**@invalid.nl> wrote in message

Well, that's just the way it is. We upgrade our development
environment after all clients sides are upgraded to the requested DB2
level. If we want to use some new DB2 functionality we create a new
release and add the new DB2 version as a mandatory software
requirement before installing this new release.


You didn't read the whole thread. This guy is using the term "clients" to
mean his customers.


I did, I just used his term. I was talking about our customers.
Nov 12 '05 #12

P: n/a
BobTheDataBaseBoy wrote:
just for grins, let's have a show of hands:

all those who think it's silly to not have a switch for stored
procedures written on 8.2 to compile through a C compiler.

^

we can't force all the clients to move at once to 8.2. nor can any
other VAR. it can't be all that difficult, can it?

BTDB

Clarification: Noone is forcing you to recompile your stored procedures
when you move from V8.1 to V8.2. Procedures compiled with teh C-Compiler
will keep working until you decide to drop and recreate them.
At that point they will magically re-appear using p-Code.
Now, I recommend to sdrop/recreate procedures on upgrade so in the odd
chance that something doesn't work the same you at least knwo it was the
upgrade. realizing that some change was introduced because a proc was
recreated a year later is bound to prolong a PMR resolution cycle.

What's the part I'm missing? I just don't get the problem (which may
have contributed to the sillyness you describe).

Cheers
Serge

PS: Supporting two separate codepaths to do the same thing is messy and
not that simple at all. Bearing a new and to me surprising revelation I
remain convinced a clear cut was the right thing to do.
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #13

P: n/a
Serge Rielau wrote:
BobTheDataBaseBoy wrote:
just for grins, let's have a show of hands:

all those who think it's silly to not have a switch for stored
procedures written on 8.2 to compile through a C compiler.

^

we can't force all the clients to move at once to 8.2. nor can any
other VAR. it can't be all that difficult, can it?

BTDB
Clarification: Noone is forcing you to recompile your stored procedures
when you move from V8.1 to V8.2.


understood. but having 8.2 as a development box makes it difficult, at
the least, to write SPs and get them to customers still on 8.1. IIRC
(not in CubeLand), 8.1 and 8.2 can't live on one machine. having a
switch in 8.2 that lets the developer decide how to "compile" a SP is a
"good thing".

what is previously unsaid, is that i am fighting to get my CubeLand
Suits to embrace SP. now, this is a significant new hurdle placed in
the way: "what, we have to manage how we compile them!!!! forget it
Bob, we'll keep writing COBOL." for developers who are/were in process
of using SP, this 8.1 8.2 nexus is inconvenient.

BTDB

Procedures compiled with teh C-Compiler will keep working until you decide to drop and recreate them.
At that point they will magically re-appear using p-Code.
Now, I recommend to sdrop/recreate procedures on upgrade so in the odd
chance that something doesn't work the same you at least knwo it was the
upgrade. realizing that some change was introduced because a proc was
recreated a year later is bound to prolong a PMR resolution cycle.

What's the part I'm missing? I just don't get the problem (which may
have contributed to the sillyness you describe).

Cheers
Serge

PS: Supporting two separate codepaths to do the same thing is messy and
not that simple at all. Bearing a new and to me surprising revelation I
remain convinced a clear cut was the right thing to do.

Nov 12 '05 #14

P: n/a
"Serge Rielau" <sr*****@ca.ibm.com> wrote in message
news:3q************@individual.net...
What's the part I'm missing? I just don't get the problem (which may have
contributed to the sillyness you describe).

Cheers
Serge


I think his company develops software, which they sell to other companies
who have to install it. I think they wanted to ship compiles code, but I am
not sure about that.
Nov 12 '05 #15

P: n/a
"BobTheDataBaseBoy" <"xxx at rcn dot com"> wrote in message
news:U6********************@rcn.net...

understood. but having 8.2 as a development box makes it difficult, at
the least, to write SPs and get them to customers still on 8.1. IIRC (not
in CubeLand), 8.1 and 8.2 can't live on one machine. having a switch in
8.2 that lets the developer decide how to "compile" a SP is a "good
thing".

what is previously unsaid, is that i am fighting to get my CubeLand Suits
to embrace SP. now, this is a significant new hurdle placed in the way:
"what, we have to manage how we compile them!!!! forget it Bob, we'll
keep writing COBOL." for developers who are/were in process of using SP,
this 8.1 8.2 nexus is inconvenient.

BTDB

You can ship source code for the SP's, and have your customers rebuild the
SQL SP's with create procedure command.. For 8.1 they will end up with
compiled C code, and for 8.2 it will bytecode. I don't see any problem
here.

Yes, as discussed, this will require a C compiler for 8.1 machines. Maybe
that is an incentive for them to move to 8.2.

As I previously stated, you and your customers can run 2 different DB2
release levels on the same machine with alternate fixpacks.
Nov 12 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.