IEFU86 WorkArea use ?

[Guillaume Boesel]

Hi,
I'm testing IEFU86 exit to be able to write on syslog the SMF record number on the fly.
It's just for educational purpose.

When I use the workarea (retrieved from IFAEXITP) to store my WTO, SMF record,etc it works pretty well.
I am able to WTO the SMF records number in syslog.
But when I login/logoff, it fails with S0C4-11 (I don't use getmain/freemain storage obtain/release in my code).

When I use STORAGE OBTAIN/release to store my stuffs and don't use IEFU86 workarea, it works well. No more S0C4-11 when I login/logoff.

According to this thread :

https://bit.listserv.ibm-main.narkive.com/cIdJ48RP/smf-exit-iefu086-work-area-size#post16

the workarea seems shared (maybe why it fails for me ?) If it is the case, what is the utility of the workarea ?

Thank you for your help
Guillaume

[Pieter Wiid]

If a work area is shared among exits, I would expect one of those exits to getmain the area and store the address.

Consider this:
LT Rx,IFAEXITP
JNZ ALLOCATED
STORAGE OBTAIN.....
ALLOCATED DC 0H

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

[Abe Kornelis]

Hi Pieter,

would you really do that? without serialization?
I hope you're using CS on the ST of the pointer to the obtained area.

And then release the storage in case the CS fails ...

Most areas that are shared have a documented serialization requirement.
The CS I suggested might be inappropriate if another mechanism is
documented.

Kind regards,
Abe Kornelis.
===========


Op 08/07/2023 om 12:17 schreef Pieter Wiid:

[Pieter Wiid]

Abe
This comes from "shoot from the hip"". You are correct

[Guillaume Boesel]

Hi Abe and Pieter
Thank you for your replies.

"I hope you're using CS on the ST of the pointer to the obtained area."

Sorry for my newbie question but what means CS and ST ?

"Most areas that are shared have a documented serialization requirement."

I didn't see anything about serialization (or I misunderstood it) in the documentation and in the SYS1.MACLIB(IFAEXITP)

https://www.ibm.com/docs/en/zos/2.5.0?topic=exits-iefu86-smf-record-exit#IEFU86__pspu86


It works well with my own Storage Obtain/Release but if the provided workarea can be used, it should be better.

Guillaume

[Abe Kornelis]

Hi Guillaume,

ST = STore, a very common instruction.
CS = Compare and Swap - an instruction mainly used in multi-processor
environments
        when a 1-word area of storage (such as a 31-bit pointer) needs
to be modified in a serialized way.

For details, please look up these instructions in the Principles of
Operation.
Or in the late John Ehrman's excellent (although overcomplete) tutorial
 Assembler Language Programming for IBM z System Servers.

Kind regards & welcome to the world of assembler programming!
Abe Kornelis
==========



Op 08/07/2023 om 16:10 schreef Guillaume Boesel:

[Guillaume Boesel]

"ST = STore, a very common instruction.
CS = Compare and Swap "

Shame on me, yes of course.
I thought that you used acronym for some serialization stuffs.

Sorry :)

[Abe Kornelis]

Guillaume,

I just read up on the exit documentation, following the pointer you
provided.

And I noticed the exit is called in supervisor mode, key 0.
If you are indeed relatively new to assembler programming,
then coding an authorized exit such as IEFU86 might not be the best
option for learning.

I suggest you have a senior colleague review your code before
you start testing it. A bug in an exit like this might bring the system
down :-(

Kind regards & success learning assembler!
Abe

===

Op 08/07/2023 om 16:10 schreef Guillaume Boesel:

[Guillaume Boesel]

Hi Abe,

"coding an authorized exit such as IEFU86 might not be the best option for learning."

Yes, you are right, I know that it's dangerous but I still did some system related stuffs with assembler and now I want to try system exits as It's very interesting.
My iefu86 works fine on my test system but I will not test it at work on a production system :)

"I just read up on the exit documentation, following the pointer you provided."

Did you see something special about the workarea serialization ?

"Kind regards & success learning assembler!"

Thank you !


Guillaume

[Abe Kornelis]

Hi Guillaume,

No I did not see anything specified on serialization.
Unless I've missed it, that should imply no serialization is needed.

I guess it's serialized by the caller of the exit,
or maybe no explicit serialization is needed at all.

But that does not help at all in resolving your abend.
I'm sorry I cannot help you there.

