Topic
  • 3 replies
  • Latest Post - ‏2012-10-10T00:12:24Z by RonCraig
george.baker
george.baker
319 Posts

Pinned topic Default PF12 does not work properly

‏2012-10-05T21:07:47Z |
I have a project for a 5250 system and I am doing default rendering. I navigate to a screen that has a subfile on it and it is rendering with a drop-down list and a F12=Cancel option appears in the Function key line. If I click the PF12 link/button to exit it does not work. If I disable the subfile rendering or change the rendering option from drop-down to either popup or checkbox it click the PF12 link/button it works. I've run a trace and can see that the input command is different between the two pages. When the PF12 input fails there seems to be additional data in the input stream.
PF12 input data stream in ASCII:
Works:

000D12A0 00000400 80030702 3CFFEF

Does not work

001012A0 00000400 80030702 3C110702 FFEF


I tried to recreate this using the iseriesd.demos.ibm.com system, but it works fine there.

I'm up a stump trying to figure out what is causing this. I could use some ideas.

Perhaps if someone could help me figure out what the difference in the datastreams is that might give me a clue. A confusing factor is that according to my reference manual the ASCII AID code for "fp12" is 40, and the code for "pf24" is 3C.
Updated on 2012-10-10T00:12:24Z at 2012-10-10T00:12:24Z by RonCraig
  • george.baker
    george.baker
    319 Posts

    Re: Default PF12 does not work properly

    ‏2012-10-07T18:48:18Z  
    I discovered what thee data stream is telling me.
    Working scenario, 030702 3CFFEF, 030702 indicates the cursor coordinates, row 7 column 2; 3C is function key 12 was pressed; FFEF is simply the end of record indicator.
    Failing scenario, 030702 3C110702 FFEF: 030702 indicates the cursor coordinates, row 7 column 2; 3C is function key 12 was pressed; 110702 indicates that the field at row 7 column 2 was modified; FFEF is simply the end of record indicator.

    I tested my hypothesis by running and tracing the actions using the host terminal. I went to the same screen and simply pressed the delete key before pressing function key 12. I got the same result, the screen simply refreshed.

    I performed one more test using the transformation: I tabbed to another input field, did not select an option then selected function key 12. I received the same visual result. The trace showed that only the field that I modified was sent in the data stream.

    I tested this on the IBM iSeriesD system. I could not trace the data stream because the connection is encrypted, but the application behaved properly.

    The key question now is: Is HATS working as designed?
  • george.baker
    george.baker
    319 Posts

    Re: Default PF12 does not work properly

    ‏2012-10-07T19:52:25Z  
    Enabling Suppress sending unmodified fields resolved this problem.

    However, why is the field modified when using a drop down list?
  • RonCraig
    RonCraig
    72 Posts

    Re: Default PF12 does not work properly

    ‏2012-10-10T00:12:24Z  
    Enabling Suppress sending unmodified fields resolved this problem.

    However, why is the field modified when using a drop down list?
    Here's what I'd do to get more info... gather runtime trace... runtime.properties trace.RUNTIME=7. You won't need pesky transport traces... you've already got that info.

    Try it both ways, and scan for 'parameters' in the trace file. Note what data the browser actually sends to the server. If it's different, then you know the issue is in the client (which is deciding what to send). That is, the javascript. Then you have the fun task of tracing through to see what's triggering the mdt attribute to be set on that input field. It'll be something in there. Might be a bug, or just might be that if you touch a drop down then you are triggering the data modification flag to be set. If that's not what you want, then you'll have to decide if the javascript needs to be customized or if just turning off the sending of unmodified data is good enough.

    Just some thoughts.