IBM Mainframe Forum

The following program actually works. The web site will not display the program correctly in the code block. Internet Explorer appears to do better than Firefox or Chrome, but better is a matter of degree. You might click on the Quote block, and copy the program to a Notepad window if your workstation is running Windows. or something similar if your workstation is running Linux. I'm hopeful someone will attempt to answer some of the questions. One of the questions requires some knowledge of the internals of how MVS operates and is probably beyond the scope of knowledge of most of the people in this forum, but I can hope. In a few days I will post the answers.

1. Why does AP SAVETIME(8),=P'1900000' work?
2. What is the purpose of the following code?
   Select all

            ORG   EDITTIME+C'0'
            ORG   ,
3. Why do this complicated business with STIMER and WAIT when STIMER WAIT is much simpler?
4. If you understand the answer to the first question, this one is real easy: why does the edit mask work?
5. The "main" program does not obtain a new save area, yet the contents of the original save area are not damaged. Why does the system work this way?
6. This one is the hardest. This code looks like a subroutine. It is clearly destroying registers 2 and 3 before it returns, but it runs correctly. Why?
   Select all

            USING *,2
   ITIMEUP  LR    2,15
            LR    3,14
            POST  ECB,0
            BR    3

at a quick glance at the ORG EDITTIME+C'0' it looks like it is putting a leading 0 in the &sysdate field

will look at the rest on Monday

Mickeydusaor wrote:at a quick glance at the ORG EDITTIME+C'0' it looks like it is putting a leading 0 in the &sysdate field...

No. Not even close.

I'll expand on Mickeydusaor's response.

Let's expand the problem a bit:After the UNPK instruction executes the data in OUTPUT is X'F0FC' . Read the description of the UNPK instruction very carefully to understand why this is so.

ORG EDITTIME+C'0'

C'0' has a value. The hexadecimal value for C'0' is F0, or 240 decimal. The purpose of the ORG Assembler instruction is to reset the value of the location counter, so after the Assembler processes the ORG instruction, the location counter is at EDITTIME+C'0' or EDITTIME+240. An ORG instruction with no operands sets the value of the location counter to the highest point it has encountered so far. From the actual Assembler listing of EDITTIME:The first line tells me the actual value of the location counter was 000108 before the ORG instruction was processed by the Assembler, and it will be reset to 000F0.

The second line tells me the location counter value is 0000F0, and the ORG instruction will reset it to 00108.

Now EDITTIME is a very small program. What will the Assembler do if the location counter value when ORG EDITTIME+C'0' was processed by the Assembler was less than 0000F0? It will set the location counter to 0000F0. After the second ORG is processed by the Assembler, since the highest value of the location counter was 0000F0, is will still be 0000F0. Why go through these gyrations? Again, going back to the listing:The first line tells me the assigned location value for HEXTAB is 00018. I compressed the second line a little so it would display better in the code box. Now lets's go back to the listing.The location counter is 00003C. DC07 C0D9 C018 is the hexadecimal representation of the instruction; C018 is the hexadecimal representation of the base/displacement address of HEXTAB: the machine will add 018 to the contents of register C. There are good things about this system, but the "displacement" value must be 0 or positive. It cannot be negative. The reason to go through the gyrations with ORG Assembler instructions ensures the displacement value for HEXTAB will be valid. If the module is very small, what will be in storage before HEXTAB at location counter 0000F0? It will not be defined, so anything can be there.

I won't repeat the questions here.

1) The TIME DEC macro returns 8 packed decimal digits in register 0, and 7 packed decimal digits and a packed decimal sign. After it stores the 2 registers in SAVETIME, SAVETIME is the equivalent of an 8 byte packed decimal data area. The low order 7 packed decimal digits have the form 0cyyddd. c is the century, 1 for 2000, and 0 for 1900. Byr adding 1900 to cyy we get a "true year." This year cyy is returning 113; 1900+113 = 2013.

2) Already discussed.

