> I almost hate to admit it, but the code in question is LE enabled. So it 
> starts with a CEEENTRY macro and ends with a CEETERM. The program is a z/OS 
> UNIX command that I'm messing around with. I use LE so that I can use C 
> subroutines.

That does not really affect how you setup your local environment and then call 
and return from your own subroutines.

The product that I am responsible for (approx. 1.5 million lines of code)  
calls "C" programs, z/OS Unix functions and a host of other strange 
programs/functions sometimes in rather exotic environments - however each CSECT 
uses the same internal structure and macro set and I just do not have "base 
register" issues at all. When I get "register poor", I take this a nature's way 
of telling me that I need to restructure/redesign the code.

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: [email protected]
Web: www.rocketsoftware.com


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On 
Behalf Of McKown, John
Sent: 11 January 2012 14:21
To: [email protected]
Subject: Re: Enhanced CALL macro?

> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:[email protected]] On Behalf Of Rob Scott
> Sent: Wednesday, January 11, 2012 8:04 AM
> To: [email protected]
> Subject: Re: Enhanced CALL macro?
>
> John,
>
> IMHO the first resource needed by any assembler programmer before
> writing anything non-trivial is a set of macros that enable subroutine
> calling, register saving and return that cater for all environments.
>
> These macros should enable the specification of the subroutine base
> and also optionally a register(s) to address any constants and
> literals.
>
> Using IEABRC and pertinent use of subroutines should remove 99.9% of
> all "base register" problems.
>
> Rob Scott

I almost hate to admit it, but the code in question is LE enabled. So it starts 
with a CEEENTRY macro and ends with a CEETERM. The program is a z/OS UNIX 
command that I'm messing around with. I use LE so that I can use C subroutines. 
So far, all that I have used is the "sprintf" because I'm too lazy to make a 
nicely formatted output string myself (removing unneeded spaces). Decoding the 
parameter list passed to a z/OS UNIX command was a bit of a trip as well. 
Definitely different from batch and TSO. R1 points to a fixed length list of 
pointers which point to more pointers. And calling C subroutines? Oh, my. 
Definitely weird parameter lists. "call by value" - blech!

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
[email protected] * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

Reply via email to