I am having problems with the INVITE keyword.
JDEdwars use the technique of WRITE BOTTOM, WRITE SFLCTL and READ SCREEN. They use INVITE to signoff after the number the seconds in the WAITRCD is reached.
The problem is, I have to hit ENTER twice to display the subfile in Genie. I do not have that problem in the green screen.
Any idea on how to overcome this issue?
Thx
INVITE Keyword Issue
-
- Experienced User
- Posts: 170
- Joined: Mon Jul 19, 2010 2:40 pm
- First Name: Jorge
- Last Name: Cabrera
- Company Name: Lennar Corp
- Phone: 305-229-6400
- Contact:
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: INVITE Keyword Issue
Unfortunately, Genie does not curently support the invite/waitrcd timeout feature of the 5250 data stream.
The trouble is, in normal 5250, the timeout is initiated by the server. The 5250 terminal is given a screen, and doesn't know that it's going to eventually time-out. Instead, after the timeout interval, the server issues a "cancel invite" to end the screen display.
In a browser environment, the server can't initiate connections to the client. The browser has to initiate all connections -- and it doesn't know when (or if) the server will send the "cancel invite", so the assumption is made that the screen should be displayed until the user presses a enter or a function key. (IBM handles it the same way in HATS, for whatever that's worth.)
So, when the user finally does hit a function key and the browser contacts the server again, it finally receives the cancel invite, and the new screen, etc... which is why it requires you to hit enter an extra time.
You could potentially work around it by adding JavaScript code to your screen on the browser site that hits enter after a specified interval (i.e. instead of doing the timeout with invite/waitrcd, you could do the timeout on the client side with Javascript.)
would that help you?
The trouble is, in normal 5250, the timeout is initiated by the server. The 5250 terminal is given a screen, and doesn't know that it's going to eventually time-out. Instead, after the timeout interval, the server issues a "cancel invite" to end the screen display.
In a browser environment, the server can't initiate connections to the client. The browser has to initiate all connections -- and it doesn't know when (or if) the server will send the "cancel invite", so the assumption is made that the screen should be displayed until the user presses a enter or a function key. (IBM handles it the same way in HATS, for whatever that's worth.)
So, when the user finally does hit a function key and the browser contacts the server again, it finally receives the cancel invite, and the new screen, etc... which is why it requires you to hit enter an extra time.
You could potentially work around it by adding JavaScript code to your screen on the browser site that hits enter after a specified interval (i.e. instead of doing the timeout with invite/waitrcd, you could do the timeout on the client side with Javascript.)
would that help you?
-
- Experienced User
- Posts: 170
- Joined: Mon Jul 19, 2010 2:40 pm
- First Name: Jorge
- Last Name: Cabrera
- Company Name: Lennar Corp
- Phone: 305-229-6400
- Contact:
Re: INVITE Keyword Issue
Hi Scott:
Thank you for your help.
I am not worry about the timeout, the problem is when I call the program I get a blank screen only with the commands at the end(Bottom screen) then I hit enter again and the subfile appears.
Is there a way to avoid that?
Thank you for your help.
I am not worry about the timeout, the problem is when I call the program I get a blank screen only with the commands at the end(Bottom screen) then I hit enter again and the subfile appears.
Is there a way to avoid that?
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: INVITE Keyword Issue
Sounds like the INVITE is on when they write the bottom of the screen. Weird...
-
- Experienced User
- Posts: 170
- Joined: Mon Jul 19, 2010 2:40 pm
- First Name: Jorge
- Last Name: Cabrera
- Company Name: Lennar Corp
- Phone: 305-229-6400
- Contact:
Re: INVITE Keyword Issue
Yes it is *ON
Attached is a print screen of what I get. I can not associate any javascript because there is no field to be used to Mark as identifier to customize the screen.
Attached is a print screen of what I get. I can not associate any javascript because there is no field to be used to Mark as identifier to customize the screen.
- Attachments
-
- INVITEISSUE.doc
- (218 KiB) Downloaded 280 times
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: INVITE Keyword Issue
Yeah, this is a tough one.
The crux of the problem is that the browser (not the server) is in control of when the user is done with a screen. We've worked around that everywhere we can, of course, but in the browser paradigm the page stays active until the user does something. The browser sees that the user is supposed to be able to type, so it's not even asking the server whether it's time to "cancel" user input, or display more information.
Here are some ideas suggested by David (one of my colleagues). David says that he knows these are imperfect solutions:
The second solution is tricky, but I'd be willing to try to assist you with it, if it's desirable.
The crux of the problem is that the browser (not the server) is in control of when the user is done with a screen. We've worked around that everywhere we can, of course, but in the browser paradigm the page stays active until the user does something. The browser sees that the user is supposed to be able to type, so it's not even asking the server whether it's time to "cancel" user input, or display more information.
Here are some ideas suggested by David (one of my colleagues). David says that he knows these are imperfect solutions:
Neither of these are great solutions, but maybe the best you can do. Really the best thing is to implement David's first suggestion -- re-do the screens. But, yeah, that could be a huge undertaking if you have a lot of screens like this.
- The program could be adjusted such that requests input when the entire screen is written. I know this may not be desirable/feasible (there may be tons of the JDE programs like this), but is the only 100% sure way of making it work that I know of. Could be reasonable solution if he had just 1 or 2 programs that were doing this, though.
- JS code could be written that looks for the screen in this state (perhaps it looks for complete lack of content in rows 1-23 or something like that) and then takes action, such using pressKey() to bring up the next screen.
The second solution is tricky, but I'd be willing to try to assist you with it, if it's desirable.
-
- Experienced User
- Posts: 170
- Joined: Mon Jul 19, 2010 2:40 pm
- First Name: Jorge
- Last Name: Cabrera
- Company Name: Lennar Corp
- Phone: 305-229-6400
- Contact:
Re: INVITE Keyword Issue
I still having problems with the INVITE keyword.
In this case hitting F6 the user export the subfile info creating a csv.
The issue is when the sflctl is written the INVITE keyword is active. In the green screen the user sees the subfile scrolling automatically and the csv is created.
In genie they have to continue hitting ENTER twice for each subfile page.
Some user uses JWALK and they do not have this problem.
Any ideas?
Thanks.
The piece of the source code:
C* Write each subfile page and call export program
C*
C ##IERC DOWEQ*BLANKS
C WRITEV512000C 99
C EXSR C00E2
C* ---- ------
C ENDDO
In this case hitting F6 the user export the subfile info creating a csv.
The issue is when the sflctl is written the INVITE keyword is active. In the green screen the user sees the subfile scrolling automatically and the csv is created.
In genie they have to continue hitting ENTER twice for each subfile page.
Some user uses JWALK and they do not have this problem.
Any ideas?
Thanks.
The piece of the source code:
C* Write each subfile page and call export program
C*
C ##IERC DOWEQ*BLANKS
C WRITEV512000C 99
C EXSR C00E2
C* ---- ------
C ENDDO
Who is online
Users browsing this forum: No registered users and 5 guests