During a recent customer environment cloning activity, I got myself up to the point where CUSTOM.plx was required to be recompiled. Nothing difficult, you might say, right? I thought the same. But that activity just killed lots of troubleshooting hours for me.

frmcmp_batch.sh call was just failing with “Terminal map initialization failed.”

My victory didn’t last too long. During one of the later steps, I was recompiling Form objects for several products using the ADADMIN, and all of these jobs were failing too. When I started looking into worker logs, I found that frmcmp_batch.sh was being executed, of course, and the logs were full of “Terminal map initialization failed” messages.
I spent many hours troubleshooting this. I couldn’t find any clue or known issue in MyOracleSupport, and my Google/Bing searches were unable to guide me to a solution. So I started “digging” myself.

Referring to Oracle Support Note [ID 1085526.1] for a generic FRM-91500 troubleshooting gave me good hints on possible issues with the fmrcvt220.res terminal mapping resource file and interaction with TERM/ORACLE_TERM environment variables. Getting no results here, I thought of trying another terminal connection using the Mac default Terminal.app (I was using SecureCRT prior to that).
And it worked!!! I saw no issues with frmcmp_batch.sh, and initiated ADADMIN Forms object compilation, which also proceeded successfully.

Having a small Terminal.app window on the screen opened by default and a 1920×1200 resolution on the screen visibility wasn’t too good, so I maximized the window by clicking on the plus icon.
As soon as my window was maximized, all running ADADMIN jobs started to fail. And what do you think I found in worker logs? Exactly! The same “Terminal map initialization failed” error.

So the reason for all these failures was just my “too large” terminal window size. I remembered that “Terminal too wide” VIM text editor issues were due to the same reason.

This can be easily reproduced. I resized my terminal to half-size, ran ADADMIN, and initiated Forms compilation for all products. While workers processed the compilation jobs, I started to resize the window using the lower-right corner.
It was possible to clearly see how all workers started to fail, and again started to successfully compile when I was resizing the terminal window back to half-size.

I have just reproduced it on my lab instance while I was writing this blog post. And it’s not only happening on more exclusive platforms like HP-UX or AIX. It’s also a generic Linux issue, which is most commonly used for E-Business Suite.

Conclusion

This blog post is definitely not about a common issue that many of my colleagues all over the world might face. It is, however, a good starting point and, I hope, will save lots of troubleshooting time or Severity 1 SR’s for someone as soon as the search engines process this post.
High-resolution displays are slowly getting a wider usage and good old 1024×768 isn’t always appropriate anymore. Who knows what else besides “Terminal too wide” and this one might await us.

Update

Referencing to one of my comment replies.
The actual problem is not with the resolution itself, but more with the row/column count your terminal has.
This problem is starting to show up as soon as you are crossing 255 column width.
I didn’t get the row count to the same number with the highest resolution on my Retina. Even with the minimal font size, I got only 123 rows. It’s just my personal guess that having more than 255 rows might lead to the same error message.
So… there is a workaround. If you would still like to use your terminal window at the full scale and not worry about such possible issues, get your font size configured properly in the terminal session so that cols/rows wouldn’t cross 255.

Thanks Maris. It’s a very good question. Just spent some time finding this out.
The actual bit here is not resolution, but rather rows*column count in your terminal. You can play around with the numbers by increasing/decreasing your session font size in your terminal.
The column count has a limit – 255. When you are extending it, you get the error.
The row count… Having the max resolution on my Retina and the lowest possible font size 6 I got maximum 123 rows and it still was working fine. My raw guess that it’s the same 255. Maybe in next 5-10 years we’ll find that out when a resolution will double itself in the industry.

I totally see how this blog post will help many Apps DBAs in the future. The screens becomes larger and it isn’t obvious how it could impact the EBS maintenance procedures as forms and libraries compilation.

Aaron, this might be a historical and platform nuance. To be able to compile Forms object, the compiler needs graphical libraries. In Unix/Linux world it’s X11. You had to set DISPLAY=something:x.y before running any form compilation. In EBS R12 or 10g Oracle Forms Oracle provided two ways how to proceed with your compilation: 1 – same old frmcmp with X11 display requirement, and a new one frmcmp_batch which doesn’t require X11 anymore, but using fmrcvt220.res and TERM/ORACLE_TERM variables parsing your terminal environment. One dependency resolved, but still there are some limitations you need to be aware of, right? :)