IBM Mainframe Forum

Hi,

I am new to assembler.

Please help with the following points:
1. I am trying to call an assembler prog PROGB from a COBOL prog PROGA.

In PROGA
Code:
CALL PROGB USING WS-PARMDATA
END-CALL

WS-PARMDATA is defined as pic x(10) in working storage.

In PROGB
Code:
PROGB CSECT
STM 14,12,12(13)
BALR 12,0
USING *,12
ST 13,SAVE+4
LA 13,SAVE
WTO 'START PROGB'
L 2,0(1)
USING PARMDATA,2
WTO 'END PROGB'
EXIT L 13,SAVE+4
LM 14,12,12(13)
BR 14
SAVE DS 18F
PARMDATA DS CL10
END PROGB

Just trying to set the addressabilty of the passed parameter but it is abending with a S0C4 when trying to execute L 2,0(1).

How can I correct this or what is the correct way to pass a parameter to an assembler routine?

2. Can I use WTO to display the value of a variable? If not is there any other way this can be done.

If the COBOL is any of the recent compilers that use Language Environment, you must read the Language Environment manual on InterLanguage Communication carefully and follow its examples. Certain registers, such as 12, are reserved by LE for certain purposes and using one as a base register may cause abends.

Production shops frown upon the use of WTO for anything other than important operator messages as the console is flooded enough already with messages from the various subsystems and applications. You could write to a file, or do a SNAP dump, but WTO is not a good idea.

You're getting the S0C4 because the WTO macro altered the register 1 that was sent to your program.

As a miscellaneous note, an END statement for a program that is intended to be used as a subroutine should not specify an entry point.

As another miscellaneous note: OS/360 save areas should be on a double threaded list. What this means is that when you establish your save area, your caller's save area should point to your save area. I always do something likeThe first store connects your save area to the caller's save area; the second store connects the caller's save area to your save area.
There's nothing "wrong" in your code in that respect, but by not doing the complete job dump programs can't do a proper save area trace. Finally, the standard IBM macro library provides a SAVE macro that will do the same STM you do, but it will also insert a character string that the dump program save area trace will insert into the dump:The bad news is the SAVE macro that inserts a program ID effectively requires that register 15 points to the start of your program. You can do more: is a very convenient way to add a sort of version control by inserting the date and time of the assembly into the program ID text. The macro library also provides a RETURN macro that will do the same LM you do, and it will also flag the save area to indicate it's no longer in use, though the save area trace in the dump program ignores this flag. The library RETURN macro also proves a mechanism to set a return code in register 15. These conventions have been essentially unchanged for more than 40 years, though they do extract a minor performance penalty in your program on modern hardware, which is one reason IBM developed the XPLINK convention in LE.

Mr. Sample's comment about the use of the WTO macro is well founded; most of my program use a WTO macro if they can't open its SYSPRINT data set, but then route all messages to SYSPRINT.

The comment about Language Environment (LE) compliance is also well founded. LE imposes some register conventions your program is not following, and also wants your programs to be reenterable, which your program is not. An LE compliant subroutine should also be AMODE ANY, RMODE ANY, which your program is as written, though it hasn't been declared as such. Like most old Assembler programmers, I rarely worry about full LE compliance, since it requires significant real extra effort that is rarely necessary, and full LE compliance means your program will not run outside of the LE world.

As for your question about using WTO for data. Yes, it's certainly possible. If you look at the WTO expansion in your program you'll see something likeThe instructions with a + are generated by the macro. The purpose of the BAL instruction is to store the message address in register 1. The line after the BAL instruction is the message; as long as register 1 points to a message buffer with the same general format as in my example when your program issues an SVC 35 instruction z/OS will write the message.

Thank you everybody for your help and advise.

I believe the WTO was causing the problem (changing the contents in R1).
Removing the WTO before using the R1 to point to the DESCT in the called program, as well as explicitly mentioning RMODE and AMODE as ANY, I was successfully able to call the Assembler program from the COBOL program; I was also able to modify the parameter passed from the COBOL program.

I was trying to pass a parm by reference and access it in the assembler routine. Was able to do it with your advice.

Since you have all adviced against using WTO (anyway it goofs up R1), what's the best way I can put in some 'debug' kind of statements (similar to DISPLAY in COBOL). Also, how can I 'display' literals as well as variables in an assembler to help debug the routine.

Hello,

One easy way is to define a file and instead of the wto, write the messsage to the file (which is also what is sometimes done in cobol when display is not to be used).

I'm glad my suggestions proved helpful. Thank you for letting us know.

Mr. Scherrer's ideas are a very common way to debug programs outside of a testing environment, though it tends to be clumsy to do this for one shot analysis, especially for an Assembler program that is intended to be reenterable or AMODE ANY. All too often you introduce a bug in your debugging code, as happened here with the in-line WTO macro. One thing most of us Assembler dinosaurs have learned, usually the hard way, is to assume any executable macro, unless the manual clearly states otherwise, will clobber registers 14, 15, 0 and 1. When in doubt, look at the macro expansion in the Assembler listing, though that often does not tell the whole story. Your original WTO macro clearly altered register 1, but the SVC 35 (the SVC instruction is comparable to the INT instruction in PC hardware, though it is rarely used in 32-bit and 64-bit PC programs) probably altered registers 0 and 15. Many macros (GET, PUT, READ, WRITE and CHECK, and that list is far from complete) also use the save area your register 13 points to, often in a non-standard way.

Mr. Sample mentioned that non-LE compliant programs will abnormally terminate when run in an LE environment. This is usually not the case, though if your program does ABEND, the LE debugging facilities may fail and will certainly generate useless output.

steve-myers wrote:Mr. Sample's comment about the use of the WTO macro is well founded; most of my program use a WTO macro if they can't open its SYSPRINT data set, but then route all messages to SYSPRINT.

The comment about Language Environment (LE) compliance is also well founded. LE imposes some register conventions your program is not following, and also wants your programs to be reenterable, which your program is not. An LE compliant subroutine should also be AMODE ANY, RMODE ANY, which your program is as written, though it hasn't been declared as such. Like most old Assembler programmers, I rarely worry about full LE compliance, since it requires significant real extra effort that is rarely necessary, and full LE compliance means your program will not run outside of the LE world.

As for your question about using WTO for data. Yes, it's certainly possible. If you look at the WTO expansion in your program you'll see something like

Select all

          WTO   'HELLO WORLD!'
+         CNOP  0,4
+         BAL   1,*+20
+         DC    AL2(16,0),C'HELLO WORLD!'
+         SVC   35

The instructions with a + are generated by the macro. The purpose of the BAL instruction is to store the message address in register 1. The line after the BAL instruction is the message; as long as register 1 points to a message buffer with the same general format as in my example when your program issues an SVC 35 instruction z/OS will write the message.

Yeah, it's WTO triggered this abend. after WTO ran, R1 pointed to another address(message buffer), so when 'L 2,0(1)' executed, the result is: R2 should one wrong value/address instead S0C4 was triggered.
anybody can explain it to me? thanks in advance.

Two years ago, the explanation of why the program got an S0C4 was clearly explained; the topic starter apparently used the explanation to correct his problem. I suggest you reread this entire thread rather than ask us to repeat the explanation.

The "z/OS Assembler Services Reference IAR-XCT" manual for your z/OS release discusses register contents required by the WTO macro. In this manual you will discover, if you bother to read it, that WTO always alters register 1 beyond what was implied by the expansion of the WTO macro. Read The Fine Manual (RTFM)!