× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 29/04/2005, at 1:29 AM, Good, Brad wrote:

I have a screen with an IO field and another output only field.

If the user types a value over a certain limit into the IO field, I set
an indicator 53 in the COBOL on and move a message to the output only
field saying "over limit".

On my screen I have an error message on the IO field for indicator 53.

What I want to happen is that the error message triggers AND the "over
limit" shows in the output only field.

What actually happens is the error message gets triggered but the output
only field shows a previous value of "under" even though when I display
the value of that field just before the write to the screen the value is
indeed "over limit".


What would be causing this?

All this traffic and still no answer.

The behaviour you see is the expected behaviour. Read the appropriate reference material (i.e., the Restrictions and Notes for Display Files in the ERRMSG and ERRMSGID section of the DDS Reference) and you will see that ERRMSG and ERRMSGID perform no other processing except that required by the keyword itself. That is when ERRMSG or ERRMSGID are active and the record format containing them is rewritten the only data sent to the workstation is:
1) The text of the error message
2) The attributes for the field in error


Further research will explain why this behaves as it does. ERRMSG and ERRMSGID use PUTOVR, OVRATR, and OVRDTA under the covers. These keywords cause only the data or attributes affected by the keywords to be sent to the display. It is intended to reduce the network load by not resending the screen when you only want to display an error.

How to solve:
a) Stop using ERRMSG and ERRMSGID and use a real message subfile and sent the messages from your application via the QMHSNDPM API or a CL program the runs SNDPGMMSG. This will allow you to send the message, reverse image the field, and update data on the panel.


b) Stop using ERRMSG and ERRMSGID and use PUTOVR, OVRATR, and OVRDTA appropriately to accomplish the same effect as ERRMSG and ERRMSGID. This will allow you to display a message, reverse image the field, and update data on the panel.

c) Redesign the screen behaviour to fit with the documented limitations of ERRMSG and ERRMSGID

NOTE: You can't try to fool the system by specifying PUTOVR at the file level and OVRATR and OVRDTA on another field conditioned with the same error indicator (i.e., 53) into which you would write "OVER" or "UNDER" and expect that to be sent to the workstation along with the error. When the documentation says ERRMSG and ERRMSGID are the only things processed they mean it.

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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.