Kind regards,
Abe
===


Op 08/07/2023 om 17:40 schreef Guillaume Boesel:

[Charles Mills]

Oh man, let me second what @Abe says. This is not the environment for a learning exercise!

(Parenthetically and counter-intuitively, it's key 0 that is really dangerous, not supervisor state. You really have to try to do something stupid with supervisor state; with key 0, any register usage "oops" is likely to bring z/OS down.)

Is WTO even legal from IEFU86? Just because it works sometimes does not mean it is safe to use. IEFU86 may be entered in cross-memory mode and with the local lock. I don't think that is a legal WTO environment.

Also, STORAGE OBTAIN is a pretty "heavy" service to be using for every SMF record. SMF records can get cut at a ferocious pace.

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Abe Kornelis
Sent: Saturday, July 8, 2023 7:32 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: IEFU86 WorkArea use ?

[Guillaume Boesel]

Hi Charles,

"This is not the environment for a learning exercise!"

Yes I understand that it's dangerous. I'm working on my own system.

"Is WTO even legal from IEFU86?"

WTO is just used to test my exit.

"STORAGE OBTAIN is a pretty "heavy" service to be using for every SMF record"

IEFU83 sample in SAMPLIB uses getmain, is it lighter than storage obtain ? I use storage obtain because i'm not able to use the workarea safely.
It was my initial question :)

Thanks
Guillaume

[Charles Mills]

Danger: so long as you understand the risks.

Not sure if it is possible in that environment to get back to user key but if you can it might be worthwhile.

WTO: well, the "legality" issue is not that the production police will come and take you downtown. The "legality" issue is that using it may cause odd and apparently unrelated results.

STORAGE OBTAIN: I think under the covers it is the same service as GETMAIN. Again, in a test system, overhead may not matter. FWIW what I did in a ***VERY*** heavily driven production IEFU8x environment was use cell pool services one time to get a cell pool, and then on each call got and returned a cell from the pool to use as a work area. CELL pool GET is very lightweight.

Note that IEFU83 is a "safer" situation than IEFU86, so lessons from an IEFU83 sample may not apply. For example, IEFU83 is not cross-memory, no locks and TCB. None of that is true for IEFU86.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Guillaume Boesel
Sent: Saturday, July 8, 2023 10:05 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: IEFU86 WorkArea use ?

[Jon Perryman]

The word "shared" has 2 meanings. For most people, it means multiple tasks using the same storage at the same time (e.g. CSA) which requires some sort of serialization (e.g. CS, ENQ and more). User exits have another type of sharing because 1 exit point can have multiple exit programs that are called serially and do not require serialization. For instance, you may have an OEM product that uses IEFU86 to monitor file open / close. The parm and is shared among all called exit programs. 

In the case of IEFU86, the workarea is passed as part of the parm. Notice the doc says workarea offset instead of address. Your exit program can either use this area if it's large enough but you shouldn't replace the parm area unless IBM gives you instructions on replacing it. If it's too small, then use storage obtain & release but remember this exit can be CPU expensive depending upon your SMFPARMS. 

Without seeing the dump, I would guess your S0C4 is caused by you not specifying LINKAGE=BRANCH on the WTO. Also, install the exit manually for testing using SETPROG from the console because you need the IPL to be successful. Also remember that production systems are very different than test. For instance, production may be collecting SUB=MSTR or hardware SMF data which can be tricky if you don't understand the environment.

[Guillaume Boesel]

Thank you Charles and Jon for your explanations.

"I would guess your S0C4 is caused by you not specifying LINKAGE=BRANCH on the WTO"

I use LINKAGE=BRANCH. Using workarea method works well (WTO OK) except when a user login/logoff (S0C4-11). I use this area for few bytes (less than 1024)

Workarea method : works but S0C4-11 when a user login/logoff on my test system
LR R10,R1 Parameter list dans R10
USING SMFEXITP,R10
...
L R8,SMXP_RECPTR R8 = record SMF
LR R9,R10 R9 = Parameter List
A R9,SMXP_WORKAREA_OFFSET R9 = Pointer to the work area
...
USING WORKAREA,R9
...
WTO MF=(E,WTOZONE),LINKAGE=BRANCH



