DB2 V8 NFM/ENFM migration

Joseph Burns

DB2 V8 NFM/ENFM migration
Hi George,

We have a similar setup to what you described for your program migration
process. My guess is many people do. We pre-compile, compile and bind on
the development environment. Then we "move" the load and DBRM to prod and
do a bind in the prod system.

We are not at v8 yet, but will begin our migration this month. So we've
had to look at some of the same things you've talked about. According to
everything I've seen, you should definitely be able to take the DBRM that
was created in the V8 ENFM system (development) and bind it in the V8 CM
system (prod). In fact, you should be able to take a V7 DBRM and bind it
in the V8 CM system. Everything about the DBRM will stay EBCDIC until you
go to full NFM.

Once in full NFM, the default setting for NEWFUN is "YES" which means you
get a UNICODE DBRM. But the default for NEWFUN is "NO" in both CM and
ENFM mode (which gets you an EBCID DBRM). So unless you override the
NEWFUN setting for some reason you should be fine.

I'm not sure what to say about staying in ENFM mode for an extended period
of time. If you need to do it, then I might consider at least rebinding
your packages/plans if you're going to be in ENFM for awhile. We plan to
rebind everything once we get to full NFM ... after letting the code set
for a little while of course.

I can also see your point about third party exploitation of new v8
features. We have some of the same concerns. But we're working with our
vendors and we've been vocal about what which features we'd like to see
sooner rather than later. At this point, we think we can get by with some
compromises on our part. So we're cautiously moving forward, but we feel
like we are better off going to V8 NFM rather than holding back.

Good luck with your migration.

Regards,
Joe Burns
Highmark Inc.



On Thu, 29 Dec 2005 08:38:45 -0500, [login to unmask email] wrote:

>George,
> IBM recommends the time window between ENFM and NFM be
>short in duration. That said, I would recommend
> deferring any migration changes for applications until
>the ENFM testing is completed. If that is not possible,
> you could migrate to ENFM in production and then do
the
>application migrations.
>
> The scenario you describe seems too risky to me.
>
>Regards,
>
>****************************************
>Steve Vagnier
>American Electric Power
>Database Administration
>One Riverside Plaza - 7th Floor
>Columbus, Ohio 43215
>Email: [login to unmask email]
>Phone: 614-716-3677
>Audinet: 200-3677
>
>
>
>
> George Palko
> <[login to unmask email]
> > To
> Sent by: DB2 Data [login to unmask email]
> Base Discussion cc
> List
> <[login to unmask email] Subject
> ORG> [DB2-L] DB2 V8 NFM/ENFM migration
>
>
> 12/29/2005 08:08
> AM
>
>
> Please respond to
> DB2 Database
> Discussion list
> at IDUG
> <[login to unmask email]
> 2-L.ORG>
>
>
>
>
>
>
>Hi List,
>
>We are in the process of migrating from DB2 V8 CM to NFM. However, we've
>encountered an issue where a number of our third-party vendors are not yet
>ready to exploit V8 NFM. To expedite the process of migrating, we've
>decided to migrate to NFM and then convert back to ENFM, thus disabling
new
>functions. My question is: is it possible for a DBRM that was created
>within ENFM with NEWFUN set to NO to be re-bound in a V8 CM subsystem? We
>have multiple development regions and my plan is to have the ENFM
>development subsystems in place for a period of time, so as to perform a
>more comprehensive regression test. However to do this, we would have to
>be able to migrate from the ENFM development subsystems into a V8 CM
>production subsystem. Our migrations are accomplished by moving the load
>module and rebinding the plan/packages. Will this be possible under the
>scenario I just described?
>
>Any and all suggestion would be greatly appreciated.
>
>Thank you,
>--------------------------------------------------------------------------
--
>
>----
>George Palko
>Sr. Systems Programmer
>Ohio Public Employees Retirement System (OPERS)
>P(614) 222-6242, F(614)227-6157
>[login to unmask email]
>
>--------------------------------------------------------------------------
-------
>
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home
>page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select
>"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-
l.org
>. The IDUG List Admins can be reached at [login to unmask email]
>Find out the latest on IDUG conferences at
>http://conferences.idug.org/index.cfm
>
>--------------------------------------------------------------------------
-------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at DB2-L-
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

William Favero

Re: DB2 V8 NFM/ENFM migration
(in response to Joseph Burns)
Hi George

