Program Call Vs SVC

[Jake anderson]

Hello All,

I am new to this I have noticed some of the product which I have started
installing it does not need a SVC instead they have started to work with PC.

Are there any advantage of moving over to PC(program calls) as compared to
SVC ? Any idea why Product developers have opted to use PC ?

Here I am just trying to understand the importance of PC replacing SVC.


Jake

[Binyamin Dissen]

On Tue, 20 May 2014 13:24:53 +0530 Jake anderson <justmai...@gmail.com>
wrote:

:>I am new to this I have noticed some of the product which I have started

:>installing it does not need a SVC instead they have started to work with PC.

:>Are there any advantage of moving over to PC(program calls) as compared to
:>SVC ? Any idea why Product developers have opted to use PC ?

There are limited numbers of SVCs shared by everyone. There are so many more
PC numbers available.

:>Here I am just trying to understand the importance of PC replacing SVC.

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

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Rob Scott]

There is also much more flexibility and environmental choice available to a software product that uses PC routines instead of an SVC.

Some of the benefits I can think of include :

PC routines can be defined to

(o) Run in a specific execution key
(o) Run with a specific cross-memory environment enabling easy client/server architecture exploitation
(o) Only be available to a subset of address spaces in the system

PC routines can (if coded correctly)
(o) Run in SRB mode
(o) Be dynamically inserted and removed from the system safely
(o) Reside in private storage


As a user of software, you should welcome the fact that the product has converted from SVC to PC.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

[John Gilmore]

Rob Scott's summary of the current situation would be hard to improve upon.

There are situations in which it is appropriate to maintain and even
perhaps extend existing SVC routines. They will not disappear anytime
soon, but they are at best obsolescent. New developments should,
however, avoid them, employing PC routines instead.

--
John Gilmore, Ashland, MA 01721 - USA

[Jon Perryman]

[Jon Perryman]

Sorry for the blank post. Trigger finger was too fast.

Other things I also like about PC routines:
1. SVC module must be in LPA. PC can be dynamically added (one less step for the customer)..
2. PC routines are replaceable.You can easily update it without an IPL or dynamic SVC module.
3. You may easily have multiple PC's for running multiple version of your product.

Jon Perryman

[Farley, Peter x23353]

PC routines are good; OK, I can accept that. But where are the substantial examples of how to properly set up and use them, showing all of the benefits Rob Scott listed below and the other sterling attributes of PC routines which have been mentioned here in the past?

I know that ISV's cannot (and should not) reveal proprietary code, but perhaps a generalized example (with set up instructions, please!) of some simple function (an adding machine example comes to mind) from experienced developers on this list would help to train the rest of us in how to use this facility correctly and effectively.

The CBT index (File 001) is not entirely useful in searching for such examples. Does anyone here know if the CBT collection has a substantial example (or any example at all) of code using PC?

Peter

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Rob Scott
Sent: Tuesday, May 20, 2014 5:59 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Program Call Vs SVC

There is also much more flexibility and environmental choice available to a software product that uses PC routines instead of an SVC.

Some of the benefits I can think of include :

PC routines can be defined to

(o) Run in a specific execution key
(o) Run with a specific cross-memory environment enabling easy client/server architecture exploitation
(o) Only be available to a subset of address spaces in the system

PC routines can (if coded correctly)
(o) Run in SRB mode
(o) Be dynamically inserted and removed from the system safely
(o) Reside in private storage

--

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.

[Rob Scott]

My colleague Bob Shannon gave a "PC Routines For Dummies" presentation back in the late 1990s that contains example code and explanations of all the major components involved.

Google confirms that it can still be found on the web.

The presentation was written before ASID and LX reuse, so bear that in mind when reading it and composing your own code.

It is well worth a read for someone starting out in this area.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

[DASDBILL2]

Try the SHARE archives.  Look for sessions done by Joel Sarch, in which he explained all this in 3 consecutive sessions at multiple consecutive SHARES in the late 1980s.  I don't remember if he had sample code in his handouts/slides or not.
Bill Fairchild

----- Original Message -----

[John Gilmore]

Institutional inertia is a problem in most mainframe shops. The
PC-based machinery that made SVCs obsolescent is now, however, more
than twenty years old.

