ISPF CONTROL DISPLAY LOCK

[Joseph Reichman]

Hi

I am updating a panel with a table that monitors jobs submitted
There maybe anywhere from 10 to 20 jobs

I would like to display the panel TBDISPL while adding entries TBADD

I am issuing a CONTROL DISPLAY LOCK
Before the TBDISPL as I want control be returned immediately after TBDISPL the panel
However when using CONTROL DISPLAY LOCK the panel is never displayed

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Jeremy Nicoll]

On Mon, 24 May 2021, at 13:53, Joseph Reichman wrote:

> I would like to display the panel TBDISPL while adding entries TBADD
>
> I am issuing a CONTROL DISPLAY LOCK
> Before the TBDISPL as I want control be returned immediately after
> TBDISPL the panel
> However when using CONTROL DISPLAY LOCK the panel is never displayed

For the umpteenth time, POST YOUR CODE.

My recollection of table handling is that the whole thing is quite tricky
to get right. That is, there's a good chance that whatever your problem
is, it will depend on how you've written all of the code - perhaps also
including the PANEL itself (eg whether it has )INIT and )REINIT logic on
it, not just one single statement in the rexx exec.

--
Jeremy Nicoll - my opinions are my own.

[Frank Clarke]

I second Jeremy's motion, especially the part where he notes "the whole thing is quite tricky".  ISPF Table Handling is like a formal court dance of the 16th century: if you don't put your feet in the right spot at the right time, everyone points and snickers.

[Joseph Reichman]

The code is pretty straight forward CONTROL EXEC DISPLAY LOCK and then TBDISPL tablename PANEL(panel name)

If its the panel looking to post well there is a lot more to it

I work for the IRS and I have problems posting under Joseph....@irs.gov

So I use my iPhone or pc

Want to understand when you say post is it the whole rexx exec

I appreciate the help but trying to be practical

BTW when I remove )PROC from the panel
It just sits there and I guess because of the lock I cannt proceed

Thanks



> On May 24, 2021, at 9:04 AM, Jeremy Nicoll <jn.ls....@letterboxes.org> wrote:

[Willy Jensen]

You need the )PROC statement.
I suggest adding this after the TBDISPL for debugging:
If rc>8 then say 'TBDISPL error' rc zerrlm


-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Joseph Reichman
Sendt: 24. maj 2021 16:55
Til: TSO-...@VM.MARIST.EDU
Emne: Re: [TSO-REXX] ISPF CONTROL DISPLAY LOCK

--
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Frank Clarke]

Here's why people keep asking you to post the code: 
I just finished a REXX/ISPF routine that extensively uses tables.  It's 1184 lines (including comments and boilerplate diagnostic subroutines — I tend to over-design my code), highly compartmentalized, and — until just recently — non-working.  Because of good diagnostic facilities I always build-in at write-time, I finally figured out that the critical error was a missing "TBVCLEAR".
One missing line.   In code I wrote myself.  It took poring through 9,000+ lines of trapped 'trace r' output to find it.
Posting two lines at a time?  No, nobody is ever going to be able to help.

[Jeremy Nicoll]

On Mon, 24 May 2021, at 13:53, Joseph Reichman wrote:

> I am issuing a CONTROL DISPLAY LOCK
> Before the TBDISPL as I want control be returned immediately after

That's not what CONTROL DISPLAY LOCK is usually used for.

It's used when one wants ispf to display a message, usually a
progress one, on a long running bit of processing, that is eg
every 10 percent of the way through something you redisplay
the panel with an updated message.

I don't understand what you are really trying to do ... which is
why we need to see the whole table handling logic, not just
the line(s) you think are the problem.

--
Jeremy Nicoll - my opinions are my own.

[Joseph Reichman]

Let me start by saying what I want to do

I’m searching for tax data then data is stored in VB files
In the case of very rare data

I may have to search for over 4,000 files

I break up the files to 100 files per job with 4,000 files that would be 40 jobs

Using the Rexx SDSF interface I get the data to monitor the jobs

I store each job and the statistics in a table

So I want to display the progress of the entire search in a TBDISPL output initially
Growing till finally when they complete
Until it completes there is n’t the need for user interaction

I thought I could this with control display lock and tbadd’s and TBDISPL


> On May 24, 2021, at 1:07 PM, Jeremy Nicoll <jn.ls....@letterboxes.org> wrote:

[Jeremy Nicoll]

On Mon, 24 May 2021, at 18:17, Joseph Reichman wrote:

