|
View previous topic :: View next topic
|
| Author |
Message |
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
I want to extend a macro that swaps between EDIT and VIEW (similar to Mark Zelden's SW) to position the line at the top of the screen at the time before the swap back at the top of the screen after the swap, both Mark's and my macros just display the first line at the moment.
However, given that there is no helpful .ZTOS system label that could give me the line number of the first displayed line, I thought about an alternative, i.e using the various
| Code: |
"ispexec vget (zscreenw)" /* screen width */
"ispexec vget (zscreend)" /* screen depth (height) */
"ispexec vget (zscreeni)" /* logical screen info (contents) */ |
variables.
However, ZSCREENW gives me the physical screen width, in my case 127, which is pretty useless if you're editing an FB(80) data set, and even worse, the length of ZSCREENI is not a multiple of ZSCREENW if the last line(s) of the visible screen end(s) in blanks.
I can of course assume that the user is always using the normal edit panel and find the position of the 'Command ===>' and 'Scroll ===>' fields, and use those to calculate the logical screen width, but that seems a very long-winded way.
Does anyone have any better suggestions, like via some mysterious location reachable via the STORAGE function? |
|
| Back to top |
|
 |
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
Sadly, that does not help.
If I use these routines, the length of ZSCREENI is (in my case, running ISPF in 56x127 mode) 56x127 but the contents, when editing an FB(80) data set contains only the logical data, and not the empty space at either side, so substr-inging sucessive 127 byte chunks is useless.
I'm sure there must be more STORAGE accessible locations, but given that Doug Nadel doesn't seem to be present on this forum will make it difficult to find them. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Well this is all i could find about it :
| Code: |
tcb = PTR(540) /* TCB (EXEC command) PSATOLD */
tcb = PTR(tcb+132) /* TCB (ISPTASK) TCBOTC */
fsa = PTR(tcb+112) /* first save area TCBFSA */
r1 = PTR(fsa+24) /* ISPTASK's R1 */
tld = PTR(r1) /* TLD address */
tls = PTR(tld+096) /* screen buffer TLDTLSP */
csr = PTR(tld+164) /* relative cursor pos. TLDCSR */
scrw = PTR(tld+192) /* screen width TLDCLSWD */
offl = scrw * TRUNC(csr/scrw) /* offset to current line */
csrp = csr-offl+1 /* cursor position */
linead = D2X(tls+offl) /* current line address */
line = STORAGE(linead,scrw) /* text of current line */
|
| Code: |
PTR:
RETURN C2D(BITAND(STORAGE(D2X(ARG(1)),4),'7FFFFFFF'X))
|
|
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
OK, what did you Google on to get at this info?
This indeed gives the logical length of the screen, but while using this, I stumbled upon another complication.
If you insert and delete lines in a data set with sequence numbers , the ISPF generated line numbers stop being relative:
| Code: |
****** ********
000100 /* REXX
000200 "isredit
000300 "ispexec
000400 "ispexec
000500
|
Insert a line after line 000200:
| Code: |
****** ********
000100 /* REXX
000200 "isredit
000210
000300 "ispexec
000400 "ispexec
000500
|
which means that you cannot just to a "L lineno" to reposition yourself back at the same place, you need to actually figure out where you are relatively the top.
Even worse, if you do a "NUM OFF", and add change, assuming the above fragment, the actual col 73-80 sequence numbers into
| Code: |
00011000
00012000
00013000
00014000
|
and then come back into edit (assuming that your profile was locked to NUMBER ON STD"), ISPF will happily come back with linenumbers
| Code: |
000110
000120
000130
000140
000500
|
Of course it is not unreasonable to assume that
- you will not start changing the data while in View before invoking the swap macro (it macro will tell you that changes will be lost)
- swapping to View from Edit after making changes is just as unlikely
And yes, there might actually be way of finding relative line numbers, and that is to invoke ISREMSPY and capture the resulting screen. I just think that doing so is probably a bit over the top, although it would be fun to give it a go. (That's the problem if you're unemployed, have too much time on your hands and are using "that" z/OS system)  |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
OK, what did you Google on to get at this info?
|
Can i read that as :
Thanks for the info, and maybe you could inform me how you got that?
A Google on zscreenw or zscreenc etc. did the job. It was quite easy. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| PeterHolland wrote: |
| Quote: |
OK, what did you Google on to get at this info?
|
Can i read that as :
Thanks for the info, and maybe you could inform me how you got that? |
Uiteraard kun je dat! 
I tried the same keywords but didn't come across these.
FWIW, did any of your results ever mention anything about the, for better or worse, "screen attribute" buffer. Doug Nadel's ISPFHTML uses "it" to convert screens into various formats (HTML/RTF/BBCode) , but obviously it's distributed as just a load module. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
FWIW, did any of your results ever mention anything about the, for better or worse, "screen attribute" buffer. Doug Nadel's ISPFHTML uses "it" to convert screens into various formats (HTML/RTF/BBCode) , but obviously it's distributed as just a load module.
|
The only time i came across screen attributes was when i was fooling around with TPUT/TGET (3270 programming). |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
The ISREMSPY approach doesn't work  , but I've found a way that works. If there is any interest, I can post the macro here, at around 300 lines it's probably not too long. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| Quote: |
| Doug Nadel doesn't seem to be present on this forum |
But you could try contacting him - sillysot.com |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| Nic Clouston wrote: |
| Quote: |
| Doug Nadel doesn't seem to be present on this forum |
But you could try contacting him - sillysot.com |
I could, but I cannot. I want the macro to be licensed under the GPL V3 (or later) which means that I do not want to include privately obtained information. |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2593
Location: Silicon Valley
|
|
|
|
I am not sure what you mean here:
| Quote: |
Insert a line after line 000200:
Code:
****** ********
000100 /* REXX
000200 "isredit
000210
000300 "ispexec
000400 "ispexec
000500
which means that you cannot just to a "L lineno" to reposition yourself back at the same place, you need to actually figure out where you are relatively the top. |
That is, it works for me. L 200 positions the screen to that line number. and L 210 correctly positions it to that line number.
From the help for locate:
| Quote: |
| If the number which is entered is 6 digits or less, it represents the line number as displayed on the left of the screen. If NUMBER mode is off, this is a relative line number. If NUMBER mode is on, it corresponds to a sequence number in the data. If the number entered is 7 or 8 digits and NUMBER mode is on, the number represents the full sequence number as it exists in the data (including the modification level for ISPF statistics). |
I think the first line number from ZSCREENI should work as the LOCATE value, regardless of NUMBER on or not. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
Sadly, the Locate command inside an edit macro only works on relative line numbers, not on ISPF line numbers or sequence numbers in the data.
Until someone can come up with an ISPF version-independent way of telling me the relative line number of the topmost visible line of the screen, I will do the following:
| Code: |
"isredit (STATE) = user_state"
"isredit f p'='"
"isredit (HERE) = linenum .zcsr"
"isredit user_state = (STATE)" |
which requires one single assumption, namely that the user has not assigned the macro to a PF key (more than very likely). |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2593
Location: Silicon Valley
|
|
|
|
Sorry, I did not read the entire thread...
1. Before you are doing what you are doing, put a label on the first line shown.
2. do it
3. locate the label. |
|
| Back to top |
|
|
Michael Jakob
New User
Joined: 13 Mar 2011
Posts: 17
Location: Switzerland
|
|
|
|
Hi Robert
Did you try the CURSOR command?
Edit-Mode:
"ISREDIT (CLIN,CCOL) =CURSOR"
View-Mode:
"ISREDIT CURSOR = (CLIN,CCOL)"
With this Command, you position on the base of relative line-numbers. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| Michael Jakob wrote: |
Did you try the CURSOR command?
Edit-Mode:
"ISREDIT (CLIN,CCOL) =CURSOR" |
No I didn't, I wrongly assumed that it would return 0 & 0 when the cursor is on the command line, but Iust tried it, and it seems to work: even if the cursor is not in the data, CLIN returns the relative line number of the line at the top of the screen.
However, if the user puts the cursor inside the data, it will give the line of the cursor, and a mode-switch will put that line at the top of the screen. Then again, my
suffers from exactly the same problem. |
|
| Back to top |
|
|
|
|