It is time, and long past time, that ab-initio code use this 'new'
machinery instead of SVCs. By all means consult the SHARE archives;
but it is even more important that you write some code and yourself
work through the difficulties that will, I suppose inevitably, arise
as you test it. Even in the short term you will find the experience
liberating. There is much less now irrelevant historical baggage to
carry forward with you.

[Tony Thigpen]

Just wondering.
What hardware first supported PCs?

Tony Thigpen

[Binyamin Dissen]

Software was MVS/SP 1.3

Perhaps a 3081?

On Wed, 21 May 2014 10:56:58 -0400 Tony Thigpen <to...@vse2pdf.com> wrote:

:>Just wondering.

:>>
:>>

[Jim Mulder]

> Just wondering.
> What hardware first supported PCs?

The 3033 (via a microcode upgrade) was the first processor
to support the 370 cross memory architecture, including the
PC instruction. This architecture was first used by
MVS SP1.2 (which never became generally available) and SP1.3.
These releases included a cross memory architecture simulator
in the program check interrupt handler so that they could run
on older machines which did not support this architecture.

Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY

[Farley, Peter x23353]

Thanks Rob, I found that one. I'll use it to start curing my ignorance.

But my question still stands: Does anyone know if CBT (or any other source) has examples of programming on z hardware with PC?

IMHO at least one such example ought to be in Appendix A of the POP, but I know it probably never will be.

Maybe there is a redbook/redpiece? I should go look there.

[Rob Scott]

Peter,

Maybe part of the reason that there is not a lot of example source is that a responsible PC routine provider must establish quite a bit of plumbing to ensure system and application integrity that goes beyond just using the ETDEF and LXRES macro services.

This is especially true for PC space-switch routines (PC-ss) rather than simple current primary (PC-cp).

I suppose a PC-cp could be written to replace a SVC routine more easily than composing a PC-ss to perform some sort of client/server application request (which is the interesting stuff!)

IMHO a person embarking on writing a PC routine should be armed with at least the following :

(o) Knowledge of how to safely move data between client and server without breaking system integrity. There are so many bad examples of supervisor/key0 code out there in the public domain that just copy data without any due care and attention. Just because your code is in key0 and it is easy to use MVC to return data to your caller not matter the key does not mean that you should. A decent PC routine is always transferring data to and from the caller in the execution key of the caller.

In fact, I recommend a PPT entry in SCHEDxx to declare your server jobstep program to execute in a non-zero system key - key 2 and 4 are currently seen to be available in so much as there is no major z/OS system component famously using them. (1 = JES, 3 =AVM,5=DFP,6=VTAM, 7=DB2, IMS and MQ)

(o) A method to issue messages, diagnostics and trace events in H<>P<>S environments and other exotic environments

(o) The habit of checking the "Environment" section of any service that they call - now that your code could be running H<>P<>S or locked, some of your favourite services may no longer be available to you.

(o) A method to add request blocks onto a queue in server private - for example something using PLO (there have been discussions about this on IBM-Main)

(o) Familiarity with SUSPEND/RESUME services so that you caller's request can be handled asynchronously

(o) Task and ASID level resource manager routines to handle both "client gone while SUSPENDed" and "server gone unexpectedly" situations

(o) Decent recovery routine(s) for ESTAE, FRR and ARR environments

I do not believe that it is very common these days for anyone working outside of IBM or an ISV to have the sort of skills or experience of all of the above.
It is probably even rarer to find someone in a sysprog team who you can go to for local help if you are writing this stuff - things were different back in the 1980s when sysprog teams were larger and assembler knowledge widespread.

If you do have a test system to play on and blessing from your employer, I would recommend that you give it a go.

There are people on this list (or maybe even better on IBM-Main) who can help when you hit problems.

[Binyamin Dissen]

On Thu, 22 May 2014 10:26:21 +0000 Rob Scott <rsc...@rocketsoftware.com>
wrote:

:>Maybe part of the reason that there is not a lot of example source is that a responsible PC routine provider must establish quite a bit of plumbing to ensure system and application integrity that goes beyond just using the ETDEF and LXRES macro services.

:>This is especially true for PC space-switch routines (PC-ss) rather than simple current primary (PC-cp).

:>I suppose a PC-cp could be written to replace a SVC routine more easily than composing a PC-ss to perform some sort of client/server application request (which is the interesting stuff!)

:>IMHO a person embarking on writing a PC routine should be armed with at least the following :

