IBM Mainframe Forum

Hi,

I have a simple, but hopefully not stupid question:

Is there an easy way to display the current PSW within my program? (something like "WTO PSW" )

For testing purposes I am interested how my PSW exactly looks like.

Thanks!

I don't know any "legal" way for a regular program to obtain the entire PSW. The BAL or BALR instructions can obtain the low order 32-bits, though there is one important caveat about this. To interpret this correctly you must know the current addressing mode. In the 24-bit addressing mode, the bits are arranged as follows -

0 and 1 - The instruction length code, 01 - 2 bytes, 10 - 4 bytes, 11 - 6 bytes (01 means BALR, 10 means BAL)
2 and 3 - The condition code.
5 to 8 - The program mask.
9 to 31 - The updated instruction counter.

In the 31-bit addressing mode -

0 - Always 1
1 to 31 - The updated instruction counter.

In all addressing modes you can use the IPM instruction to get the condition code and program mask, arranged in the register as in the 24-bit addressing mode. The instruction length code area will be 00, per Principles of Operation.

In all addressing modes, you can use the SPM instruction to forcibly set the condition code and program mask, though the SPIE macro provides a more "legal" way to set the program mask. IPM dates back to XA architecture, SPM was in the original System/360.

Of course you can always establish a STAE exit, force an ABEND, and get the PSW from the SDWA passed to the ESTAE exit, but I doubt that's what you had in mind.

Hello,

Try here:
http://publibz.boulder.ibm.com/epubs/pdf/dz9zr006.pdf

What i believe you are looking for is in Chapter 3. . .

Thank you both for your ideas!

@steve:
If it is really that hard to examine the PSW, the ABEND solution is indeed probably the best. Another idea could be to create a snapshot dump with the LE callable function "CEEDUMP". I don't know if this will work, but I can try it out next week.

@dick:
Yes, actually I am reading this chapter and hope to understand some things.

But at the moment, I even have too little understanding to answer myself a question like:
- Who determines the storage-key of my program?
(Actually the starting question in this thread is closely related to this: I wanted to get to know the storage key my program is running with. Afterwards, I wanted to see if the keys are different when running under IMS, TSO, Batch etc.)


I try to get a "mental picture" of how storage management, storage protection, addressing etc. works in z/OS, but I am currently at a very initial stage.

You're welcome - happy hunting

Suggest you add this to your collection of operating system links:
http://publib.boulder.ibm.com/infocente ... c18049.htm

Of early use will probably be these:
z/OS MVS Data Areas, Volumes 1–5

They contain information about "control blocks" which will be of interest to your research.

The storage key issue gets kind of complicated. The primary storage protection issue in virtual memory systems is the paging hardware and its related tables. Storage keys are important in MVS because there is so much shared storage, which really goes back to OS/360 when there was just one address space shared by all jobs and storage keys provided the protection.

In MVS, most - not all - address spaces run in storage key 8. Your job can't normally "peek" another address space because the paging tables forbid it.

Some MVS functions run with other storage keys, usually 0 through 7. JESx, for example, normally runs in key 1. This storage key is used when the function allocates storage in CSA. This is why z/OS 1.9 put in a change to prevent "problem" key users (storage keys 8 through 15) from allocating CSA storage.

Another storage protection function is low storage protect, which "protects" storage addresses from 512 through 4095 (decimal). MVS uses this storage for something which smarter people than me thought represented an integrity exposure if non-system people could read it.

Knowing your current protection key provides almost 0 knowledge; it''s almost certainly 8. Doesn't matter if it's a regular batch program, a TSO user, or an IMS batch program.

steve-myers wrote:Knowing your current protection key provides almost 0 knowledge;

You're probably right...

@dick:
I have seen most of the manuals that are linked on this page before, but most of them are quite advanced. Can you suggest manuals that expect less knowledge in advance?
A concret example: Do you know a good reference to get to know the basics about SRBs?

Thanks!

Manuals are manuals -- they are describing a certain part of the system and there's not typically any beginner set of manuals. z/OS systems can be extremely complicated, and hence the manuals have to be complicated to describe the system adequately. You might look at the IBM Redbooks to see if they can help.

There used to be a book on MVS control blocks that might be an introduction for you. Unfortunately, the book is out of print so it might not be easy to find a copy.

LotharLochkarte wrote:... I have seen most of the manuals that are linked on this page before, but most of them are quite advanced. Can you suggest manuals that expect less knowledge in advance?
A concret example: Do you know a good reference to get to know the basics about SRBs?

In 35+ years of working with MVS I've done one SRB routine, and that was nearly 30 years ago. There is essentially nothing "basic" about an SRB routine. IBM discourages people from even thinking about SRB routines these days. They are very risky, and they can be very difficult to debug. Just exactly what do you propose to do in your proposed SRB routine?

I have no concrete example in mind.

I just want to understand what is going on. For example the TIMEUSED-macro measures the amount of processor time my task has used since it was created. But activity that is done in SRB-mode is excluded in this value. So if I want to interpret the value returned by TIMEUSED, I have to know what events are not accumulated, for example I/O.

Canonical questions arise, e.g: is it useful to measure code that include database-calls with the TIMEUSED-macro?

Most of my interest aims to answer performance-related questions. I want to know how to measure performance and, as a consequence, get a feeling what really affects the performance of a assembler program.