3) For a job run in batch, it doesn't make any difference. When STIMER WAIT is run in a TSO session, an attempt to get an attention through to the TSO session is deferred until thewait time completes. For this code, where the wait time is 1 second it really doesn't matter. For longer interval it can by annoying.

4) The SAVETIME data area is the equivalent of 15 packed decimal digits. The edit mask specifies 15 digit select characters, so the final result is hh:mm:ss.hh yyyy/ddd. The first h will be blank if the program is run before 10 AM.

5) You need a new save area if your program calls a sbroutine or it does I/O using the GET/PUT/READ/WRITE/CHECK macros. The TIME, STIMER, WAIT and TPUT macros all SVC instructions to invoke system services; the SVC interrupt handler (yes, the SVC instruction generates an interrupt) saves your registers elsewhere, and restores them when the SVC service completes.

6) The code is sort of a subroutine. Logically, it is called by the operating system. The trouble is if it really worked the way I just described, your little subroutine would be entered as though it were the operating system. That's a no no; it would be an open sesame to all sorts of mischief. So what really happens is trickery.

Essentially all programs in MVS run under control of a system control block called a request block. There are oodles and oodles of request block types. Most programs run under a "Program Request Block," which makes sense. One of the fields in the request block is a "wait count" field, which is just the number of event control blocks that must be marked complete. If the wait count field is not 0, the system will not run your program. In order to run the little subroutine, timer services executes a macro called CIRB, which creates a special type of request block called an IRB (Interrupt Request Block) when the timer interval completes and sets it tun run your routine. Once the CIRB macro completes, timer services is done and the operating system looks for other work, like run other tasks. Sooner or later it will get to your task, it will notice there is a request block (the IRB) with a wait count = 0, and it will start your interrupt program. The POST macro in the interrupt program will, among other tasks, will locate the request block that the event control block is associated with and reduce its wait count by 1. Now, register 14, when the interrupt routine is entered, does not really point to anything in the operating system; it actually points to an SVC 3 instruction, which starts system code to terminate a request block. If the request block is the last request block for the task, which this should not be, it will terminate the task.

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

Peter_Mann (Fri Aug 16, 2013 2:47 am)

so hard to understand this program.

C018 should be the address of HEXTAB, but obviously, (R12)+018 points to another address, can you explain it? thanks.

here, HEXTAB EQU *-C'0' = HEXTAB EQU 0?

and i think HEXTAB EQU 0 is similar to "R0 EQU 0", both of them don't have address, they are just one value 0, is it right?

Yes and no.

HEXTAB DC C'0123456789ABCDEF'

Regardless of the "value," HEXTAB is a relocatable value. This means several things

1. When it is used in an address constant, e.g., DC A(HEXTAB) when the program is loaded into storage, the data stored in the 4 bytes will be the address of of the storage assigned to the symbol.
2. When HEXTAB is used in an instruction, provided it is in storage covered by a USING Assembler instruction, the Assembler will compute the "displacement" and base register from the USING, and store them in the binary instruction.

*, in IBM Assemblers, always means the current value of the location counter. That means it is relocatable. So, *-C'0' is relocatable because C'0' is a constant.

HEXTAB-C'0' is relocatable provided HEXTAB is relocatable.

You can do other types of arithmetic on relocatable values, provided they are in the same logical domain.

TABLE DC 256AL1(*-TABLE)

IBM assemblers will generate 256 1 byte data areas containing 1 2 3 4 5 6 7 8 9 ... 255.

I have to go now.

This table is in most of my programs that write a SYSPRINT type data set. What is its purpose?
Hint, though it's not much of a hint, an argument can be made that the AL1(2) in (C'0'-(*-OELINES))X'FF',AL1(2) should be AL1(2,255). Why?

If you can figure this out - and it's not easy - you will have a very solid idea about how arithmetic with relocatable values works in Assembler.

AL1(2) = AL1(2,255) = AL1(2,255,255) = AL1(2,255,255,255), we add one 255 more, the value of * should be +1, so the table above should equal to:



right?