Compiling and linking Assembler modules

k_rajesh · New User Joined: 14 May 2010 Posts: 14 Location: hyd

Hi, I am using the below JCL to compile and Link edit a program A which calls program B. I compiled program B first and then when I am compiling program A, A is not able to reference B. Please help.

I need your help in proper compilation of Assembler module A calling another module B:

//USERLIB JCLLIB ORDER='SYS1.ADMIN.PROCLIB'
//STEP010 EXEC ASMACL,MEMBER=PGMA,
// SRCELIB=USERID.SRCELIB,
// LOADLIB=USERID.LOADLIB
//SYSLIB DD DISP=SHR,DSN=USERID.MACLIB
// DD DISP=SHR,DSN=SYS1.MACLIB
// DD DISP=SHR,DSN=SYS1.MODGEN
//LKED.SYSLIB DD DISP=SHR,DSN=USERID.LOADLIB

I am getting the following message when compiling PGMA which calls PGMB.

BATCH EMULATOR JOB(R01681C ) STEP(STEP010 ) PGM= HEWL PROCEDURE(LKED )
IEW2278I B352 INVOCATION PARAMETERS - MAP,LET,LIST,NCAL

IEW2454W 9203 SYMBOL PGMB UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED.
IEW2650I 5102 MODULE ENTRY NOT PROVIDED. ENTRY DEFAULTS TO SECTION PGMA.

The related PGMA has the following code along with standard house keeping:

** CALL PGMB
L R15,=V(PGMB)
BASR R14,R15

I did not define any other variable related to PGMB in PGMA.

PGMB CSECT
ENTRY HOUSE KEEPING
WTO '* PGMY IS STARTING...'
EXIT HOUSE KEEPING.

I tried my luck by going ahead and running. It ABENDED with S0C1 and R15 is filled with zeroes.

Please help me in calling PGMB from PGMA.

Robert Sample · Posted: Thu Jan 20, 2011 12:30 am

In the compile JCL for PGMA, you need:

Garry Carroll · Posted: Thu Jan 20, 2011 1:07 pm

Or, alternatively, assemnle/link PGMA specifying ",PARM.LKED=(LIST,XREF)' . The NCAL parameter specified in your procedure tells the linkage editor not to resolve external references.

Garry.

k_rajesh · New User Joined: 14 May 2010 Posts: 14 Location: hyd

Hi Frens,

Thanks to your help I was able to come out of compilation hickups and call program B from A. I also learnt few lessons hard way. Plz confirm if they are correct:

1. When you use single JCL to compile and Link edit the modules (ASMACL) then in an A calling B scenario if changes are made in B they will not be reflected at run time unless B is compiled and Linked first. PGM a shuld also be compiled and link ed as A is calling B.

2. The best way to shoot ones leg in Assembler is to use WTO's recklessly, especially in the called pgm. WTOs tend to corrupt R1 and R2 where in R1 holds the parameter list address.

Lastly :

+IHB0017B DC V(PGMY)
+ LA 1,IHB0019
+ B IHB0019A
+IHB0019 DS 0F
+ DC A(PARM01)
+ DC A(PARM02)
+ DC A(PARM03)
+ DC A(PARM04+X'80000000')

I am calling PGMY with 4 parms and it is getting expanded as shown above.

I see that X'80000000' is placed at the end while compiling. Is it to help us determine end of parameter list in the called module??

Thanks for your help.

Munni.

Robert Sample · Posted: Fri Jan 21, 2011 10:55 pm

In assembler, when calling a subprogram, the high-order bit being set to one indicates the end of the parameter list.

One of the reasons for using dynamically called programs is so you don't have to recompile the calling program every time you change the called program. With a statically called program, changing the called program means you have to recompile the called AND calling programs.

Many production environments only allow a programmer to use a WTO by management approval, which is another reason not to use them.

Ronald Burr · Posted: Fri Jan 21, 2011 11:25 pm

Robert Sample · Posted: Fri Jan 21, 2011 11:45 pm

Ronald -- true, but it depends upon what was changed in the called program. When the change affects one of the varaibles going between the program, such as a length change, recompiling both programs will keep them synchronized.

Ronald Burr · Posted: Sat Jan 22, 2011 12:27 am

True, Robert - and a very good point, indeed.

Also, I realized, after it was too late to edit my post, that what I posted is not 100% correct, anyway. I SHOULD have stated in the example I provided that PGMA was the main ENTRY point for the statically-linked executable (PGME), not the main MODULE in the executable. Entry points (PROGRAM-ID's or CSECT's) in statically-linked executables do not have to equate to the actual name of a load/object module in the executable, as would be a requirement in dynamically called modules.