Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!auvm!UALTAVM!COLSON
From: COLSON@UALTAVM.BITNET (Cathy Olson Programmer Analyst)
Newsgroups: bit.listserv.cics-l
Subject: Re: Macro conversion
Message-ID: <CICS-L%90020709322741@UALTAVM.BITNET>
Date: 7 Feb 90 16:32:24 GMT
Sender: CICS Discussion List <CICS-L@AKRONVM>
Reply-To: CICS Discussion List <CICS-L@AKRONVM>
Lines: 28
Approved: NETNEWS@AUVM Gateway


 *** Reply to note of 02/07/90 08:53
                                        Library Systems
                                        University of Alberta
 Most of our problems came, not with the converting which is straight-forward
 but with the application which relied on the way things work in macro CICS.

 Command CICS, from my perspective, takes some of the unnecessary space
 management out of the programmers hands. Unfortunately, our application was
 designed with the assumption that the programs do all their own space
 management (eg. freemain and getmains). The space management problem will
 occur in any language.

 Assembler presented it's own problems in that at least one, if not two, extra
 registers are needed.

 The command CICS programmers guide has a two page listing of the conversion
 from macro statement to command statements. It does not list changes such as
 changing the addressing from storage name to addressing by pointer address.
 For these changes you have to sit down with both manuals.

 For example, command level Freemain's, can only be done on areas that a
 previous Getmain was done on within the user program. System areas can no
 longer be Freemained by the user programs but they are Freemained by the
 system programs at some very inconvenient times. You can't rely on system
 areas like TIOA to stay around.

 Cathy