Re: Indicator Coding Technique

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 13/01/2006, at 9:18 AM, Scott Klement wrote:

> When you use DSPATR(&VAR), what you're really doing is setting VAR to 
> have
> the exact 5250 code that you want to send to the display.  However,
> "position cursor" isn't really a display attribute.  There's no 5250
> attribute value for position cursor, so there's no value you could
> possibly put into &VAR that it could send to the terminal.
While I agree that the implementation of DSPATR(&VAR) could have been 
better it's not true to state that the content is a 5250 attribute 
value. That is only true for the non-protected field values. The values 
for protected fields do not match 5250 attribute bytes because they 
have the left-most bit on. Attribute bytes must have the first 3 bits 
set to 001. Setting the left-most bit to on makes this byte look more 
like a Field Control Word (FCW) byte but it's not because FCWs are two 
bytes. It also looks like an extended attribute byte but is not in the 
correct range for one of those.
DSPATR(&VAR) doesn't support any of the other non-attribute values 
either such as SP, OID, or MDT. However this is very odd because PR is 
not an attribute either but they chose to support that. PR is 
implemented by the Bypass bit in the Field Format Word (FFW) byte of 
the Start of Field order. MDT is implemented by the MDT bit in the FFW. 
SP and OID are implemented via FCWs. PC is implemented via the Insert 
Cursor or Move Cursor orders.
I would have thought that PC was of more use than the PR values so it's 
odd that they provided a second set of values for protected fields. As 
soon as the designed started creating separate sets for different 
classes of attribute he/she should have realised they were on the wrong 
path.
PC, PR, SP, OID, and MDT should have been implemented via a different 
keyword. I don't have any real problem with IBM expecting the 5250 
attribute values for DSPATR(&VAR) because a decent set of named 
constants takes care of the ugliness. Constants can be ORed to create 
composite values and the code is still self-documenting.
> I have the same problem with that technique.  We shouldn't have to work
> with the raw 5250 AID bytes, we should have some level of abstraction.
> It's a really poor design that our two options are hex codes vs. 
> numeric
> indicators.
While it would be nice to have symbolic constants for the AID byte 
values that would be an RPG specific extension and I'd rather see the 
compiler writers provide new function that I cannot do myself than have 
them provide different methods of accomplishing the same 
thing--especially when a decent set of named constants avoids me having 
to deal with the 5250 values directly.
The real problem with symbolic constants for the fields in the 
INFDS/PSDS is where to stop? You want AID byte symbolic values, someone 
else will want file type symbolic values, someone else again will want 
symbolic values for the miscellaneous flags especially since they are 
bit values. The compiler writers only do 10 or so (*FILE, *STATUS, 
*OPCODE, etc.). I really don't want them wasting time on this when a 
decent set of constants will handle symbolic values.
Thank goodness they've caught up with providing BIF versions of all the 
fixed-form op-codes so maybe now they can concentrate on new function 
(like overloaded procedures, name spaces, etc.)
I too agree that a DDS keyword for position the cursor is needed. 
CSRLOC is too primitive. It requires me to do the field to row/col 
mapping. What is needed is the opposite of RTNCSRLOC that would allow 
record/field/position to be specified. The *WINDOW|*MOUSE version would 
be useful for output too. Call it SETCSRLOC. You'd have to do a DCR for 
this feature and it would be against Rochester because as far as I know 
they own the DDS compiler.
However I doubt much if any work will happen to make DDS display file 
processing any easier. Shouldn't we all be using Java for display 
output therefore client/server applications?

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------