On Sat, 27 Jun 2020 10:12:55 -0500, Lionel B Dyck wrote:
>
>When there are more (I don't know what that number is yet but in excess of
>30 but less than 100) the shell input status changes from RUNNING to INPUT
>and will not proceed until I hit ENTER. I've waited and ENTER is a must.
>
"Doctor it hurts when I do this."
>Note that this does NOT occur when I SSH into the z/OS system and run the
>rexx script from that interface.
>
"Don't do that!"
It's a terrible design, perhaps a desperate accommodation to the
limitations of TSO and VTAM. Perhaps this is the reason that ISPF
generally has no interruptible progress bars. CMS has no such problem.
In order to have the keyboard appear unlocked while a command is
running, 3270 OMVS polls intensively (READ SCREEN?) and unlocks
the keyboard on any keystroke. This is CPU-intensive so after a fixed
time (wall-clock, I believe, not resource use), OMVS pauses the
running task and waits for a 3270 interrupt.
You've found a circumvention: use SSH, not 3270.
Would putting the command in background:
cp -A -U -v /u/me/pdsdir/* "//'hlq.my.pds'" &
... make a difference? The status might yet go to INPUT, but
the command might continue to run.
What about SYSCALL spawn? A dozen more lines of code than
BPXWUNIX.
Batch?
Years ago this was whined about on MVS-OE. I don't know that
there ever was an RFE. It couldn't have been resolved satisfactorily.
Dammit! ISPF LM services should be made zFS-savvy!
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
