AMT and Custom COBOL pgms/libraries

Interested to discuss how others are handling Custom code/Libraries in terms of upgrades (ex: upgrading to Infor10). We have a ton of customs, and have to 'manually' reimplement them after patching, etc..

If we were to do a major upgrade to v10 (soon), is there a way/technique that ensures customs would be "picked up" by the AMT process when doing an upgrade? (Assuming this would meean appmeta/meta loads also). I believe we heard that in order for the v10 Upgrade to work for us, we would "Need to have customs included in the AMT" - just not clear on how to accomplish this?

Make sense?

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

unknown

Hi mcmill - Just curious - What do you mean by "AMT"? I haven't heard that term before...

By "custom", are you talking about mods to delivered code or separate custom coded objects or both?

My initial thought is that you'll need to manually review customizations (and related metadata) in every modified delivered object, even if your "custom" code is merged, as in my experience the merging sometimes doesn't really work as you'd expect. Also, the metadata (particularly messages and keynumbers) tend to get overwritten, so we often dump them off prior to the upgrade for later comparison.

Along with pure custom objects, we have quite a few objects that we have "cloned" from delivered objects and then modified. When we do patching, we usually have to use BeyondCompare to identify the changes between the delivered objects and the related clones and then manually retrofit. It pretty much sucks.

We try to avoid modifying delivered objects if at all possible - with the exception of modifying some libraries to recognize custom programs that are "clones" of delivered programs.

Hopefully someone else has a better reply, because we may need to go through this before too long as well.

asztudenyak

AMT stands for Application Maintenance Toolset, and is the utility that is used to apply patches. When you preview the patch, you get a log file that shows you what custom items are impacted. These are flagged with an "m".

There is nothing that automatically includes your customizations in an upgrade, that I am aware of. It's a manual review, and it is long and tedious.

unknown

It is a pain in the neck. We have many customizations and have to re-merge those changes for patches and upgrades.

Hans Mueller

I am confused... The AMT tooling has been extremely well received by the customer community and has been repeatedly enhanced to provide even more value surrounding patching and taking updates. All of what is being described above are the "problems" that come with customizing code. As a client if you choose to customize, you take on this responsibility and the limitations that come with that.

That being said, if there are further improvements that you are seeking with regard to the AMT tooling, we would be happy to take them in and review them. We are always looking for ways to make the available tooling better.

Vid dEPM-652 - Custom Report.mp4

unknown

I completely agree with Hans that AMT does a good job of doing what it's intended to do. The fact that it provides the ability to identify modified code and report it is a great example of functionality that helps customers who do modify delivered code.

We realized going in that if we chose to customize and/or clone delivered objects that this would cause us extra work down the road - particularly when patching and upgrading. The patching functionality is pretty good, but it can only do so much. If we modify something that is later patched, we know we have to review it because the patch may make our custom code obsolete, or break, or cause additional problems.

The fact that it is a "pain in the neck" is not an AMT problem or an Infor Lawson problem - it's just a fact of life caused by our choice to modify the delivered objects to provide additional/different functionality due to our business requirements.

The other contributor to the issue is the fact that the coding is done in COBOL, which has it's own good and bad quirks when it comes to merging changes.

asztudenyak

"The fact that it is a "pain in the neck" is not an AMT problem or an Infor Lawson problem - it's just a fact of life caused by our choice to modify the delivered objects to provide additional/different functionality due to our business requirements. "

Completely agree. It's the nature of the beast.

Copyright © 2025 Infor. All rights reserved.