Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

HLASM WTO Mechanics

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
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    Post subject: HLASM WTO Mechanics
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 User


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

PostPosted: Mon Jul 20, 2015 5:10 pm    Post subject:
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    Post subject:
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 User


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

PostPosted: Tue Jul 21, 2015 4:29 pm    Post subject:
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    Post subject:
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 User


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

PostPosted: Sat Jul 25, 2015 9:45 pm    Post subject:
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    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts How to recall (or wait for recall of)... JPVRoff PL/I & Assembler 4 Wed Feb 18, 2015 9:19 am
No new posts Call HLASM from Java directly k_v_mahesh PL/I & Assembler 1 Tue May 06, 2014 6:58 pm
No new posts Biggner to MVS HLASM - Need Good Book... dick scherrer PL/I & Assembler 4 Mon Jul 11, 2011 8:11 am
No new posts Comparison of COBOL, C and HLASM aravindanrkumar PL/I & Assembler 1 Fri Jan 11, 2008 2:56 pm
No new posts difference between HLASM and TPF Asse... alokagarwaljgd PL/I & Assembler 2 Thu Oct 11, 2007 2:33 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us