¿ªÔÆÌåÓý


Re: Program Interrupts (signals)

 

On Tue, Apr 21, 2020 at 07:44 PM, Bob Polmanter wrote:
Even if you made an effort to set these things up, I can't see how your program check handling routine could recover or fix anything up that failed in a compiled language environment.?
Considering a shared GCCLIB and BREXX, and thinking of a REXX program calling something like EXECIO also leveraging GCCLIB. Well I need a way to know that a program (say EXECIO) had bought a farm and then free up malloced memory for EXECIO but not BREXX. And flush?IO that is cached within GCCLIB (but for EXECIO only) and stuff like that. Sounds more complex than it is ... but to do it I need to know a program is about to die!


Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

Joe,

Yes you can take control, but the question I would ask is do you want to? What are you going to do if a program does a divide by zero,.

For example FORTRAN already catches divide by zero¡­.

?

So we have a FORTRAN program¡­

?

type dave1 fortran???????????

??????????????????????????????

??????WRITE(6,1)?????????????

?1??? FORMAT(' Hi Dave ')????

??????I = 0??????????????????

??????J =10??????????????????

??????K=J/I??????????????????

??????STOP???????????????????

??????END????????????????????

??????????????????????????????

Ready; T=0.01/0.01 20:49:13?? ?????????????????????????????

?

And we compile it

?

fortran dave1??????????????????????????

FORTRAN IV (G) COMPILATION COMPLETE.???

Ready; T=0.01/0.02 20:50:11????????????

?

Write a little wrapper exec

?

type dave exec????????????????

???????????????????????????????

FI 06 TERM????????????????????

