IBM Mainframe Forum

Hello Experts,

I have the below code in one of the existing program.

Here in the SRL instruction,the operand 2 is *-*  .Can someone help me understand what this is and how the shift factor is calculated in this case ?

Also can you please explain SHIFTCT  EQU   *-1 ?




Thanks

In Assembler code, when you see * in an expression, the * is a short cut that says to the Assembler insert the current value of the location counter. So *-* is the location counter, whatever it is minus the location counter, or 0. Many Assembler programmers use *-* to mark a storage area that will be filled in during execution.

Now, if you think about the definition of *, you can figure out all by your self what SHIFTCT EQU *-1 in the code fragment means. How *-* came to mean this data area is to contain data that will be filled in during execution can't be conclusively known; what follows is the opinion of a dinosaur that is not yet extinct. The Assembler programs for the 704/709/7090/7094/7040/7044 series of computers from the 1950s to the early 1960s calculated ** as the location counter (the first *) times (the second *) 0 (the missing second operand for the multiply), so if you would often see

TRA **

TRA is TRAnsfer execution to an address that will be filled in later. Many early System/360 programmers came from 704x/709x computers. When they tried using ** the System/360 Assemblers would not take **, so they substituted *-* for **. I first encountered *-* in HASP for OS/360. The people that wrote HASP came from the 704x/709x tradition, and used 704x/709x methods where they were possible. Once I figured out what Simpson and Crabtree (the programmers that wrote HASP) were thinking I, too, adopted *-* for its currently accepted meaning.

The Shift Factor

Now the shift factor. This has always seemed somewhat odd to me, but it provides a method for a variable shift amount without resorting to the store instruction in the program fragment. For the whole story, please go to the discussion of SRL and SRLG in Principles of Operation. You'll notice the shift amount is determined by performing address arithmetic on the base/displacement in the instruction. Most of the time the address arithmetic just uses the displacement with "base register" 0, which really means 0 for the value from the base register. In other SRL reg,5 uses 5 as the shift amount, but SRL reg,0(6) effectively takes the shift amount from register 6. Do not forget to apply "... the second-operand address is not used to address data; its rightmost six bits indicate the number of bit positions to be shifted. The remainder of the address is ignored."

Now, given all that, you can determine the actual shift amount. It might surprise you. I know what it is, but I ain't tellin'.

These users thanked the author steve-myers for the post:

ramkumar1992sp (Thu Jan 19, 2017 2:49 am)

Hi Steve,

Thanks for the detailed response and the history.I ended up googling about 'HASP' and got this link.Thought of sharing it.

http://www.share.org/p/bl/et/blogaid=238


Now coming back to my code fragment,below is what I think.

*-* would give location counter minus location counter,so

SRL R6,*-* is equivalent to SRL R6,0.

SHIFTCT EQU *-1 would mean current location counter minus 1 byte ,so that would point to *-* in the previous SRL R6,*-* .

I'm still thinking about the whole purpose of doing this.But can you please correct me if I got it wrong ?


Thanks

ramkumar1992sp wrote:... *-* would give location counter minus location counter,so

SRL R6,*-* is equivalent to SRL R6,0.

Yes.

ramkumar1992sp wrote:...SHIFTCT EQU *-1 would mean current location counter minus 1 byte ,so that would point to *-* in the previous SRL R6,*-* ...

I think you've almost got it, but not quite. hint: *-* in the instruction is 2 bytes: the first 4 bits specify a base register, which is 0 because no base register is specified, and the remaining 12 bits specify a nominal displacement value. The STC instruction is not altering the nominal base register.

ramkumar1992sp wrote:... I'm still thinking about the whole purpose of doing this. ...

Well, for what it's worth, I am too. I thought of starting my comments with, "This makes absolutely no sense to me ..."

Altering the instruction stream, the STC R7,SHIFTCT/SRL R6,*-*/SHIFTCT EQU *-1 was very common in the 704/709/7090/7040 days, but it is considered poor practice these days. HASP for OS/360 used code like STC reg,*+L'*+1/MVC xxx(*-*),xxx to replace the length attribute in the second byte of the instruction quite often. In HASP 4 for OS/VS2 Release 1 most, probably all, of this was replaced with EX reg,yyy/.../yyy MVC xxx(*-*),xxx.

I read through the HASP link you provided. Some of the dates are wrong, but most of the rest is pretty good.

The first shared SPOOL was for HASP for OS/360 at the National Institutes of Health. I never ran it, though there was interest in it where I worked in the early 1970s; it conflicted with some pretty junky HASP changes to support some pretty junky hardware we had installed. People at Mellon Bank produced shared SPOOL for HASP 4 for OS/VS2 Release 1 and still add enhancements. When it was time to go to HASP 4 the powers to be had gotten rid of the junky hardware, so we went directly to HASP 4 with the Mellon shared SPOOL.

NJE has a more complex history than indicated in your link. ASP, at one time, had an NJE like function, and it was terrible. The ASP at each side had to be at exactly the same version and release. As indicated in your link, Triangle Universities in North Carolina had an NJE like network, though I don't know many details.

VM/370, possibly in the CP67 days, had taken the RJE code from HASP and it became the basis for what is still called RSCS. VM/370 was wildly popular within IBM, and a capability to do VM/370 RSCS <-> VM/370 RSCS had been done. They decided to minimize release to release dependencies by transmitting data elements called network job headers and network SYSOUT headers to exchange queuing data that are translated to the actual system/release dependent queuing data at each end. These headers were designed so they could easily be extended. NJE for JES2 just took the RSCS scheme and added some significant extensions so that JES2 could join the IBM VM/370 network. Prior to the internet this was the largest network in the world!

Well, enough of my memories, such as they are. I have to go, so I'll send this off.

These users thanked the author steve-myers for the post:

ramkumar1992sp (Thu Jan 19, 2017 2:49 am)

Thanks Steve for the help.

I'm not sure what exactly is going on.But this is what I think its doing..

It looks like SHIFTCT EQU *-1 will alter the SRL instruction to SRL R6,SHIFTCT. Now since we have STC R7,SHIFTCT as the prior instruction,the SRL instruction would mean contents of R6 will shifted to the left depending on the value in its rightmost 6 bits of SHIFTCT.

Suppose R7 had 00000000 00000000 00000000 00000101

Then STC R7,SHIFTCT would mean that SHIFTCT would have 00000101 00000000 00000000 00000000.

After this I m not sure what SRL R6,*-* would mean ,as the rightmost 6 bits of SHIFTCT are zeroes.

Can you please help ?


Thanks

SHIFTCT specifies the address of one byte of storage, as it happens, the last byte of the SRL 6,*-* instruction. The STC R7,SHIFTCT instruction stores the contents of register 7 into SHIFTCT, so the contents of the low order 8 bits of register 7 become the shift amount.

Now, is there any difference in the effect on register 6 between SRL R6,0(R7) and STC R7,*+4+3/SRL R6,*-*? These two instructions are essentially the same as the two instruction we have been talking about, with the confusing SHIFTCT label removed. Assembler code purists don't like to see constructs like *+4+3 in Assembler code for roughly 2 reasons. First, it's as confusing as the definition of the SHIFTCT label, and it depends on the actual lengths of both instructions.

These users thanked the author steve-myers for the post:

ramkumar1992sp (Thu Jan 19, 2017 8:23 pm)

Thank you Steve.