Version Promotion

[AS400Guru]

BlankList,=20
Can anyone please tell me what is the easiest way to promote versions =
from one environment to another. Yes OMW would be ideally the place to =
do it, But what happens if the users have created a lot of versions in =
the test environment and all of the versions have to be promoted to the =
prod environment.
Any ideas/sugestions are greatly appreciated.

TIA,
AS400 V4R5 XE Citrix Metframe xp (50-60 users).

 

[Walter Brink]

With OMW the project with all the versions can be easily promoted to the =
next environment.
The problem that arises is how to build a package for versions only. You =
need the object (as is in the F9861 OL Detail) to select the project in =
Package assembly. So add all the objects(UBE's, APPL) to the project and =
all will go well. Be sure that the objects themselves have not changed.

Break a leg...

Greetings.

Walter Brink

BlankList,=3D20
Can anyone please tell me what is the easiest way to promote versions =3D
from one environment to another. Yes OMW would be ideally the place to =3D
do it, But what happens if the users have created a lot of versions in =3D
the test environment and all of the versions have to be promoted to the =
=3D
prod environment.
Any ideas/sugestions are greatly appreciated.

TIA,
AS400 V4R5 XE Citrix Metframe xp (50-60 users).






--------------------------


OneWorld Xe
Unix HP9000 11
Oracle 8.1.6
Citrix

 

[PAULDCLARK]

Use the R980512. I do it all the time.

The JDE.INI file has to be modified as its an upgrade report:

[OMW]
R9830512_UBE_VERSION_COPY=W

Create a custom version, this one copies all interactive custom version from one PathCode to another:

Processing Options are:

1: 1
2: Blank
3: 1
4: 1

Data Selection:

Where BC Version History <> ZJDE0000-ZJDE9999
And BC Version History <> XJDE0000-XJDE9999
And BC Version History <> ZJDEAAAA-ZJDEZZZZ
And BC Version History <> XJDEAAAA-ZJDEZZZZ
And BC Version List Mode = 1

Run it locally and enter the Source and Destinations at runtime.

Hope this helps

Paul

 

[LoriStephens]

You don't need to build a package for versions only... just promote the
project through OMW....

Lori
OW Xe SP16 Update 2
AS400 V4R5
NT
Citrix
email: [email protected]

 

[AS400Guru]

The problem we are facing over here is that the users have created tons of
versions in the test environment and all these versions will be in their
default projects. The question here is that how to promote every version
that is present in the test environemnt(yes there could be some unwanted
versions too) in the prd environment.
Will copying the F983051 to the prd lib and changing the path code field
help?. Do we still need to build a full package after that?.

TIA.
AS400 V4R5 XE Citrix Metaframe xp (50-60 users).
----- Original Message -----
From: "LoriStephens" <[email protected]>
To: <[email protected]>
Sent: November 29, 2001 4:38 PM
Subject: Re: Version Promotion


http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=
24532

 

[Zoltan_Gyimesi]

Hi Martin,

I do not know that this suggestion will help you or not but here it is.

Create a new project and use the Move Objects row exit on the default project. Enter the new project ID into the "To Project:" field.
The form will let you make multiple selection what object(s) to move (use the SHIFT and CTRL mouse click combinations) and you can also filter for "UBEVER" or "APPLVER" or "*VER" for both type of versions in the QBE line. Move the required versions to the new project and promote this project. This action will also clean up the moved versions from the default project which is generally desirable.

If you do not want to preserve this new project and you have enough right in OMW then simply delete the project.

I supposed, you are very well know what kind of OMW configurations required (Statuses, User Roles, Allowed actions, Activity Rules, etc.) to perform this task.

Of course, if somebody want to perform this task not on own default project then she/he should be added previously to that default project with the appropriate user role and privilegs.

Hope, could be a bit of help.

Zoltán
P.S.: Let us know, could it work for you? Thanks.

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

 

[LoriStephens]

TIA, If they are versions only, no base object mods or business functions,
etc. just map your OMW to allow you to transfer projects from test to prod.
Be sure to create new project names, you can drag the ones you want in
each project from your default project & drop them into the new projects.
Then leave out the ones you don't want to go (the test ones). It's so quick
to promote versions but the OMW needs to be set up properly to do this.
Also don't let just ANYONE do the promotions--set up security on
OMW/promotions. You should also run a report on them first and make sure
all objects are checked in prior to the promotion. I've found that to
really help keep things in order...

This way you won't be copying your version library from test to production
and hosing the existing versions that have been set up. By promoting you'll
be much less vulnerable. If in doubt, always take good backups before doing
anything!

Best Wishes!

Lori
OW Xe SP16 Update 2
AS400 V4R5
NT
Citrix
email: [email protected]

 

[richardjackson]

You _can_ copy F983051 - so long as you are certain that NONE (as in ZERO) of your versions have any ER, form customization, or other spec stuff associated with them. I am not that certain so I suggest you look at the version copying app in one of the previous replies or use the OMW. When I am copying environments, I usually copy the F983051 but I also copy central objects so the "opportunity" noted above doesn't apply.

I have found that it helps if you have all the users check everything in every day. If that is too painful to achieve, have them do the best they can (check in whatever they can figure out) then delete all the checkout rows from the F98221 then do a full package build and deploy then test to see what was lost. Eventually you have to have the good stuff checked in and the bad stuff thrown away so they have to do this - eventually.

If you do the package assembly on the deployment server, you can't see the user versions. Do the package assembly on another fat client logged into the source environment then go to the deployment server, log into DEP733 and do the build.

Richard Jackson

 

[AS400Guru]

I guess, I was not able to explain the problem properly. Yes if person A has
created the versions, it will be in his default project and then he can
create a project and drag the versions from the default project and promote
the new project. Lets assume that there are 'N' number of users and they
have created many versions...in that case, adding person A to that persons
default project and moving them to the new project is the solution???.

TIA,
AS400 V4R5 Xe Citrix Metaframe xp (50-60 users).
----- Original Message -----
From: "LoriStephens" <[email protected]>
To: <[email protected]>
Sent: November 30, 2001 1:56 PM
Subject: Re: Version Promotion


prod.
quick
you'll
doing
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=
24600

 

[AS400Guru]

Could you please tell me what is the importance of the entry in the ini
file. What happens if this entry is not included in the ini file.

Thanks.
AS400 V4R5 Xe Citrix Metaframe XP (50-60 users).
----- Original Message -----
From: "PAULDCLARK" <[email protected]>
To: <[email protected]>
Sent: November 29, 2001 9:10 AM
Subject: Re: Version Promotion


from one PathCode to another:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OW&Number=2
4514

 

[ShaneM]

You could just create a project called NewVersions, or something to =
that
effect, give all users access to the project, and have them move the
versions to the project when they are ready.=20

Shane McConnell

 

[Leroy]

Tia,

That's one of the good sides of OMW. Create a project for the users and
tell them to place all objects (versions) into the project.
Then you only have one thing to migrate. It may take a while to migrate
but it requires very little work from yourself.

This can then be put into a package pretty quickly by doing an update
package for that project only.

Lee
IT Dept

 

[Jason_NGT]

Richard,

When you say this:

"If you do the package assembly on the deployment server, you can't see the user versions. Do the package assembly on another fat client logged into the source environment then go to the deployment server, log into DEP733 and do the build."

When you saay logged into the source environment, I assume you mean if a version was made in DV, then you log onto DV? This is a problem ive been having, not being able to see the versions we've made.

We are implemting XE with financials, HR & payroll, service billing etc... and doing it all ourselves! Weve hired a former consultant to lead us and teach us how to implement and run everything, but he's used to an older version of the system and some things have changed.

Anyway hope you can clear that up, thanks.

-----------------------------
Jason Barber
Systems Administrator
--------------------
Xe, SP15, NT 4.0, SQL 7.0, Websphere 3.5, Update 2.

 

[CHo]

If you are building a DV package, then log into DV on a fat client.

If the versions were created in DV, but you want to deploy them to PY. Then transfer the versions from DV to PY and then build a PY package in PY.

Hope that answers your question.

C Ho
Intermediate Programmer/Analyst
Xe SP 15.1, update1
AS/400 V5R1 coexistant
CO on SQL 7.0 SP2 + hotfix