LOAD DAVE1 (START?????????????

CP Q N????????????????????????

???????????????????????????????

Ready; T=0.01/0.01 20:53:19???

?

And run it¡­

?

Ready; T=0.01/0.01 20:52:08?????????????????????????????????????????????????????????????

dave????????????????????????????????????????????????????????????????????????????????????

FI 06 TERM???????????????????????????????????????? ??????????????????????????????????????

LOAD DAVE1 ( START??????????????????????????????????????????????????????????????????????

Execution begins...?????????????????????????????????????????????????????????????????????

Hi Dave?? ????????????????????????????????????????????????????????????????????

IHC900I EXECUTION TERMINATING DUE TO ERROR COUNT FOR ERROR NUMBER? 209??????????????????

IHC209I IBCOM - PROGRAM INTERRUPT- DIVIDE CHECK OLD PSW IS? FFE40009A202013C????????????

TRACEBACK? ROUTINE? CALLED FROM ISN?? REG.? 14?? REG.? 15?? REG.?? 0?? REG.?? 1?????????

???????????MAIN?????????????????????? 000125D6?? 00020000?? 0000A9C4?? 0000ACF0????? ????

ENTRY POINT=? 00020000??????????????????????????????????????????????????????????????????

?????????????????????????????????????????????????????????????????????????????????????????

SUMMARY OF ERRORS FOR THIS JOB?? ERROR NUMBER?? NUMBER OF ERRORS????????????????????????

??????????????????????????????????209????????????? 1????????????????????????????????????

+++ R(00016) +++??????????????????????????????????????????????????????????? ?????????????

CP Q N??????????????????????????????????????????????????????????????????????????????????

CPWATCH? - DSC, OPERATOR - 009, CMSBATCH - DSC, MAINT??? - 0C0??????????????????????????

Ready; T=0.01/0.02 20:52:12?????????????????????????????????? ???????????????????????????

?

Note that the FORTRAN Run Time catches the divide by zero, and the exec continues to run¡­??

¡­ even if its REXX on the 6-pack the exec continues to run

?

type dave exec??????????????

?????????????????????????????

/* */???????????????????????

FI 06 TERM??????????????????

"LOAD DAVE1 (START"?????????

CP Q N??????????????????????

?????????????????????????????

Ready; T=0.01/0.01 21:00:20?

?

And run it¡­

?

dave???????????????????????????????????????????????????????????????????????????

Execution begins...????????????????????????????????????????????????????????????

Hi Dave????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????

IHC900I EXECUTION TERMINATING DUE TO ERROR COUNT FOR ERROR NUMBER? 209?????????

????????????????????????????????????????????????????????????????????????????????

IHC209I IBCOM - PROGRAM INTERRUPT- DIVIDE CHECK OLD PSW IS? FFE40009A202013C???

????????????????????????????????????????????????????????????????????????????????

TRACEBACK? ROUTINE? CALLED FROM ISN?? REG.? 14?? REG.? 15?? REG.?? 0?? REG.?? 1

????????????????????????????????????????????????????????????????????????????????

???????????MAIN?????????????????????? 000125D6?? 00020000?? 00EB0B90?? 00EB0AB0

????????????????????????????????????????????????????????????????????????????????

ENTRY POINT=? 00020000??????????????????? ??????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????

SUMMARY OF ERRORS FOR THIS JOB?? ERROR NUMBER?? NUMBER OF ERRORS???????????????

????????????????????????????????????????????????????????????????????????????????

??????????????????????????????????209????????????? 1???????????????????????????

?????3 *-* "LOAD DAVE1 (START"?????????????????????????????????????????????????

???????+++ RC(16) +++??????????????????????????????????????????????????????????

CPWATCH? - DSC, OPERATOR - 009, CMSBATCH - DSC, MAINT??? - 0C0?????????????????

Ready; T=0.02/0.06 21:00:37????????????????????????????????????????????????????

?

Thoughts? I guess if it was an assembler program then you might want to catch it, but then do you have to clear/check SPIE before/after commands?

How does REXX on VM/SP behave?

?

Dave

?

?

?

From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 21 April 2020 21:30
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

The VM/370 System Programmers Guide, page 238:

?

"The?program?interruption?handler,?DMSITP,?receives control?when a?program?interruption?occurs.?When DMSITP?gets?control,?it?stores?the Program?old PSW?and?the contents of the?registers?14, 15, 0, 1,?and 2?into?the program?interruption?element (PIE). (the routine?that?handles the?SPIE macro?instruction?has already placed the address of the program?interruption?control area?(PICA)?into?PIE.)?DMSITP?then determines whether or not the event?that?caused the?interruption?was?one of those?selected?by a SPIE macro?instruction. If?it?was?not,?DMSITP?passes control to the?DMSABN?abend recovery?routine.

If?the cause of the?interruption?was one?of those selected in?a SPIE macro?instruction,?DMSITP?picks?up?the?exit?routine address?from?the?PICA and?passes control to the?exit routine.?Upon?return?from?the?exit routine,?DMSITP?returns?to the?interrupted?program by?loading the?original?program?check old?PSW. The?address?field?of the PSW was modified?by a SPIE?exit?routine in the PIE."

So it would appear that in a runtime, Adrian could issue an SPIE to get control of program interrupts.

Joe

?

On Tue, Apr 21, 2020 at 2:42 PM Dave Wade <dave.g4ugm@...> wrote:

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 21 April 2020 20:22
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:

emulation layer and serviced by routine

I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer?


Re: Program Interrupts (signals)

 

The VM/370 System Programmers Guide, page 238:

"The?program?interruption?handler,?DMSITP,?receives control?when a?program?interruption?occurs.?When DMSITP?gets?control,?it?stores?the Program?old PSW?and?the contents of the?registers?14, 15, 0, 1,?and 2?into?the program?interruption?element (PIE). (the routine?that?handles the?SPIE macro?instruction?has already placed the address of the program?interruption?control area?(PICA)?into?PIE.)?DMSITP?then determines whether or not the event?that?caused the?interruption?was?one of those?selected?by a SPIE macro?instruction. If?it?was?not,?DMSITP?passes control to the?DMSABN?abend recovery?routine.

If?the cause of the?interruption?was one?of those selected in?a SPIE macro?instruction,?DMSITP?picks?up?the?exit?routine address?from?the?PICA and?passes control to the?exit routine.?Upon?return?from?the?exit routine,?DMSITP?returns?to the?interrupted?program by?loading the?original?program?check old?PSW. The?address?field?of the PSW was modified?by a SPIE?exit?routine in the PIE."

So it would appear that in a runtime, Adrian could issue an SPIE to get control of program interrupts.

Joe


On Tue, Apr 21, 2020 at 2:42 PM Dave Wade <dave.g4ugm@...> wrote:

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 21 April 2020 20:22
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:

emulation layer and serviced by routine

I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer?


Re: Program Interrupts (signals)

 

That is exactly as Bob wrote. I've checked POPS for System/370? - on page 72 you have all serviceable exceptions wit old and new PSW what probably cover all cases. And this is as in Unix world - the same signals cannot be serviced two in the same time.

Piotr


wt., 21 kwi 2020 o 22:06?Dave Wade <dave.g4ugm@...> napisa?(a):

I don¡¯t think there is an issue with the OS interrupt handlers, the problem with OS macros is that if you are using OS storage the chains get cleaned at program termination time.

Provided you are not using OS macros then its not a problem.

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of rvjansen@...
Sent: 21 April 2020 20:56
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

Can¡¯t we use STAE? Or is that also one of those ¡¯tainted¡¯ OS macro¡¯s?



On 21 Apr 2020, at 21:42, Dave Wade <dave.g4ugm@...> wrote:

?

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave

?

From:?[email protected]?<[email protected]>?On Behalf Of?adriansutherland67
Sent:?21 April 2020 20:22
To:?[email protected]
Subject:?Re: [h390-vm] Program Interrupts (signals)

?

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:

emulation layer and serviced by routine

I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer??

?


Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

I don¡¯t think there is an issue with the OS interrupt handlers, the problem with OS macros is that if you are using OS storage the chains get cleaned at program termination time.

Provided you are not using OS macros then its not a problem.

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of rvjansen@...
Sent: 21 April 2020 20:56
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

Can¡¯t we use STAE? Or is that also one of those ¡¯tainted¡¯ OS macro¡¯s?



On 21 Apr 2020, at 21:42, Dave Wade <dave.g4ugm@...> wrote:

?

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave

?

From:?[email protected]?<[email protected]>?On Behalf Of?adriansutherland67
Sent:?21 April 2020 20:22
To:?[email protected]
Subject:?Re: [h390-vm] Program Interrupts (signals)

?

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:

emulation layer and serviced by routine

I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer??

?


Re: Program Interrupts (signals)

 

STAE is an OS macro as well.?? I can't recall for sure but if memory serves this macro provides almost nothing in CMS.? I seem to recall it being a no-op.

Bob

Can¡¯t we use STAE? Or is that also one of those ¡¯tainted¡¯ OS macro¡¯s?


Re: Program Interrupts (signals)

 

Adrian,

Divide-by-zero does indeed cause a program check interruption 9.? If you are concerned about this possibility, mitigate it in your C code by checking the divisor first to see if it is zero.? Abend avoided.

Interruption details and type are provided at the time of the interruption within the PSW.? That PSW is always stored at location X'28' in the virtual machine when the interruption occurs.

You will just get one single interrupt, unless your interruption handler also has bugs and causes a program check, in which case you could have a program check interruption loop.

Bob


On Tue, Apr 21, 2020 at 12:29 PM, adriansutherland67 wrote:
Also I considered a interrupt handler but
1/ am not certain if div by zero etc. cause interrupts
2/ i did not see any way to determine the interrupt details (but I assume I would eventually)
3/ wouldn't I get 100s a second?


Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

Can¡¯t we use STAE? Or is that also one of those ¡¯tainted¡¯ OS macro¡¯s?

On 21 Apr 2020, at 21:42, Dave Wade <dave.g4ugm@...> wrote:

I suggest reading the CMS program logic manuals¡­
¡­ I think we are limited to SPIE & HDNINT ¡­
CP is not really involved. It reflects interupts
?
Dave
?
From:?[email protected]?<[email protected]>?On Behalf Of?adriansutherland67
Sent:?21 April 2020 20:22
To:?[email protected]
Subject:?Re: [h390-vm] Program Interrupts (signals)
?
On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:
emulation layer and serviced by routine
I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer??



Re: Program Interrupts (signals)

 

HNDINT handles i/o interruptions, not program checks.
HNDEXT handles external interruptions.

There is not one for program checks except SPIE, which is OS simulation.

Regards,
Bob


On Tue, Apr 21, 2020 at 12:42 PM, Dave Wade wrote:

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave


Re: Program Interrupts (signals)

 

I can think of a few ways you can intercept and handle program interruptions, but they all point to the same answer that I don't think you will like:? use assembler.

You could use the SPIE macro to intercept some kinds of interruptions, but that is an OS simulation macro,which as I recall you are trying to avoid.? If you did want to use it, you would need to call an assembler routine to set it up, and more assembler for the routines to handle the actual interruptions you wish to trap.

More commonly back in the day, it was necessary to write your own program check interruption handler because CMS at the time lacked the necessary structure to provide this kind of capability at the application level.? This would necessarily need to be in assembler too, and involves temporarily stealing CMS's program check new PSW and replacing it with your own that points to your handler, and putting back CMS's PSW before your application exits for good.

Even if you made an effort to set these things up, I can't see how your program check handling routine could recover or fix anything up that failed in a compiled language environment.? Recovery is much easier if the whole thing is in the same language because you know where all your storage areas are and what routine is what and who should be called, what routine or frame was in control, and so forth.

Your best bet if you want to stay with C in this environment (that is, an old CMS and no LE (Language Environment) support that is in modern-day compilers and run-times), would probably be to do everything you can in your application code to ensure reliability and minimize the chances of a program check.? But if it blows up, it is just going to blow up.

Regards,
Bob


Re: Program Interrupts (signals)

 

¿ªÔÆÌåÓý

I suggest reading the CMS program logic manuals¡­

¡­ I think we are limited to SPIE & HDNINT ¡­

CP is not really involved. It reflects interupts

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 21 April 2020 20:22
To: [email protected]
Subject: Re: [h390-vm] Program Interrupts (signals)

?

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:

emulation layer and serviced by routine

I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer?


Re: Program Interrupts (signals)

 

Also I considered a interrupt handler but
1/ am not certain if div by zero etc. cause interrupts
2/ i did not see any way to determine the interrupt details (but I assume I would eventually)
3/ wouldn't I get 100s a second?


Re: Program Interrupts (signals)

 

On Tue, Apr 21, 2020 at 07:02 PM, Piotr Kolasi¨½ski wrote:
emulation layer and serviced by routine
I was wondering if using os macros would be feasible / acceptable?

Also I noticed I can use a CMS macro to intercept SVC calls ... so does the os emulator really fire SVC 13? Is this part of an answer?


Re: Program Interrupts (signals)

 

So any ideas welcome :-)


Re: Program Interrupts (signals)

 

CMS I think.

Obviously I can handle (fake) "abends", for example if a program calls abort().

The problem is situations when the program "encounters" an abend. E.g. if the program divides by zero, trashes memory so bad that CMS notices, or (and I think CMS does this by polling) gets a HX. In this case I was looking for a way to intercept this with an exit function for cleanups.

Considering we have resident GCCLIB and BREXX without this bad things are inevitable!


Re: Program Interrupts (signals)

 

I may be wrong but it is virtual machine and trapping program interrupts is taken be emulation layer and serviced by routine with address defined in 4 kB area (PSA)? I dont have POPS 370 here.
Piotr


Re: Program Interrupts (signals)

 

The reason I am asking is this...

You have a runtime in C. So, you should be able to trap abends in your runtime before they get to CP, or maybe even CMS. This?can be done by appropriately setting up the environment before the runtime hands control over to the problem program...

Joe



On Tue, Apr 21, 2020 at 12:39 PM Joe Monk via <joemonk64=[email protected]> wrote:
So the question is, where are you trying to trap abends?

CMS or CP?

Joe

On Tue, Apr 21, 2020 at 11:46 AM adriansutherland67 <adrian@...> wrote:
So I do not believe our VM/370 supports ABMEXIT (If I am wrong please, please me, and let me know!)

I see no way to trap an ABEND (like divide by zero) nor a HX (which seems to be a pooling mechanism!?).

This means that an ABEND of a C program (well any program?!) will inevitably require an IPL as cleanups cannot be guaranteed :-(

Also HI is not supported.

It may not be the IBM way ... but a mod that fired SVC 13 (or 213 ... or whatever) on starting to process an abend would allow a SVC handler to be registered ...

Adrian



Re: Program Interrupts (signals)

 

So the question is, where are you trying to trap abends?

CMS or CP?

Joe

On Tue, Apr 21, 2020 at 11:46 AM adriansutherland67 <adrian@...> wrote:
So I do not believe our VM/370 supports ABMEXIT (If I am wrong please, please me, and let me know!)

I see no way to trap an ABEND (like divide by zero) nor a HX (which seems to be a pooling mechanism!?).

This means that an ABEND of a C program (well any program?!) will inevitably require an IPL as cleanups cannot be guaranteed :-(

Also HI is not supported.

It may not be the IBM way ... but a mod that fired SVC 13 (or 213 ... or whatever) on starting to process an abend would allow a SVC handler to be registered ...

Adrian



Re: Program Interrupts (signals)

 

So I do not believe our VM/370 supports ABMEXIT (If I am wrong please, please me, and let me know!)

I see no way to trap an ABEND (like divide by zero) nor a HX (which seems to be a pooling mechanism!?).

This means that an ABEND of a C program (well any program?!) will inevitably require an IPL as cleanups cannot be guaranteed :-(

Also HI is not supported.

It may not be the IBM way ... but a mod that fired SVC 13 (or 213 ... or whatever) on starting to process an abend would allow a SVC handler to be registered ...

Adrian



Re: Dynamic / split stacks (gcclib)

 

Dynamic stack completed.

Will now play with memset() challenge entries (the field is quite small ... lol).

Then signals ... any minimalist example of an ABEND or HX handler would be very welcome!?

Adrian