MVSFORUMS.com

kregen · Beginner Joined: 29 Jan 2004 Posts: 3 Topics: 2

Hi there,

the following situation...

one Panel with ISPF Table.
more than one person are working (inserting and updating data), so that the data in the ispf-table is changed.

how can i make a autorefresh (without pressing enter), to all screens (persons), when the data of the ispf table is changed from anywhere?
_________________
cu
kai

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

The simple answer to that is you can't.

The only way you can achieve what you describe -

"more than one person are working (inserting and updating data), so that the data in the ispf-table is changed."

- is to open the table for WRITE, make the change and close it again. Otherwise when one person opens it for WRITE, everyone else will be locked out of the table.

What you are seeing when you issue TBDISPL and scroll up and down is an in-storage copy of the table which is unique to you. It will only reflect the changes you make unless you re-read the table periodically. You cannot do this without 'interrupting' the panel display and triggering code.
_________________
My opinions are exactly that.

Mike · Posted: Tue Mar 02, 2004 5:59 pm Post subject:

Maton,
I'd dispute 'you can't', however it would be a relatively complex process and would probably be resource hungry. It could be based upon the ISPF CONTROL DISPLAY LOCK service and may require a panel with dynamic areas to display the table data.

Perhaps a better/simpler option might be to check for changes when the user attempts an action and if changes have been made (perhaps only to the relevant row(s)) to then either prompt for confirmation or re-dsiplay the panel with the new table data and an appropriate message.
_________________
Regards,
Mike.

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

Mike - with all due respect I defy you to produce an application that refreshes the screen in ISPF without hitting any key whatsoever.

You certainly can't update someone else's view of a table based on changes you make - at least not using ordinary REXX/CLIST/ISPF.

You might be able to write a program which executed as a started task that managed that sort of stuff - but if you were going to that much trouble you wouldn't bother with ISPF tables.

Even SDSF does not refresh without hitting ENTER or using AUTOUPDATE (which amounts to the same thing).
_________________
My opinions are exactly that.

Mike · Posted: Tue Mar 02, 2004 7:44 pm Post subject:

How about done in 5 minutes Maton Smile

To test it, create a panel named PROB0013, that will display a variable named count.

The copy the following code into your rexx library and run it :-

Dibakar · Posted: Wed Mar 03, 2004 7:05 am Post subject:

It seems that when the panel is running, the control is either with the user or with the system. but Kai's requirement seems to be that both get control simultaneously, atleast apparently. ie to pass the control between user and system alternately so that it appears doing auto refresh while accepting data. This would require displaying the panel for an arbitrary time. Is it possible?

Thanks,
DIba.

Mike · Posted: Wed Mar 03, 2004 4:03 pm Post subject:

Diba,
yes the problem would be processing input whilst the panel is locked. This is probably possible but beyond what I know. I would guess that it would require interrogaton of terminal to check what keys have been pressed within the loop. Let's put it this way you can ATTN out of the loop when running the Rexx above, thus some form of terminal interaction is possible.

Another way around this would be to have a windows/PC based program as the GUI communicating with the mainframe to gather and modify the data, perhaps via MQ or even TCP/IP. I've never personally done anything like this though, although I know that people have.
_________________
Regards,
Mike.

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

Mike,

You completely missed the point of everything I was saying - taking into account all of kregens requirements you can't achieve what he wants because of the very thing you put in your code - an end to the loop which refreshes the table display. Consequently you lose your view of the table updates at that time and then what??? You have lost what kregen wanted - visibility of changes.

I'm not stupid - I am well aware of CONTROL DISPLAY LOCK and it's uses. A clock display being one of them - but you can't interrupt it without PA1/ATTN as I've previously stated, which would throw you out of your application. At the risk of labouring an already carved in stone obvious point - if you terminate your refresh with some sort of counter or time limit - YOU LOSE VISIBILITY OF CHANGES WHICH IS WHAT KREGEN WANTED IN THE FIRST PLACE!!!!

I can see very little use for an application where you can either sit and watch the screen update with everyone elses changes except yours because you can't interrupt the refresh process.
_________________
My opinions are exactly that.

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

Diba,

Your statement -

"This would require displaying the panel for an arbitrary time. Is it possible?"

Yes it is possible but it is not a solution. You need to be able to display the panel with refreshed data UNTIL such time as the user wants to make changes - you cant refresh and make changes in ISPF at the same time. It is no use displaying the panel for an arbitrary time because you don't know how long to display it for do you? As soon as you stop refreshing the display your missing potential changes aren't you?
_________________
My opinions are exactly that.

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

Mike,

I misstated my original challenge so I must wear the blame for your response. Your response to my challenge as stated was perfectly correct.

In hope of highlighting my at least part of the point I was making, change your panel to include input fields, Set your counter to a resonably high value (say 10000) and then run it and try and update one of the input fields before the counter expires.

Maton
_________________
My opinions are exactly that.

Mike · Posted: Wed Mar 03, 2004 9:38 pm Post subject:

Maton,
I don't think I missed any of your points at all. I do understand that trying to do what Kregen has asked is beyond the scope of the vast majority of experienced Rexx/CLIST/ISPF programmers, including myself. However I still consider that it may well be possible and as such, me being the pedantic so and so that I am was simply disputing you saying 'you can't'. If the task were sent my way then I'd reply saying that it's not feasable.

You appear to have got the impression that I consider you stupid. Well I haven't said it or implied it, nor, for the fact of the matter, do I think it. I have seen a number of your replies and to the contrary of what you may believe I would say that you are pretty smart, certainly a worthy contributor to these boards.

Regarding the updating of the screen I would have done the reverse of what you were considering. That is instead of the updater informing all others that an update has taken place. The others would actually poll the data to see if there had been changes. Perhaps not within Kregen's spec there again I think that it may be.

As for your last challenge, sorry but that's not really feasable Smile

_________________
Regards,
Mike.

Maton_Man · Beginner Joined: 30 Jan 2004 Posts: 123 Topics: 0

You aren't the only pedant here... Wink

I was trying to remain faithful to the original question rather than raise any hopes by simply saying that technically it might be possible. Sure, I could probably write something which emulated what he wanted - but I'd be kicked off the system for hogging CPU along with all the other users of my application. (Which is why *most* installations disable the autoupdate feature of SDSF - continuous polling wastes CPU)

There may be other technologies as you suggested which are more appropriate to the task.

I have played with Excel and TIBCO (can you believe it?!) Where an update to one spreadsheet is immediately visible on another spreadsheet opened by another user. Even this scenario involves two spreadsheets not one as you can't have two users editing the same spreadsheet at the same time.

As a general comment, I know of very few applications which demostrate the requirements kregen has asked for. Most of them still require a user to hit a key or press a button to refresh data.
_________________
My opinions are exactly that.