IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

HLASM WTO Mechanics


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Catz

New User


Joined: 22 May 2015
Posts: 6
Location: Latvia

PostPosted: Mon Jul 20, 2015 3:52 pm
Reply with quote

Good day. Id like to ask a question on one detail regarding WTO function:

For example we have something along the lines of:

SOMLBL CLC SOMETHNG,=X'FF'
//Store regs
WTO MF=(E,MYMSG)
//Load regs
BE LBL2
...

I've observed the branch behaving differently if the WTO is placed after comparison. I understand WTO is an SVC request. That
is, it is an interrupt, which should preserve the original PSW. But I have no other explanation to the change in the behavior, but
modification to condition code..
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Mon Jul 20, 2015 5:10 pm
Reply with quote

You are correct in your observation that the WTO macro invokes an SVC.

However -

The CLC instruction updates an internal (to the hardware) two bit register called the condition code. Many other instructions also update the condition code. In theory, since the condition code is part of the PSW, the interrupt generated by the SVC instruction should preserve the condition code. I've never tried to observe if this is correct. I just go by the rule that all macros destroy the condition code, usually because most macros have other instructions. The WTO in your code fragment, for example, generates

LA 1,MYMSG
SVC 35

The LA instruction does not alter the condition code.

Two more observations.
  1. Your one byte CLC would be better coded using the CLI instruction.
    • CLI is a 4 byte instruction, CLC is a 6 byte instruction.
    • The =X'FF' in your CLC references storage. The X'FF' in the equivalent CLI is part of the instruction. Assembler programmers try to avoid unnecessary storage references. The hardware design engineers have finally deduced this is good; we see many newer instruction introduce data as part of the instruction. CLI, on the other hand, has been in the hardware since System/360.
  2. Registers 2 through 13 are generally not altered by any IBM macro; it is not necessary to save and restore them yourself. On the other hand, registers 0, 1, 14 and 15 are altered by most IBM macros. As noted before, the macro code in WTO alters register 1, and MVS Programming: Assembler Services clearly states registers 0, 1, 14 and 15 are altered somewhere in WTO macro processing.
Back to top
View user's profile Send private message
Catz

New User


Joined: 22 May 2015
Posts: 6
Location: Latvia

PostPosted: Tue Jul 21, 2015 11:45 am
Reply with quote

Thank you for your points - there is really no need to unnecessarily bloat literal pool or text, that example was
sloppy. What document better explains the interrupt mechanics on zOS? I've been mostly reading Operation
Basics so far, then there is also Systems Programming redbook. What sources would you recommend?
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Tue Jul 21, 2015 4:29 pm
Reply with quote

Technically, Principles of Operation, but its very hard going and it's incomplete as it does not discuss what happens after the interrupt completes as that's not hardware, it's software. Here is a summary for an SVC interrupt.
  1. The current PSW is stored at a fixed location in the PSA.
  2. A new PSW is loaded from a different, fixed location in the PSA. This PSW starts executing a nucleus routine called a FLIH (First Level Interrupt Handler). The SVC FLIH saves the registers, saves the interrupt PSW, retrieves the interrupt code (the code from the SVC instruction), uses the interrupt code to retrieve additional information about the requested SVC from the SVC table, and runs the code for the SVC. After the SVC routine completes, the SVC FLIH restores the registers and resumes the program.
It's actually more complex than that, but that's a pretty good very high level summary. I wanted to retrieve more info, but as I'm writing this the IBM manuals web page appeared to be broken.
Back to top
View user's profile Send private message
Catz

New User


Joined: 22 May 2015
Posts: 6
Location: Latvia

PostPosted: Wed Jul 22, 2015 3:08 pm
Reply with quote

Thank you. It seems the general idea is not different from that other architectures are using. Its all in the details.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Sat Jul 25, 2015 9:45 pm
Reply with quote

Catz wrote:
Thank you for your points - there is really no need to unnecessarily bloat literal pool or text, that example was
sloppy. ...
Personally, I won't comment on "bloating" the literal pool. I better not, since I'm often guilty of doing just that! But a storage reference is another matter. It can be very expensive. In the early 1980s I developed a performance analyzer targeted at JES2. One thing the analyzer did was note JES2 waits caused by a page fault. There were very few, but one that did stand out was one instruction in HASPPRPU that looked at one byte in a JES2 control area called a DCT. This single instruction dominated JES2 page faults! Now, by definition, PRPU is going to be using DCTs since DCTs are used to define JES2 devices like printers, though it took some research to figure out why it was getting a page fault at this one location for just the one byte. PRPU was looking at a DCT it was actively using when it executed the instruction; it was fully justified in checking the byte, but it was not using the DCT often enough to prevent MVS from paging it out. The immediate solution was a local user mod to copy the one byte to storage less likely to be paged out before effectively releasing its use of the DCT storage.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> PL/I & Assembler

 


Similar Topics
Topic Forum Replies
No new posts Injecting HTTPHEADER parameters in th... PL/I & Assembler 0
No new posts HLASM bug PL/I & Assembler 2
No new posts How to recall (or wait for recall of)... PL/I & Assembler 4
No new posts Call HLASM from Java directly PL/I & Assembler 1
No new posts Biggner to MVS HLASM - Need Good Book... PL/I & Assembler 4
Search our Forums:

Back to Top