I have a short write-up on ENFM at
http://blogs.ittoolbox.com/database/db2zos/archives/006862.asp that you
may want to take a look at.

Willie

George Palko wrote:

>Hi List,
>
>We are in the process of migrating from DB2 V8 CM to NFM. However, we've
>encountered an issue where a number of our third-party vendors are not yet
>ready to exploit V8 NFM. To expedite the process of migrating, we've
>decided to migrate to NFM and then convert back to ENFM, thus disabling new
>functions. My question is: is it possible for a DBRM that was created
>within ENFM with NEWFUN set to NO to be re-bound in a V8 CM subsystem? We
>have multiple development regions and my plan is to have the ENFM
>development subsystems in place for a period of time, so as to perform a
>more comprehensive regression test. However to do this, we would have to
>be able to migrate from the ENFM development subsystems into a V8 CM
>production subsystem. Our migrations are accomplished by moving the load
>module and rebinding the plan/packages. Will this be possible under the
>scenario I just described?
>
>Any and all suggestion would be greatly appreciated.
>
>Thank you,
>----------------------------------------------------------------------------
>----
>George Palko
>Sr. Systems Programmer
>Ohio Public Employees Retirement System (OPERS)
>P(614) 222-6242, F(614)227-6157
>[login to unmask email]
>
>---------------------------------------------------------------------------------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>
>
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Joan Keemle

Re: DB2 V8 NFM/ENFM migration
(in response to William Favero)
The answer to your question is Yes: DBRMs generated with NEWFUN NO can
be bound in CM. There may be a few minor exceptions.

As regards going to NFM and then "converting back to ENFM", why not stop
at ENFM? Just don't run that final job DSNTIJNF until you're ready for
NFM, and keep NEWFUN=NO in your DSNHDECP.

I recommend you do the comprehensive regression test while still in
Compatibility Mode. This approach has served us well. Our experience
is detailed here:
http://www-1.ibm.com/support/docview.wss?rs=0&q1=DB2+UDB+for+z%2fOS+V8+M
igration%3a+An+Ironman%c2%ae+event&uid=swg27006236&loc=en_US&cs=utf-8&cc
=us&lang=en

There is a lot of V8 information available on the roadmap web site:

http://www-306.ibm.com/software/data/db2/zos/roadmap.html

Thanks, Joan

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of George Palko
Sent: Thursday, December 29, 2005 7:09 AM
To: [login to unmask email]
Subject: [DB2-L] DB2 V8 NFM/ENFM migration

Hi List,

We are in the process of migrating from DB2 V8 CM to NFM. However,
we've encountered an issue where a number of our third-party vendors are
not yet ready to exploit V8 NFM. To expedite the process of migrating,
we've decided to migrate to NFM and then convert back to ENFM, thus
disabling new functions. My question is: is it possible for a DBRM
that was created within ENFM with NEWFUN set to NO to be re-bound in a
V8 CM subsystem? We have multiple development regions and my plan is to
have the ENFM development subsystems in place for a period of time, so
as to perform a more comprehensive regression test. However to do this,
we would have to be able to migrate from the ENFM development subsystems
into a V8 CM production subsystem. Our migrations are accomplished by
moving the load module and rebinding the plan/packages. Will this be
possible under the scenario I just described?

Any and all suggestion would be greatly appreciated.