Storage Obtain method : works every time on my test system
LR R10,R1 Parameter list dans R10
USING SMFEXITP,R10
...
L R8,SMXP_RECPTR R8 = record SMF
STORAGE OBTAIN,LENGTH=WORKLEN,ADDR=(R1),SP=245
LTR R15,R15 Storage Obtain OK ?
JNZ FIN Non, on sort sans RELEASE
LR R9,R1 R9 = addr memoire obtenue
...
USING WORKAREA,R9
ST R9,WORKADDR Sauvegarde de l addr pour le release
...
WTO MF=(E,WTOZONE),LINKAGE=BRANCH
STORAGE RELEASE,LENGTH=WORKLEN,ADDR=WORKADDR,SP=245

[Binyamin Dissen]

If you are coding system exits, you should know (or learn) how to read a dump.

Is the 0C4 in your code or did you possibly mess up other storage?

Look at the PSW and registers. Look at the work areas.


On Sat, 8 Jul 2023 04:50:36 -0400 Guillaume Boesel <guil...@BOESEL.FR>
wrote:

:>Hi,

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

[Seymour J Metz]

I would advise testing the length of the work area against your required length.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Guillaume Boesel [guil...@BOESEL.FR]
Sent: Saturday, July 8, 2023 3:35 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: IEFU86 WorkArea use ?

[Guillaume Boesel]

Hi Binyamin and Seymour
Thanks for your advices.

"Is the 0C4 in your code or did you possibly mess up other storage?"

According to IPCS the 0C4 is in my code, failing instruction is when I store stuffs in the IEFU86 workarea (only when a new user login or logout).

"I would advise testing the length of the work area against your required length."

The IEFU86 WorkArea length is 1024 (SMXP_WORKAREA_LENGTH in SYS1.MACLIB(IFAEXITP) and x'400' when I dumped it), I only use few bytes.


But, my original question was, is the IEFU86 workarea shared and if yes, do you use it to safely store stuffs inside ? Or this workarea is not to be used to store stuffs and has another utility ?


Thank you

[Binyamin Dissen]

On Sun, 9 Jul 2023 02:00:30 -0400 Guillaume Boesel <guil...@BOESEL.FR>
wrote:

:>Hi Binyamin and Seymour

:>Thanks for your advices.

:>"Is the 0C4 in your code or did you possibly mess up other storage?"
:>According to IPCS the 0C4 is in my code, failing instruction is when I store stuffs in the IEFU86 workarea (only when a new user login or logout).

So why are you getting the PIC-11?

Do the following basic debugging steps.

Look at the register that you think is pointing to the workarea.

Look at the address of the SMXP.

Does your calculated address make sense?

:>"I would advise testing the length of the work area against your required length."

:>The IEFU86 WorkArea length is 1024 (SMXP_WORKAREA_LENGTH in SYS1.MACLIB(IFAEXITP) and x'400' when I dumped it), I only use few bytes.

:>But, my original question was, is the IEFU86 workarea shared and if yes, do you use it to safely store stuffs inside ? Or this workarea is not to be used to store stuffs and has another utility ?

As it is an extent ion of the SMXP I would not expect it to be shared.

[Seymour J Metz]

Did you check the length in storage, or on;y in the macro?

Please show the failing code and the registers.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Guillaume Boesel <guil...@BOESEL.FR>

Sent: Sunday, July 9, 2023 2:00 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: IEFU86 WorkArea use ?

Hi Binyamin and Seymour

[Guillaume Boesel]

Hi Binyamin and Seymour

"Look at the register that you think is pointing to the workarea."

In the following code, the register pointing to SMXP is R10.
I add SMXP_WORKAREA_OFFSET to it to point to the workarea (R9)
R10 = 7F620050 SMXP
R9 = 7F720450 WorkArea

Before to use this workarea, I check if I'm really in SMXP thanks to the eyecatcher (R7 = X'E2D4E7D7')

LR R10,R1 Parameter list dans R10
USING SMFEXITP,R10

*
L R7,SMXP_EYECATCHER R7 doit contenir 'SMXP'
CL R7,=CL4'SMXP' Verification ?
JNE FIN Non, on sort
*
L R8,SMXP_RECPTR R8 = Pointer to the SMF record
...

LR R9,R10 R9 = Parameter List
A R9,SMXP_WORKAREA_OFFSET R9 = Pointer to the work area

USING WORKAREA,R9
ST R9,WORKADDR
MVC WTOU86D(WTOBUFFL),WTOBUFF RAZ zone WTO



