Moving an object off B7332 and onto Xe

HampMcCool

Active Member
Does anyone know a method to allow the export of a specific custom object
from a B7332 installation, and the subsequent import of that same object onto
an Xe installation?

Thanks!
 
Yes I do, although JDE and others frown upon it. The technique is a variation on a GATS document called "Object Transfer Between Instances" and I have used it many times.

For one of my clients I wrote up the procedure on an AS400 system (I had two systems, hence all the file copies etc) and I have pasted it in below:

Libraries SYSB733, OLB7333, DDB733, CODEVB733 and DEVB733DNT were backed up from the live B7332 system and restored onto the Xe system box. Additionally the live DEVB733 PathCode was copied via a PC from the live system onto the B733 share on the Xe deployment server. This share still exists and there are packages in place. An Xe workstation was then saved using SnapShot and a DEVB733 Package Deployed to the workstation complete with development objects. Security Server and Lock Manager were then disabled in the JDE.INI file.

From here a configuration was set in B7332 to connect to the Xe system. Firstly the following DataSources were created, and these point to the library indicated:

• System – XE SYS7333
• System – XE – DNT SYS7333
• Object Librarian – XE OL7333
• Data Dictionary – XE DD7333
• Central Objects – DVXE CODV7333
• Versions – DVXE – DNT DV7333DNT

A PathCode was then defined in B7332 called DV7333 at a release level of B733 using the B7333 Share and the Central Objects – DVXE DataSource as the deployment DataSource. Copying DEVB733 then created an Environment called XETRANS and XETRANS was then modified so that the PathCode became DV7333. The OCM was then changed so that Central Objects, Versions, System, Data Dictionary and Data Dictionary all point to the new XE DataSources defined above.

Effectively this process allows B7332 to transfer objects to the DV7333 XE PathCode. What happens in Object Transfer is that the target PathCode is set to DV7333, when the transfer button is hit, the Environment Master is read and the first Environment found with that PathCode entry is used, in this case it will be XETRANS. The OCM for that environment is then read, and together the PathCode definition, the Central Object Records and files on the Deployment Server are transferred to DV7333. The XE Object Librarian is also populated via the OCM entries, so records from OLB733 are copied into OL7333.

This process was tested, and an OMW Project called TRANSFER was created at Status 21 with the JDE Profile as Supervisor, Manager and Developer. B7332 was run and the custom objects transferred across. These were then added to the TRANSFER Project and checked out, these objects are now part of the standard OneWorld XE system.

To do this for real, the following Procedure needs to be run:

• Identify on the B7332 system all Objects and Versions that need to be transferred to the XE system.

• On the B7332 Live System verify that all of these Objects and Versions are in the DEVB733 PathCode. Use Object Transfer to move them if required.

• Backup from the B7332 System Libraries OLB733, CODEVB733, DEVB733DNT and DDB733. Restore these libraries to the XE System. DO NOT restore SYSB733; the existing library contains the definition for the Transfer Environment.

• Copy the B7332 B733\DEVB733 Share (Excluding Packages) from the B7332 system to the B733\DEVB733 share on the XE System.

• Enter DEVB733 on a B7332 machine running from the XE system and enter object Transfer; the menus will not work so run P98604 from the FastPath. Transfer all Objects and Versions to PathCode DV7333, this will probably take some time and is a manual procedure.

• Sign into DV7333 on XE and add all of these transferred objects to a project, TRANSFER is available should it be required. The objects can now be promoted via the OMW rules and packages built accordingly.

NOTE1: This system should not be used for Standard Objects, custom Objects and Versions should be the ONLY objects transferred.

NOTE2: Any custom tables transferred will need to be generated in the relevant DataSource in Xe.


Paul Clark
Independant CNC Consultant
Multiple Clients - All Xe AS400
 
Another easier (and more dangerous) method is the following - highly frowned upon by the CNC community - but I have done this a couple of times if my transporter is not available :

1. Make sure you have 2 PC's - one installed with XE Development and the other installed with B7332 Development

2. On the Xe Development machine, create a custom object with EXACTLY the same name as the object you wish to transfer - DO NOT CHECK IT IN

3. On the B7332 machine, check out the object you wish to transfer

4. On the Xe machine - rename DV7333 directory (under \B7) to DV7333BAK

5. Copy DEVB733 directory from the B7332 machine to the Xe machine - and rename the directory (after it has finished copying) to "DV7333"

6. Log into Xe and Check in the object from the Xe machine

7. Clean up by deleting the pathcode you just copied over - and rename DV7333BAK back to DV7333

8. Don't blame me if things go horribly wrong (but they shouldn't)

The worst thing that usually happens is an error might occur. However, try this out - and you should be able to get your object in smoothly enough.

Jon Steel
Xe Upgrade Specialist

ERP Sourcing
http://www.erpsourcing.com
[email protected]
 
Hi,

This might be possible but I'm no sure, you can use Product Packaging to do this.

Adrian Valentim
Valmatrix Consulting Inc.
 
In the best case scenario, the BSFN API calls in your custom app still work. In the worst case scenario, you will corrupt your version and Central Objects tables to the point where they will need to be restored from backup. All development from the point that you corrupted them will need to be redone. If you like risk, it can be done.

JD Nowell
OW: B7332
ES: AS400 V4R4 CO: DB2/400 SP: 11.2
Users: 250 TSE Users: 100
 
Hi All

FWIW...

We had a load of trouble getting Product Packaging to work in B7332 - it's riddled with problems in this version.

When we moved to Xe, Paul Clark used the method he described to move our B7332 development to Xe without a hitch. We've never had a problem.

Regards
Terry

OW XE SP14.2 ES=AS400 V4R5, DS=NT4.0
Set up OW Security FAST. QSeries - For all your OW Security needs http://www.qsoftware.com/oneworld.htm
 
R98700 (Spec Merge) should do the trick and is probably the quickest way assuming there are no changes in the format of the Central Objects tables.

Good Luck

Ger

Currently OneWorld B7332/Xe Windows NT SQL 7.0 Server SP3/ Citrix XP (Experienced on all platforms)
 
Last reply from me on this. The technique I described was invented by a very talented German CNC consultant, who I worked with in 1999. Back then we performed a parallel run on B733, B7331Beta and B7331GA all on the same hardware.

A team of us performed a complete transfer of all objects from B733 to B7331GA using this technique. It was slow but very safe.

Since then I have used it on at least four clients, with all types of objects transferred, and never had a hitch with it, one of them was very hairy, involving an offline system, a combination of this technique and Jon's forced checkout method.

If you think about the CNC, the system is just .H and .C files, and database records. As long as nothing is overwritten its fine, so I therefore fail to see how the entire Central Object specs can be corrupted, this would take some form of major database failure, or a checkin on thousands of bad objects from a workstation.

Paul Clark
Independant CNC Consultant
Multiple Clients - All Xe AS400
 
Back
Top