Thank you,
------------------------------------------------------------------------
----
----
George Palko
Sr. Systems Programmer
Ohio Public Employees Retirement System (OPERS)
P(614) 222-6242, F(614)227-6157
[login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

George Palko

DB2 V8 ENFM migration
(in response to Joan Keemle)
Hi,

I'd like to thank everyone who answered my previous question concerning
DBRM mode compatibility within V8.

I have an additional question concerning the V8 migration. As I stated in
my previous post, we're in a situation where a number of our third-party
vendors are not willing, yet, to give us a date, as far as, when they will
be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
But, because of the time that is involved in migrating, we feel that we
should begin the ENFM migration sooner rather than later.

Once the production ENFM is complete, it's my "hope" that the vendors will
be ready. However, if they are not ready, we will be in a position where
we will have to stay in ENFM for an extended period of time. All the
documentation that I've been reading states that one should stay in ENFM
for a short period. For obvious reasons, I understand why one would want
to complete the DSNTIJNE job as quickly as possible. But, I'm having a
difficult time understanding what the implications would be if we have to
keep all our subsystems, including production, in ENFM for an extended
period.

Does anyone know of any technical reasons, as to why, one should not stay
in ENFM for extended periods?


Thank you,
George

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

William Favero

Re: DB2 V8 ENFM migration
(in response to George Palko)
I don't think there is a technical reason for quickly moving from ENFM
to NFM. ENFM converts the catalog (Unicode and long names) and the
recommendation is to test the conversion and move on so you can take
advantage of the new SQL and other features of V8. NFM essentially
mean the NEWFUN switch in DSNHDECP has been flipped from NO to YES and
changes DBRMs from EBCDIC to Unicode. (Take a look at
http://blogs.ittoolbox.com/database/db2zos/archives/007155.asp) So
your migration is really completed in ENFM, you are just not letting
anyone use any new features.

Also remember, that NEWFUN can be set at precompiler time. So not
running the job to enter NFM does not totally guarantee that no one can
use a new feature in V8.

--
Willie
My DB2 blog --> http://blogs.ittoolbox.com/database/db2zos




George Palko wrote:

>Hi,
>
>I'd like to thank everyone who answered my previous question concerning
>DBRM mode compatibility within V8.
>
>I have an additional question concerning the V8 migration. As I stated in
>my previous post, we're in a situation where a number of our third-party
>vendors are not willing, yet, to give us a date, as far as, when they will
>be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
>But, because of the time that is involved in migrating, we feel that we
>should begin the ENFM migration sooner rather than later.
>
>Once the production ENFM is complete, it's my "hope" that the vendors will
>be ready. However, if they are not ready, we will be in a position where
>we will have to stay in ENFM for an extended period of time. All the
>documentation that I've been reading states that one should stay in ENFM
>for a short period. For obvious reasons, I understand why one would want
>to complete the DSNTIJNE job as quickly as possible. But, I'm having a
>difficult time understanding what the implications would be if we have to
>keep all our subsystems, including production, in ENFM for an extended
>period.
>
>Does anyone know of any technical reasons, as to why, one should not stay
>in ENFM for extended periods?
>
>
>Thank you,
>George
>
>---------------------------------------------------------------------------------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>
>
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

David Seibert

Re: DB2 V8 ENFM migration
(in response to William Favero)
I think you'd be better off staying in Compatibility mode.

What is the motivation to get to ENFM where things are more complicated if
you're not going to move into NFM?
Why get all the long names in the catalog and unicode and virtually none of
the benefits?

I don't think it is as if you are going to save any time getting to ENFM
early.

See Joan Keemle's excellent presentation from IDUG in her post 3 days ago.

Dave




-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of George Palko
Sent: Friday, January 06, 2006 9:39 AM
To: [login to unmask email]
Subject: [DB2-L] DB2 V8 ENFM migration


Hi,

I'd like to thank everyone who answered my previous question concerning DBRM
mode compatibility within V8.

I have an additional question concerning the V8 migration. As I stated in
my previous post, we're in a situation where a number of our third-party
vendors are not willing, yet, to give us a date, as far as, when they will
be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
But, because of the time that is involved in migrating, we feel that we
should begin the ENFM migration sooner rather than later.

Once the production ENFM is complete, it's my "hope" that the vendors will
be ready. However, if they are not ready, we will be in a position where we
will have to stay in ENFM for an extended period of time. All the
documentation that I've been reading states that one should stay in ENFM for
a short period. For obvious reasons, I understand why one would want to
complete the DSNTIJNE job as quickly as possible. But, I'm having a
difficult time understanding what the implications would be if we have to
keep all our subsystems, including production, in ENFM for an extended
period.

Does anyone know of any technical reasons, as to why, one should not stay in
ENFM for extended periods?


Thank you,
George

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm



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.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Marc --- Sr. Database Analyst --- CFS Costa

Re: DB2 V8 ENFM migration
(in response to David Seibert)
George,

To my knowledge there is no issue of staying in ENFM for an extended
period of time. At the tech conference I heard about one company that
was planning on staying in CM for 6 months and ENFM for six months
before going to NFM.

The real question I have is why are you migrating right now to V8 if it
isn't to take advantage of the new features in version 8? Until you run
DSNTIJNF, you aren't going to get the new features. Wouldn't you wait 6
months to a year to do this if you don't need some of the new features
(and allow the vendors to "maybe" be in a better position to support
V8)? We are in NFM and we have had (and continue to have) issues with
vendor products. We had discussions with almost all of our vendors to
talk about what they would support and when. From my perspective, most
vendors will be in a better position to fully support V8 later this year
(hopefully).

Marc
-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of George Palko
Sent: Friday, January 06, 2006 7:39 AM
To: [login to unmask email]
Subject: [DB2-L] DB2 V8 ENFM migration

Hi,

I'd like to thank everyone who answered my previous question concerning
DBRM mode compatibility within V8.

I have an additional question concerning the V8 migration. As I stated
in
my previous post, we're in a situation where a number of our third-party
vendors are not willing, yet, to give us a date, as far as, when they
will
be exploiting V8 NFM. This has made us very reluctant to migrate to
NFM.
But, because of the time that is involved in migrating, we feel that we
should begin the ENFM migration sooner rather than later.

Once the production ENFM is complete, it's my "hope" that the vendors
will
be ready. However, if they are not ready, we will be in a position
where
we will have to stay in ENFM for an extended period of time. All the
documentation that I've been reading states that one should stay in ENFM
for a short period. For obvious reasons, I understand why one would
want
to complete the DSNTIJNE job as quickly as possible. But, I'm having a
difficult time understanding what the implications would be if we have
to
keep all our subsystems, including production, in ENFM for an extended
period.

Does anyone know of any technical reasons, as to why, one should not
stay
in ENFM for extended periods?


Thank you,
George

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


*******************************************************
This message contains information that is confidential
and proprietary to FedEx Freight or its affiliates.
It is intended only for the recipient named and for
the express purpose(s) described therein.
Any other use is prohibited.
*******************************************************

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

[login to unmask email]

Re: DB2 V8 ENFM migration
(in response to Marc --- Sr. Database Analyst --- CFS Costa)
George,

I'm fascinated by your comment, "a number of our third-party vendors are
not willing, yet, to give us a date, as far as, when they will be
exploiting V8 NFM." Uh, DB2 UDB for z/OS Version 8 went GA in March 2004.
Most third-party vendors were given early versions of the code as early
as January 2003. Isn't almost three years enough time ?!

That said, here's my take on your proposed situation. Successful execution
of DSNTIJNE puts you in "No New Function New Function Mode" (a phrase I
atribute to Jay Yothers). Granted, as I think Dave Seibert noted, you have
all the issues of NFM (Unicode catalog, long names) but cannot use most
new V8 functions. Still, I see a few benefits in remaining here for a bit,
depending upon your situation.

NNFNFM (a great acronym!) means that you can deal with any issues you have
related to the catalog conversion without also having to deal with issues
related to new function use. If you expect that you will have these types
of issues, maybe you should put off NFM for a while.

Do you have production applications that access catalog tables? If so,
they may need new host variable definitions for certain catalog columns.
Do you expect any code page or CCSID errors associated with objects or
objects' names? Do you have SQL statements that use the caret ("^")
character in operators (like ^<, ^>, or ^=)? Do you have objects
associated with vendor products whose names, once translated to Unicode,
will have multi-byte characters?

Do you have applications that will use byte-based functions (like SUBSTR
and LENGTH) on table columns that are now Unicode? If so, you may need to
use the new character-based functions (like SUBSTRING).

All of these issues (and more) are discussed and presented in detail on
the IBM DB2 V8 support web site:

www.ibm.com/software/data/db2/zos/support.html

Hope this helps.

Lock Lyon
Compuware Corp




George Palko <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
01/06/2006 09:38 AM
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc

Subject
[DB2-L] DB2 V8 ENFM migration






Hi,

I'd like to thank everyone who answered my previous question concerning
DBRM mode compatibility within V8.

I have an additional question concerning the V8 migration. As I stated in
my previous post, we're in a situation where a number of our third-party
vendors are not willing, yet, to give us a date, as far as, when they will
be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
But, because of the time that is involved in migrating, we feel that we
should begin the ENFM migration sooner rather than later.

Once the production ENFM is complete, it's my "hope" that the vendors will
be ready. However, if they are not ready, we will be in a position where
we will have to stay in ENFM for an extended period of time. All the
documentation that I've been reading states that one should stay in ENFM
for a short period. For obvious reasons, I understand why one would want
to complete the DSNTIJNE job as quickly as possible. But, I'm having a
difficult time understanding what the implications would be if we have to
keep all our subsystems, including production, in ENFM for an extended
period.

Does anyone know of any technical reasons, as to why, one should not stay
in ENFM for extended periods?


Thank you,
George


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Gerald Hodge

Re: DB2 V8 ENFM migration
(in response to LL581@DAIMLERCHRYSLER.COM)
George:

The main reason for not completing the V8 conversion is that many 3rd party
vendors can not support it. The only tools vendor, I am aware of, that has
a complete set of fully functional and exploitive V8 tools is IBM.
(Obviously I would not say this if our tools did not support and exploit
V8.) You need to weigh input on this topic based on the economic position
of the person giving the input.

Our understanding is that the Optimizer has different factors it considers
in full function mode. This means that binds or rebinds need to be
monitored. Our test show benefits and some risks, please look at out
http://www.hlstechnologies.com/downloads.html page for our free analysis
white paper and the material to recreate our test scenarios. Download the
material and run the tests on your play pen system and compare your results
to ours.

VNEXT is coming. When it does V7's days are numbered. V8 will not be a
skip release and you won't get pass it from compatibility mode. If costs
for analyzing your risks are a restraining factor, please see our
advertisement in the current IDUG Solutions Journal on page 5. Please feel
free to email me off line or call me at the toll free number below.

Gerald Hodge
HLS Technologies, Inc.
888-494-9019

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roger Miller

Re: DB2 V8 ENFM migration
(in response to Gerald Hodge)
There is quite a bit of good information in the other responses. I'd like
to twist on a couple of points. Vendors generally got the first code in
October 2002, so that's more than 3 years ago. The customers started
their early program in Feb 2003 for 14 months. V8 general availability is
at 21 months now and counting. In ENFM, you have almost exactly the same
function as in CM, since any new function DBRM will not BIND.

This is a judgement call, but I'd say that staying in CM a long time is a
lot safer than a long time in ENFM. The major testing here was for NFM
and CM. Have you looked at vendor test and support for ENFM? That seemed
to be much less than for NFM to me. I think that several chose not to
handle the complexity, since it can generally be under an hour. Customers
are generally spending a month or more in CM, going through ENFM in an
hour, then running NFM for most of the time. There are a couple of
exceptions, as always. Running in the mainstream of our testing and
customer use is safer, especially if you don't have lots of extra time to
test, as this is one more unique choice.

Nnext is coming, and we have some good information on the web. The place
to start is on the web - probably the ftp web site. Sort by latest dates.
ftp://ftp.software.ibm.com/software/data/db2zos/
VNEXT.pdf is Curt's presentation with a couple of foils on V8, then about
50 foils on Vnext. The foils include notes on almost every page.
DB2Futures.pdf is the version John Campbell used in his webcast, with the
audio file in DB2Futures.zip (about 10 MB). John's recent presentations
on storage management and V8 migration are also there.

Roger Miller


On Fri, 6 Jan 2006 09:11:14 -0600, Willie Favero <[login to unmask email]>
wrote:

>I don't think there is a technical reason for quickly moving from ENFM
>to NFM. ENFM converts the catalog (Unicode and long names) and the
>recommendation is to test the conversion and move on so you can take
>advantage of the new SQL and other features of V8. NFM essentially
>mean the NEWFUN switch in DSNHDECP has been flipped from NO to YES and
>changes DBRMs from EBCDIC to Unicode. (Take a look at
>http://blogs.ittoolbox.com/database/db2zos/archives/007155.asp) So
>your migration is really completed in ENFM, you are just not letting
>anyone use any new features.
>
>Also remember, that NEWFUN can be set at precompiler time. So not
>running the job to enter NFM does not totally guarantee that no one can
>use a new feature in V8.
>
>--
>Willie
>My DB2 blog --> http://blogs.ittoolbox.com/database/db2zos
>
>
>
>
>George Palko wrote:
>
>>Hi,
>>
>>I'd like to thank everyone who answered my previous question concerning
>>DBRM mode compatibility within V8.
>>
>>I have an additional question concerning the V8 migration. As I stated
in
>>my previous post, we're in a situation where a number of our third-party
>>vendors are not willing, yet, to give us a date, as far as, when they
will
>>be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
>>But, because of the time that is involved in migrating, we feel that we
>>should begin the ENFM migration sooner rather than later.
>>
>>Once the production ENFM is complete, it's my "hope" that the vendors
will
>>be ready. However, if they are not ready, we will be in a position where
>>we will have to stay in ENFM for an extended period of time. All the
>>documentation that I've been reading states that one should stay in ENFM
>>for a short period. For obvious reasons, I understand why one would want
>>to complete the DSNTIJNE job as quickly as possible. But, I'm having a
>>difficult time understanding what the implications would be if we have to
>>keep all our subsystems, including production, in ENFM for an extended
>>period.
>>
>>Does anyone know of any technical reasons, as to why, one should not stay
>>in ENFM for extended periods?
>>
>>
>>Thank you,
>>George
>>
>>-------------------------------------------------------------------------
--------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

William Favero

Re: DB2 V8 ENFM migration
(in response to Roger Miller)
It seems that I mis-stated another thing in my post, sorry , typing too
fast... I should know better than answer an e-mail before my first cup
of coffee... LOL However, my blog has it stated correctly...

My last sentence is completely off base. Once you migrate to NFM, you
can toggle back and forth between ENFM and NFM, but you do have to get
to NFM first... CATENFM with COMPLETE does do a few "special" things
when entering NFM.

Thanks Joan

Willie
http://blogs.ittoolbox.com/database/db2zos/

Roger Miller wrote:

>There is quite a bit of good information in the other responses. I'd like
>to twist on a couple of points. Vendors generally got the first code in
>October 2002, so that's more than 3 years ago. The customers started
>their early program in Feb 2003 for 14 months. V8 general availability is
>at 21 months now and counting. In ENFM, you have almost exactly the same
>function as in CM, since any new function DBRM will not BIND.
>
>This is a judgement call, but I'd say that staying in CM a long time is a
>lot safer than a long time in ENFM. The major testing here was for NFM
>and CM. Have you looked at vendor test and support for ENFM? That seemed
>to be much less than for NFM to me. I think that several chose not to
>handle the complexity, since it can generally be under an hour. Customers
>are generally spending a month or more in CM, going through ENFM in an
>hour, then running NFM for most of the time. There are a couple of
>exceptions, as always. Running in the mainstream of our testing and
>customer use is safer, especially if you don't have lots of extra time to
>test, as this is one more unique choice.
>
>Nnext is coming, and we have some good information on the web. The place
>to start is on the web - probably the ftp web site. Sort by latest dates.
>ftp://ftp.software.ibm.com/software/data/db2zos/
>VNEXT.pdf is Curt's presentation with a couple of foils on V8, then about
>50 foils on Vnext. The foils include notes on almost every page.
>DB2Futures.pdf is the version John Campbell used in his webcast, with the
>audio file in DB2Futures.zip (about 10 MB). John's recent presentations
>on storage management and V8 migration are also there.
>
>Roger Miller
>
>
>On Fri, 6 Jan 2006 09:11:14 -0600, Willie Favero <[login to unmask email]>
>wrote:
>
>
>
>>I don't think there is a technical reason for quickly moving from ENFM
>>to NFM. ENFM converts the catalog (Unicode and long names) and the
>>recommendation is to test the conversion and move on so you can take
>>advantage of the new SQL and other features of V8. NFM essentially
>>mean the NEWFUN switch in DSNHDECP has been flipped from NO to YES and
>>changes DBRMs from EBCDIC to Unicode. (Take a look at
>>http://blogs.ittoolbox.com/database/db2zos/archives/007155.asp) So
>>your migration is really completed in ENFM, you are just not letting
>>anyone use any new features.
>>
>>Also remember, that NEWFUN can be set at precompiler time. So not
>>running the job to enter NFM does not totally guarantee that no one can
>>use a new feature in V8.
>>
>>--
>>Willie
>>My DB2 blog --> http://blogs.ittoolbox.com/database/db2zos
>>
>>
>>
>>
>>George Palko wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I'd like to thank everyone who answered my previous question concerning
>>>DBRM mode compatibility within V8.
>>>
>>>I have an additional question concerning the V8 migration. As I stated
>>>
>>>
>in
>
>
>>>my previous post, we're in a situation where a number of our third-party
>>>vendors are not willing, yet, to give us a date, as far as, when they
>>>
>>>
>will
>
>
>>>be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
>>>But, because of the time that is involved in migrating, we feel that we
>>>should begin the ENFM migration sooner rather than later.
>>>
>>>Once the production ENFM is complete, it's my "hope" that the vendors
>>>
>>>
>will
>
>
>>>be ready. However, if they are not ready, we will be in a position where
>>>we will have to stay in ENFM for an extended period of time. All the
>>>documentation that I've been reading states that one should stay in ENFM
>>>for a short period. For obvious reasons, I understand why one would want
>>>to complete the DSNTIJNE job as quickly as possible. But, I'm having a
>>>difficult time understanding what the implications would be if we have to
>>>keep all our subsystems, including production, in ENFM for an extended
>>>period.
>>>
>>>Does anyone know of any technical reasons, as to why, one should not stay
>>>in ENFM for extended periods?
>>>
>>>
>>>Thank you,
>>>George
>>>
>>>-------------------------------------------------------------------------
>>>
>>>
>--------
>
>---------------------------------------------------------------------------------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>
>
>


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Joan Keemle

Re: DB2 V8 ENFM migration
(in response to William Favero)
(OK, Willie, here is the post!)

For clarifiction -

If the DSNTIJNF job is not executed (DSNUTILB with CATENFM COMPLETE), you
will not be able to precompile with NEWFUN=YES or use new function in
dynamic SQL.

If DSNTIJNF has been executed, you can precompile with NEWFUN=YES or
NEWFUN=NO and depending on what is specified, the DBRM is in EBCDIC or
UNICODE. (Regardless of system default in DSNHDECP.)

I think there is some confusion that DSNHDECP system default of NEWFUN=YES
is what 'flips the switch' for new function, when in fact it is not. It is
the execution of DSNTIJNF (DSNUTILB with CATENFM COMPLETE) that 'flips the
switch'.

Thanks, Joan

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roland Schiradin

Re: DB2 V8 ENFM migration
(in response to Joan Keemle)
I also wonder about the ISV as DB2 V8 is in the market since about two years !!!!
We had/have some issue with ASG-TMON/DB2 4.0 but mostly not related to V8 only. Perhaps
we had a deeper look for application and ISV after the upgrade to V8. The TMON-DB2 SQL-Analyzer
was very buggy.

BMC Catalog Manager (7.4 and 8.1) is still a pain waiting for version 8.2 to support V8 NFM.

Compuware Strobe still doesn't support CICS TS V3.1 and this is in the market for about
9 months and their packages for DB V8 require NFM!!!

Roland


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of [login to unmask email]
Sent: Friday, January 06, 2006 4:40 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 V8 ENFM migration



George,

I'm fascinated by your comment, "a number of our third-party vendors are not willing, yet, to give us a date, as far as, when they will be exploiting V8 NFM." Uh, DB2 UDB for z/OS Version 8 went GA in March 2004. Most third-party vendors were given early versions of the code as early as January 2003. Isn't almost three years enough time ?!

That said, here's my take on your proposed situation. Successful execution of DSNTIJNE puts you in "No New Function New Function Mode" (a phrase I atribute to Jay Yothers). Granted, as I think Dave Seibert noted, you have all the issues of NFM (Unicode catalog, long names) but cannot use most new V8 functions. Still, I see a few benefits in remaining here for a bit, depending upon your situation.

NNFNFM (a great acronym!) means that you can deal with any issues you have related to the catalog conversion without also having to deal with issues related to new function use. If you expect that you will have these types of issues, maybe you should put off NFM for a while.

Do you have production applications that access catalog tables? If so, they may need new host variable definitions for certain catalog columns. Do you expect any code page or CCSID errors associated with objects or objects' names? Do you have SQL statements that use the caret ("^") character in operators (like ^<, ^>, or ^=)? Do you have objects associated with vendor products whose names, once translated to Unicode, will have multi-byte characters?

Do you have applications that will use byte-based functions (like SUBSTR and LENGTH) on table columns that are now Unicode? If so, you may need to use the new character-based functions (like SUBSTRING).

All of these issues (and more) are discussed and presented in detail on the IBM DB2 V8 support web site:

www.ibm.com/software/data/db2/zos/support.html

Hope this helps.

Lock Lyon
Compuware Corp




George Palko <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>

01/06/2006 09:38 AM
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc
Subject
[DB2-L] DB2 V8 ENFM migration






Hi,

I'd like to thank everyone who answered my previous question concerning
DBRM mode compatibility within V8.

I have an additional question concerning the V8 migration. As I stated in
my previous post, we're in a situation where a number of our third-party
vendors are not willing, yet, to give us a date, as far as, when they will
be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
But, because of the time that is involved in migrating, we feel that we
should begin the ENFM migration sooner rather than later.

Once the production ENFM is complete, it's my "hope" that the vendors will
be ready. However, if they are not ready, we will be in a position where
we will have to stay in ENFM for an extended period of time. All the
documentation that I've been reading states that one should stay in ENFM
for a short period. For obvious reasons, I understand why one would want
to complete the DSNTIJNE job as quickly as possible. But, I'm having a
difficult time understanding what the implications would be if we have to
keep all our subsystems, including production, in ENFM for an extended
period.

Does anyone know of any technical reasons, as to why, one should not stay
in ENFM for extended periods?


Thank you,
George

--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Edward Long

Re: DB2 V8 ENFM migration
(in response to Roland Schiradin)
I don't know if anyone ever tells you Roger; but, thank you for participating in this listserv and providing the kinds of detailed advice you give.
This is a good thing; thanks for doing it.
Ed Long

Roger Miller <[login to unmask email]> wrote:
There is quite a bit of good information in the other responses. I'd like
to twist on a couple of points. Vendors generally got the first code in
October 2002, so that's more than 3 years ago. The customers started
their early program in Feb 2003 for 14 months. V8 general availability is
at 21 months now and counting. In ENFM, you have almost exactly the same
function as in CM, since any new function DBRM will not BIND.

This is a judgement call, but I'd say that staying in CM a long time is a
lot safer than a long time in ENFM. The major testing here was for NFM
and CM. Have you looked at vendor test and support for ENFM? That seemed
to be much less than for NFM to me. I think that several chose not to
handle the complexity, since it can generally be under an hour. Customers
are generally spending a month or more in CM, going through ENFM in an
hour, then running NFM for most of the time. There are a couple of
exceptions, as always. Running in the mainstream of our testing and
customer use is safer, especially if you don't have lots of extra time to
test, as this is one more unique choice.

Nnext is coming, and we have some good information on the web. The place
to start is on the web - probably the ftp web site. Sort by latest dates.
ftp://ftp.software.ibm.com/software/data/db2zos/
VNEXT.pdf is Curt's presentation with a couple of foils on V8, then about
50 foils on Vnext. The foils include notes on almost every page.
DB2Futures.pdf is the version John Campbell used in his webcast, with the
audio file in DB2Futures.zip (about 10 MB). John's recent presentations
on storage management and V8 migration are also there.

Roger Miller


On Fri, 6 Jan 2006 09:11:14 -0600, Willie Favero
wrote:

>I don't think there is a technical reason for quickly moving from ENFM
>to NFM. ENFM converts the catalog (Unicode and long names) and the
>recommendation is to test the conversion and move on so you can take
>advantage of the new SQL and other features of V8. NFM essentially
>mean the NEWFUN switch in DSNHDECP has been flipped from NO to YES and
>changes DBRMs from EBCDIC to Unicode. (Take a look at
>http://blogs.ittoolbox.com/database/db2zos/archives/007155.asp) So
>your migration is really completed in ENFM, you are just not letting
>anyone use any new features.
>
>Also remember, that NEWFUN can be set at precompiler time. So not
>running the job to enter NFM does not totally guarantee that no one can
>use a new feature in V8.
>
>--
>Willie
>My DB2 blog --> http://blogs.ittoolbox.com/database/db2zos
>
>
>
>
>George Palko wrote:
>
>>Hi,
>>
>>I'd like to thank everyone who answered my previous question concerning
>>DBRM mode compatibility within V8.
>>
>>I have an additional question concerning the V8 migration. As I stated
in
>>my previous post, we're in a situation where a number of our third-party
>>vendors are not willing, yet, to give us a date, as far as, when they
will
>>be exploiting V8 NFM. This has made us very reluctant to migrate to NFM.
>>But, because of the time that is involved in migrating, we feel that we
>>should begin the ENFM migration sooner rather than later.
>>
>>Once the production ENFM is complete, it's my "hope" that the vendors
will
>>be ready. However, if they are not ready, we will be in a position where
>>we will have to stay in ENFM for an extended period of time. All the
>>documentation that I've been reading states that one should stay in ENFM
>>for a short period. For obvious reasons, I understand why one would want
>>to complete the DSNTIJNE job as quickly as possible. But, I'm having a
>>difficult time understanding what the implications would be if we have to
>>keep all our subsystems, including production, in ENFM for an extended
>>period.
>>
>>Does anyone know of any technical reasons, as to why, one should not stay
>>in ENFM for extended periods?
>>
>>
>>Thank you,
>>George
>>
>>-------------------------------------------------------------------------
--------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm




Edward Long

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm