Hi Mike,
that was also my analysis...
Many thanks and regards
Yves
Please don't try to analyze the dump - I did it already - this is not really my
problem
I would be interested:
- what did IBM change in TLD - CB not documented?
- will this change make problems in other software?
- do someone (???) have the source?
Thanks to all of you
Best regards
Yves
H, C9E2D7D7F0F0F140 is "
ISPP001" (Start of ISPF Log - - - - Session # )
At 02:46 PM 12/19/2023, you wrote:
Yves,
I installed the CAPTURE CLIST and the ISPFHTML load module on a vanilla
z/OS V3R1 system; I get the same S0C1 ABEND.
Digging deeper, the ABEND is caused when ISPFHTM
Yves,
I installed the CAPTURE CLIST and the ISPFHTML load module on a vanilla
z/OS V3R1 system; I get the same S0C1 ABEND.
Digging deeper, the ABEND is caused when ISPFHTML branches to a x'184'
offset into the TLD, where there is data, not a valid op code. Instead of
the code that ISPFHTML expect
Yves,
Do you have the same display in 2.4?
René
Le mardi 19 décembre 2023 à 17:44:16 UTC+1, Yves Colliard
a écrit :
Bonjour René,
oui je pense que vous avez raison - you could be right... is it documented?
00035000 000183A8 000184A8 000185A8 000186A8 0B4782C8 0135 E3D3C4F1
On 12/19/2023 9:27 AM, Mike Shaw wrote:
Doug used to work in ISPF development at IBM. His code is using knowledge
he had of the TLD format that us mere mortals don't have. Looks like the
TLD may have changed under z/OS V3R1?
Oh no! In our software, we are using a "trick" given to us years ago b
Yves,
On our z/OS V2R4 system, ISPFHTML does not fail and works as advertised.
You pointed out that upon entry, R1 contains the address of a TLD (Terminal
Logical Descriptor) which is the ISPF control block associated with each
logical screen under ISPF. On my system, ISPFHTML code shortly after
Yves,,
IMHO (and I am only a lowly bit fiddler with VSE background)
the problem is this
code in ISPFHTM
47F0F026B OVER_EYECATCHER
21C9E2D7 C6C8E3D4 D340F0F0 F0F2F040 6040C2C1 E2C540D6 E261F3F9
*.00..ISPFHTML 00020 - BASE OS/39*
0976F020 F040D94B F1F0
OVER_EYECATC
Bonjour René,
oui je pense que vous avez raison - you could be right... is it documented?
00035000 000183A8 000184A8 000185A8 000186A80B4782C8 0135 E3D3C4F1
00035018 *..cy..dy..ey..fy..bHTLD1..&.*
00035020 00035018 0B495AF0 00035018000429F0 000429D8 000157B0
00015810
Hi Yves,
Do You have the memoty at 00035000 (80bytes) ?
I heard something about before we address and now we have address of address...
but i don't remember more.
René
Le mardi 19 décembre 2023 à 07:43:59 UTC+1, Yves Colliard
a écrit :
Hello Mike,
many thanks for your answer. Ana
Hello Mike,
many thanks for your answer. Analysis the dump (I did it already...) will not
really solve the problem - since no source code is available and without
reverse eng. no correction is possible. It will also not solve the base
problem: what have changed???
But if you like here the data
Yves,
Any regs and PSW you can share?
The module was last compiled in the year 2000 and is written in PL/X; no
source AFAIK.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
On Mon, Dec 18, 2023 at 11:12 AM Yves Colliard
wrote:
> Hello!
>
> since years I'm using ISPFHTML from Doug Nade
Hello!
since years I'm using ISPFHTML from Doug Nadel - so a nice tool. But now -
using z/OS 3.1 - I got an Abend S0C1...
Do someone know something about:
- is the source of ISPFHTML somewhere?
- what did change in ISPF that could produce this problem... this could be the
bigger issue using z/OS
13 matches
Mail list logo
