Anatomy of a P-Field

October 13, 2004 Dominic Lefevre

It may appear that text-based screens are dead, but looks can be deceiving. Text-based interfaces, or “green screens,” are still very widely used, and not just on iSeries systems. What’s more, text-based systems are not going away anytime soon, because they’re effective and easy to develop. As long as we still have to write them, we might as well have a little fun, right? One of the ways to have fun writing green-screen programs is by using P-fields.

LOOK, MA, NO INDICATORS!

P-fields are one-byte codes that control the color and attributes of a field in a display file. Before

Use System Naming Convention and Library List with .NET Managed Provider

October 13, 2004 Michael Sansoterra

The iSeries .NET managed provider, first released in iSeries Access V5R3, lacked the ability to specify a library list and the SQL naming convention in connection strings. We were stuck with the defaults. However, with the introduction of service pack SI15176, in early September, IBM has enhanced the provider to set the library list and naming convention in the connection string.

For those unfamiliar with the concept of a managed data provider, it is .NET’s plug-in equivalent to an ODBC driver in the Windows world or a JDBC driver in the Java world. Each database manufacturer creates a .NET provider

Handling Oversized Numbers Gracefully

October 13, 2004 Hey, Ted

These MCH1210 errors are driving me nuts. We run packaged software and a lot of the database fields are bigger than we need them to be. I often use smaller fields on displays and reports in order to save room. Then one day, for some reason, a field has a bigger value than I expected and an EVAL command blows up with MCH1210 (the target for a numeric operation is too small to hold the result). Is there any way in all this new-fangled RPG stuff to tell the system to print hash marks and keep on trucking?

–Dave

RPG