:>(o) Knowledge of how to safely move data between client and server without breaking system integrity. There are so many bad examples of supervisor/key0 code out there in the public domain that just copy data without any due care and attention. Just because your code is in key0 and it is easy to use MVC to return data to your caller not matter the key does not mean that you should. A decent PC routine is always transferring data to and from the caller in the execution key of the caller.

Similar to SVC logic

:>In fact, I recommend a PPT entry in SCHEDxx to declare your server jobstep program to execute in a non-zero system key - key 2 and 4 are currently seen to be available in so much as there is no major z/OS system component famously using them. (1 = JES, 3 =AVM,5=DFP,6=VTAM, 7=DB2, IMS and MQ)

What is the advantage? What is wrong with the standard key8? The (E)CSA
resident blocks do not gain from the PPT entry and the server blocks are not
available to the client code.

:>(o) A method to issue messages, diagnostics and trace events in H<>P<>S environments and other exotic environments

:>(o) The habit of checking the "Environment" section of any service that they call - now that your code could be running H<>P<>S or locked, some of your favourite services may no longer be available to you.

In general, unless you are front ending a system service, you know your
environment.

But if XMEM, certain locks will block other locks,

:>(o) A method to add request blocks onto a queue in server private - for example something using PLO (there have been discussions about this on IBM-Main)

:>(o) Familiarity with SUSPEND/RESUME services so that you caller's request can be handled asynchronously

WAIT is also available. And latches.

:>(o) Task and ASID level resource manager routines to handle both "client gone while SUSPENDed" and "server gone unexpectedly" situations

As well as checking that the server is up before issuing the PC.

:>(o) Decent recovery routine(s) for ESTAE, FRR and ARR environments

:>I do not believe that it is very common these days for anyone working outside of IBM or an ISV to have the sort of skills or experience of all of the above.
:>It is probably even rarer to find someone in a sysprog team who you can go to for local help if you are writing this stuff - things were different back in the 1980s when sysprog teams were larger and assembler knowledge widespread.

:>If you do have a test system to play on and blessing from your employer, I would recommend that you give it a go.

:>There are people on this list (or maybe even better on IBM-Main) who can help when you hit problems.

[ess...@juno.com]

Rob Scott wrote

> Task and ASID level resource manager routines to handle >both "client gone while SUSPENDed" and "server gone >unexpectedly" situations

.
.
Rob could you elaborate on the bullet above ...
Are You suggesting that the PC Service Provider be notified when
the client has abended while it (client) is suspended ??

Paul D'Angelo

---------- Original Message ----------
From: Rob Scott <rsc...@rocketsoftware.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Program Call Vs SVC

Date: Thu, 22 May 2014 10:26:21 +0000

Peter,

Maybe part of the reason that there is not a lot of example source is that a responsible PC routine provider must establish quite a bit of plumbing to ensure system and application integrity that goes beyond just using the ETDEF and LXRES macro services.

This is especially true for PC space-switch routines (PC-ss) rather than simple current primary (PC-cp).

I suppose a PC-cp could be written to replace a SVC routine more easily than composing a PC-ss to perform some sort of client/server application request (which is the interesting stuff!)

IMHO a person embarking on writing a PC routine should be armed with at least the following :

(o) Knowledge of how to safely move data between client and server without breaking system integrity. There are so many bad examples of supervisor/key0 code out there in the public domain that just copy data without any due care and attention. Just because your code is in key0 and it is easy to use MVC to return data to your caller not matter the key does not mean that you should. A decent PC routine is always transferring data to and from the caller in the execution key of the caller.

In fact, I recommend a PPT entry in SCHEDxx to declare your server jobstep program to execute in a non-zero system key - key 2 and 4 are currently seen to be available in so much as there is no major z/OS system component famously using them. (1 = JES, 3 =AVM,5=DFP,6=VTAM, 7=DB2, IMS and MQ)

(o) A method to issue messages, diagnostics and trace events in H<>P<>S environments and other exotic environments

(o) The habit of checking the "Environment" section of any service that they call - now that your code could be running H<>P<>S or locked, some of your favourite services may no longer be available to you.

(o) A method to add request blocks onto a queue in server private - for example something using PLO (there have been discussions about this on IBM-Main)

