PUTOVR driving me mad

[gregwga50]

I have a DSPF that has PUTOVR specified at the record level (no conditioning) and OVRDTA (no conditioning) specified on several output fields. In my program, I display the record format with exfmt and then after some calculations that cause the fields with OVRDTA specified to change, I display the record format again. The screen, however does not reflect the new values in the fields that have ovrdta specified. I have verified the new values in the fields by debugging and placing break points right before the exfmt. The debugger (RDI) verifies that new values in the fields but the screen still shows the old value. when exfmt is executed immediately following the breakpoint. I have used PUTOVR/OVRDTA for many years successfully, so I am befuddled by this. It occurred to me that maybe it has something to do with some of the parameter defaults on the CRTDSPF command like RSTDSP, DFRWRT, etc. but that does not seem to be the case as I have tried various combinations of these.

Has something changed lately about PUTOVR as this is the first time I have used it in several years. I am totally baffled at this point.

[Scott Klement]

Is there any reason to still use PUTOVR/OVRDTA anymore? Seems to me this just makes your program more complicated, and provides no value.

This was really designed for back in the 1980's and earlier when network speeds were very limited. Often people would connect with a 300 baud modem, so every byte you could save in sending the screen would help. But, today, data is sent over networks with 1500 MTU packets. So, you won't ever notice the difference of saving 10 bytes here, 20 bytes there, etc. The performance would be exactly the same, since a whole screen is going to fit in either one or two packets.

Having said that... no, I'm not aware of any change to PUTOVR/OVRDTA. In my experience, it works the same as it always has.

[gregwga50]

Thanks for responding. I took out the PUTOVR and OVRDTA and am still having the same issue. That is, the 2nd EXFMT to the same rcdfmt does not reflect the changes to the data fields on the screen that occurred between the 1st and 2nd exfmt to the same rcdfmt. I have put break points in my program right before the exfmt to verify that the data has changed. Just to try and narrow things down, I made a temporary change to have DSPATR(RI) activated on one of the fields on the 2nd i/o and had the same problem with the DSPATR(RI).

Here is the sequence in my program
1. dsplay subfile SF1, followed by exfmt FmtA
2. readc SF1
3. dsply SF1, followed by exfmt FmtA. Some of the data on FmtA is changed (along with DSPATR) as a result of readc in step 2.

Since the same issue persists with or without PUTOVR/OVRDTA, I am starting to think maybe the issue is with the way the DSPF was created using CRTDSPF.

Any thoughts

[gregwga50]

As a last resort, I decided to try something just on a hunch. The DSPF described in the OP uses the ERRMSG keyword to display error messages for the fields in error (I inherited this program and dspf from a previous employee, I would never use ERRMSG). It locks the keyboard when displaying an error message and has to be reset. I was wondering if this may have something to do with it, so I removed all the ERRMSG keywords and added a message subfile to the display file and modified the program to use QMHSNDPM to send the error messages to the message subfile and display the msg subfile.

and Voila, that remedied the problem I was having, not sure I have an explanation.

[CRinger400]

Just as FYI, OUTPUT only fields don't get refreshed when an ERRMSG or ERRMSGID is triggered. The fix is to save all error indicators into an array, set them OFF, write the record format, restore indicators then do the EXFMT.

D cErrIndCount    c                   Const(33) 
D IndArrPtr       s               *   Inz(%Addr(*In))            
D                 ds                  Based(IndArrPtr)           
D  InAll99                      99a                              
D  InAllErrors                    n   Overlay(InAll99:27) Dim(cErrIndCount)
D*
D HadError        s               n   
D SaveDspfErr     s               n   Dim(cErrIndCount)
D cInAllZeros     s               n   Dim(cErrIndCount) Inz(*Off)

If ( HadError ) ;                   
   SaveDspfErr(*) = InAllErrors(*) ;  // *IN27-59 
   InAllErrors(*) = cInAllZeros(*) ; 
   Write SCREEN1 ;                  
   InAllErrors(*) = SaveDspfErr(*) ; 
EndIf ;                              
ExFmt SCREEN1 ; 
HadError  = Off ;

Ringer