Erik:
This was being done in CICS (v3?) long before CICS/TS. This was
back when MVS/XA was still in support just before MVS/SP4 (as I
recall) had come out. .
IBM PROLOG for 370 (based on PROLOG that ran under VM) could run
under CICS but I think it was found that it needed to run in a
subsystem so that it did not lockup CICS while doing all the
processing needed to get an answer. And so this is what the Cross
Mem Charge back SMF record was created for -- reporting CPU use
and the like for handling a query in the Prolog subsystem.
So IBM PROLOG for 370 needed to use storage keys beyond Key8 for
stack/heap control. We had set up to use Key9 for our SVC as I
recall, when we were contacted and asked if we could change (this
was by CICS dev). So we did.
Alas, it appears that IBM Prolog for 370 went into the dust bin
about 1996.
I know that a large user of it was a manufacturer in Europe. They
had been using the VM version and I think they wanted an MVS
version.
Steve Thompson
On 5/3/2024 10:41 AM, Farley, Peter wrote:
I am not a CICS person, but I thought that normal transactions are discouraged
from issuing SVCs (happy to be corrected if not so).
True for original-flavor CICS transactions that run on the QR (quasi-reentrant)
TCB. Newer code designed to run on the โOpenโ TCB pool do not have that
restriction, so long as they only use CICS services that do not require the QR
TCB (and there are fewer and fewer of those as Hursley gets around to updating
them).
Peter
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Rob
Scott
Sent: Friday, May 3, 2024 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc)
Erik.
In the current implementation of the SVC that would work fine, since it is all
doing the MVC's in key 0, but if I change that to MVCSK and MVCDK instructions
I might get the 0C4 abend.
Whilst I applaud your desire to implement MVCDK/SK, I think the word "fine" is
doing some heavy lifting in the above. ๐
Using MVC in key0 to read/write non-Key0 memory is obviously a risk to system
integrity.
A couple of other minor observations :
(o) Is this SVC part of new development? If so, perhaps consider using PC-cp
instead - I am some sample code that could help in this endevour if you are
interested.
You will require a resource owning ASID to house the PC routine, but it can be
limited function in design.
(o) I am not a CICS person, but I thought that normal transactions are
discouraged from issuing SVCs (happy to be corrected if not so).
Rob Scott
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Erik Janssen
Sent: Thursday, May 2, 2024 6:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Testdriving svc in key 9 (was: finding callers key in svc)
Hello Peter,
My apologies for not changing the subject. I managed to show now that the code
in the svc is correct, it indicated that the caller was in key 9. I've solved
the testdriver issue now by marking that routine as REFReshable and put it in
SYS1.LINKLIB. I saw an old thread about this that gave this option, the module
now gets loaded into subpool 252, which is not fetch protected. I'm testing
this on a personal ZPDT machine, so in this case it is a fair way to get the
job done easily, without having to figure out how to do ATTACHX programming.
I just would like to simulate the situation where a cics transaction running in
key 9 would access a storage area it provided to the svc with key 8. In the
current implementation of the SVC that would work fine, since it is all doing
the MVC's in key 0, but if I change that to MVCSK and MVCDK instructions I
might get the 0C4 abend.
That was also where my confusion (bias) was, I was thinking (expecting) the 0C4
was triggered in the SVC, while actually it was my test program that abended on
not being able to get the next instruction from the fetch protected subpool 251
my program was loaded in.
Next stop is to see if I can get an ESTAE in the routine to give a message
about this situation and after that perhaps make it more intelligent to allow a
switch to key 8 in this situation.
I've not done a lot of assembler programming over the years, so it always takes
me some time to get used to it again, and these routines are of course not the
easiest to handle. But I like taking on such a challenge, because the amount of
stuff you learn is always very satisfying.
Kind regards,
Erik Janssen.
On Thu, 2 May 2024 14:07:25 +0000, Peter Relson <rel...@us.ibm.com> wrote:
Please try to have different threads with suitable subjects for each. The 0C4
is unrelated to the subject.
Since the code shown for the SVC routine is correct for type 2/3/4 yet you say
that you do not find the right data, then prove it:
Show the definition of the SVC, show extracts from IPCS looking at the dump
storage.
If you are blowing up at the instruction right after the SPKA to a different
key, regardless of what that instruction was, then your program is in key 8
fetch-protected storage so unless your new key is 0, you will not be able to
access the instruction. Requirements for placing a reentrant program into key 0
non-fetch-protected storage depend on authorization and various system-wide
options, along with the possibility of doing an ATTACHX with the KEY=NINE
parameter (which will place into key 0 storage without relying on
authorization).
Peter Relson
z/OS Core Technology Design
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
