Compiling DSPF with NO CHECK

[jj_dahlheimer]

I usually do my absolute best to avoid no check but I was only trying to add a CA function to a very simple widely used screen. The only problem is after adding it and compiling the one numeric input field is getting its last position cut off when a submission happens. Seems really weird. I did not change any of the contents of the screen. I only added CA03(03 'F3=EXIT') before the screen format name.

[BryanLeaman]

Re: Compiling DSPF with NO CHECK

Adding a function key adds a new field to the record format. There has to be room for that '0' or '1' value to come back to your program. One way to avoid this issue for display programs is to use the INDARA keyword to place indicators in their own special location apart from the other fields. Still, if you've added a function key, shouldn't the programs be changed to recognize it and recompiled with the new functionality added?

[jj_dahlheimer]

Re: Compiling DSPF with NO CHECK

That explains it, I will look at the INDARA. I only need programs going forward to recognize it, none of the past programs needed the F3 function. It is just a really simple screen the gets a 3 digit number, very generic. On the most recent program I was looping the screen and gathering multiple values and need a way to exit the loop.

[tomliotta]

Re: Compiling DSPF with NO CHECK

It sounds as if there should only be a single program (or single procedure) that even references that particular display. Any other program that needs the value would call this program to display the screen and to return the value to the caller.

[jj_dahlheimer]

Re: Compiling DSPF with NO CHECK

That sounds like a good idea. But even if I did it that way I would still have to modify every program because instead of just returning the value entered it also needs to return *IN03? Or am I missing something.

[tomliotta]

Re: Compiling DSPF with NO CHECK

Yes, though that gives a chance to return a ReturnCode or ErrCode DS of some kind. Once that's done, it could make it easier to modify only programs that need particular returned statuses. Other programs might only have a basic success/failure default handling.

That would be some future function or general change. For now, the current setup can have something like this in each program to handle the new INDARA:

     FTSTDONLY  cf   e             workstn indDS( indWS )

     D indWS           ds
     d  F3Exit                         n   overlay( indWS :3 )
     d  daULRI                         n   overlay( indWS :61 )

The display indicator DS is 99 positions, and each position corresponds to a numbered indicator in the DDS. Note that these are not the same as the *INxx indicators in your program; those are totally separate.

The example DS shows that the <F3> key will turn on a "named" indicator when control returns to the program. The name in this case is "F3Exit". The name can be used in IF-tests or EVAL statements or wherever you would use "*INxx".

Another named indicator in the example is "daULRI". That could be used as conditioning indicator 61, perhaps to condition DSPATR( UL RI ) in the DDS. The program might have lines that say:

     select ;
        when ( some-error ) ;
           daULRI    = *on ; 
           ...other error code...

When the screen is redisplayed, the conditioned fields would have underline and reverse-image turned on.

You might find it better this way:

     D indWS           ds                  [B]qualified[/B]
     d  F3Exit                         n   overlay( indWS :3 )
     d  daULRI                         n   overlay( indWS :61 )

The program references would then be "indWS.F3Exit" and "indWS.daULRI" rather than "F3Exit" and "daULRI". There are long-term advantages to using qualified names.

You might want to create a standard DS that includes most of your standard F-keys and ones like RollUp/RollDown, etc., and put it into a /COPY member. Individual programs can add source lines after the /COPY statement to add the indicators that are unique to that program.

One possible significant problem in changing to use INDARA and INDDS:

Your programs are using numbered indicators today, and the programming expects them to be the same as the numbered indicators in the DDS. When you change to use an INDARA, you'll need to account for that. If your program sets some numbered indicator *ON or *OFF for the display, or if it tests any response indicator, the code will need to be changed to reference the position in the INDDS.

Since this seems to be a fairly small function, that doesn't seem like it'll be a big deal in this case.

[BryanLeaman]

Re: Compiling DSPF with NO CHECK

Even though you'd add the *IN03 return to a common program, you could make it an optional parm (options(*nopass) or options(*nopass:*omit) and only fill it if it was passed in from the calling program (if %parms>1 and %addr(parm2)<>*null).

[jj_dahlheimer]

Re: Compiling DSPF with NO CHECK

I will have to rethink how we do DSPF, we don't use them that much (trying to do more web stuff) but I don't think they will ever go away. Thanks for all the info.

[tomliotta]

Re: Compiling DSPF with NO CHECK

That could argue more for making it a called function. One version would work in green-screen, another in a web environment. And maybe not.

If web migration is a real direction, and existing green-screen programs are not part of it, maybe simply recompiling everything to eliminate the level-check is the best choice. The F-key processing still needs attention anyway.