STORAGE macro vs. GETMAIN/FREEMAIN



High Level Assembler(HLASM) for MVS & VM & VSE

STORAGE macro vs. GETMAIN/FREEMAIN

Postby steve-myers » Sat Mar 26, 2016 11:01 am

The more recent MVS versions have the STORAGE macro in addition to GETMAIN and FREEMAIN.

Some years ago, when STORAGE first appeared I experimented with it just a bit, and concluded I wasn't going to bother with it, because if STORAGE OBTAIN failed with an x78 ABEND there did not seem to any easy way to locate where in the program the STORAGE macro was located.

My question: does anyone know any justifiable reason to use STORAGE rather than GETMAIN / FREEMAIN? I looked in the manuals and didn't see anything that looked pertinent.

Let me rephrase the question.

Does anyone know any justifiable reason to use STORAGE OBTAIN rather than GETMAIN RU/RUC/VRU/VRC?
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Re: STORAGE macro vs. GETMAIN/FREEMAIN

Postby Philippe Leite » Mon May 23, 2016 9:22 pm

STORAGE OBTAIN/RELEASE macro expansion uses PC(Program Call) instead of SVC on GETMAIN/FREEMAIN.
From the Operating system perspective, a PC instruction is much more efficient than a SVC interruption.


Regards.
Regards,

Philippe Leite
z/OS System Programmer
Philippe Leite
 
Posts: 2
Joined: Mon May 23, 2016 9:16 pm
Has thanked: 0 time
Been thanked: 0 time

Re: STORAGE macro vs. GETMAIN/FREEMAIN

Postby steve-myers » Mon May 23, 2016 10:29 pm

Philippe Leite wrote:STORAGE OBTAIN/RELEASE macro expansion uses PC(Program Call) instead of SVC on GETMAIN/FREEMAIN.
From the Operating system perspective, a PC instruction is much more efficient than a SVC interruption.


Regards.

That's the official party line, but when I ran some tests, STORAGE used much more charged CPU time than GETMAIN/FREEMAIN for the identical storage mapping.

No matter how you look at it MVS GETMAIN/FREEMAIN/STORAGE resource utilization is awful. Trying to paint the corpse by using PC rather than SVC doesn't hide the decay!

Compare -
T20100   STORAGE OBTAIN,LENGTH=(3)
+T20100   DS     0H                
+         CNOP   0,4              
+         B      IHB0033B          
+IHB0033F DC     BL1'00000000'    
+         DC     AL1(0*16)        
+         DC     AL1(0)            
+         DC     BL1'00000010'    
+IHB0033B DS     0F                
+         LR     0,3              
+         L      15,IHB0033F      
+         L      14,16(0,0)        
+         L      14,772(14,0)      
+         L      14,160(14,0)      
+         PC     0(14)            
with
T10100   GETMAIN RU,LV=(3)  
+         CNOP  0,4          
+T10100   B     IHB0021C    
+IHB0021F DC    BL1'00000000'
+         DC    AL1(0)      
+         DC    AL1(0)      
+         DC    BL1'00000010'
+IHB0021C DS     0H          
+         LR    0,3          
+         L     15,IHB0021F  
+         SR    1,1          
+         SVC   120          
Part of the trouble is with this sequence -

L 14,16(0,0)
L 14,772(14,0)
L 14,160(14,0)

The storage at address 16 may be in the storage cache. The storage for the other two instructions is unlikely to be in the storage cache, which means lots of hardware wait states fetching the data.

When I first looked at the setup for the PC instruction, I admired the generality of the concept rather than having fixed LX/EX data, without fully understanding the performance implication. Now I think about how slow storage is compared with the storage cache and the instruction rate.

Either this -

LHI 14,X'030B'

or

BAS 14,*+L'*+4
DC AL4(X'030B')
L 14,0(,14)

would be much faster, but then the LX/EX would be fixed.
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times


Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post