Setting Merge Flag?

[BBritain]

Masters,

I have a CNC person whose only training is OJT. We are trying to take an ESU without losing the custom mods (minor) for an application. I seem to recall that a Merge Flag needed to be set, but can't find where. I have looked both here and in the Technical forum archives but with no luck. Can anybody point me in the right direction?

Ben Britain
OW B7334 SP22 - AS400, DB2/400

 

[JMR]

Ben,

I have never used them so I don't know if/how they work....But if you go to design on the particular object, you'll see a tab called Install/Merge Codes. See if you find what you're looking for there and then let us know how it works.

Good luck

 

[BBritain]

Already tried that - nothing that looks promising. Anyone else?

 

[Alex_Pastuhov]

I believe, OW stopped doing merges some time ago and now ESU's replace entire objects...

 

[DBohner-(db)]

The merge flag is not trust-worthy... it is better to compare the pre /
post ESU code - and hand do the changes...

You can merge, then compare - but... variables have a tendency to get very
hosed!

Daniel Bohner





Looking for work out west
Daniel Bohner | JDE P/A III | Freelance-JDE/Web/Photo
www.ExistingLight.Net | www.ExtremeSights.com | [email protected]
JDE XE | SP20 | AS/400 | V5R1

 

[Scott Beebe]

Hi Ben,
|
I got this from CJ:
|
The merge flag is set using the Spec Merge Selection program P98401 (GH9611 menu). Also, the merge flag can be verified when applying the software update using a Form Exit, Advanced button.
|
I would recommend they read the software update ESU guide thoughly before applying any ESU(s). Retrofitting can be done if replacing the objec using the visual compare tool.
|
Let me know if this helps.
|

 

[Alex_Pastuhov]

It might also be a good idea to export/save the objects in question before the application of this ESU, so that they can be recovered, should something go wrong...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

 

[MCCInet]

We just had problems with some ESUs that merged by default when we were expecting a replace.

Since JDE has no idea how the merge program logic actually determines what to merge and how to deal with conflicts, it is very dangerous. You have no idea what was lost.

The file F9861 shows which programs have been modified (changed) with a 'C' in MRGMOD (merge mod) field. The MRGOPT (merge option) field indicates how the ESU will update the program. *CAUTION here - our UDC table had very wrong descriptions for what the codes mean. (2 = DO NOT MERGE) That is the one you must use to have a clean update.

Once you have the new code, you can apply your modifications on top of a 'pristine' version of the program. Determining what modifications/screen fields/field positions/ERs were kept, and which were dropped could be a daunting task. You have no idea whether some of the 'lost' items in a merge were part of the new ESU requirements.

Another note: the merge wiped out all custom ERs but left overlapping fields on the screen.

We managed to force a Do Not Merge so that we had a clean version of the program.

I hope that helps...

 

[BBritain]

I want to send thanks to all for the information AND the feedback. The information was helpful and the feedback has sparked a discussion within the client regarding customizing copies or customizing base code. I will probably be opening a new post regarding that topic, but don't want to open that can of worms here.

To Scott, thank you and thank CJ for me and tell him 'Hi'. Let him know that my phone number is still the same.

Ben again,