PSW: 07042000 80000000 00000000 0E81F058
Instruction length: 04 Interrupt code: 0011
Failing instruction text: 189A5A90 A00C5090 9000D284
Translation exception address: 00000000_7F720400

General purpose register values
Left halves of all registers contain zeros
0-3 7F620598 00100400 00000000 00000000
4-7 00000010 00000400 04000000 E2D4E7D7
8-11 7F5D6BA8 7F720450 7F620050 7F5D6BA8
12-15 8E81F006 7F61FDF0 8127CC90 8E81F000

189A 60 LR R9,R10
5A90 A00C 0000C 61 A R9,SMXP_WORKAREA_OFFSET
R:9 00000 68 USING WORKAREA,R9
5090 9000 00000 69 ST R9,WORKADDR
70 *
D284 9010 C0E2 00010 000E8 71 MVC WTOZONE(WTORAZL),WTORAZ



Thanks

[Guillaume Boesel]

My bad, I found the bug,
I should have used
AH R9,SMXP_WORKAREA_OFFSET R9 = Pointer to the work area

and no

A R9,SMXP_WORKAREA_OFFSET R9 = Pointer to the work area

because "SMXP_WORKAREA_OFFSET DS H Offset to work area" in SYS1.MACLIB(IFAEXITP)

Now, all is working fine. Login/logout no more make crash my IEFU86 !

Thank you for all your suggestions !

And sorry to have flooded you with my idiot problem :)

Guillaume

[Peter Relson]

The linked-to post is not about the work area being "shared" per se. The work area is for use by the called exit routine for the duration of that exit routine's being in control. There can be no assumptions about contents on entry.

Basic debugging is necessary for any error. If you're going to ask for help, then provide the information that those who might help would need.

The OP did not post the complete exit routine. For all I know, the use of the "execute form" of WTO is incorrect and is not properly initialized and incorrectly assumes some storage is zeroes but might not be.
The OP did not post anything about just where the 0C4-11 occurred.

Making the readers guess is not the right approach.

Binyamin wrote:
<snip>

Is the 0C4 in your code or did you possibly mess up other storage?

Look at the PSW and registers. Look at the work areas.

</snip>
Exactly.

<snip>

"Is WTO even legal from IEFU86?"

WTO is just used to test my exit.

</snip>
That does not answer to the question. But the odds are that a BRANCH=YES WTO will work according to specifications if it is done correctly, whether or not you should use it within an exit such as IEFU86.

<snip>

STORAGE OBTAIN,LENGTH=WORKLEN,ADDR=(R1),SP=245

LTR R15,R15 Storage Obtain OK ?

JNZ FIN Non, on sort sans RELEASE

</snip>
STORAGE OBTAIN defaults to COND=NO. This invocation would abend (not return) if the storage could not be obtained.
Thus there is no reason to check R15 afterwards. Only if you also specify CHECKZERO=YES for a COND=NO STORAGE OBTAIN could you successfully obtain the storage and get a non-zero return code.

Charles M wrote
<snip>

STORAGE OBTAIN: I think under the covers it is the same service as GETMAIN.

</snip>

That would depend on how far under the covers you go, and whether you specify LINKAGE= on the STORAGE invocation.
STORAGE OBTAIN with LINKAGE=SVC or LINKAGE=BRANCH is exactly the same service as GETMAIN.
STORAGE OBTAIN with the default LINKAGE=SYSTEM has different initial and final processing than GETMAIN. The "middle" is common to both.

<snip>

Not sure if it is possible in that environment to get back to user key but if you can it might be worthwhile.

</snip>
Switching to user key would likely be a very wrong thing to do.

And a reminder: questions about how z/OS works (such as whether a work area provided on a z/OS interface has certain characteristics) do not belong on assembler-list. IBM-Main is a much better choice, getting to a wider audience of folks who might help.

Peter Relson
z/OS Core Technology Design

[Rene BRANDT]

J'en étais loin, je pensais que certaines entrées comme le logon n'avait pas de workarea...

Bravo
Bonne soirée,
René

[Tom Marchant]

On Sat, 8 Jul 2023 16:22:26 +0200, Abe Kornelis <a...@BIXOFT.NL> wrote:

>CS = Compare and Swap - an instruction mainly used in multi-processor
>environments

CS (and its relatives) are needed in uniprocessor environments too,
Your program can be interrupted after any instruction, and another task may be dispatched before you are.

--
Tom Marchant