(o) Familiarity with SUSPEND/RESUME services so that you caller's request can be handled asynchronously

(o) Task and ASID level resource manager routines to handle both "client gone while SUSPENDed" and "server gone unexpectedly" situations

(o) Decent recovery routine(s) for ESTAE, FRR and ARR environments

I do not believe that it is very common these days for anyone working outside of IBM or an ISV to have the sort of skills or experience of all of the above.
It is probably even rarer to find someone in a sysprog team who you can go to for local help if you are writing this stuff - things were different back in the 1980s when sysprog teams were larger and assembler knowledge widespread.

If you do have a test system to play on and blessing from your employer, I would recommend that you give it a go.

There are people on this list (or maybe even better on IBM-Main) who can help when you hit problems.

[Rob Scott]

Yes

It is very possible that the client request has caused the server to allocate resources and if the caller goes away while SUSPENDed - maybe by an operator CANCEL - then it is preferable to have a way that the server can be informed.

The way that I have accomplished this in the past is for the task level resource manager routine to PC-ss back into the server address space and add a "TCB gone" request block onto a special queue in the server private. This "TCB Gone" request would include the ASID and TCB of the caller so that the server can remove any outstanding requests that match and cleanup any associated resources obtained on its behalf.

[Tom Marchant]

On Wed, 21 May 2014 17:13:35 -0400, Farley, Peter x23353 wrote:

>Maybe there is a redbook/redpiece? I should go look there.

You might want to read the section on Synchronous Cross Memory
Communication in the Extended Addressability Guide.

--
Tom Marchant

[Rob Scott]

> What is the advantage? What is wrong with the standard key8? The (E)CSA resident blocks do not gain from the PPT entry and the server blocks are not available to the client code.

A lot of the system services invoked by software that I have written require PKM 0-7.

I try to avoid key-switching as much as possible - having a software product with a E(CSA) anchor block in key 0-7 and then executing in key8 means that every time you want to change something in the anchor you have to switch keys. Some products approach this issue by running in Key0 all the time - personally, I think the risk of unintentional storage overlays make this an uncomfortable solution.

If your server program runs in, for example, key2 - then :

(o) You can keep key-switching to a minimum
(o) The anchor block in (E)CSA can be in the same key2
(o) The server programs private storage is in key2
(o) The chances of your server code overlaying storage is drastically reduced.
(o) Other minor advantages when looking at dumps and diagnostics is that storage owned by your server code is much easier to spot and QA for storage leak analysis.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Binyamin Dissen
Sent: 22 May 2014 11:54
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Program Call Vs SVC

[John McKown]

On Thu, May 22, 2014 at 7:50 AM, Rob Scott <rsc...@rocketsoftware.com>wrote:

> > What is the advantage? What is wrong with the standard key8? The (E)CSA
> resident blocks do not gain from the PPT entry and the server blocks are
> not available to the client code.
>
> A lot of the system services invoked by software that I have written
> require PKM 0-7.
>
> I try to avoid key-switching as much as possible - having a software
> product with a E(CSA) anchor block in key 0-7 and then executing in key8
> means that every time you want to change something in the anchor you have
> to switch keys. Some products approach this issue by running in Key0 all
> the time - personally, I think the risk of unintentional storage overlays
> make this an uncomfortable solution.
>

Why not use MVCDK to update the non-key8 storage?

>
> If your server program runs in, for example, key2 - then :
>
> (o) You can keep key-switching to a minimum
> (o) The anchor block in (E)CSA can be in the same key2
> (o) The server programs private storage is in key2
> (o) The chances of your server code overlaying storage is drastically
> reduced.
> (o) Other minor advantages when looking at dumps and diagnostics is that
> storage owned by your server code is much easier to spot and QA for storage
> leak analysis.
>

I especially agree with the last two. And I'll add one more. If the data
might contain "confidential" information, such as passwords or "keys", then
you can make your (E)CSA fetch protected to decrease the likelihood of them
being disclosed.

>
>
> Rob Scott
> Lead Developer
> Rocket Software
>

--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

[Rob Scott]

> Why not use MVCDK to update the non-key8 storage?

That is fine for fields where you are replacing the entire contents - but how about an individual bit in a status byte for example where normally you would use OI/NI or OIL/NIL ?

Rob Scott
Lead Developer
Rocket Software