> So I want to display the progress of the entire search in a TBDISPL
> output initially
> Growing till finally when they complete
> Until it completes there is n’t the need for user interaction
>
> I thought I could this with control display lock and tbadd’s and TBDISPL

It's possibly possible, but is it a good idea? It only makes sense, I think,
if the rexx exec that's running this is continually busy, updating the info
about the running jobs. That sounds to me like a lot of wasted CPU,
and a TSO session that's unusable for anything else while this runs.

Why not collect the progress data when the user presses Enter and
(implicitly) gives control back to the governing exec so that it can
update the table and redisplay it?

Then the tso/ispf session can be used for other things at the same
time.

[Willy Jensen]

This small sample works like a charm..

/* setup enviroment */
Address TSO
Address ispexec
"control errors return"

/* build table */
$tbl = '$'Time('s')
$names = 'sel p1 p2'
sel = ''
"tbcreate" $tbl "names("$names") nowrite"

text.1= 'kilroy / was here'
text.2= 'it is a lovely / summer morning'
text.3= 'flowers are / in bloom'
do n=1 to 3
parse var text.n p1 '/' p2
"tbadd" $tbl
"tbtop" $tbl
"control display lock"
"tbdispl" $tbl "PANEL(TBDISPLT)"
if rc>8 then do
say rc zerrlm
exit 8
end
zz=RxWait(2)
end

Panel:
)ATTR
# TYPE(INPUT) COLOR(turq) CAPS(off)
_ TYPE(INPUT) COLOR(yellow) CAPS(ON)
@ TYPE(INPUT) COLOR(yellow) CAPS(ON) padc('''')
" TYPE(text ) COLOR(green) skip(on)
)BODY EXPAND(\\)
"\ \Table display sample \ \+
%CMD ==>_ZCMD \ \%Scrl#scin+
+
"S "p1 p2
)MODEL
@Z #p1 #p2
)INIT
&SCIN = 'CSR'
.ZVARS = '(SEL)'
)PROC
)END

-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Joseph Reichman
Sendt: 24. maj 2021 16:55
Til: TSO-...@VM.MARIST.EDU
Emne: Re: [TSO-REXX] ISPF CONTROL DISPLAY LOCK

--
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Frank Clarke]

... or he could run those jobs in background, produce -n- transaction files (one from each), then feed the (sorted?) transactions into a process that puts them all into an ISPF table or a VB file or a whatever file.
Tying up a TSO session waiting for -n- background jobs to complete is wasteful unless there's some critical need to have the information available instantly.  I mean, he's collecting taxes, not landing a crew on Mars.
This isn't a coding problem.  This is a design problem.

[Bill Turner, WB4ALM]

Now, now Frank - ispf table design problems?
never hear of any issues in this arena, except when several hundred
people want to UPDATE a table thaa many more want to READ...

/s/ Bill Turner, wb4alm

On 5/24/21 1:53 PM, Frank Clarke wrote:
> ... or he could run those jobs in background, produce -n- transaction files (one from each), then feed the (sorted?) transactions into a process that puts them all into an ISPF table or a VB file or a whatever file.
> Tying up a TSO session waiting for -n- background jobs to complete is wasteful unless there's some critical need to have the information available instantly.  I mean, he's collecting taxes, not landing a crew on Mars.
> This isn't a coding problem.  This is a design problem.
>
>
> On Monday, May 24, 2021, 01:29:43 PM EDT, Jeremy Nicoll <jn.ls....@letterboxes.org> wrote:
>
> On Mon, 24 May 2021, at 18:17, Joseph Reichman wrote:
>
>> So I want to display the progress of the entire search in a TBDISPL
>> output initially
>> Growing till finally when they complete
>> Until it completes there is n’t the need for user interaction
>>
>> I thought I could this with control display lock and tbadd’s and TBDISPL
> It's possibly possible, but is it a good idea?  It only makes sense, I think,
> if the rexx exec that's running this is continually busy, updating the info
> about the running jobs.  That sounds to me like a lot of wasted CPU,
> and a TSO session that's unusable for anything else while this runs.
>
> Why not collect the progress data when the user presses Enter and
> (implicitly) gives control back to the governing exec so that it can
> update the table and redisplay it?
>
> Then the tso/ispf session can be used for other things at the same
> time.
>

[Frank Clarke]

:-). “Hundred” ... “many more” ... You left the area of suitability for tables long before that.

Sent from my iPhone

> On May 24, 2021, at 2:18 PM, Bill Turner, WB4ALM <wb4...@arrl.net> wrote:
>
> Now, now Frank - ispf table design problems?

[Bill Turner, WB4ALM]

Touche!     (can't find the right accent keys....)

/s/ Bill