If you could write a program that could accurately predict the future, you’d be set for life. Unfortunately–or fortunately, depending on your point of view–such a program is not possible. But you can make a program look ahead as it reads a sequential data set, and that can be a valuable asset.

The RPG cycle includes a handy lookahead feature, which allows a program to view data in the next record to be read, but it’s not available for externally described files, nor for full-procedural files. However, rolling your own lookahead logic is easy. To demonstrate just how easy it

I haven’t been able to get SQL to handle result fields in the same way Query/400 can. In Query, I can define a result field, then use that field in the definition of another field. If I try this with SQL, I get a message that says, “Column X not in specified tables.” Is there a way to avoid duplicating the calculations of a work field?

–Erik

No, Erik. Not with SQL/400. To my knowledge, the only SQL-based software product that permits you to define work fields is Advanced System Concepts‘ SEQUEL. But I can give you some workarounds

I just wrote a CL program that uses the Create Duplicate Object command (CRTDUPOBJ) to copy a file into a user’s QTEMP library for test processing. However, every time my users run the CRTDUPOBJ command in that CL, it gives them a CPF2189 error (Not authorized to object), even though the users have *PUBLIC *USE authority to the object. What’s going on here?

–Brian

I’ve run into this problem before when running the following Create Duplicate Object command (CRTDUPOBJ):

CRTDUPOBJ OBJ(object_name) FROMLIB(library_name) OBJTYPE(*FILE) TOLIB(QTEMP) DATA(*YES)

The solution is simple. This is an authority issue, but it’s