How the new MetaLink saved my life

You have been there, debugging, trying a fix something and you are just lost in the code or debug logs. That happened to me today, but thanks to the new MetaLink site, I was saved.

We change a parent dll on several of the business functions and we discovered that the COK (Call Object Kernal) was still looking at the old parent dll for the code. Well this obviously wasn't what we wanted, so we rebooted and built and rebooted and cleared cached and rebooted, you get the idea. Well, I did notice that there were changes announced to MetaLink and I decided to take stab, WOW! One search box for everything, one, I didn't have to dig through three screens and guess what THEY called their platforms and then try to decipher where in the world the answer might be...bugs, archives, documentation oh my! No, I simply entered some key words and it told me, ME where the answer might be. Absolutely amazing. I will be going there more often.

Take a look through MetaLink now, it is pretty cool and a very big help. I don't think I will search anywhere else first. I do need to post this on JDEList, this was just too helpful.

I do want to include the resolution to the problem that was solved just in case anyone needs to have it. The article ID is ID 626421.1. It describes the process of synchronizing the OL table (F9860) with the blobs in the Record information (F98762). The system always assumes that the information is in synch and that it doesn't change (which is a pretty good assumption.) The blob in the F98762 contains information on the location or address of where the COK can execute the method on the DLL. It gets generated only once I assume so you need to regenerate that information if you ever change the parent DLL name on the business function.

Here are the steps from the document (626421.1),

The process to synchronize the JDEBLC for a specific object is detailed below.

1. First checkout the object in OMW on a workstation.
2. Launch Busbuild (it needs to be standalone) on the workstation.
3. Choose the Tools|Synchronize JDEBLC menu option.
4. Checkin the function through OMW
5. Build and deploy an update package for the clients and server.

Z-Table Processing and WHY THE HECK THEY DON'T WORK!!

There are several Z-Processes within JDE and for what they do they are worth their weight in gold...if you can figure them out. Many of them don't have any ouput and if they have output it only tells you it failed and nothing else. Many of them don't have interactive apps so you are pretty much flying blind....pretty much unless you know about the F0113XX tables...

There are a set of tables in the F0113 series that are actually logging tables. For most of the z-processes out there they actually contain errors and information of the z-process. The F0113 is the header table and the rest F0113(1. M. T. 2. 3, ...) are all detail tables from one process or another. They are worth looking at when running processes to see what might be happening behind the scenes. These tables hold varying amounts of detail.

The other option is to set UBE logging at Level 6 and calling your significant other and telling them you will be late for dinner...

Transaction Processing and Button Clicked Event

So after much discussion I finally sat down and had to figure out the transaction processing on interactive applications.

A little over two years ago we were working on a project and I had to make sure everything, i.e., Business Functions and Table I/O were included or failed as one transaction. We were on Tools Release 8.96 at the time and it was as simple as setting the Transaction form property and then putting everything inside the Ok button events.

We moved to 8.98.x at the first of 2009 and some developers were complaining that they couldn't get the stuff to work. My reply was always..check APPL X, it works there. I guess I probably sounded like some old guy, 'it worked when I was a kid!' Today it came to a head and one of the developers was finally calling me out, it doesn' work on APPL X. I didn't believe him, of course it worked, I built it myself. Well he turned out to be right, the transaction boundary had changed. Now the only place you can call Cancel User Transaction is within the Post Button Clicked event. Things have changed since the good ol' days of 8.96, forward progress.

The process we used to test,

1. Create a Fix/Inspect or Power Edit.
2. Check Transaction on the form property.
3. Open Ok button Event Rules
4. Select Post-Button Clicked Event
5. Open Table clicking Advanced button selecting the Include in transactions.
6. Perform Table I/O.
7. Check for SV File_IO_status errors.
8. If there are errors call system function Cancel User Transaction.
9. Close all tables.

It really is that easy and if you want to include any business functions, all you need to do is make sure that you are including them in the transaction as well.

Hope this help as it was a mystery for some time and I finally had a moment to solve it.