So here I am sitting in front of my computer, with a cold Pepsi at my side, again placing pen to paper (or fingers to keyboard, as it were) to offer up another bit of insight into the vagaries of how EnterpriseOne works.
Let’s dive right in, shall we? The issue at hand is, while using the Enterprise Report Writer (otherwise known as ERW, or RDA for you old schoolers like me) the message, “The GBSPEC file is missing. Would you like to create a new one?” hits the screen and stops you dead in your tracks.
Now if you’re like me, at this point you normally would groan and use some creative phrasing to describe your feelings for the machine in front of you. Don’t be shy; it’s OK to admit you’ve done it. I have too. But let’s be honest about a few things. It’s really not the computer’s fault (though I like to blame it anyway just to make myself feel better). Chances are it’s something that was done in the not so distant past that caused you to get this message and it may be something you don’t even realize.
So…why is the GBSPEC file reported as missing? It’s often because the file got corrupted by a seemingly innocuous actions of a user or even (heaven forbid) a techie. Here’s an example. By show of hands: Who has ever had EnterpriseOne apparently “lock up” on them and then shut it down by using Windows Task Manager? While doing this may seem harmless enough to most users, it can be downright tragic. Here’s why. When you’re using one of the Design Aids (ERW, FDA, TDA, etc…) and EnterpriseOne “locks up”, the system is actually taking that time to write the spec files (including good old GBSPEC) in the background. Sometimes this is long process for whatever reason, but ending the program prematurely can and will corrupt the spec files. This corruption causes the dreaded message .
What’s the solution? Simple…be patient and wait for EnterpriseOne to resolve its “lock up” condition on its own sweet time instead of ending it with Windows Task Manager. Now I know waiting for ERW or OMW to close down can sometimes seem like an eternity, but I think it beats the alternative. When a spec file is corrupted, you will more often than not have to reinstall your development environment and all of its update packages just to get back to where you were before you got the message. Now you and I know that reinstalling is not only arduous, but also makes life all the more difficult when you have other things to do and deadlines to reach.
I apologize for not offering up a better solution to the issue, but it’s the solution that works. Advise your users to take their time and be a little more patient with EnterpriseOne. And just in case someone does give Windows the three-finger salute, make sure you save often and use your DEVSAVE environment, as this can make restoring easier.
If you have any questions about this tip, or if you need further advice about how to make your JD Edwards applications work better, feel free to leave me a comment in the box below. You can also email me at email@example.com.