77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of John McKown
Sent: 22 May 2014 14:12
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Program Call Vs SVC

[John Gilmore]

These are mostly matters of taste and style; and arguments about taste
and style, while they are often diverting and have the merit that
anyone, however ignorant, can participate in them, are never very
productive.

There are many ways to do these things. What is important is to
choose a viable scheme and then to use it consistently.

That said, John McKown's point about the MCDK instruction is
important; it is too little used.

I will make another point that is all but predictable coming from me.
The housekeeping functions Rob Scott enumerated need to be done well,
but in practice they are less onerous than any list of them makes
them seem. They can be embodied in reusable parameterized macros, and
doing so is 1) time-saving 2) much less error-prone than rewritten,
i.e., copied, code.

[John McKown]

On Thu, May 22, 2014 at 8:32 AM, Rob Scott <rsc...@rocketsoftware.com>wrote:

> > Why not use MVCDK to update the non-key8 storage?
>
> That is fine for fields where you are replacing the entire contents - but
> how about an individual bit in a status byte for example where normally you
> would use OI/NI or OIL/NIL ?
>

Good point. The only way that I can think of would be some sort of
serialization to allow the field to be moved, with MVCSK to a key 8 area,
update it, then MVCDK back. But that is likely way too much overhead. Doing
a couple of SPKA instructions to change to key 2, update, change back to
key 8 would likely be simpler. Or, even simplier, just run your server in
key 2, exactly as you said to begin with. I guess you use the PPT to assign
key 2 to your server's program and running it as a single step STC.

[Rob Scott]

John

No need for it to be a single step STC - in fact during QA and testing it is quite common for me to front-end my server program STC JCL with a one or more "primer" steps.

The PPT properties are assigned to the jobstep program.

BTW - I make extensive use of MVCDK and MVCSK to pass data between caller and server - they are just hidden inside product macros.

Rob Scott
Lead Developer
Rocket Software

77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of John McKown
Sent: 22 May 2014 14:59
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Program Call Vs SVC

[John Gilmore]

About use of the MVCDK instruction Rob Scott writes:

<begin extract>

That is fine for fields where you are replacing the entire contents -
but how about an individual bit in a status byte for example where
normally you would use OI/NI or OIL/NIL ?

</end extract>

and I am not persuaded. Here 'field' means addressable unit of
storage, i.e., byte. In resetting a bit one can ordinarily---in my
experience always---calculate the new containing-byte value painlessly
and then replace it as a unit. Moreover, one usually wishes to avoid
moot operations of this kind (or at least to distinguish moot and
non-moot ones).

That said, Rob's posts in this thread have been particularly valuable;
and I would not want this nit picking to suggest that I think
otherwise.

[Ed Jaffe]

On 5/22/2014 3:26 AM, Rob Scott wrote:
> In fact, I recommend a PPT entry in SCHEDxx to declare your server jobstep program to execute in a non-zero system key - key 2 and 4 are currently seen to be available in so much as there is no major z/OS system component famously using them. (1 = JES, 3 =AVM,5=DFP,6=VTAM, 7=DB2, IMS and MQ)

I agree 100% with this recommendation. Privileged key programming is so
much more convenient when TCBPKF is properly established. Otherwise,
execution key must be changed at entry to the program and every
GETMAIN/STORAGE OBTAIN must be coded to explicitly specify subpool/key.
A complicating factor is that such overrides are not always possible for
embedded routines. In short, without PPT help, it's a mess.

Ignorance is probably the chief reason why PPT entries are not used as
often as they should be. Also, once the truth is realized, it can be
difficult (i.e., expensive) to convert a program that has already been
written without proper PPT setup. I also think some PPT avoidance is
deliberate - the result of a desire for fewer installation steps or
dependencies on customer-specified system options.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Tony Harminc]

On 22 May 2014 06:53, Binyamin Dissen <bdi...@dissensoftware.com> wrote:
> :>(o) Familiarity with SUSPEND/RESUME services so that you caller's request can be handled asynchronously
>
> WAIT is also available. And latches.

But sadly, STIMER[M] is not. Yes, it can be worked around, though not
without difficulty. It seems strange that the surely very common
paradigm of waiting for the first of (an event or a fail-safe timer)
is not easily available. All it would take is STIMER[M]
LINKAGE=SYSTEM. Easy for me to say, of course.

Tony H..