







^PY^-

^IOP^IS404^IL0600^IC1000^IJ00450^IT00700^PN^-





WARNING!  This is an obsolete version of the Unix documentation for

          AIPS.  It was last revised in 1990 for the 15APR90 release,

          and there have been 6 releases since then.  For up to date

          documentation, refer to UGUIDE.TEX in the DOCTXT area, or

          UGUIDE.PS in the AIPSPUBL area.  Also see INSTALL.TEX in

          DOCTXT and INSTALL.PS in AIPSPUBL for a better guide.















OBSOLETE!  OBSOLETE!    AIPS INSTALLATION GUIDE    OBSOLETE!  OBSOLETE!



      formerly for the 15APR90 AIPS release.  NOT for later releases!!!



                             UNIX VERSION







                           Kerry C. Hilldrup

                 National Radio Astronomy Observatory

                             Edgemont Road

                  Charlottesville, VA  22903-2475 USA

                      (804) 296-0372 or 296-0211

                           TWX=510-587-5482

                          FAX=(804) 296-0278

                   aipsmail@nrao.edu [192.33.115.2]

                      NRAO::AIPSMAIL    [6654::]

                         AIPSMAIL@NRAO.BITNET

                      ...!uunet!nrao.edu!aipsmail



                             9 April 1990



                                                          9 April 1990





                                   CONTENTS







CHAPTER 1       OVERVIEW



        1.1     LOGICALS . . . . . . . . . . . . . . . . . . . . . 1-1

        1.2     NEW DIRECTORY STRUCTURE  . . . . . . . . . . . . . 1-2

        1.3     SOURCE CODE OVERHAUL . . . . . . . . . . . . . . . 1-2

        1.4     AIPS VERSIONS  . . . . . . . . . . . . . . . . . . 1-3

        1.5     DISK SPACE REQUIREMENTS  . . . . . . . . . . . . . 1-3

        1.5.1     Text Files . . . . . . . . . . . . . . . . . . . 1-3

        1.5.1.1     SYSTEM Directories . . . . . . . . . . . . . . 1-6

        1.5.1.2     DEV Directories  . . . . . . . . . . . . . . . 1-7

        1.5.1.2.1     Z-routines . . . . . . . . . . . . . . . . . 1-7

        1.5.1.2.2     Y-routines . . . . . . . . . . . . . . . . . 1-8

        1.5.1.2.3     Q-routines . . . . . . . . . . . . . . . . . 1-9

        1.5.2     Binary Files . . . . . . . . . . . . . . . . .  1-10

        1.5.3     Selective Tar  . . . . . . . . . . . . . . . .  1-11

        1.6     THE INSTALLATION PROCESS . . . . . . . . . . . .  1-11





CHAPTER 2       INSTALLATION STEP 1



        2.1     INTRODUCTION . . . . . . . . . . . . . . . . . . . 2-1

        2.2     THE AIPS ACCOUNT . . . . . . . . . . . . . . . . . 2-1

        2.3     LOADING THE INSTALLATION TAPE  . . . . . . . . . . 2-2

        2.4     LOCAL DIRECTORIES  . . . . . . . . . . . . . . . . 2-2

        2.5     AREA LOGICALS  . . . . . . . . . . . . . . . . . . 2-5

        2.6     LOCAL AREA LOGICALS  . . . . . . . . . . . . . .  2-12

        2.7     LOGIN PROCEDURES . . . . . . . . . . . . . . . .  2-14

        2.8     OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS  .  2-18

        2.8.1     LIBR.DAT . . . . . . . . . . . . . . . . . . .  2-18

        2.8.1.1     Subroutine And Object Library Mappings . . .  2-22

        2.8.1.2     Program And Object Library Mappings  . . . .  2-24

        2.8.2     INCS.SH  . . . . . . . . . . . . . . . . . . .  2-27

        2.9     COMPILER AND LOADER OPTIONS  . . . . . . . . . .  2-29

        2.10    PROGRAMMING AND EXECUTION TOOLS  . . . . . . . .  2-30

        2.11    SOURCE CODE PREPROCESSOR . . . . . . . . . . . .  2-31

        2.11.1    Preprocessor Program . . . . . . . . . . . . .  2-32

        2.11.2    Preprocessor Procedure . . . . . . . . . . . .  2-32

        2.12    CHECK LIST . . . . . . . . . . . . . . . . . . .  2-33





CHAPTER 3       INSTALLATION STEP 2



        3.1     RUNNING INSTEP2  . . . . . . . . . . . . . . . . . 3-1

        3.2     DEVICE LOGICALS  . . . . . . . . . . . . . . . . . 3-3

        3.2.1     Data Areas . . . . . . . . . . . . . . . . . . . 3-3

        3.2.2     Tape Drives  . . . . . . . . . . . . . . . . . . 3-4

        3.2.3     Reserved Terminals . . . . . . . . . . . . . . . 3-5

        3.2.4     Message Terminals  . . . . . . . . . . . . . . . 3-5

        3.2.5     Graphics Terminals . . . . . . . . . . . . . . . 3-6

        3.2.6     TV Display Devices . . . . . . . . . . . . . . . 3-6



                                                          9 April 1990





        3.2.7     Batch Error Terminal/File  . . . . . . . . . . . 3-7

        3.2.8     Printers And Plotters  . . . . . . . . . . . . . 3-7





CHAPTER 4       INSTALLATION STEPS 3 AND 4



        4.1     RUNNING INSTEP3  . . . . . . . . . . . . . . . . . 4-1

        4.2     RUNNING FILAIP . . . . . . . . . . . . . . . . . . 4-2

        4.3     PASSWORDS  . . . . . . . . . . . . . . . . . . . . 4-4

        4.4     RUNNING POPSGN . . . . . . . . . . . . . . . . . . 4-5

        4.5     RUNNING SETPAR AND SETTVP  . . . . . . . . . . . . 4-6

        4.6     EXERCISING AIPS  . . . . . . . . . . . . . . . . . 4-9

        4.6.1     AIPS Start-up Procedure  . . . . . . . . . . . . 4-9

        4.6.2     Task Initiation  . . . . . . . . . . . . . . . . 4-9

        4.6.3     Tape Interface . . . . . . . . . . . . . . . .  4-10

        4.6.4     "Dirty Dozen" Tasks  . . . . . . . . . . . . .  4-10

        4.6.5     Running Under A Debugger . . . . . . . . . . .  4-10

        4.6.6     The VERSION Adverb . . . . . . . . . . . . . .  4-11

        4.7     RUNNING INSTEP4  . . . . . . . . . . . . . . . .  4-12





APPENDIX A      Z-ROUTINES AND Z-PROGRAMS



        A.1     HISTORY  . . . . . . . . . . . . . . . . . . . . . A-1

        A.2     STANDARDS. . . . . . . . . . . . . . . . . . . . . A-1

        A.3     ZDCHI2 . . . . . . . . . . . . . . . . . . . . . . A-2

        A.3.1     BYTFLP . . . . . . . . . . . . . . . . . . . . . A-2

        A.3.2     SPFRMT And DPFRMT  . . . . . . . . . . . . . . . A-3

        A.3.3     NSHORT, TTYCAR, SYSTYP And SYSVER  . . . . . . . A-4

        A.4     ROUTINES THAT REQUIRE LOCAL DEVELOPMENT  . . . . . A-4

        A.5     UNIX Z-ROUTINES  . . . . . . . . . . . . . . . . . A-5

        A.5.1     Descriptions . . . . . . . . . . . . . . . . . . A-5

        A.6     UNIX Z-PROGRAMS  . . . . . . . . . . . . . . . .  A-43





APPENDIX B      RELEASE NOTES



        B.1     INTRODUCTION . . . . . . . . . . . . . . . . . . . B-1

        B.2     NOTES FOR THE 15OCT86 RELEASE  . . . . . . . . . . B-1

        B.2.1     Introduction . . . . . . . . . . . . . . . . . . B-1

        B.3     NOTES FOR THE 15JAN87 RELEASE  . . . . . . . . . . B-1

        B.3.1     Introduction . . . . . . . . . . . . . . . . . . B-1

        B.3.2     Changes Of Interest  . . . . . . . . . . . . . . B-1

        B.4     NOTES FOR THE 15APR87 RELEASE  . . . . . . . . . . B-2

        B.4.1     Introduction . . . . . . . . . . . . . . . . . . B-2

        B.4.2     Changes Of Interest  . . . . . . . . . . . . . . B-2

        B.5     NOTES FOR THE 15JUL87 RELEASE  . . . . . . . . . . B-3

        B.5.1     Introduction . . . . . . . . . . . . . . . . . . B-4

        B.5.2     Changes Of Interest  . . . . . . . . . . . . . . B-4

        B.6     NOTES FOR THE 15OCT87 RELEASE  . . . . . . . . . . B-4

        B.6.1     Introduction . . . . . . . . . . . . . . . . . . B-4

        B.6.2     Changes Of Interest  . . . . . . . . . . . . . . B-5

        B.7     NOTES FOR THE 15JAN88 RELEASE  . . . . . . . . . . B-6

        B.7.1     Introduction . . . . . . . . . . . . . . . . . . B-6



                                                          9 April 1990





        B.7.2     Changes Of Interest  . . . . . . . . . . . . . . B-7

        B.8     NOTES FOR THE 15APR88 RELEASE  . . . . . . . . . . B-7

        B.8.1     Introduction . . . . . . . . . . . . . . . . . . B-7

        B.8.2     Changes Of Interest  . . . . . . . . . . . . . . B-7

        B.9     NOTES FOR THE 15JUL88 RELEASE  . . . . . . . . . . B-7

        B.9.1     Introduction . . . . . . . . . . . . . . . . . . B-8

        B.9.2     Changes Of Interest  . . . . . . . . . . . . . . B-8

        B.10    NOTES FOR THE 15OCT88 RELEASE  . . . . . . . . . . B-8

        B.10.1    Introduction . . . . . . . . . . . . . . . . . . B-8

        B.10.2    Changes Of Interest  . . . . . . . . . . . . . . B-8

        B.11    NOTES FOR THE 15JAN89 RELEASE  . . . . . . . . . . B-9

        B.11.1    Introduction . . . . . . . . . . . . . . . . . . B-9

        B.11.2    Changes Of Interest  . . . . . . . . . . . . . . B-9

        B.12    NOTES FOR THE 15APR89 RELEASE  . . . . . . . . .  B-10

        B.12.1    Introduction . . . . . . . . . . . . . . . . .  B-10

        B.12.2    Changes Of Interest  . . . . . . . . . . . . .  B-10

        B.13    NOTES FOR THE 15JUL89 RELEASE  . . . . . . . . .  B-10

        B.13.1    Introduction . . . . . . . . . . . . . . . . .  B-10

        B.13.2    Changes Of Interest  . . . . . . . . . . . . .  B-11

        B.14    NOTES FOR THE 15OCT89 RELEASE  . . . . . . . . .  B-11

        B.14.1    Introduction . . . . . . . . . . . . . . . . .  B-11

        B.14.2    Changes Of Interest  . . . . . . . . . . . . .  B-11

        B.15    NOTES FOR THE 15JAN90 RELEASE  . . . . . . . . .  B-11

        B.15.1    Introduction . . . . . . . . . . . . . . . . .  B-11

        B.15.2    Changes Of Interest  . . . . . . . . . . . . .  B-11

        B.16    NOTES FOR THE 15APR90 RELEASE  . . . . . . . . .  B-12

        B.16.1    Introduction . . . . . . . . . . . . . . . . .  B-12

        B.16.2    Changes Of Interest  . . . . . . . . . . . . .  B-12





APPENDIX C      SYSTEM SPECIFIC NOTES



        C.1     INTRODUCTION . . . . . . . . . . . . . . . . . . . C-1

        C.1.1     System V . . . . . . . . . . . . . . . . . . . . C-1

        C.1.2     Alliant Systems  . . . . . . . . . . . . . . . . C-2

        C.1.3     Convex Systems . . . . . . . . . . . . . . . . . C-5

        C.1.4     Cray Systems . . . . . . . . . . . . . . . . . . C-5

        C.1.5     Sun Systems  . . . . . . . . . . . . . . . . . . C-6





APPENDIX D      UPDATING USER DATA FORMATS



        D.1     INTRODUCTION . . . . . . . . . . . . . . . . . . . D-1

        D.2     UPDATING DATA TO THE 15JUL85 FORMAT  . . . . . . . D-1

        D.2.1     Introduction . . . . . . . . . . . . . . . . . . D-1

        D.2.2     Updating Instructions For 15JUL84 Release 

                  (SAVE/GET Ver 6) . . . . . . . . . . . . . . . . D-2

        D.2.3     Updating Instructions For 15OCT84 Release 

                  (SAVE/GET Ver 7) . . . . . . . . . . . . . . . . D-3

        D.2.4     Updating Instructions For 15APR85 Release 

                  (SAVE/GET Ver 7) . . . . . . . . . . . . . . . . D-5

        D.2.5     Updating Instructions For 15JUL85 Release 

                  (SAVE/GET Ver 7) . . . . . . . . . . . . . . . . D-6



                                                          9 April 1990





        D.3     UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO 

                THE CURRENT SYSTEM . . . . . . . . . . . . . . . . D-8

        D.3.1     Introduction . . . . . . . . . . . . . . . . . . D-8

        D.3.2     Data Format Changes Since 15JUL85  . . . . . . . D-8

        D.3.2.1     Data Version A (First Appears In 15APR86)  . . D-8

        D.3.2.2     Data Version A (15OCT86) . . . . . . . . . . . D-8

        D.3.2.3     Data Version B (15JAN87) . . . . . . . . . . . D-8

        D.3.2.4     Data Version B (15APR87) . . . . . . . . . . . D-8

        D.3.2.5     Data Version B (15JUL87) . . . . . . . . . . . D-8

        D.3.2.6     Data Version B (15OCT87) . . . . . . . . . . . D-9

        D.3.2.7     Data Version B (15APR88) . . . . . . . . . . . D-9

        D.3.2.8     Data Version B (15JUL88) . . . . . . . . . . . D-9

        D.3.2.9     Data Version B (15OCT88) . . . . . . . . . . . D-9

        D.3.2.10    Data Version B (15JAN89) . . . . . . . . . . . D-9

        D.3.2.11    Data Version B (15APR89) . . . . . . . . . . . D-9

        D.3.2.12    Data Version C (15JUL89) . . . . . . . . . . . D-9

        D.3.2.13    Data Version C (15OCT89) . . . . . . . . . . . D-9

        D.3.2.14    Data Version C (15JAN90) . . . . . . . . . .  D-10

        D.3.2.15    Data Version C (15APR90) . . . . . . . . . .  D-10

        D.3.3     Running UPDAT  . . . . . . . . . . . . . . . .  D-10

























                               CHAPTER 1



                               OVERVIEW







     The  installation  of  AIPS  under  UNIX   is   necessarily   more

complicated  than  for proprietary operating systems like VMS.  To some

extent, this is because there is no such thing  as  a  "standard"  UNIX

operating  system.   Over  the last several years, NRAO has encountered

most variations on UNIX and have taken the  lowest  common  denominator

approach  in  our  implementation  of  UNIX/AIPS, portability being the

number one priority.  Even so, there is no way to  account  for  vendor

"enhancements"  that  may  cause  problems.   There  has  also  been  a

concentrated (although not necessarily concerted) effort  to  make  our

implementation  of  AIPS  under  all  operating  systems  as similar as

possible.  The notion that AIPS should look and feel the same to  users

no  matter  what  system  it  is  on,  has  been  extended  to the AIPS

installation and maintenance "tools".  This is not always possible, but

at least the spirit is there.



     Recipients of UNIX/AIPS installation kits should also keep in mind

that  we  try  tries  to  service  customers  with  a  broad  range  of

programming and/or UNIX expertise.  Most are astronomers  who  are  not

UNIX  "gurus"  and  have  no  desire  to  become  one.   For  them, the

documentation may prove confusing, if  not  insufficient.   Conversely,

"real"  programmers may find some of the detailed explanations somewhat

insulting.  In any case, if there are problems, don't hesitate to  call

us and we will do our best to talk you through them.







1.1  LOGICALS



     Throughout the guide, AIPS directories  will  be  referred  to  in

several  ways including UNIX path names, AIPS programming "logicals" or

concatenations thereof.  In the case of UNIX, AIPS programming logicals

take  the  form of environment variables.  For example, $NEW is defined

as the absolute path name of the topmost directory of  the  release  or

"version"  of  AIPS  regarded  as  "new".  They are also used as device

"logicals" such as data areas, tape drives,  TV  display  and  graphics

devices.   Descriptions  of  "logicals"  appear as they are encountered

during the relevant installation instructions.

OVERVIEW                                                       Page 1-2

NEW DIRECTORY STRUCTURE                                    9 April 1990





1.2  NEW DIRECTORY STRUCTURE



     The structure of AIPS was  changed  in  some  major  ways  in  the

15APR86  release.   Most of the changes were in the directory structure

and in the supporting shell scripts.  The new directory  structure  now

keeps  tasks  that  use  the  TV  and  AP  in  separate directories and

maintains libraries for alternate devices.   AIPS  memo  39  "Shareable

Images  for  AIPS under VMS" explains the changes in detail.  This memo

is included on the installation  tape  and  will  be  loaded  into  the

$DOCTXT directory under the file name MEMO39.MEM.  The memo can also be

obtained  from  the  AIPS  Group  in  Charlottesville.   Naturally   it

describes  things  from a VMS point of view, however, the approach from

the beginning for UNIX/AIPS has been  to  imitate  the  VMS/AIPS  model

wherever possible, all in the interest of evolving in parallel (even if

to do this required standing UNIX on its head).  In fact,  the  changes

made were largely driven by the desire to support sharable images under

VMS, but in the long run, the new directory  structure  should  benefit

AIPS  ports to all operating systems.  For example, code that could not

possibly work on  anything  but  machine  "X"  with  device  "Y"  under

operating  system "Z" have now been isolated into subdirectories and no

longer have to be discovered so painfully.  Nevertheless, these changes

completely  voided  most  of  our prior UNIX/AIPS development effort in

terms of documentation and procedures for installing,  programming  and

maintaining  the  system.   As  of the 15OCT86 release, after months of

chasing the tail of VMS/AIPS,  we  finally  recovered  sufficiently  to

release UNIX/AIPS again.







1.3  SOURCE CODE OVERHAUL



     15OCT89 represented the first publicly available  release  of  the

long   overdue  "overhauled"  AIPS.   The  overhaul  strategy  actually

implemented differs  substantially  from  the  original  incisive  plan

announced in the 15APR87 AIPSletter and presented at the September 1987

AIPS Workshop.  This, plus several  personal  disasters  prior  to  the

initiation  of  the overhaul in April 1988, accounts for the protracted

delay.  A detailed description of the ordeal is  beyond  the  scope  of

this  guide, however, the basic change is from FORTRAN 66 with multiple

extensions (e.g., "TYPE*N"  declarations  like  INTEGER*2,  ENCODE  and

DECODE  statements, non-generic intrinsic functions) to ANSI FORTRAN 77

with only two non-ANSI features, 1) VMS-style "INCLUDE" statements, and

2)  a  new  data  "type", HOLLERITH.  Most of the former hollerith-type

character data and  its  baroque  manipulation  has  be  replaced  with

FORTRAN 77 CHARACTER data and constructs wherever possible.  The latter

along with extensive cosmetic changes (e.g., GO TO's replaced  with  IF

THEN . .   ELSE constructs, mixed case in FORMAT statements, etc.), all

of which had to  be  done  manually,  accounted  for  majority  of  the

overhaul effort.  A FORTRAN source code preprocessor is now used in all

implementations, including  VMS,  to  process  INCLUDE  statements  and

convert  HOLLERITH  to  REAL  type  declarations.   The  output  of the

preprocessor is ANSI FORTRAN 77 code.  A document titled "Conversion of

Old AIPS Software to Run Under 15OCT89 and Later Releases" is available

and will be shipped with  the  installation  kits  for  the  first  few

OVERVIEW                                                       Page 1-3

SOURCE CODE OVERHAUL                                       9 April 1990





post-overhaul releases.  It's intended a guide for those who would like

to convert private AIPS programs and routines to run  under  the  "new"

AIPS.   It  includes  descriptions  and  instructions on the use of the

three conversion programs used to perform the majority of the overhaul,

XLATE, CONINC and XEDIT.







1.4  AIPS VERSIONS



     Since the AIPS system is continuously evolving at  NRAO,  we  have

found  it  desirable to simultaneously maintain three separate versions

of AIPS (OLD, NEW and TST) which, if possible, all access the same user

data.   Periodically,  a  new  TST version is created, the previous TST

version is redefined as NEW, and the previous NEW version is  redefined

as OLD and used to fill orders in the queue.  This is usually done on a

quarterly basis and releases are referred to by the date of their birth

as 15MMMYY (e.g., 15APR90).  NRAO staff are encouraged to use TST since

this is the version subject to the  most  changes.   For  visitors,  we

recommend  NEW, which is changed only to fix substantive bugs.  In this

way,  the  code  we  ultimately  ship  to  customers  has  been  rather

thoroughly exercised, at least on NRAO systems.



     Because of the large amount of disk space needed for each  version

(see  requirements  below)  most sites maintain only one release (i.e.,

OLD=NEW=TST).  However, some sites have found it very useful  to  bring

up  a  new  version  of  AIPS  defined  that  coexists  with  an older,

established version.  After the new version checks out, simple  changes

in some procedures can be made to redefine the version "logicals".  The

number of versions simultaneously available at a given site is simply a

question  of  disk  space  and  confidence in the updates.  To minimize

confusion, throughout the remainder of this document, the absolute path

name  of  the  topmost  directory  for the release of AIPS that you are

about to install will be denoted as  $XXX  regardless  of  whether  you

decide to define it as OLD, NEW or TST.







1.5  DISK SPACE REQUIREMENTS



1.5.1  Text Files



     The disk space required for all of the text files that come on the

installation  tape is roughly 33 Mbytes, however, a rather large number

of subdirectories are not required  to  be  on  disk  for  a  UNIX/AIPS

installation.  Elimination of the unnecessary text files can reduce the

disk space occupied to about 20 Mbytes.  This can  be  further  reduced

after  the  installation  phase  by  moving  the  source  code to tape,

however, we don't recommend this  until  you  are  confident  that  the

system  is  properly installed.  The space in kilobytes for each branch

of the $XXX directory tree is shown below.  These sizes  are  from  our

NRAO-CV  Convex C-1 (NRAO1) for the 15APR90 release and may differ from

that required on a non-Convex system or  for  file  systems  configured

with  different block/fragment sizes (we use 8K/1K).  In any case, they

OVERVIEW                                                       Page 1-4

DISK SPACE REQUIREMENTS                                    9 April 1990





should only be used as estimates of  what  may  be  required  for  your

system.  These sizes do not include program object modules that you may

want to preserve to facilitate re-linking and require about another  10

Mbytes.   The  $XXX sub-trees that need not be kept or even loaded from

tape are denoted by  an  asterisk,  those  sub-trees  that  are  almost

certainly candidates for deletion are denoted by a double asterisk, and

those sub-trees that MUST be present for the execution of programs  are

denoted by a triple asterisk:



        K Bytes Directory



        32616   15APR90



        1630    15APR90/AIPS

        773     15APR90/AIPS/PGM

        354     15APR90/AIPS/PGM/NOTST

        10      15APR90/AIPS/PGM/NOTST/UNIX

**      343     15APR90/AIPS/PGM/NOTST/VMS

        856     15APR90/AIPS/SUB



        11945   15APR90/APL

        1897    15APR90/APL/DEV

        919     15APR90/APL/DEV/UNIX

        307     15APR90/APL/DEV/UNIX/BELL

        221     15APR90/APL/DEV/UNIX/BELL/CRI

        17      15APR90/APL/DEV/UNIX/BELL/MASC

        303     15APR90/APL/DEV/UNIX/BERK

        16      15APR90/APL/DEV/UNIX/BERK/ALLN

        98      15APR90/APL/DEV/UNIX/BERK/CVEX

        4       15APR90/APL/DEV/UNIX/BERK/CVEX/NRAO1

        11      15APR90/APL/DEV/UNIX/BERK/CVEX/VLAC1

        55      15APR90/APL/DEV/UNIX/BERK/SUN

        9       15APR90/APL/DEV/UNIX/BERK/VAX

**      352     15APR90/APL/DEV/VMS

        7056    15APR90/APL/PGM

        5406    15APR90/APL/PGM/NOTST

        24      15APR90/APL/PGM/NOTST/UNIX

**      1       15APR90/APL/PGM/NOTST/VMS

        2991    15APR90/APL/SUB

        1539    15APR90/APL/SUB/NOTST

        83      15APR90/APL/SUB/NOTST/VMS



*       4932    15APR90/DOC

        4897    15APR90/DOC/TEXT



***     2792    15APR90/HELP



*       130     15APR90/HIST



        238     15APR90/INC

        1       15APR90/INC/LOCAL

        18      15APR90/INC/NOTST

        5       15APR90/INC/NOTST/ALLN

        6       15APR90/INC/NOTST/CRI

OVERVIEW                                                       Page 1-5

DISK SPACE REQUIREMENTS                                    9 April 1990





        5       15APR90/INC/NOTST/CVEX

**      1       15APR90/INC/NOTST/VMS



        6150    15APR90/Q

        4409    15APR90/Q/DEV

**      3797    15APR90/Q/DEV/FPS

        3725    15APR90/Q/DEV/FPS/16B

        1769    15APR90/Q/DEV/FPS/16B/120B

        1721    15APR90/Q/DEV/FPS/16B/5000

        5       15APR90/Q/DEV/FPS/32B

        1       15APR90/Q/DEV/FPS/32B/190

        611     15APR90/Q/DEV/PSAP

        42      15APR90/Q/DEV/PSAP/ALLN

        59      15APR90/Q/DEV/PSAP/CRI

        83      15APR90/Q/DEV/PSAP/CVEX

**      44      15APR90/Q/DEV/PSAP/VMS

        1359    15APR90/Q/PGM

        1294    15APR90/Q/PGM/NOTST

**      1       15APR90/Q/PGM/NOTST/VMS

        381     15APR90/Q/SUB

        331     15APR90/Q/SUB/NOTST



        927     15APR90/QY

        926     15APR90/QY/PGM

        789     15APR90/QY/PGM/NOTST

**      1       15APR90/QY/PGM/NOTST/VMS



***     44      15APR90/RUN



***     2049    15APR90/SYSTEM

        1422    15APR90/SYSTEM/UNIX

        25      15APR90/SYSTEM/UNIX/ALLN

        79      15APR90/SYSTEM/UNIX/CRI

        754     15APR90/SYSTEM/UNIX/CVEX

        409     15APR90/SYSTEM/UNIX/CVEX/NRAO1

        220     15APR90/SYSTEM/UNIX/CVEX/NRAO1/UPDATE

        260     15APR90/SYSTEM/UNIX/CVEX/VLAC1

        89      15APR90/SYSTEM/UNIX/CVEX/VLAC1/UPDATE

        33      15APR90/SYSTEM/UNIX/INSTALL

        73      15APR90/SYSTEM/UNIX/SUN

        50      15APR90/SYSTEM/UNIX/UPDATE

        12      15APR90/SYSTEM/UNIX/UPDATE/NRAO1

        19      15APR90/SYSTEM/UNIX/UPDATE/SUN3

        17      15APR90/SYSTEM/UNIX/UPDATE/SUN4

        1       15APR90/SYSTEM/UNIX/UPDATE/VLAC1

**      475     15APR90/SYSTEM/VMS

        59      15APR90/SYSTEM/VMS/INSTALL

        88      15APR90/SYSTEM/VMS/LOCAL

        46      15APR90/SYSTEM/VMS/LOCAL/UPDATE

        79      15APR90/SYSTEM/VMS/UPDATE

        26      15APR90/SYSTEM/VMS/UPDATE/VLA



*       224     15APR90/UPDATE



OVERVIEW                                                       Page 1-6

DISK SPACE REQUIREMENTS                                    9 April 1990





        1554    15APR90/Y

        703     15APR90/Y/DEV

        1       15APR90/Y/DEV/ARGS

        67      15APR90/Y/DEV/DEA

        171     15APR90/Y/DEV/IIS

        76      15APR90/Y/DEV/IIS/M70

        66      15APR90/Y/DEV/IIS/M75

        101     15APR90/Y/DEV/IVAS

        3       15APR90/Y/DEV/LEX

        2       15APR90/Y/DEV/LEX/LEXC

        111     15APR90/Y/DEV/SSS

        64      15APR90/Y/DEV/SSS/SVU

        13      15APR90/Y/DEV/STUB

        1       15APR90/Y/DEV/V20

        91      15APR90/Y/DEV/VTV

        734     15APR90/Y/PGM

        522     15APR90/Y/PGM/NOTST

**      1       15APR90/Y/PGM/NOTST/VMS

        60      15APR90/Y/PGM/VDEV

        116     15APR90/Y/SUB

        2       15APR90/Y/SUB/NOTST



        589     TEXT

        588     TEXT/IONS





     In addition, there  will  be  some  operating  system  and  device

specific   subdirectories   of   $XXX/SYSTEM  (e.g.,  $XXX/SYSTEM/VMS),

$XXX/APL/DEV    (e.g.,     $XXX/APL/DEV/VMS),     $XXX/Q/DEV     (e.g.,

$XXX/Q/DEV/FPS)  and  $XXX/Y/DEV  (e.g.,  $XXX/Y/DEV/DEA) that won't be

relevant to your installation.  The generic forms (i.e., those that are

the   same  for  two  or  more  installations)  reside  in  the  higher

subdirectories and as you descend these directory structures, the  more

operating system or device specific the code becomes.







1.5.1.1  SYSTEM Directories -



     The  subdirectories  of   $XXX/SYSTEM   contain   procedures   and

definitions  for  the  programming,  maintenance  and execution of AIPS

based on the host operating system (e.g., UNIX vs VMS).   In  addition,

you'll  find  subdirectories  of  $XXX/SYSTEM/UNIX that contain Alliant

(ALLN),  Convex  (CVEX),  Sun  (SUN),  etc. specific   procedures   and

definitions.    The   installation   procedure   will  require  that  a

subdirectory be created for site specific procedures  and  definitions.

There  is  also  a  directory called $XXX/SYSTEM/UNIX/INSTALL where the

UNIX version of the AIPS installation procedures are  stored  and  from

which  much  of  the  installation  will  be performed.  Procedures for

performing quarterly updates on NRAO machines running UNIX as  well  as

nightly  updates  (i.e., the so called "midnight" jobs) are supposed to

be stored in $XXX/SYSTEM/UNIX/UPDATE and its subdirectories.

OVERVIEW                                                       Page 1-7

DISK SPACE REQUIREMENTS                                    9 April 1990





                                         SYSTEM

                                   ________/\________

                                  /                  \

                                 /                   VMS

                                /              ______/|\______

                               /              /       |       \

                              /        INSTALL   LOCAL   UPDATE

                             /                        |        |

                            /                      UPDATE     VLA

                          UNIX

      ____________________/|\____________________

     /      /      /       |       \      \      \

   ALLN   CRI   CVEX    INSTALL   LOCAL   SUN  UPDATE

             ___/ \___                     ______/ \______

            /         \                   /     /   \     \

         NRAO1       VLAC1             NRAO1  SUN3  SUN4 VLAC1

           |           |

        UPDATE      UPDATE









1.5.1.2  DEV Directories -



     A routine name that begins with Q, Y and Z indicates that it is at

least potentially device or operating system specific.







1.5.1.2.1  Z-routines -



     $XXX/APL/DEV and  its  subdirectories  contain  operating  system,

architecture   and  device  dependent  source  code  or  what  we  call

Z-routines (even though there are a few whose names begin with  another

letter).   Generic  forms  (i.e., those that are the same for more than

one system) are kept in the higher subdirectories of $XXX/APL/DEV (some

day there might even be some in $XXX/APL/DEV itself) and as you descend

the directory structure below $XXX/APL/DEV, the more specific the  code

becomes  (e.g.,  UNIX  versus  VMS,  Bell  versus Berkeley UNIX, Convex

versus Sun, etc.).

OVERVIEW                                                       Page 1-8

DISK SPACE REQUIREMENTS                                    9 April 1990





                                       APL

                        _______________/|\____________

                       /                |             \

                     DEV               SUB            PGM

                  ___/ \___             |               \

                 /         \            |                \

               UNIX        VMS        NOTST             NOTST

                |                       |             ___/ \___

                |                       |            /         \

                |                      VMS         UNIX        VMS

      _________/ \_________

     /                     \

   BELL                   BERK

   / \               ______/\______

  /   \             /    /    \    \

CRI   MASC       ALLN  CVEX   SUN  VAX

                     ___/\___

                    /        \

                 NRAO1      VLAC1





     The $XXX/APL/SUB branch is for  routines  that  are  in  principle

system  independent.   A  NOTST  area exists for those which, while not

fully following AIPS coding standards, stand a good chance  of  working

on  most  systems.   The  system  specific areas on this branch are for

peculiar non-standard routines that are not part of standard AIPS.  The

$XXX/APL/PGM  branch is for task programs.  It too has non-standard and

system specific  areas.   The  system  specific  areas  should  not  be

construed  as  an invitation to flood AIPS with machine dependent code.

Apart from the system specific areas containing  Z-routines,  the  UNIX

areas are essentially empty.  The same cannot be said of the VMS areas.

This is an unfortunate consequence of AIPS's VMS dominated adolescence.







1.5.1.2.2  Y-routines -



     Strictly TV display device oriented  routines,  or  Y-routines  as

they  are  called,  are  kept  in  $XXX/Y/DEV  and  its subdirectories.

$XXX/Y/DEV subdirectories exist for several vendors and  models  of  TV

display  devices  as  well  as  one  containing stubbed versions (i.e.,

$XXX/Y/DEV/STUB) for installations with no TV.  The most generic  forms

are kept in $XXX/Y/DEV and as you descend the directory structure below

$XXX/Y/DEV, the more vendor or model specific the code becomes.



                                                        Y

                         ______________________________/|\_________

                        /                               |          \

                      DEV                              PGM         SUB

    __________________/|\__________________            / \          |

   /    /    /    /    |    \    \    \    \          /   \         |

ARGS  DEA  IIS  IVAS  LEX   SSS STUB  V20  VTV     VDEV  NOTST    NOTST

           / \         |     |                             |

          /   \        |     |                             |

OVERVIEW                                                       Page 1-9

DISK SPACE REQUIREMENTS                                    9 April 1990





        M70   M75     LEXC  SVU                           VMS





     The $XXX/Y/SUB branch is for routines that are in principle system

independent.   There  is  a NOTST area for those which, while not fully

following AIPS coding standards, stand a good chance of working on most

systems.   The  $XXX/Y/PGM  branch  is  for  task programs.  It too has

non-standard as well as  system  specific  areas.   Again,  the  system

specific  areas  should not be construed as an invitation to flood AIPS

with machine dependent code.







1.5.1.2.3  Q-routines -



     The most computationally intensive portion of the AIPS source code

has  been  isolated  into  what  we  call Q-routines and resides in the

subdirectories of $XXX/Q/DEV.  Several models of  FPS  (Floating  Point

Systems)  array  processors  are  supported  as  well as a pseudo array

processor library (i.e., $XXX/Q/DEV/PSAP)  for  installations  with  no

array  processor.  The pseudo array processor routines emulate an array

processor  in  memory.   Once  again,  as  you  descend  the  directory

structure  below  $XXX/Q/DEV,  the more vendor or architecture specific

the routines become.  The $XXX/Q/DEV/PSAP routines have been written to

vectorize  and/or  parallelize  on  machines that support such notions.

Beneath the $XXX/Q/DEV/PSAP directory you will find subdirectories  for

several  vector  register  machines including Alliant (ALLN) and Convex

(CVEX) where particularly efficient  versions  of  the  $XXX/Q/DEV/PSAP

routines are maintained.



                                            Q

                   ________________________/|\______

                  /                         |       \

                DEV                        SUB      PGM

            ___ / \_________                |         \

           /                \               |          \

         FPS                PSAP          NOTST       NOTST

         / \         _______/ \_______                  |

        /   \       /     /     \     \                 |

      32B   16B   ALLN  CRI    CVEX   VMS              VMS

      /     / \

     /     /   \

   190  120B   5000





     The $XXX/Q/SUB branch is for routines that are in principle system

independent.   There  is  a  NOTST area for those which while not fully

following AIPS coding standards stand a good chance of working on  many

systems.   The  $XXX/Q/PGM  branch  is  for  task programs.  It too has

non-standard as well as  system  specific  areas.   Again,  the  system

specific  areas  should  not  be considered an invitation to flood AIPS

with machine dependent code.

OVERVIEW                                                      Page 1-10

DISK SPACE REQUIREMENTS                                    9 April 1990





     By this point, it must be obvious that there are a large number of

directories  that  you can safely eliminate.  In addition to the device

independent code, you need only keep  the  $XXX/*/DEV  and  $XXX/SYSTEM

subdirectories  relevant  to  your  installation.   However, if you are

porting AIPS to a new operating system or architecture, or  interfacing

a model of TV or array processor not already supported, you should find

the code in some of the existing directories useful as models.







1.5.2  Binary Files



     The disk  space  required  for  binary  files  (object  libraries,

program  object  modules,  executable modules and system files) is much

greater (roughly  90  Mbytes  per  release).   This  is  based  on  the

requirements  for  the  NRAO-CV  Convex  C-1  (NRAO1)  installation  (8

interactive plus 2 batch streams, 2 TV display devices plus 2 Tektronix

graphics   terminals  and  the  executable  modules  for  all  possible

programs).  The disk space consumed by C-1 binary files is shown below.

(these $XXX subdirectories are created by the installation procedures):



      Kbytes   Major branch



      1678         DA00

      5229         LIBR

      131650       LOAD

      5881         MEMORY





     The additional disk space required  for  the  TV  and/or  graphics

terminal  is  minimal.   The disk space requirements for "memory" files

increases in proportion to the number of interactive and batch streams,

but again, this is rather minimal.  The real disk hog is the executable

or "load" module library.  Executable modules  under  UNIX  are  rather

large  compared  to  VMS.  A possible reason for this is that some data

arrays may be kept in expanded form in the executable module itself.  A

discussion  of  unnecessary  load  modules  is beyond the scope of this

document and will largely depend on whether your installation has a  TV

display  and/or  graphics  terminal  and,  of course, the needs of your

users.  However, there are several likely candidates that fall into the

category  of stand alone system manager utility programs (as opposed to

AIPS "tasks").  For example, not  all  the  CATCH*  executable  modules

generated  from  the  programs found in the $XXX/AIPS/PGM directory are

necessary.  These  are  programs  designed  for  converting  user  data

already  on  disk  from  an old release format to a new release format.

This must be done in a stepwise fashion if more than  one  data  format

change  has  occurred  since a given AIPS site last updated its system.

In any case, if you don't need to perform any data format  conversions,

you certainly don't need these programs in any form.  However, don't be

too quick to delete things until you're  positive  that  they  are  not

needed.   Once your installation of AIPS has stabilized, you can always

move the source code to tape.

OVERVIEW                                                      Page 1-11

DISK SPACE REQUIREMENTS                                    9 April 1990





1.5.3  Selective Tar



     Since the syntax for executing "tar" varies  so  widely  from  one

UNIX  system  to  the  next, down loading the installation tape must be

performed manually.  The tape contains a single file generated via "tar

-cb  20  15MMMYY"  (e.g.,  tar  -cb  20  TEXT/IONS 15APR90).  Directory

branches can be selectively down loaded, for example,



   "tar x... TEXT/IONS 15APR90/AIPS 15APR90/APL 15APR90/HELP ..."



however, it is probably safer and  simpler  to  down  load  its  entire

contents, then delete whatever you don't need.







1.6  THE INSTALLATION PROCESS



     The first steps of the installation process involves creating  the

AIPS  account,  loading  the  installation  tape  to  disk and creating

several  "local"  directories  where  custom  versions  of  Z-routines,

procedures,  system  definition  files,  etc., are to be stored.  Among

other things, the procedure and system definition  files  you  need  to

copy  and  edit  are  used  to  establish the procedure and source code

search paths for your system.  They are also  used  to  map  the  local

compiler/loader  syntax  and options onto the syntax and options of the

the  AIPS  programming  procedures.   In   short,   this   amounts   to

establishing your AIPS system programming and execution environment and

is critical to the remainder  of  the  installation  process.   In  the

future,   much   of   this   may  be  handled  in  a  procedure  called

$XXX/SYSTEM/UNIX/INSTALL/INSTEP1 which currently does not exist.  Until

then, heavily commented, roughed in versions of the files that you will

need  to  copy  and   customize   are   provided   in   the   directory

$XXX/SYSTEM/UNIX.   You  will  also find examples for some systems with

which we have either had  first  hand  experience  or  that  have  been

contributed  by  non-NRAO sites.  These are stored in subdirectories of

$XXX/SYSTEM/UNIX             (e.g.,              $XXX/SYSTEM/UNIX/ALLN,

$XXX/SYSTEM/UNIX/CVEX/NRAO1, $XXX/SYSTEM/UNIX/SUN).



     As for the Z-routines that may require local development  (only  a

handful  hopefully),  the generic versions should suffice well into the

installation process.  Similarly, the Q-routines which  constitute  the

"vanilla"  pseudo array processor library (i.e., $XXX/Q/DEV/PSAP/*.FOR)

and the stubbed versions  of  Y-routines  (i.e.,  $XXX/Y/DEV/STUB/*.FOR

plus  $XXX/Y/DEV/*.FOR) will suffice until you are ready to address the

problem of local development for unsupported systems.



     Please DO NOT simply edit the distributed versions of  text  files

if  you  find  they  require modification.  In most cases the directory

structure and search path mechanisms provide for purely local versions.

Where  this  scheme  fails  and  you  need  to modify text files, first

preserve the original version in the same directory under  a  different

name.   Giving the preserved version a consistent, meaningful extension

(e.g., filename.NRAO) will facilitate the  communication  of  bugs  and

suggestions  to  NRAO.   Also,  text  file  comparison utilities (e.g.,

OVERVIEW                                                      Page 1-12

THE INSTALLATION PROCESS                                   9 April 1990





"diff") become useless when drastic changes are made to the code.   You

may not like our typing standards, but we simply don't have the time to

extract differences by hand from large text  files.   It  may  also  be

necessary  to  login  remotely  to  your  system to provide assistance.

Masking changes to the  system  not  called  for  by  the  installation

instructions can make such "house calls" much more difficult.



     Ignoring any custom coding (Q, Y or Z-routines) and any AIPS  data

file  updating  that may be required, the remainder of the installation

process is largely  automated.   $XXX/SYSTEM/UNIX/INSTALL/INSTEP2  will

attempt  to  compile all the required routines based on the source code

search path definitions and create various object libraries from  them.

This  step  can take quite a while since it must locate, preprocess and

compile approximately 1000 routines.  Some  400  routines  precede  the

Z-routines,  so  the  first  part  of  INSTEP2 is a good time to putter

around with the few Z-routines and Z-procedures that require any  local

development  (see  Chapter  3).   In  particular, on DEC or Intel-style

processors where "little endian" byte ordering is used,  the  value  of

BYTFLP  as set in the routine ZDCHI2 must be changed.  Also, the values

for SPFRMT, DPFRMT, TTYCAR  as  well  as  other  system  constants  and

parameters defined in the routine ZDCHI2 should be checked and modified

as required.  Unless they already  exist  from  a  previous  execution,

INSTEP2  (also  INSTEP3  and INSTEP4) will generate what are called "@"

files (i.e., "at" files).  These files contain  lists  of  source  code

path  names  and  are  used  to  drive  the  compilation and/or linking

procedures.  These lists  are  automatically  edited  and  checkpointed

after  each  successful  module creation.  Therefore, in the event that

either the system crashes or a given module creation fails,  corrective

action  can  be  taken  and  INSTEP2  (also INSTEP3 and INSTEP4) can be

restarted in midstream.



     The third step of the installation process involves the  execution

of $XXX/SYSTEM/INSTALL/INSTEP3 which will attempt to compile and link a

small but highly representative subset of stand alone programs and task

programs.  The programs involved represent:



     1.  the stand alone programs required to create and initialize the

         AIPS system files



     2.  AIPS itself



     3.  a dozen or so of the most heavily used task programs





     The AIPS system files that must be generated are  files  that  are

required  before  any  AIPS  program  can be executed.  These include a

system parameter file, an accounting file, batch queue and  batch  work

files,  a  password  file,  image  catalog files, a task communications

file, a "gripes" file, and POPS "memory" files.  These are created  via

the program FILAIP which prompts for its inputs.  This must be followed

by the execution of the program POPSGN to initialize  the  POPS  memory

files  (POPS  is  the  command language of AIPS).  Finally, the program

SETPAR should be run to set the system parameters  not  set  by  FILAIP

during  the  system  parameter  file  creation.  In addition, for those

OVERVIEW                                                      Page 1-13

THE INSTALLATION PROCESS                                   9 April 1990





systems with TVs, the program SETTVP may also need to be run  in  order

to  change  the  default TV parameters.  After these programs have been

run, you are ready to actually run AIPS and execute tasks.



     NOTE:  Most of the task program executables generated  by  INSTEP3

are  the  same  ones used in what is known as the "Dirty Dozen Test" or

"DDT".  This test is used to regenerate images and  UV  datasets  which

are  then  compared  against  a  master  set  in  order  to  certify an

installation.  The master set is available on  request  from  the  AIPS

group.   The DDT is also used internally to measure both consistency of

results (i.e., regression testing) and performance  (i.e.,  benchmarks)

from  release  to  release.   Performance  data  on  new systems in the

community are always welcome.



     The fourth step of the installation process involves the execution

of  $XXX/SYSTEM/INSTALL/INSTEP4  which is much like INSTEP2 and INSTEP3

except that it will attempt to compile  and  link  all  possible  stand

alone  programs  and task programs of the AIPS system.  Given this, the

foolhardy may be tempted to skip INSTEP3 since its actions are included

in  INSTEP4.  This is true, but it's well worthwhile testing the system

a fair amount before generating the remainder of the  system.   If  the

programs  of INSTEP3 won't work, it's pointless and wasteful to execute

INSTEP4 which involves some 220 programs and can take almost as long to

complete as INSTEP2, if not longer.



     The final steps in the installation process involve any  necessary

customization of Z-routines and Z-procedures and any conversion of user

data files that may be required as a result of format changes.  This is

only  required if the current installation is an AIPS system update and

the AIPS data format has changed.

























                               CHAPTER 2



                          INSTALLATION STEP 1







2.1  INTRODUCTION



     Before  executing  any  of  the   $XXX/SYSTEM/UNIX/INSTALL/INSTEP*

procedures,   you'll  need  to  create  your  "local"  directories  and

otherwise configure the local AIPS programming environment.  This is an

entirely manual process at the moment, but should give you a great deal

of insight into the AIPS programming philosophy.







2.2  THE AIPS ACCOUNT



     Have your system manager create an account for use with  AIPS.   A

good  name  for  the  account is "aips" but not an absolutely necessary

one.  The default login shell may be the Bourne shell, C shell or  Korn

shell.   At  NRAO,  most AIPS usage is conducted from this account or a

special account setup for AIPS usage, but AIPS may also be executed  or

programmed  from  private accounts provided the AIPS system directories

are setup with the proper group and/or "world"  permissions.   AIPS  is

designed to run without any special privileges, but in order to program

from other logins, you may want to establish  an  AIPS  "group".   AIPS

creates  its  data  files  with  666  (i.e.,  "-rw-rw-rw-") permissions

explicitly, however, this may be changed by modifying the file creation

Z-routine  ZCREA2.   Prior  to  execution, the value for "umask" should

also be the same (i.e., 000 =>  666  permissions).   If  possible,  the

system  source  and  binary  code  for  one AIPS release (e.g., 15APR90

versus 15JAN90) should reside entirely on one file  system.   The  AIPS

installation  and programming procedures move files around and the "mv"

command may fail on some systems if the move is  to  a  different  file

system.



     In addition to being very compute intensive, AIPS is also very I/O

intensive  in  many  cases  (the  task UVSRT is a good example).  It is

therefore useful to configure user data areas  on  multiple  disks  and

controllers  in  order  to  establish as many independent data paths as

possible and thereby  reduce  I/O  contention.   AIPS  is  designed  to

distribute  its  scratch  files  over  as  many  of these disks as have

sufficient space, however, users have a tendency to first fill  up  one

disk and then the next.  Instead, they should be encouraged to exercise

I/O load leveling if at all possible.  This  means  leaving  sufficient

INSTALLATION STEP 1                                            Page 2-2

THE AIPS ACCOUNT                                           9 April 1990





space on each disk for an even distribution of scratch files.







2.3  LOADING THE INSTALLATION TAPE



     To load the installation tape, login to your AIPS  account,  mount

the  tape  and  "tar" its contents to disk.  On most systems this is as

simple as typing



tar x                  (x for "extract")





     particularly  if  there's  only  one  tape  drive  on  the  system

Multi-drive  systems  may require somewhat more complicated tar command

arguments to select the proper drive (and  density  perhaps).   Consult

the  reference  manual  for  the  details  on using tar on your system.

Again,  we  recommend  that  you  tar  the  entire  contents   of   the

installation  tape to disk, then delete unnecessary or irrelevant files

and directories.  "Tar" will create a directory with a name of the form

15MMMYY (e.g., 15APR90) which corresponds to the release date.  This is

the directory  we  have  referred  to  as  $XXX  and  should  have  the

subdirectories  AIPS, APL, DOC, HELP, HIST, INC, Q, QY, RUN, SYSTEM and

Y.  Some of these  represent  the  roots  of  some  rather  complicated

directory trees (e.g., APL, Q and Y).  Others have no subdirectories at

all   (e.g.,   HELP,   RUN).    More   will   be   created    by    the

$XXX/SYSTEM/UNIX/INSTALL/INSTEP*   procedures,   in   particular,   the

directories for the binary files.







2.4  LOCAL DIRECTORIES



     The number of purely local directories  required  will  depend  on

several  factors.   A  local  SYSTEM  directory  plus a local Z-routine

directory are the minimum.  If your system has no TV or has a  TV  that

is  supported  in the distributed $XXX/Y/DEV subdirectory hierarchy, no

local Y-routine directory may be necessary.  Similarly, if your  system

has  no  AP  and/or the $XXX/Q/DEV/PSAP (pseudo AP library) and perhaps

one of its subdirectories is sufficient for your system,  you  probably

won't  need  a  local  Q-routine  directory  either.   Even if you must

eventually develop Q-routines  for  your  system,  the  $XXX/Q/DEV/PSAP

library   will  suffice  for  the  initial  installation  as  will  the

$XXX/Y/DEV/STUB library in the case of Y-routines.  In any  case,  this

is    a    good   time   to   create   such   directories   (at   least

$XXX/SYSTEM/UNIX/LOCAL and a local Z-routine directory), invent logical

definitions for them and map out a source code search path.



     NOTE:   The  distribution   tape   may   contain   the   directory

$XXX/SYSTEM/UNIX/LOCAL (or symbolic link).  If so, delete it and create

your  own.   It  comes  from  generating  the  distribution  tape  from

production AIPS installation on one of our systems.

INSTALLATION STEP 1                                            Page 2-3

LOCAL DIRECTORIES                                          9 April 1990





     The directory structure beneath $XXX/SYSTEM/UNIX  looks  something

like the following:



$XXX/SYSTEM/UNIX                         (Generic UNIX)

$XXX/SYSTEM/UNIX/ALLN                    (Alliant specific)

$XXX/SYSTEM/UNIX/CRI                     (Cray Research, Inc. specific)

$XXX/SYSTEM/UNIX/CVEX                    (Convex specific)

$XXX/SYSTEM/UNIX/CVEX/NRAO1              (NRAO-CV Convex specific)

$XXX/SYSTEM/UNIX/CVEX/VLAC1              (NRAO-VLA Convex specific)

$XXX/SYSTEM/UNIX/INSTALL                 (Generic UNIX installation)

$XXX/SYSTEM/UNIX/LOCAL                   (Local directory or a link

                                         to it)

$XXX/SYSTEM/UNIX/SUN                     (Sun specific)

$XXX/SYSTEM/UNIX/UPDATE                  (Quarterly and nightly update

                                         procedures)





     The way $CDOLD, $CDNEW and $CDTST work, the local SYSTEM directory

must   be   $XXX/SYSTEM/UNIX/LOCAL.   An  alternative  available  under

Berkeley UNIX is to make  $XXX/SYSTEM/UNIX/LOCAL  a  symbolic  link  to

another     directory     (e.g.,     ln    -s    $XXX/SYSTEM/UNIX/LOCAL

$XXX/SYSTEM/UNIX/SUN/RIGEL).  In any case, since many  of  the  current

procedures  have  $XXX/SYSTEM/UNIX/LOCAL  hard  coded  into  them, this

dictates the pathname of $SYSLOCAL.  This will probably be  changed  in

future  releases.   However, as of the 15JAN90 release, $SYSLOCAL is no

longer defined in AREAS.CSH or AREAS.SH.  Instead, it  is  defined  (as

always)  in  LOGIN.CSH  and/or  LOGIN.SH  (just to establish an initial

pathname)    and    thereafter,    in    $SYSLOCAL/CDVER.CSH     and/or

$SYSLOCAL/CDVER.SH.    CDVER.*  is  also  where  other  strictly  local

directories should  be  defined,  for  example,  $QLOCAL,  $YLOCAL  and

$ZLOCAL  for  local  Q, Y and Z-routines, respectively (see "Local Area

Logicals").



     Z-routines  are  stored  under  $XXX/APL/DEV  and  its   directory

structure looks something like the following:



$XXX/APL/DEV                             (Generic)

$XXX/APL/DEV/UNIX                        (Generic UNIX)

$XXX/APL/DEV/UNIX/BELL                   (Bell UNIX)

$XXX/APL/DEV/UNIX/BELL/MASC              (Masscomp Bell)

$XXX/APL/DEV/UNIX/BERK                   (Berkeley UNIX)

$XXX/APL/DEV/UNIX/BERK/ALLN              (Alliant Berkeley)

$XXX/APL/DEV/UNIX/BERK/CVEX              (Convex Berkeley)

$XXX/APL/DEV/UNIX/BERK/CVEX/NRAO1        (local NRAO-CV Convex)

$XXX/APL/DEV/UNIX/BERK/CVEX/VLAC1        (local NRAO-VLA Convex)

$XXX/APL/DEV/UNIX/BERK/VAX               (VAX Berkeley)

$XXX/APL/DEV/UNIX/BERK/SUN               (Sun Berkeley)

$XXX/APL/DEV/VMS                         (DEC's VMS)





     To maintain the hierarchical structre, you  should  position  your

local  directory  such  that  it  accurately  reflects your system, for

example, $XXX/APL/DEV/UNIX/BERK/ALLN/CERBERUS might be the  choice  for

an  Alliant  system.   Our Bell UNIX system support is rather dated and

INSTALLATION STEP 1                                            Page 2-4

LOCAL DIRECTORIES                                          9 April 1990





probably incomplete.  If  your  system  is  based  on  Bell  UNIX,  but

supports   Berkeley  UNIX  extensions,  you  should  probably  use  the

$XXX/APL/DEV/UNIX/BERK branch.



     Y-routines are stored under $XXX/Y/DEV and its directory structure

looks something like the following:



$XXX/Y/DEV                               (Generic)

$XXX/Y/DEV/ARGS                          (ARGS pipe from M70)

$XXX/Y/DEV/DEA                           (DeAnza)

$XXX/Y/DEV/IIS                           (IIS)

$XXX/Y/DEV/IIS/M70                       (IIS model 70)

$XXX/Y/DEV/IIS/M75                       (IIS model 75)

$XXX/Y/DEV/IVAS                          (IIS model IVAS)

$XXX/Y/DEV/SSS                           (SUN Screen Server)

$XXX/Y/DEV/SVU                           (Sunview)

$XXX/Y/DEV/STUB                          (Stubbed)

$XXX/Y/DEV/V20                           (Comtal Vision 1/20)

$XXX/Y/DEV/VTV                           (Virtual TV routine area)

$XXX/Y/DEV/LEX                           (Lexidata)

$XXX/Y/DEV/LEX/LEXC                      (Lexidata written in C)





     If you have no  TV  (use  $XXX/Y/DEV/STUB)  or  have  one  of  the

supported  TV  display  devices, then you probably won't need to do any

Y-routine development.  Otherwise, you should logically  position  your

local  Y-routine  directory  as  in  the  case  of your local Z-routine

directory.  You  may  also  safely  elect  to  postpone  any  Y-routine

development  by  defining $XXX/DEV/Y/STUB followed by $XXX/DEV/Y as the

only directories in your Y-routine source code search path (see "Object

Libraries and Source Code Search Paths").



     NOTE:  Y-routines should be developed to be device  specific  only

(if  at  all possible), not operating system specific or subject to the

availability of specific languages or compilers.



     Q-routines are stored under $XXX/Q/DEV and its directory structure

looks something like the following:



$XXX/Q/DEV                               (Generic)

$XXX/Q/DEV/FPS                           (Floating Point Systems AP)

$XXX/Q/DEV/FPS/16B                       (16 bit FPS)

$XXX/Q/DEV/FPS/16B/120B                  (FPS model 120B)

$XXX/Q/DEV/FPS/16B/5000                  (FPS models 5105, 5205 ...)

$XXX/Q/DEV/FPS/32B                       (32 bit FPS)

$XXX/Q/DEV/FPS/32B/190                   (FPS model 190)

$XXX/Q/DEV/PSAP                          (Pseudo AP)

$XXX/Q/DEV/PSAP/ALLN                     (Alliant specific)

$XXX/Q/DEV/PSAP/CVEX                     (Convex specific)

$XXX/Q/DEV/PSAP/VMS                      (VMS specific)



INSTALLATION STEP 1                                            Page 2-5

LOCAL DIRECTORIES                                          9 April 1990





     If  you  have  no  AP  or  if  your  system  matches  any  of  the

subdirectories  of  $XXX/Q/DEV/PSAP, chances are you won't need a local

Q-routine directory.  Otherwise, you  should  logically  position  your

local  directory subject to a hierarchical search.  You may also safely

elect  to  postpone  any  Q-routine   development   by   defining   the

$XXX/Q/DEV/PSAP  directory  as  the  only  directory  in your Q-routine

search path.







2.5  AREA LOGICALS



     In the parlance of the AIPS group, directories are often  referred

to  as  "areas"  and  even  more  often  referred to by their sometimes

unpronounceable "logical" names.  In the  case  of  UNIX,  the  logical

names  for  areas  take  the  form  of  environment variables (or shell

variables if you prefer).  Apart from local area  logicals,  these  are

defined   in   $XXX/SYSTEM/UNIX/AREAS.*.   The  areas  are  defined  in

AREAS.CSH using C shell syntax and defined in AREAS.SH using Bourne  or

Korn  shell  syntax.   The  logical  names,  though  they  may often be

unpronounceable,  serve  as  shorthand,  often  mnemonic  devices   for

programming  in  the  AIPS  environment.   In addition, the programming

tools depend heavily on them.  With experience, programmers  can  often

derive  the  full  path name to an area from its logical name, although

there are some irritating inconsistencies like $YGEN and $QDEV.



     NOTE:  Prior to the 15JAN90 release,  the  installation  procedure

called  for  copying AREAS.CSH and/or AREAS.SH from $XXX/SYSTEM/UNIX to

your local SYSTEM  directory  and  modifying  them/it  to  include  the

definitions  for  any  local  "areas" (i.e., directories) that you have

created.    These   days,   local   areas   are   defined    only    in

$SYSLOCAL/CDVER.CSH   and/or   $SYSLOCAL/CDVER.SH   (see   "Local  Area

Logicals").



     The $XXX/SYSTEM/UNIX versions of AREAS.CSH and AREAS.SH that  come

on  the installation tape are actually generated from yet a third file,

$XXX/SYSTEM/AREAS.DAT.  The utility script $XXX/SYSTEM/UNIX/AREAS reads

$XXX/SYSTEM/AREAS.DAT  and massages it into the proper syntax to create

$XXX/SYSTEM/UNIX/AREAS.CSH and $XXX/SYSTEM/UNIX/AREAS.SH.  The text  of

$XXX/SYSTEM/AREAS.DAT follows:



! "--------------------------------------------------------------------"

! " AREAS.DAT                                                          "

! "--------------------------------------------------------------------"

! " This file defines the entire AIPS directory structure (relative to "

! " a 'version' directory node) plus the 'logical' associated with     "

! " each 'area' (i.e., directory).                                     "

! "                                                                    "

! " UNIX: The script $SYSUNIX/AREAS uses $SYSAIPS/AREAS.DAT to create  "

! " $SYSUNIX/AREAS.CSH and $SYSUNIX/AREAS.SH, which contain C shell    "

! " and Bourne/Korn shell syntax, respectively, to define the area     "

! " logicals in terms of environment variables.  The definitions are   "

! " toggled between different versions of AIPS by executing $CDOLD,    "

! " $CDNEW or $CDTST, which are defined $AIPS_ROOT/LOGIN.CSH and/or    "

INSTALLATION STEP 1                                            Page 2-6

AREA LOGICALS                                              9 April 1990





! " $AIPS_ROOT/LOGIN.SH.  The AREAS.* environment variables are NOT    "

! " required for the execution of AIPS programs, just for AIPS         "

! " programming.  In fact, having all the area logicals defined takes  "

! " up such a large fraction of the available environment space on     "

! " some systems that the execution of AIPS programs, UNIX commands,   "

! " AIPS programming tools and system debuggers can be impaired.  To   "

! " avoid this, it may be necessary to comment out some or all of the  "

! " definitions that don't apply to the host implementation.           "

! "                                                                    "

! " VMS: AIPS_PROC:ASSNLOCAL.COM uses this file more or less directly  "

! " to establish the definitions of area logicals.  The definitions    "

! " are toggled between different versions of AIPS by executing the    "

! " AIPS defined 'VERSION' command (see AIPS_PROC:AIPSUSER.COM), e.g., "

! " 'VERSION NEW'.                                                     "

! "--------------------------------------------------------------------"

! " Top level directories of source code areas                         "

! "--------------------------------------------------------------------"

!

AIP             AIPS

APL             APL

Q               Q

QY              QY

Y               Y

!

! "--------------------------------------------------------------------"

! " AIPS program areas                                                 "

! "--------------------------------------------------------------------"

!

!                                       "Standard programs"

AIPPGM          AIPS.PGM

!                                       "Non-standard programs"

AIPNOT          AIPS.PGM.NOTST

!                                       "UNIX non-standard programs"

AIPGUNIX        AIPS.PGM.NOTST.UNIX

!                                       "VMS non-standard programs"

AIPGVMS         AIPS.PGM.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " AIP subroutine areas - only referenced by AIP* programs            "

! "--------------------------------------------------------------------"

!

AIPSUB          AIPS.SUB

!

! "--------------------------------------------------------------------"

! " APL program areas - these reference only APL* routines             "

! "--------------------------------------------------------------------"

!

!                                       "Standard programs"

APLPGM          APL.PGM

!                                       "Non-standard programs"

APGNOT          APL.PGM.NOTST

!                                       "UNIX programs"

APGUNIX         APL.PGM.NOTST.UNIX

!                                       "VMS programs"

INSTALLATION STEP 1                                            Page 2-7

AREA LOGICALS                                              9 April 1990





APGVMS          APL.PGM.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " APL subroutine areas - nothing here references Q or Y-routines     "

! "--------------------------------------------------------------------"

!

!                                       "Standard routines"

APLSUB          APL.SUB

!                                       "Non-standard routines"

APLNOT          APL.SUB.NOTST

!                                       "VMS non-standard routines"

APLNVMS         APL.SUB.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " Z-routine areas                                                    "

! "--------------------------------------------------------------------"

!

!                                       "Generic"

APLGEN          APL.DEV

!                                       "Generic UNIX"

APLUNIX         APL.DEV.UNIX

!                                       "Bell UNIX"

APLBELL         APL.DEV.UNIX.BELL

!                                       "Cray Research Inc"

APLCRI          APL.DEV.UNIX.BELL.CRI

!                                       "Masscomp"

APLMASC         APL.DEV.UNIX.BELL.MASC

!                                       "Berkeley UNIX"

APLBERK         APL.DEV.UNIX.BERK

!                                       "Alliant"

APLALLN         APL.DEV.UNIX.BERK.ALLN

!                                       "Convex"

APLCVEX         APL.DEV.UNIX.BERK.CVEX

!                                       "NRAO-VLA Convex local"

APLVLAC1        APL.DEV.UNIX.BERK.CVEX.VLAC1

!                                       "NRAO-CV Convex local"

APLNRAO1        APL.DEV.UNIX.BERK.CVEX.NRAO1

!                                       "Sun"

APLSUN          APL.DEV.UNIX.BERK.SUN

!                                       "VAX"

APLVAX          APL.DEV.UNIX.BERK.VAX

!                                       "Generic VMS"

APLVMS          APL.DEV.VMS

!

! "--------------------------------------------------------------------"

! " Documentation areas                                                "

! "--------------------------------------------------------------------"

!

DOC             DOC

DOCTXT          DOC.TEXT

!

! "--------------------------------------------------------------------"

! " Core dump area                                                     "

! "--------------------------------------------------------------------"

INSTALLATION STEP 1                                            Page 2-8

AREA LOGICALS                                              9 April 1990





!

ERRORS          ERRORS

!

! "--------------------------------------------------------------------"

! " HELP file area                                                     "

! "--------------------------------------------------------------------"

!

HLPFIL          HELP

!

! "--------------------------------------------------------------------"

! " History area                                                       "

! "--------------------------------------------------------------------"

!

HIST            HIST

!

! "--------------------------------------------------------------------"

! " INCLUDE file areas                                                 "

! "--------------------------------------------------------------------"

!

!                                       "Standard INCLUDEs"

INC             INC

!                                       "Non-standard INCLUDEs"

INCNOT          INC.NOTST

!                                       "Local"

INCLOC          INC.LOCAL

!                                       "Alliant"

INCALN          INC.NOTST.ALLN

!                                       "Cray Research Inc"

INCCRI          INC.NOTST.CRI

!                                       "Convex"

INCVEX          INC.NOTST.CVEX

!                                       "VMS"

INCVMS          INC.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " Object module areas                                                "

! "--------------------------------------------------------------------"

!

!                                       "Subroutine object libraries"

LIBR            LIBR

!                                       "Executable modules"

LOAD            LOAD

!                                       "Alternate executable modules"

!                                       "Pseudo AP w/wo TV 1"

LOAD1           LOAD.ALT1

!                                       "TV 2 w/wo real AP"

LOAD2           LOAD.ALT2

!                                       "TV 2 w Pseudo AP"

LOAD3           LOAD.ALT3

!

! "--------------------------------------------------------------------"

! " POPS memory file area                                              "

! "--------------------------------------------------------------------"

!

INSTALLATION STEP 1                                            Page 2-9

AREA LOGICALS                                              9 April 1990





MEMORY          MEMORY

!

! "--------------------------------------------------------------------"

! " Q-routine areas (real and pseudo array processor)                  "

! "--------------------------------------------------------------------"

!

!                                       "Generic"

QDEV            Q.DEV

!                                       "Generic FPS"

QFPS            Q.DEV.FPS

!                                       "16 bit FPS"

QFPS16          Q.DEV.FPS.16B

!                                       "Model 120B FPS"

Q120B           Q.DEV.FPS.16B.120B

!                                       "Models 5105, 5205 ... FPS"

Q5000           Q.DEV.FPS.16B.5000

!                                       "32 bit FPS"

QFPS32          Q.DEV.FPS.32B

!                                       "Model 190 FPS"

Q190            Q.DEV.FPS.32B.190

!                                       "Generic pseudo AP"

QPSAP           Q.DEV.PSAP

!                                       "Alliant pseudo AP"

QALN            Q.DEV.PSAP.ALLN

!                                       "Cray Research Inc pseudo AP"

QCRI            Q.DEV.PSAP.CRI

!                                       "Convex pseudo AP"

QVEX            Q.DEV.PSAP.CVEX

!                                       "VMS pseudo AP"

QVMS            Q.DEV.PSAP.VMS

!

! "--------------------------------------------------------------------"

! " Programs that reference Q-routines                                 "

! "--------------------------------------------------------------------"

!

!                                       "Standard programs"

QPGM            Q.PGM

!                                       "Non-standard programs"

QPGNOT          Q.PGM.NOTST

!                                       "VMS programs"

QPGVMS          Q.PGM.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " Subroutines that reference Q-routines                              "

! "--------------------------------------------------------------------"

!

!                                       "Standard routines"

QSUB            Q.SUB

!                                       "Non-standard routines"

QNOT            Q.SUB.NOTST

!

! "--------------------------------------------------------------------"

! " Programs that reference both Q-routines and Y-routines             "

! "--------------------------------------------------------------------"

INSTALLATION STEP 1                                           Page 2-10

AREA LOGICALS                                              9 April 1990





!

!                                       "Standard programs"

QYPGM           QY.PGM

!                                       "Non-standard programs"

QYPGNOT         QY.PGM.NOTST

!                                       "VMS programs"

QYPGVMS         QY.PGM.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " System RUN file area - useful procedures for everyone              "

! "--------------------------------------------------------------------"

!

RUNSYS          RUN

!

! "--------------------------------------------------------------------"

! " System manager areas                                               "

! "--------------------------------------------------------------------"

!

!                                       "Midnight job data area"

UPDATE          UPDATE

!                                       "Generic"

SYSAIPS         SYSTEM

!                                       "Generic UNIX"

SYSUNIX         SYSTEM.UNIX

!                                       "Alliant"

SYSALLN         SYSTEM.UNIX.ALLN

!                                       "Cray Research Inc"

SYSCRI          SYSTEM.UNIX.CRI

!                                       "Convex"

SYSCVEX         SYSTEM.UNIX.CVEX

!                                       "NRAO-VLA Convex local"

SYSVLAC1        SYSTEM.UNIX.CVEX.VLAC1

!                                       "NRAO-CV Convex local"

SYSNRAO1        SYSTEM.UNIX.CVEX.NRAO1

!                                       "Sun"

SYSSUN          SYSTEM.UNIX.SUN

!                                       "UNIX installation"

INSUNIX         SYSTEM.UNIX.INSTALL

!                                       "UNIX midnight and quarterly"

!                                       "update"

UPDUNIX         SYSTEM.UNIX.UPDATE

!                                       "NRAO-CV Convex midnight and"

!                                       "quarterly update"

UPDNRAO1        SYSTEM.UNIX.UPDATE.NRAO1

!                                       "NRAO-VLA Convex midnight and"

!                                       "quarterly update"

UPDVLAC1        SYSTEM.UNIX.UPDATE.VLAC1

!                                       "Generic VMS"

SYSVMS          SYSTEM.VMS

!                                       "Local VMS"

SYSLVAX         SYSTEM.VMS.LOCAL

!                                       "VMS installation"

INSVMS          SYSTEM.VMS.INSTALL

!                                       "VMS midnight and quarterly"

INSTALLATION STEP 1                                           Page 2-11

AREA LOGICALS                                              9 April 1990





!                                       "update"

UPDVMS          SYSTEM.VMS.UPDATE

!                                       "NRAO-VLA VAXn midnight and"

!                                       "quarterly update"

UPDVLA          SYSTEM.VMS.UPDATE.VLA

!

! "--------------------------------------------------------------------"

! " Y-routine areas                                                    "

! "--------------------------------------------------------------------"

!

!                                       "Generic"

YGEN            Y.DEV

!                                       "ARGS pipe from M70"

YARGS           Y.DEV.ARGS

!                                       "Deanza"

YDEA            Y.DEV.DEA

!                                       "IIS generic"

YIIS            Y.DEV.IIS

!                                       "IIS Model IVAS"

YIVAS           Y.DEV.IVAS

!                                       "IIS Model 70"

YM70            Y.DEV.IIS.M70

!                                       "IIS Model 75"

YM75            Y.DEV.IIS.M75

!                                       "Lexidata"

YLEX            Y.DEV.LEX

!                                       "Lexidata C code"

YLEXC           Y.DEV.LEX.LEXC

!                                       "SUN Screen Server"

YSSS            Y.DEV.SSS

!                                       "SSS - SunView *.C"

YSVU            Y.DEV.SSS.SVU

!                                       "Stubbed"

YSTUB           Y.DEV.STUB

!                                       "Comtal Vision 1/20"

YV20            Y.DEV.V20

!                                       "Virtual TV"

YVTV            Y.DEV.VTV

!

! "--------------------------------------------------------------------"

! " Programs that reference Y-routines                                 "

! "--------------------------------------------------------------------"

!

!                                       "Standard programs"

YPGM            Y.PGM

!                                       "Virtual TV program"

YPGVDEV         Y.PGM.VDEV

!                                       "Non-standard programs"

YPGNOT          Y.PGM.NOTST

!                                       "VMS programs"

YPGVMS          Y.PGM.NOTST.VMS

!

! "--------------------------------------------------------------------"

! " Subroutines that reference Y-routines                              "

INSTALLATION STEP 1                                           Page 2-12

AREA LOGICALS                                              9 April 1990





! "--------------------------------------------------------------------"

!

!                                       "Standard routines"

YSUB            Y.SUB

!                                       "Non-standard routines"

YNOT            Y.SUB.NOTST



     It should be noted that some UNIX systems may choke on the size of

an environment resulting from so many definitions.  The limiting factor

is the value of NCARGS as defined in /usr/include/sys/param.h.  This is

the  maximum  number of characters that can appear in an argument list.

Since the environment is passed as part of the argument list,  a  large

environment can start to cause problems for "wild card" operations like

"ls long_directory_path_name/*".  NCARGS is  typically  10240  so  this

does  not usually present a problem.  On some systems it may be smaller

and you may find it necessary to eliminate  some  of  the  definitions,

unless  of  course,  you  want  to  rebuild  your  system kernel with a

sufficiently large value  for  NCARGS,  but  eliminating  some  of  the

definitions  for  those areas that you have chosen to delete as part of

any disk space economizing and that otherwise have no relevance to your

implementation of AIPS is probably a simpler solution.







2.6  LOCAL AREA LOGICALS



     As of the 15JAN90 release, local area logicals should  be  defined

in  CDVER.CSH  and/or  CDVER.SH as stored in the $XXX/SYSTEM/UNIX/LOCAL

directory.   You   should   copy   CDVER.CSH   and/or   CDVER.SH   from

$XXX/SYSTEM/UNIX  to  $XXX/SYSTEM/UNIX/LOCAL  and  add your local "area

logical" definitions.  Even if you don't plan  to  use  some  of  these

areas  yet,  it  doesn't  hurt  to  give them logical definitions.  The

$XXX/SYSTEM/UNIX versions of CDVER.CSH and CDVER.SH are shown below:

# "--------------------------------------------------------------------"

# " Usage: source CDVER.CSH                                            "

# "--------------------------------------------------------------------"

# " This file is used to establish the AIPS programming area logicals  "

# " (environment variables) as defined in $SYSUNIX/AREAS.CSH (created  "

# " from $SYSAIPS/AREAS.DAT by the $SYSUNIX/AREAS script) or toggle    "

# " these definitions between different AIPS versions (i.e., OLD, NEW  "

# " and TST).  Normally, it is only used by the environment variables  "

# " $CDOLD, $CDNEW and $CDTST.  Area logicals for local directories    "

# " should be defined here, not in $SYSUNIX/AREAS.CSH.  This includes  "

# " $SYSLOCAL, which (for the moment) *MUST* be $SYSUNIX/LOCAL, but    "

# " also any directories containing local Q, Y or Z routines.  It also "

# " toggles the search path for executables (i.e., $PATH) to include   "

# " the directories $SYSLOCAL and $SYSUNIX.                            "

# "                                                                    "

# " Generic C shell version.                                           "

# "--------------------------------------------------------------------"

#                                       "Define/redefine standard AIPS "

#                                       "programming logicals.         "

source $AIPS_VERSION/SYSTEM/UNIX/AREAS.CSH

#                                       "$SYSLOCAL must be defined as  "

INSTALLATION STEP 1                                           Page 2-13

LOCAL AREA LOGICALS                                        9 April 1990





#                                       "follows.                      "

setenv SYSLOCAL $SYSUNIX/LOCAL

#                                       "Redefine execution search     "

#                                       "path (initially established   "

#                                       "by LOGIN.CSH during login) to "

#                                       "search $SYSLOCAL, then        "

#                                       "$SYSUNIX for AIPS scripts.    "

setenv PATH .:"$SYSLOCAL":"$SYSUNIX":"$TPATH"

#                                       "Define any local area logicals"

#                                       "here (e.g., Q, Y or Z-routine "

#                                       "directories).  For example,   "

#

#                                       "setenv QLOCAL $QPSAP/LOCAL    "

#                                       "setenv YLOCAL $YIVAS/LOCAL    "

#                                       "setenv ZLOCAL $APLSUN/LOCAL   "

#

#                                       "Be sure to include your local "

#                                       "area logicals in your         "

#                                       "$SYSLOCAL/LIBR.DAT directory  "

#                                       "search paths.                 "

#

#                                       "Delete the following line     "

#                                       "after establishing your local "

#                                       "area logicals.                "

echo "Define local area logicals in $SYSLOCAL/CDVER.CSH"

#                                       "Display AIPS version.         "

echo AIPS_VERSION=$AIPS_VERSION





: "--------------------------------------------------------------------"

: " Usage: . CDVER.SH                                                  "

: "--------------------------------------------------------------------"

: " This file is used to establish the AIPS programming area logicals  "

: " (environment variables) as defined in $SYSUNIX/AREAS.SH (created   "

: " from $SYSAIPS/AREAS.DAT by the $SYSUNIX/AREAS script) or toggle    "

: " these definitions between different AIPS versions (i.e., OLD, NEW  "

: " and TST).  Normally, it is only used by the environment variables  "

: " $CDOLD, $CDNEW and $CDTST.  Area logicals for local directories    "

: " should be defined here, not in $SYSUNIX/AREAS.SH.  This includes   "

: " $SYSLOCAL, which (for the moment) *MUST* be $SYSUNIX/LOCAL, but    "

: " also any directories containing local Q, Y or Z routines.  It also "

: " toggles the search path for executables (i.e., $PATH) to include   "

: " the directories $SYSLOCAL and $SYSUNIX.                            "

: "                                                                    "

: " Generic Bourne/Korn shell version.                                 "

: "--------------------------------------------------------------------"

:                                       "Define/redefine standard AIPS "

:                                       "programming logicals.         "

. $AIPS_VERSION/SYSTEM/UNIX/AREAS.SH

:                                       "$SYSLOCAL must be defined as  "

:                                       "follows.                      "

SYSLOCAL=$SYSUNIX/LOCAL; export SYSLOCAL

:                                       "Redefine execution search     "

:                                       "path (initially established   "

INSTALLATION STEP 1                                           Page 2-14

LOCAL AREA LOGICALS                                        9 April 1990





:                                       "by LOGIN.SH during login) to  "

:                                       "search $SYSLOCAL, then        "

:                                       "$SYSUNIX for AIPS scripts.    "

PATH=.:"$SYSLOCAL":"$SYSUNIX":"$TPATH"; export PATH

:                                       "Define any local area logicals"

:                                       "here (e.g., Q, Y or Z-routine "

:                                       "directories).  For example,   "

:

:                                       "QLOCAL=$QPSAP/LOCAL           "

:                                       "export QLOCAL                 "

:                                       "YLOCAL=$YIVAS/LOCAL           "

:                                       "export YLOCAL                 "

:                                       "ZLOCAL=$APLSUN/LOCAL          "

:                                       "export ZLOCAL                 "

:

:                                       "Be sure to include your local "

:                                       "area logicals in your         "

:                                       "$SYSLOCAL/LIBR.DAT directory  "

:                                       "search paths.                 "

:

:                                       "Delete the following line     "

:                                       "after establishing your local "

:                                       "area logicals.                "

echo "Define local area logicals in $SYSLOCAL/CDVER.SH"

:                                       "Display AIPS version.         "

echo AIPS_VERSION=$AIPS_VERSION







2.7  LOGIN PROCEDURES



     After examining AREAS.* and modifying CDVER.*  above,  you  should

have  some  feeling  for  AIPS  programming  logicals.   Throughout the

remainder of this document, areas will be referred to by their  logical

names  (e.g.,  $SYSUNIX rather than $XXX/SYSTEM/UNIX).  You may find it

useful to print out a copy of $SYSUNIX/AREAS.CSH (or $SYSUNIX/AREAS.SH,

whichever) to help translate.



     All of the AIPS procedures are written in Bourne shell syntax  and

have  been exercised under logins where the default shell is either the

Bourne shell, Korn shell, or  (most  often)  the  C  shell.   LOGIN.CSH

and/or  LOGIN.SH  should  be  copied from $SYSUNIX to a directory where

everyone who needs it can get to it/them easily.  A good place  is  the

home  directory  for  the  AIPS  account.  It/they need to be edited to

reflect the local AIPS system.  One should  be  incorporated  into  the

login procedure for the AIPS account via "source LOGIN.CSH" where the C

shell is the default login shell or ". LOGIN.SH" where  the  Bourne  or

Korn  shell  is  the  default.  The login procedures for other accounts

that intend to execute or program  AIPS  should  similarly  incorporate

these definitions.  They serve as the starting point for all other AIPS

definitions, including the default AIPS version (i.e.,  $AIPS_VERSION).

The  distributed  versions  of $SYSUNIX/LOGIN.CSH and $SYSUNIX/LOGIN.SH

are shown below:

# "--------------------------------------------------------------------"

INSTALLATION STEP 1                                           Page 2-15

LOGIN PROCEDURES                                           9 April 1990





# " Usage: source LOGIN.CSH                                            "

# "--------------------------------------------------------------------"

# " A procedure that should be executed by all logins that require     "

# " AIPS system definitions.  It should be store in the home directory "

# " of the AIPS account so everyone knows where to find it.            "

# "                                                                    "

# " Generic UNIX version.                                              "

# "--------------------------------------------------------------------"

#                                       "Disable core dumps entirely.  "

limit coredumpsize 0

#                                       "Define the AIPS account home  "

#                                       "directory as the root         "

#                                       "for all other definitions.    "

setenv AIPS_ROOT /DEFINE_ME

#                                       "Save PATH as set on normal    "

#                                       "login.                        "

setenv TPATH "$PATH"

#                                       "Define non-version specific   "

#                                       "directory logicals.           "

#

#                                       "Ionospheric data.             "

setenv AIPSIONS $AIPS_ROOT/TEXT/IONS

#                                       "Public.                       "

setenv AIPSPUBL $AIPS_ROOT/TEXT/PUBL

#                                       "Gripes.                       "

setenv AIPSGRIP $AIPS_ROOT/TEXT/GRIP

#                                       "AIPS user lists.              "

setenv AIPSWHO  $AIPS_ROOT/TEXT/WHO

#                                       "Define AIPS versions.         "

setenv OLD $AIPS_ROOT/15JAN90

setenv NEW $AIPS_ROOT/15APR90

setenv TST $AIPS_ROOT/15JUL90

#                                       "Assign default version.  At   "

#                                       "NRAO this should be the TST   "

#                                       "area.  Elsewhere, it should   "

#                                       "probably be the NEW area.     "

setenv AIPS_VERSION $NEW

#                                       "Define AIPS procedure areas   "

#                                       "and redefine PATH.            "

setenv SYSLOCAL $AIPS_VERSION/SYSTEM/UNIX/LOCAL

setenv SYSUNIX $AIPS_VERSION/SYSTEM/UNIX

setenv PATH .:"$SYSLOCAL":"$SYSUNIX":"$TPATH"

#                                       "Define CDOLD, CDNEW & CDTST.  "

#                                       "These are environment         "

#                                       "variables that are assigned a "

#                                       "command sequence for toggling "

#                                       "the definitions of AIPS       "

#                                       "programming environment       "

#                                       "variables between OLD, NEW    "

#                                       "and TST versions,             "

#                                       "respectively.                 "

setenv CDOLD 'eval setenv AIPS_VERSION $OLD; source $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.CSH'

setenv CDNEW 'eval setenv AIPS_VERSION $NEW; source $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.CSH'

setenv CDTST 'eval setenv AIPS_VERSION $TST; source $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.CSH'

INSTALLATION STEP 1                                           Page 2-16

LOGIN PROCEDURES                                           9 April 1990





#                                       "Define default RUN file area. "

setenv RUNFIL $AIPS_ROOT/RUN

#                                       "Define default FITS disk area."

setenv FITS /DEFINE_ME

#                                       "Define local device logicals. "

source $SYSLOCAL/ASSNLOCAL.CSH





: "--------------------------------------------------------------------"

: " Usage: . LOGIN.SH                                                  "

: "--------------------------------------------------------------------"

: " A procedure that should be executed by all logins that require     "

: " AIPS system definitions.  It should be store in the home directory "

: " of the AIPS account so everyone knows where to find it.            "

: "                                                                    "

: " Generic UNIX version.                                              "

: "--------------------------------------------------------------------"

:                                       "Disable core dumps entirely.  "

:                                       "How under Bourne/Korn shell?  "

:

:                                       "Define the AIPS account home  "

:                                       "directory as the root         "

:                                       "for all other definitions.    "

AIPS_ROOT=DEFINE_ME; export AIPS_ROOT

:                                       "Save PATH as set on normal    "

:                                       "login.                        "

TPATH="$PATH"; export TPATH

:                                       "Define non-version specific   "

:                                       "directory logicals.           "

:

:                                       "Ionospheric data.             "

AIPSIONS=$AIPS_ROOT/TEXT/IONS; export AIPSIONS

:                                       "Public.                       "

AIPSPUBL=$AIPS_ROOT/TEXT/PUBL; export AIPSPUBL

:                                       "Gripes.                       "

AIPSGRIP=$AIPS_ROOT/TEXT/GRIP; export AIPSGRIP

:                                       "AIPS user lists.              "

AIPSWHO=$AIPS_ROOT/TEXT/WHO; export AIPSWHO

:                                       "Define AIPS versions.         "

OLD=$AIPS_ROOT/15JAN90; export OLD

NEW=$AIPS_ROOT/15APR90; export NEW

TST=$AIPS_ROOT/15JUL90; export TST

:                                       "Assign default version.  At   "

:                                       "NRAO this should be the TST   "

:                                       "area.  Elsewhere, it should   "

:                                       "probably be the NEW area.     "

AIPS_VERSION=$NEW; export AIPS_VERSION

:                                       "Define AIPS procedure areas   "

:                                       "and redefine PATH.            "

SYSLOCAL=$AIPS_VERSION/SYSTEM/UNIX/LOCAL; export SYSLOCAL

SYSUNIX=$AIPS_VERSION/SYSTEM/UNIX; export SYSUNIX

PATH=.:"$SYSLOCAL":"$SYSUNIX":"$TPATH"; export PATH

:                                       "Define CDOLD, CDNEW & CDTST.  "

:                                       "These are environment         "

INSTALLATION STEP 1                                           Page 2-17

LOGIN PROCEDURES                                           9 April 1990





:                                       "variables that are assigned a "

:                                       "command sequence for toggling "

:                                       "the definitions of AIPS       "

:                                       "programming environment       "

:                                       "variables between OLD, NEW    "

:                                       "and TST versions,             "

:                                       "respectively."

CDOLD='eval AIPS_VERSION=$OLD; export AIPS_VERSION; . $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.SH'; export CDOLD

CDNEW='eval AIPS_VERSION=$NEW; export AIPS_VERSION; . $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.SH'; export CDNEW

CDTST='eval AIPS_VERSION=$TST; export AIPS_VERSION; . $AIPS_VERSION/SYSTEM/UNIX/LOCAL/CDVER.SH'; export CDTST

:                                       "Define default RUN file area. "

RUNFIL=$AIPS_ROOT/RUN; export RUNFIL

:                                       "Define default FITS disk area."

FITS=/DEFINE_ME; export FITS

:                                       "Define local device logicals. "

. $SYSLOCAL/ASSNLOCAL.SH



     There is a provision for up to three different versions  of  AIPS.

If  you  only have one version of AIPS, then define OLD, NEW and TST to

be the same.  If you are installing a second version, you may prefer to

define  it  originally  as,  say TST.  If you already have a version of

AIPS in production, you may find it useful to call the new version  TST

and  rename it after everything seems to be functioning.  Some releases

of AIPS are so disparate with previous  release  that  maintaining  two

versions may not be possible (see "UPDATING USER DATA FORMATS").



     Initial values for $SYSLOCAL and $SYSUNIX are generated  from  the

login  definition of $AIPS_VERSION and the environment variable PATH is

extended to include $SYSLOCAL followed by $SYSUNIX.   AIPS  definitions

can be toggled from OLD to NEW to TST through $CDOLD, $CDNEW and $CDTST

which.  These strange  creatures  are  the  lowest  common  denominator

solutions  for  all  flavors  of  UNIX  and  shells.   They  amount  to

executable environment variables (like "symbols" in VMS)  and  you  are

not  likely to see these constructs in any other UNIX application.  The

C shell has "aliases" that could serve this purpose, and Bell System  V

has the notion of "functions" that could serve as well, but the idea is

to  minimize  the  number  of  variations  requiring  maintenance   and

explanation.   To  toggle  version  based definitions, all one needs to

type is one of these (e.g., $CDNEW), which may take a minute or  so  to

execute.



     The last line of LOGIN.CSH (i.e., source  $SYSLOCAL/ASSNLOCAL.CSH)

defines  device  logicals,  as  does the last line of LOGIN.SH (i.e., .

$SYSLOCAL/ASSNLOCAL.SH).   Commented  paraforms  of  ASSNLOCAL.CSH  and

ASSNLOCAL.SH  are  distributed in the $SYSUNIX directory.  These should

be copied to $SYSLOCAL and ultimately customized to  reflect  the  host

devices  (e.g.,  AIPS data directories, tape drives, TV devices, etc.).

For the time being, copies of  the  $SYSUNIX  paraforms  will  suffice,

since   accurate   definitions  are  only  required  for  AIPS  program

execution, not AIPS programming (see "Device Logicals").



     After incorporating LOGIN.CSH (or LOGIN.SH) into the AIPS  account

login  procedure,  the  simplest  and  safest  way  to execute it is by

logging in again.  $SYSLOCAL and $SYSUNIX will be defined  as  part  of

INSTALLATION STEP 1                                           Page 2-18

LOGIN PROCEDURES                                           9 April 1990





the  login,  however, one of $CDOLD or $CDNEW or $CDTST will have to be

executed to define the rest of the AIPS programming logicals.  This  is

imperative  for  the  AIPS programming tools to work properly.  You may

prefer to incorporate the execution of one of these in the AIPS account

login  procedure,  but they take a while to execute and the definitions

are not needed for AIPS usage, only AIPS programming.  After  executing

one,  typing  "printenv" (Berkeley UNIX) or "set" (from a Bourne shell)

will display all the new definitions.  Don't worry, you aren't required

to  memorize all these in order to install AIPS, however, you should at

least verify that your local  directories  are  correctly  defined  and

familiarization  with  the  ones most relevant to your system will also

prove useful.







2.8  OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS



     Now that the AIPS programming logicals have been defined, you  are

ready  to  address  the  problem  of  search paths.  The success of the

remainder of the  installation  process  depends  critically  on  these

definitions  and  it's  well worthwhile taking the care to get it right

the first time.  The crucial files involved  are  called  LIBR.DAT  and

INCS.SH  and  their  paraform  versions  in the $SYSUNIX area should be

copied to your local SYSTEM area (i.e., $SYSLOCAL).







2.8.1  LIBR.DAT



     A given implementation of  AIPS  will  require  the  use  of  only

specific  areas  in  the  directory  infrastructure.   Under  UNIX, the

mapping of source code area search paths, subroutine source  code  area

to object libraries and object library link list to program source code

area is all maintained in a  single  file  called  LIBR.DAT  (with  the

exception  of  "included"  FORTRAN  source  text; see "INCS.SH" below).

LIBR.DAT has two sections.  The first  section  is  used  to  associate

subroutine  source  code  areas with one or more object libraries.  The

second section is used to specify one or more object library link lists

for each program source code area.



     The paraform LIBR.DAT provided in the  generic  UNIX  system  area

(i.e,  $SYSUNIX)  is  shown  below.   The  prescribed  mappings for the

machine independent code areas  are  well  determined  and  should  not

require   modification.    The   mappings  that  are  highlighted  with

"(---blah,  blah,  blah---)"  notes  designate   those   that   require

attention.   The  notes,  of  course,  should  not appear in your final

version of LIBR.DAT.  We also distribute versions of LIBR.DAT  some  of

the  more established AIPS platforms.  These can be found in the vendor

specific subdirectories of $SYSUNIX (e.g., $SYSALLN, $SYSCVEX, $SYSSUN)

and probably serve better as examples for similar installations.

AIPS subroutine source code search paths and object libraries:



$LIBR/AIPSUB/SUBLIB:0:$AIPSUB



INSTALLATION STEP 1                                           Page 2-19

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





APL subroutine source code search paths and object libraries:



Standard routines



$LIBR/APLSUB/SUBLIB:0:$APLSUB



Non-standard and routines



$LIBR/APLNOT/SUBLIB:0:$APLNOT



Z-routines



$LIBR/APLALLN/SUBLIB:0:(---Your local Z-routine directory goes here---)

$LIBR/APLALLN/SUBLIB:0:$APLALLN(---for example---)

$LIBR/APLALLN/SUBLIB:0:$APLBERK(---for example---)

$LIBR/APLALLN/SUBLIB:0:$APLUNIX

$LIBR/APLALLN/SUBLIB:0:$APLGEN



Q subroutine source code search paths and object libraries:



Standard routines



$LIBR/QSUB/SUBLIB:0:$QSUB



Non-standard routines



$LIBR/QNOT/SUBLIB:0:$QNOT



Q-routines



$LIBR/QVEX/SUBLIB:0:$QVEX(---for example---)

$LIBR/QVEX/SUBLIB:0:$QPSAP(---for example---)

$LIBR/QVEX/SUBLIB:0:$QDEV



Y subroutine source code search paths and object libraries:



Standard routines



$LIBR/YSUB/SUBLIB:0:$YSUB



Non-standard routines



$LIBR/YNOT/SUBLIB:0:$YNOT



Y-routines



$LIBR/YSTUB/SUBLIB:0:$YSTUB(---for example---)

$LIBR/YSTUB/SUBLIB:0:$YGEN



AIPS stand alone program source code search paths and link libraries:



AIPGUNIX => UNIX specific stand alone programs



$LIBR/AIPSUB/SUBLIB:0:$AIPGUNIX

INSTALLATION STEP 1                                           Page 2-20

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPGUNIX

$LIBR/APLSUB/SUBLIB:0:$AIPGUNIX

$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPGUNIX

$LIBR/APLSUB/SUBLIB:0:$AIPGUNIX

$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPGUNIX



AIPPGM => Standard stand alone programs



$LIBR/AIPSUB/SUBLIB:0:$AIPPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPPGM

$LIBR/YSUB/SUBLIB:0:$AIPPGM

$LIBR/YSTUB/SUBLIB(---for example---):0:$AIPPGM

$LIBR/APLSUB/SUBLIB:0:$AIPPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPPGM

$LIBR/APLSUB/SUBLIB:0:$AIPPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$AIPPGM



APL-task source code search paths and link libraries:



APGUNIX => UNIX specific tasks that call neither Q nor Y-routines



$LIBR/APLNOT/SUBLIB:0:$APGUNIX

$LIBR/APLSUB/SUBLIB:0:$APGUNIX

$LIBR/APLALLN/SUBLIB(---for example---):0:$APGUNIX

$LIBR/APLSUB/SUBLIB:0:$APGUNIX



APGNOT => Non-standard tasks that call neither Q nor Y-routines



$LIBR/APLNOT/SUBLIB:0:$APGNOT

$LIBR/APLSUB/SUBLIB:0:$APGNOT

$LIBR/APLALLN/SUBLIB(---for example---):0:$APGNOT

$LIBR/APLSUB/SUBLIB:0:$APGNOT

$LIBR/APLNOT/SUBLIB:0:$APGNOT

$LIBR/APLALLN/SUBLIB(---for example---):0:$APGNOT



APLPGM => Standard tasks that call neither Q nor Y-routines



$LIBR/APLSUB/SUBLIB:0:$APLPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$APLPGM

$LIBR/APLSUB/SUBLIB:0:$APLPGM



Q-task source code search paths and link libraries:



QPGNOT => Non-standard tasks that call Q-routines but not Y-routines



$LIBR/QNOT/SUBLIB:0:$QPGNOT

$LIBR/APLNOT/SUBLIB:0:$QPGNOT

$LIBR/QSUB/SUBLIB:0:$QPGNOT

$LIBR/QVEX/SUBLIB(---for example---):0:$QPGNOT

$LIBR/APLSUB/SUBLIB:0:$QPGNOT

$LIBR/APLALLN/SUBLIB(---for example---):0:$QPGNOT

$LIBR/APLSUB/SUBLIB:0:$QPGNOT



QPGM => Standard tasks that call Q-routines but not Y-routines

INSTALLATION STEP 1                                           Page 2-21

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990







$LIBR/QSUB/SUBLIB:0:$QPGM

$LIBR/QVEX/SUBLIB(---for example---):0:$QPGM

$LIBR/APLSUB/SUBLIB:0:$QPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$QPGM

$LIBR/APLSUB/SUBLIB:0:$QPGM



Y-task source code search paths and link libraries:



YPGVDEV => Virtual TV server program



$LIBR/YSUB/SUBLIB:0:$YPGVDEV

$LIBR/YSSS/SUBLIB(---for example---):0:$YPGVDEV

$LIBR/APLSUB/SUBLIB:0:$YPGVDEV

$LIBR/APLALLN/SUBLIB(---for example---):0:$YPGVDEV

$LIBR/APLSUB/SUBLIB:0:$YPGVDEV



YPGNOT => Non-standard tasks that call Y-routines but not Q-routines



$LIBR/YNOT/SUBLIB:0:$YPGNOT

$LIBR/APLNOT/SUBLIB:0:$YPGNOT

$LIBR/YSUB/SUBLIB:0:$YPGNOT

$LIBR/YSTUB/SUBLIB(---for example---):0:$YPGNOT

$LIBR/APLSUB/SUBLIB:0:$YPGNOT

$LIBR/APLALLN/SUBLIB(---for example---):0:$YPGNOT

$LIBR/APLSUB/SUBLIB:0:$YPGNOT



YPGM => Standard tasks that call Y-routines but not Q-routines



$LIBR/YSUB/SUBLIB:0:$YPGM

$LIBR/YSTUB/SUBLIB(---for example---):0:$YPGM

$LIBR/APLSUB/SUBLIB:0:$YPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$YPGM

$LIBR/APLSUB/SUBLIB:0:$YPGM



QY-task source code search paths and link libraries:



QYPGNOT => Non-standard tasks that call both Q-routines and Y-routines



$LIBR/QNOT/SUBLIB:0:$QYPGNOT

$LIBR/APLNOT/SUBLIB:0:$QYPGNOT

$LIBR/QNOT/SUBLIB:0:$QYPGNOT

$LIBR/QSUB/SUBLIB:0:$QYPGNOT

$LIBR/QVEX/SUBLIB(---for example---):0:$QYPGNOT

$LIBR/YSUB/SUBLIB:0:$QYPGNOT

$LIBR/YSTUB/SUBLIB(---for example---):0:$QYPGNOT

$LIBR/APLSUB/SUBLIB:0:$QYPGNOT

$LIBR/APLALLN/SUBLIB(---for example---):0:$QYPGNOT

$LIBR/APLSUB/SUBLIB:0:$QYPGNOT



QYPGM => Standard tasks that call both Q-routines and Y-routines



$LIBR/QSUB/SUBLIB:0:$QYPGM

$LIBR/QVEX/SUBLIB(---for example---):0:$QYPGM

INSTALLATION STEP 1                                           Page 2-22

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





$LIBR/YSUB/SUBLIB:0:$QYPGM

$LIBR/YSTUB/SUBLIB(---for example---):0:$QYPGM

$LIBR/APLSUB/SUBLIB:0:$QYPGM

$LIBR/APLALLN/SUBLIB(---for example---):0:$QYPGM

$LIBR/APLSUB/SUBLIB:0:$QYPGM







2.8.1.1  Subroutine And Object Library Mappings -



     The upper part of LIBR.DAT is used to associate  object  libraries

(i.e.,  $LIBR/*/SUBLIBs)  with the proper set of subroutine source code

areas for the host implementation.  The  associated  subroutine  source

code  areas  will be searched in the order they are given to locate the

proper module to be used in the construction of the  associated  object

library.  For example, on the NRAO-CV Convex C-1, the prescribed search

path for Z-routine source code is:



$LIBR/APLCVEX/SUBLIB:0:$APLNRAO1           (NRAO-CV Convex local)

$LIBR/APLCVEX/SUBLIB:0:$APLCVEX            (Convex specific)

$LIBR/APLCVEX/SUBLIB:0:$APLBERK            (Berkeley UNIX)

$LIBR/APLCVEX/SUBLIB:0:$APLUNIX            (Generic UNIX)

$LIBR/APLCVEX/SUBLIB:0:$APLGEN             (Generic)





     The associations are all expressed in terms  of  AIPS  programming

logicals,  with  object  libraries  followed  by  source code areas and

separated by an  "alternate"  library  indicator  number  delimited  by

colons (CAREFUL:  no leading, embedded or trailing blanks).  The use of

alternate library indicator numbers is explained below.



     NOTE:  The $LIBR area itself contains only  subdirectories  (e.g.,

$LIBR/APLCVEX) which serve as staging areas for object modules that are

to be added or replaced in the object  libraries  (i.e.,  UNIX  archive

files)  using  the  host  object  librarian  (e.g.,  "ar").  All of the

archive files  have  the  same  name,  SUBLIB,  but  simply  reside  in

different  directories.  In the UNIX world, the term "archive file" has

a very special meaning.  Archive files can be used for  purposes  other

than "object libraries".  Rather than risk confusing the uninitiated or

offending the purists by  using  the  terms  interchangeably,  we  will

hereafter  refer  to archive files made up of object modules as "object

libraries".  This is the only way in which archive files  are  used  in

AIPS programming.



     The notion of "alternate" libraries may not be of any concern  for

most  systems  (i.e., the indicator will always be "0"), but under some

implementations,  a  given  object  module  "may"  be   used   in   the

construction  of  more  that  one  object  library.  As an example, our

NRAO-CV Convex C-1 (NRAO1) is configured with 2  different  TV  display

devices,  an  IIS  model  70E  and  an  IIS  model  IVAS.  To implement

different TV devices, AIPS maintains distinct, device  specific  object

libraries  (only  one of which is used in the generation of executables

for using the  particular  device).   Some  of  the  Y-routines  areas,

however,  may  contain  code  that  is  common to the implementation of

INSTALLATION STEP 1                                           Page 2-23

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





different devices.  In the case of the model 70E and IVAS, it turns out

that several of the $YGEN (i.e., "generic") routines (e.g., YCINIT) are

sufficient and common to the implementation of  both  devices  and  the

object  code  generated from these routines needs to be stored in their

respective object libraries.  Originally, we only had the model 70E and

our  $SYSLOCAL/LIBR.DAT  section  for its object library and associated

source code areas looked like the following (and still does):



IIS Model 70 Y-routines



$LIBR/YM70/SUBLIB:0:$YM70

$LIBR/YM70/SUBLIB:0:$YIIS

$LIBR/YM70/SUBLIB:0:$YGEN





     Later,  when  we  acquired   the   IVAS   display,   we   modified

$SYSLOCAL/LIBR.DAT  to  include  an  object  library  for the IVAS, its

associated source code areas and the order in  which  to  search  these

areas, i.e.,



IIS Model 70 Y-routines



$LIBR/YM70/SUBLIB:0:$YM70

$LIBR/YM70/SUBLIB:0:$YIIS

$LIBR/YM70/SUBLIB:0:$YGEN



IIS Model IVAS Y-routines



$LIBR/YIVAS/SUBLIB:2:$YIVAS

$LIBR/YIVAS/SUBLIB:2:$YGEN





     For the case above, whenever an object module  is  generated  from

source code common to the implementation of both the model 70 and IVAS,

it   gets   added   or   replaced   in   both   $LIBR/YM70/SUBLIB   and

$LIBR/YIVAS/SUBLIB.   Actually,  the object modules are only staged for

replacement.  This is done  automatically  by  the  primary  subroutine

compiling  procedure,  COMRPL.  The primary program compiling procedure

COMLNK is designed to invoke the  subordinate  procedure  called  LINK,

which checks all the $LIBR object library directories in the prescribed

link list for the given program and invokes the procedure  called  LIBR

to  add  or  replace  any  object modules staged there.  The COMRPL and

COMLNK procedures as well as their subordinate procedures are described

in more detail later.



     The following is the $LIBR directory structure as it exists on the

NRAO-CV  Convex  C-1  where  we  have an IIS model 70 TV device, an IIS

model IVAS TV device.  The  subroutine  areas  from  which  the  object

libraries are generated are given on the right:



$LIBR/AIPSUB/SUBLIB        $AIPSUB

$LIBR/APLCVEX/SUBLIB       $APLNRAO1,$APLCVEX,$APLBERK,$APLUNIX,$APLGEN

$LIBR/APLNOT/SUBLIB        $APLNOT

$LIBR/APLSUB/SUBLIB        $APLSUB

INSTALLATION STEP 1                                           Page 2-24

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





$LIBR/QNOT/SUBLIB          $QNOT

$LIBR/QSUB/SUBLIB          $QSUB

$LIBR/QVEX/SUBLIB          $QVEX,$QPSAP

$LIBR/YIVAS/SUBLIB         $YIVAS,$YGEN

$LIBR/YM70/SUBLIB          $YM70,$YIIS,$YGEN

$LIBR/YNOT/SUBLIB          $YNOT

$LIBR/YSUB/SUBLIB          $YSUB

$LIBR/YVTV/SUBLIB          $YVTV,$YGEN



There's nothing  particularly  magical  about  the  $LIBR  subdirectory

names,  however,  they should probably be chosen to be as meaningful as

possible.  At NRAO, we tend to use the name of the area logical for the

most operating system, vendor or device/model specific source code area

used in the generation of the object library that  will  reside  there.

For example, $LIBR/AIPSUB is where the object library (i.e., SUBLIB) is

maintained for object code generated  completely  from  $AIPSUB  source

code  (i.e.,  $AIPSUB  has no subdirectories since all $AIPSUB routines

are machine independent).  At the other extreme, we  use  $LIBR/APLCVEX

to  store the object library that is constructed from source code found

in various directories of the Z-routine  directory  infrastructure,  of

which  $APLCVEX  is  the  most  operating  system  and vendor specific.

Whatever you choose, the most important thing is to be consistent.  You

can  always  change  the  directory name later, however it MUST also be

changed in LIBR.DAT.  The procedure INSTEP2 will automatically generate

$LIBR and its subdirectories if they don't already exist.



     Whereas the choice of $LIBR subdirectory names may  be  arbitrary,

the  use  of  SUBLIB  as  the file name of the actual object library is

imperative.  The AIPS programming tools depend  on  it.   As  mentioned

above, a procedure called LIBR is used to maintain the various SUBLIBs.

Given the overhead involved with adding or replacing an  object  module

(i.e.,  via  "ar") then randomizing it (i.e., via "ranlib", at least on

systems based on Berkeley UNIX), modules are  saved  up  and  added  or

replaced  in  the  corresponding  SUBLIB  en  masse.   Whenever LIBR is

invoked for a given $LIBR subdirectory  and  it  finds  object  modules

there  to  process,  it  will update the corresponding SUBLIB.  This is

usually whenever the procedure LINK is invoked to link a program  whose

link list includes a SUBLIB that to needs to be updated.  However, LIBR

may also be used stand-alone with the name of an  AIPS  program  source

code  area  as  its  argument.   In  that case, it will determine which

SUBLIBs should be included in the  link  lists  of  such  programs  and

perform any required updating.  LIBR also takes pains to lock the given

SUBLIB while updating it in order to prevent colliding  processes  from

corrupting  the  object library.  The UNIX world doesn't always protect

you from such potentially disastrous collisions.







2.8.1.2  Program And Object Library Mappings -



     Whereas the upper portion of LIBR.DAT maps subroutine source  code

areas  to  one  or  more  object  libraries, the lower portion maps the

program source code areas  to  the  object  libraries  that  should  be

included  in  the  link  list  for one or more link steps.  Notice that

INSTALLATION STEP 1                                           Page 2-25

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





object libraries are often repeated in the  link  lists.   This  is  to

account  for  the  single  pass  nature  of  most UNIX loaders (linkage

editors).  Libraries must often be cycled in several times in order  to

resolve  all  external  references.   For  example,  the object library

containing object modules generated from the $APLSUB source  code  area

needs  to  be  cycled  in  at  least  twice in the link lists for every

program source code area.  This is because routines used from the other

object  libraries  specified  in the lists often call $APLSUB routines.

The required order of  the  link  lists  that  appear  in  the  various

distributed  versions  of LIBR.DAT have been determined empirically and

with rare exceptions, should apply to most systems.



     At least a default link list is required in LIBR.DAT for  each  of

the  program  source  code  areas  (i.e.,  $AIPPGM, $AIPGUNIX, $APLPGM,

$APGNOT, $APGUNIX, $QPGM, $QYPGNOT, $QYPGM,  $QYPGNOT,  $YPGM,  $YPGNOT

and $YPGVDEV).  Different link lists are distinguished by a number code

inserted between the object library and delimited with colons.  Default

link  lists  are  indicated  by  the  number  code "0" and load modules

generated using the default link lists are stored in the  default  load

library, $LOAD.  Depending on the system, alternate link lists may also

be required and are designated by codes  1-9,  however,  even  numbered

codes  greater than "2" are rarely needed.  Load modules generated from

the alternate link lists are stored in the corresponding alternate load

libraries,  $LOAD1,  $LOAD2,  . . ., defined as $LOAD/ALT1, $LOAD/ALT2,

 . . ., respectively.  The alternate link lists and load  module  areas

are  only  required  on those systems where more that one type of array

processor or TV device is to be implemented, or both.  The majority  of

AIPS  programs use neither Q-routines nor Y-routines (e.g., $APLPGM and

$APGNOT) and their load modules are always stored in the  default  load

module  area.   However,  some  AIPS  programs  use  Q-routines  (array

processor) but not Y-routines  (e.g.,  $QPGM  and  $QPGNOT),  some  use

Y-routines  (TV)  but  not Q-routines ($YPGM and $YPGNOT) and some even

use both Q-routines and Y-routines (e.g., $QYPGM and $QYPGNOT).   NOTE:

The "NOT" in the program area names above mean "not standard", not "not

used".



     For example, suppose a system is configured with  2  different  TV

devices  (e.g.,  IIS  model  70  and IVAS) as well as 2 different array

processors ("real" and "pseudo").  All systems need  to  link  with  at

least  a  stubbed  set of Y-routines (i.e., $YSTUB) and all systems are

capable of "pseudo" array processor mode.  Systems with attached  array

processors  were  once  relatively  common  (e.g.,  VAX/VMS + FPS array

processor), but this scenario has never really evolved in the  case  of

AIPS  under UNIX.  However, for the sake of illustration, we'll pretend

such a system exists.  On such a system, 4  different  combinations  of

array  processor and TV device dependency are possible (i.e., "real" AP

with TV  1, "pseudo" AP with TV  2, "real" AP with TV  1  and  "pseudo"

AP  with  TV   2).   The  programs  that depend on Q-routines should be

linked once with the object libraries that will cause the "real"  array

processor  to be used, creating one load module, then linked again with

the "pseudo" array processor object library,  creating  a  second  load

module.   In  our  imaginary system, the first load module is stored in

the default load module area (i.e., for the sake of  performance),  and

the second is stored in $LOAD1.  In the case of programs that depend on

INSTALLATION STEP 1                                           Page 2-26

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





Y-routines, we need to link once with the object library  for  the  IIS

model 70 and once with the object library for the IVAS.  The first load

module is store in, say, the default load module area, $LOAD0, and  the

second  is  stored  in  the  load library $LOAD2.  As for programs that

depend on both  Q-routines  and  Y-routines,  we  need  to  generate  4

distinct  load  modules,  the  first linked with "real" array processor

Q-routine library and the model 70 Y-routine library and  store  it  in

$LOAD0, the second linked with "real" array processor Q-routine library

and the IVAS 70 Y-routine library and store it  in  $LOAD1,  the  third

linked with "pseudo" array processor Q-routine library and the model 70

Y-routine library and store it in $LOAD2, and the  fourth  linked  with

"pseudo"  array  processor  Q-routine  library  and  the IVAS Y-routine

library and store it in $LOAD3, i.e.,



"real"   AP + IIS model 70 TV -> $LOAD0



"pseudo" AP + IIS model 70 TV -> $LOAD1



"real"   AP + IIS model IVAS  -> $LOAD2



"pseudo" AP + IIS model IVAS  -> $LOAD3



You must adhere strictly to the convention of associating TV device   1

with load module areas $LOAD0 and $LOAD1, TV device  2 with load module

areas $LOAD2 and $LOAD3,  . . , because the task  activation  mechanism

depends on it.  However, the "real" versus "pseudo" AP order may be and

should be flipped on  those  systems  that  have  no  "real"  AP.   For

example, on our NRAO-CV Convex C-1 configured with both an IIS model 70

and IVAS and only "pseudo" array processor mode is used,  our  LIBR.DAT

entries for programs that reside in the $QYPGM looks like the following

(note the absence of alternate link lists "1" and "3"):



QYPGM => Standard tasks that call both Q-routines and Y-routines



w/ IIS Model 70 Y-routines



$LIBR/QSUB/SUBLIB:0:$QYPGM

$LIBR/QVEX/SUBLIB:0:$QYPGM

$LIBR/YSUB/SUBLIB:0:$QYPGM

$LIBR/YM70/SUBLIB:0:$QYPGM

$LIBR/APLSUB/SUBLIB:0:$QYPGM

$LIBR/APLCVEX/SUBLIB:0:$QYPGM

$LIBR/APLSUB/SUBLIB:0:$QYPGM



w/ IIS Model IVAS Y-routines



$LIBR/QSUB/SUBLIB:2:$QYPGM

$LIBR/QVEX/SUBLIB:2:$QYPGM

$LIBR/YSUB/SUBLIB:2:$QYPGM

$LIBR/YIVAS/SUBLIB:2:$QYPGM

/nrao1/aips/pgmr/egreisen/ivas2/ieee/XANTH.LIB:2:$QYPGM

$LIBR/APLSUB/SUBLIB:2:$QYPGM

$LIBR/APLCVEX/SUBLIB:2:$QYPGM

$LIBR/APLSUB/SUBLIB:2:$QYPGM

INSTALLATION STEP 1                                           Page 2-27

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990







In this case, when programs from the $QYPGM area are linked,  they  are

linked  twice, once with the IIS model 70 object library and again with

the IIS model IVAS object library.  The  resultant  executable  modules

are  stored in separate load libraries, $LOAD and $LOAD2.  This is done

automatically by the procedure, LINK, which is invoked by  the  primary

program  compiling  and  linking  procedure,  COMLNK.  LINK can also be

invoked independently if the program object module already exists.   Of

course,  if  the  program  source or any of the included source text on

which it depends has been modified, this is NOT the thing to do.



     Many of the AIPS  programming  procedures  make  use  of  LIBR.DAT

either  directly  or  indirectly, including COMRPL, COMLNK, LIBR, LIBS,

LINK, MAKEAT and SEARCH.  LINK is a procedure that links  programs  and

uses  LIBR.DAT to determine the required $LIBR/*/SUBLIBs to use in link

list.  SEARCH is a procedure that  (using  the  order  of  source  code

directories  prescribed in LIBR.DAT for the directory where the program

resides) searches for the proper module for  the  host  implementation.

For  example,  if an AIPS programmer tries to compile a given Z-routine

in $APLUNIX (generic UNIX) using  the  procedure  COMRPL  (compile  and

replace),  but  the proper version of the routine actually resides in a

lower directory as listed in LIBR.DAT (for example,  $APLBERK),  SEARCH

will  discover  this and substitute the path name to the proper module.

Actually, SEARCH and some of the other procedures mentioned  above  use

files  called  SEARCHn.DAT.   These  are  automatically  generated from

LIBR.DAT  the  first  time  they  are  needed  and  are   automatically

regenerated thereafter whenever LIBR.DAT is modified (i.e., is found to

be newer than SEARCHn.DAT).



     Using LIBR.DAT, all of a given AIPS implementation's  source  code

search  paths (except for "INCLUDE" files), object code libraries, link

lists and  load  module  areas  can  be  mapped  in  a  single,  easily

maintained  file.  Furthermore, once defined properly, programmers have

to go through a bit of trouble,  even  subterfuge,  to  get  the  wrong

module.   As  you  can  see, LIBR.DAT is at the center of the UNIX/AIPS

programming universe.







2.8.2  INCS.SH



     The file called INCS.SH is used  to  independently  prescribe  the

search  path  for  source text to be included in FORTRAN modules by the

source code preprocessor, PP.  VMS style INCLUDE statements are used to

designate what source text is to be included.  These INCLUDE statements

are always of the general form:



       INCLUDE 'INCS:filename'



where "INCS:" denotes a blank separated list of directory  path  names.

INCS.SH  simply defines the environment variable $STDINCS as the search

path.  In the case of FORTRAN modules (i.e., *.FOR files),  the  source

code  preprocessor  PP will invoke INCS.SH to define $STDINCS, then use

it to define INCS=$STDINCS, but only if no user provided definition  of

INSTALLATION STEP 1                                           Page 2-28

OBJECT LIBRARIES AND SOURCE CODE SEARCH PATHS              9 April 1990





INCS  already  exists.  PP translates $INCS and searches directory list

one at a time until "filename" is found, then inserts its  source  text

(see "Source Code Preprocessor").



     $INC is the  root  of  the  hierarchical  include  file  directory

structure.   Like  the  Z-routine and SYSTEM directory structure, it is

based on the operating system and you may find it necessary to create a

purely local directory for your system.  At the moment, system specific

include files are limited to those used in the pseudo  array  processor

library.   In  particular,  the  include  files  used for the pseudo AP

implementation on Alliant and Convex systems have special  requirements

and come on the installation tape.



                                 INC

                                  |

                                  |

                                NOTST

                        _________/|\_________

                       /     /    |    \     \

                     ALLN  CRI  CVEX  UNIX  VMS





     Chances are you won't need a purely local include  file  directory

if you are simply using the "vanilla" pseudo AP library (most systems).

The structure that comes on the installation tape looks something  like

the following:



$XXX/INC                                 (Generic)

$XXX/INC/NOTST                           (Not Standard)

$XXX/INC/NOTST/ALLN                      (Alliant)

$XXX/INC/NOTST/CVEX                      (Convex)

$XXX/INC/NOTST/UNIX                      (Generic UNIX)

$XXX/INC/NOTST/VMS                       (VMS)



For example, the INCS.SH file for a Convex system should  (technically)

define STDINCS as:



STDINCS="$INCVEX $INCUNIX $INCNOT $INC"



However, for the moment, we define it as:



STDINCS="$INCVEX $INC"



This is because the directories  $INCUNIX  and  $INCNOT  are  currently

empty  and  we  leave  them  out  to speed up the search process.  On a

system that only needs the generic include files  (most  systems),  the

definition  of  STDINCS  is  reduced  to  simply  $INC.  If the program

INCLUDE includes files  from  a  directory  other  than  those  in  the

$STDINCS  search  path, it will merely issue warnings.  In other words,

there are no insurmountable obstacles to prevent  the  an  unscrupulous

programmer   from  corrupting  the  system  with  private  and  perhaps

irreproducible object code.

INSTALLATION STEP 1                                           Page 2-29

COMPILER AND LOADER OPTIONS                                9 April 1990





2.9  COMPILER AND LOADER OPTIONS



     Each UNIX system seems to have a slightly  different  grammar  for

compiler   and  loader  options.   To  solve  this  problem,  the  AIPS

programming tool kit contains compilation procedures called AS, CC, and

FC  for  assembler,  C  and  FORTRAN,  respectively.   There  is also a

procedure  called  LINK  to  link  programs.   The   files   ASOPTS.SH,

CCOPTS.SH,   FCOPTS.SH   and  LDOPTS.SH  are  used  to  map  the  local

compiler/loader syntax onto the AIPS-style options.  Heavily  commented

paraforms  of these files are stored in $SYSUNIX as well as some of the

vendor specific "system" directories  that  come  on  the  distribution

tape.   You  must  copy  the  $SYSUNIX/*OPTS.SH  files to the $SYSLOCAL

directory and modify them to reflect the local  compiler/loader  syntax

for the various options.



     In particular, the issue of optimization levels can  be  ticklish.

AIPS  has  many,  many  routines and faulty optimization for only a few

modules can cause big headaches.  If this is your first installation of

AIPS,  we recommend that you proceed with extreme caution in this area.

Our experience has  been  that  C  compiler  optimization  (i.e.,  "-O"

option)  is  quite  safe.   FORTRAN  is  an  entirely different matter,

especially since FORTRAN compilers  often  don't  get  nearly  as  much

attention as C compilers in the UNIX world.  Even the highly touted VMS

FORTRAN compiler fails in an unacceptable number of cases for AIPS code

when  optimization  is  specified.   In  general, a performance gain of

10-20% is all that you can expect from simple  optimization.   When  we

port  AIPS  to  an  unfamiliar system, we always start with the default

optimization level, increasing the optimization in steps until  we  run

into  trouble, then back off.  Any extraordinary effort in optimization

should be concentrated in the area of Q-routines since these  represent

the most computationally intensive AIPS code.  A complete discussion of

systems that have compilers capable  of  generating  vectorized  and/or

parallelized code is beyond the scope of this document.  Let it suffice

to say that the Q-routines lend themselves  particularly  well  to  the

highest levels of optimization available.



     NOTE:  A list of modules, which includes the Q-routines,  that  we

have  found  lend  themselves  to the highest levels of optimization is

maintained in the file OPT2.LIS in the $SYSCVEX directory.   A  special

version  of the FORTRAN compilation procedure, FC, which is designed to

use  $SYSLOCAL/OPT2.LIS  to  switch  from  $SYSLOCAL/FCOPTS.SH  default

optimization  level  to something higher can also be found in $SYSCVEX.

You might want to make a copy of this to  $SYSLOCAL/FC  and  modify  it

(look for OPT2.LIS in the text) suitably for your system's optimization

options.



     Paraform versions of the *OPTS.SH files for systems  on  which  we

have  had  first-hand  experience are stored in the $SYSALLN (Alliant),

$SYSCVEX (Convex) and $SYSSUN (Sun) directories, however, these  should

not   be   simply   copied   to  $SYSLOCAL  without  understanding  the

definitions.  Also, given  the  variations  in  compiler  versions  and

hardware configurations just within the Alliant, Convex and Sun worlds,

familiarization with the definitions is certainly worthwhile.

INSTALLATION STEP 1                                           Page 2-30

PROGRAMMING AND EXECUTION TOOLS                            9 April 1990





2.10  PROGRAMMING AND EXECUTION TOOLS



     The directory $SYSUNIX contains  many  procedures  and  even  some

programs  used  in  UNIX/AIPS programming and execution.  Most of these

are written to be generic, however, some may require some  customizaton

(e.g.,  ZLPCL2).   Most  of  the  programming  oriented  procedures and

programs require that the AIPS programming logicals be defined prior to

their  use  (i.e.,  via  the  execution  of  $CDOLD,  $CDNEW or $CDTST,

whichever is appropriate; see "Login Procedures" in  Chapter  2).   The

versions  of  the C programs in the $SYSUNIX directory should be copied

to the $SYSLOCAL  directory,  compiled  and  linked.   Rather  detailed

descriptions  of  each  procedure/program and its usage can be found as

comments in the its text.  Also,  most  are  designed  to  give  you  a

synopsis of their usage if invoked incorrectly (e.g., no arguments).  A

brief description of each is given here  and  those  that  may  require

customization are denoted with an asterisk:



   AIPS         procedure to startup program AIPS



   AS           procedure used to perform assemblies (invokes

                $SYSLOCAL/ASOPTS.SH)



   BATER        procedure to startup program BATER



   CC           procedure used to perform C compilations (invokes

                $SYSLOCAL/CCOPTS.SH)



   COMLNK       procedure to compile programs and link them with

                the appropriate object libraries (calls procedures

                SEARCH, PP, FC and LINK)



   COMRPL       procedure to compile subroutines and move the

                resulting object code to the appropriate object

                library (calls procedures SEARCH, PP, AS or CC

                or FC)



   FC           procedure to perform FORTRAN compilations (invokes

                $SYSLOCAL/FCOPTS.SH)



   LIBR         procedure used to build/update object libraries

                maintained in $LIBR subdirectories (uses

                $SYSLOCAL/LIBR.DAT)



   LIBS         procedure that, given a program source code area,

                prints the required object library link list (uses

                $SYSLOCAL/LIBR.DAT)



   LINK         procedure used to link programs (uses

                $SYSLOCAL/LIBR.DAT and calls procedure LIBR)



   MAKEAT       procedure used to generate "@" files (uses

                $SYSLOCAL/LIBR.DAT)



   NEWEST.C     program used to determine the newest file in its

INSTALLATION STEP 1                                           Page 2-31

PROGRAMMING AND EXECUTION TOOLS                            9 April 1990





                argument list



   PP           procedure used to preprocess source code (invokes

                $SYSLOCAL/PP.EXE)



   PRINTENV.C   program to imitate the Berkeley UNIX command "printenv"



   RUN          procedure used to run programs other than AIPS or

                BATER



   SEARCH       procedure used to search for the proper version/form

                of a module (calls program NEWEST)



*  ZLASCL       procedure used by the routine ZLASC2.C to send laser

                printer task (e.g., QMSPL, CANPL) output to the

                appropriate device



*  ZLPCL2       procedure used by the routine ZLPCL2.C to send line

                printer output to the appropriate device





     Copy the  "C"  programs  NEWEST.C  and  PRINTENV.C  found  in  the

directory   $SYSUNIX   to  the  directory  $SYSLOCAL  as  NEWEST.c  and

PRINTENV.c  respectively.   Then  compile  and  link  these  to  create

executable modules by the same name, i.e.,



cd $SYSLOCAL



cp $SYSUNIX/NEWEST.C NEWEST.c



cc -O NEWEST.c -o NEWEST



cp $SYSUNIX/PRINTENV.C PRINTENV.c



cc -O PRINTENV.c -o PRINTENV









2.11  SOURCE CODE PREPROCESSOR



     There is only one official version of the AIPS source code.  It is

the form in which it is stored on the primary AIPS development machine,

a VAX/780 at NRAO in Charlottesville,  Va .   (CVAX).   Great  care  is

taken  to  ensure  that  it  is kept in the same form on all other NRAO

systems, regardless of operating system or architecture.  Otherwise,  a

system  the size of AIPS would soon become totally unmanageable.  Prior

to the source code overhaul (15OCT89  being  first  publicly  available

release),  considerable  preprocessing was required in order to get the

FORTRAN modules in AIPS to compile and execute properly on anything but

a   VAX  running  VMS.   These  days,  the  amount  of  FORTRAN  module

preprocessing required is minimal, but some is still necessary  on  all

machines and operating systems (even VMS) and includes:

INSTALLATION STEP 1                                           Page 2-32

SOURCE CODE PREPROCESSOR                                   9 April 1990





     1.  locating VMS-style INCLUDE statements, then searching for  and

         inserting the text from the specified external file



     2.  detecting "local" include text at the beginning of  the  file,

         storing  the  text and its name away in memory, then inserting

         the text wherever specified via VMS-style INCLUDE statements



     3.  substituting "REAL" for "HOLLERITH" type  declarations,  which

         are  used  for  storing  4  (always)  hollerith characters per

         element (i.e., despite host word size)









2.11.1  Preprocessor Program



     To generate the source code preprocessor executable, PP.EXE, which

is invoked by the source code preprocessor script, PP, copy the FORTRAN

program PP.FOR as found in the  directory  $SYSUNIX  to  the  directory

$SYSLOCAL  as  PP.f.  Also copy the "C" subroutine ZTRLOG.C as found in

the directory $APLUNIX to $SYSLOCAL as ZTRLOG.c, i.e.,



cd $SYSLOCAL



cp $SYSUNIX/PP.FOR PP.f



cp $APLUNIX/ZTRLOG.C ZTRLOG.c



ZTRLOG is a  routine  that  translates  "logicals"  (i.e.,  environment

variables under UNIX).  Next compile ZTRLOG.c via



cc -c -O ZTRLOG.c



then, using the host FORTRAN compiler command, compile PP.f and link it

with ZTRLOG.o to produce PP.EXE, e.g.,



f77 -O PP.f ZTRLOG.o -o PP.EXE









2.11.2  Preprocessor Procedure



     The procedure PP stored in the directory $SYSUNIX will only accept

file  arguments with the extensions  .C,  .FOR or  .S (i.e., C, FORTRAN

and assembler code, respectively).  C and  assembler  modules  are  not

changed,  just  copied to files of the same name but with the extension

 .c  or   .s,  repectively.   PP  may  perform  some  minor  C   source

preprocessing  in  the  future  (e.g., toggling conditional compilation

flags).  In the case of  FORTRAN  modules,  PP  assigns  the  value  of

$STDINCS  to  the  environment  variable  INCS,  unless INCS is already

defined.  This allows programmers to override the standard INCLUDE file

search path.  If so, PP issues a warning message to the effect that a a

user defined search path is being used and displays it, all of which is

INSTALLATION STEP 1                                           Page 2-33

SOURCE CODE PREPROCESSOR                                   9 April 1990





directed  to  "stderr".   PP then of FORTRAN source, PP invokes PP.EXE,

also redirecting the  "stdout"  of  PP.EXE  to  "stderr"  (e.g.,  error

messages).   PP.EXE creates the output file with the same name but with

the extension  .f.  This is done using a FORTRAN  OPEN  statement.   In

all  cases,  PP  deletes  any extant preprocessed file and displays its

actions on "stderr".  If not successful, PP issues  error  messages  on

"stdout".   If  successful,  PP  displays the output file name, also on

"stdout".







2.12  CHECK LIST



     This section contains a simple check list of the items covered  in

the  first  two chapters.  If you make sure that you have completed all

of the below, you can save yourself a lot of trouble:



     Have all required local directories been  created,  that  is,  for

local versions of "system" definition files/procedures (i.e., $SYSLOCAL

as $SYSUNIX/LOCAL) and Q, Y or Z-routines  (see  "Local  Directories")?

DO  NOT  use  the  $SYSUNIX/LOCAL directory (or symbolic link) that may

have come on the installation tape.  If one came  on  the  installation

tape, delete it and create your own, virgin $SYSUNIX/LOCAL directory.



     Have you created the executables NEWEST, PRINTENV  and  PP.EXE  in

$SYSLOCAL  (see  "Programming  and  Execution  Tools"  and "Source Code

Preprocessor")?



     Have all required local directories been defined as "logicals"  in

$SYSLOCAL/CDVER.CSH   and/or   $SYSLOCAL/CDVER.SH   (see   "Local  Area

Logicals")?



     Have you copied $SYSUNIX/LOGIN.CSH  or  $SYSUNIX/LOGIN.SH  to  the

home  directory  for  the  AIPS  account,  edited  it appropriately and

included its execution in  the  account  login  procedure  (see  "Login

Procedures")?



     Have you copied $SYSUNIX/LIBR.DAT to $SYSLOCAL and  edited  it  to

reflect  the  proper  source  code  search  paths  and object libraries

mappings for the host implementation (see "Object Libraries and  Source

Code Search Paths")?



     Have you copied $SYSUNIX/INCS.SH to $SYSLOCAL  and  edited  it  to

reflect  the  proper search path for "included" source text (again, see

"Object Libraries and Source Code Search Paths")?



     Have you copied the $SYSUNIX/*OPT.SH files to $SYSLOCAL and edited

them  to  reflect the host option syntax for compiling and linking (see

"Compiler and Loader Options")?



     Have you looked at the appendix on "SYSTEM SPECIFIC NOTES" to  see

if there are any special action items for your system?

























                               CHAPTER 3



                          INSTALLATION STEP 2







3.1  RUNNING INSTEP2



     Change directory to $XXX/SYSTEM/UNIX/INSTALL.  There you will find

several  files with names of the form INSTEP*.  These are shell scripts

that represent the various installation steps.  INSTEP1 does not  exist

yet,   but  may  in  the  future.   INSTEP2  will  create  any  missing

directories  in  which  to  store  binary  files   (object   libraries,

executable  modules,  etc.) and compile all the subroutines required by

AIPS  on  the  host  system  based  on  the  specifications  given   in

$SYSLOCAL/LIBR.DAT.   INSTEP3  will compile a subset of the programs of

the AIPS system, link them  with  the  required  libraries  created  in

INSTEP2  and store the resulting load module(s) in the appropriate load

module area(s).  This subset is useful for exercising the system a  bit

before  launching  into INSTEP4 which will compile and link practically

every possible programs of the AIPS system.  To execute INSTEP2, simply

type:



INSTEP2





     INSTEP2 will first check for the existence of the  directories  in

which  binary  files  will  be  stored and if not found will attempt to

create them.  These existence/creation operations are  very  fast,  but

the  source  code  compilation  phase  can take quite some time.  On an

unload Sun 3 system, this can mean the  better  part  of  a  day.   The

Z-routine compilations don't occur until well into the INSTEP2 process,

so this gives you time to look into  any  local  Z-routine  development

that  may  be required (see appendix "Z-ROUTINES AND Z-PROGRAMS").  The

values of BYTFLP, SPFRMT,  DPFRMT,  TTYCAR  as  well  as  other  system

constants and parameters which are set in ZDCHI2 should be checked.



     INSTEP2 will cycle through all the major  subroutine  source  code

areas in the following order:



$AIPSUB

$APLSUB

$APLGEN

$YGEN

$YSUB

$YNOT

INSTALLATION STEP 2                                            Page 3-2

RUNNING INSTEP2                                            9 April 1990





$APLNOT

$QDEV

$QSUB

$QNOT





     and execute the procedure $SYSUNIX/MAKEAT to  generate  "@"  files

containing  lists  of  path names to all subroutine source code modules

pertinent to the host implementation.  For example, MAKEAT $APLGEN will

ultimately  produce  the  file  APLGEN.LIS containing a list of all the

subroutine source code found in the directory $APLGEN and below that is

relevant  to  the  host  implementation.   The  path names selected are

determined by the directory search paths defined in $SYSLOCAL/LIBR.DAT.

The  "@"  files are then used by the procedure $SYSUNIX/COMRPL to drive

the mass compilation  phase.   As  each  subroutine  is  compiled,  the

resulting  object module is staged to one or more $LIBR subdirectories,

again based on LIBR.DAT.  For example, object  modules  generated  from

$APLGEN/...  subroutine  source  code  is  staged  to  the proper $LIBR

subdirectory defined for  such  modules.   After  all  subroutines  are

complied  for,  say  $AIPSUB, the procedure $SYSUNIX/LIBR is invoked to

build an object library (i.e., "archive" file in  UNIX  parlance)  from

all the object modules found in the directory $LIBR/AIPSUB.



     COMRPL maintains a record of which modules in the "@"  files  have

been  successfully  processed,  so  INSTEP2  can  be  rerun as often as

necessary.  The way COMRPL knows which modules have been  processed  is

to  edit  the  "@"  files as it goes along and prefix a "-" to the path

name of the subroutine source code.  In the event of  a  system  crash,

INSTEP2  can  be  restarted  and will resume with the next module as if

nothing had happened.  INSTEP2 will also abort whenever COMRPL fails on

a  given  module.   This  allows you to investigate and take corrective

action  and  resume  the  process  simply  by  running  INSTEP2  again.

Alternatively,  you  could lie to INSTEP2 by editing the respective "@"

file, marking the problem routine as done (i.e., prefix "-" to its path

name),   restarting   INSTEP2   and   addressing  the  problem  routine

asynchronously.   A  description  of  which  modules   are   absolutely

essential  to  getting  AIPS off the ground is beyond the scope of this

document, so compilation failures should not be  ignored  indefinitely.

In  particular,  corrective  action  should  be  taken  before  INSTEP2

finishes processing the respective "@" file since its next step  is  to

build  the  respective  object library.  The object libraries are built

for single pass linking.  That is, the ordering of the object  code  in

the  library  is  such  that the loader can resolve all references in a

single pass.  A missing object  module  can  perturb  the  single  pass

ordering.



     The object libraries built by INSTEP2 via the procedure  LIBR  all

have  the  same name, SUBLIB (e.g., $LIBR/AIPSUB/SUBLIB).  INSTEP2 will

also check for the existence of the SUBLIB for a given major subroutine

source  code  area and if found, will completely skip it, regardless of

residual unprocessed path names in the respective "@" file.  The reason

for this is that, once the SUBLIB object libraries exist, the procedure

LIBR merely replaces (or adds) object modules in  the  library  without

any  consideration  to  ordering.   If you find yourself in a situation

INSTALLATION STEP 2                                            Page 3-3

RUNNING INSTEP2                                            9 April 1990





where a given SUBLIB  was  built  prematurely,  simply  change  to  the

respective  $LIBR  subdirectory,  execute  "ar x SUBLIB" to extract all

object modules and delete SUBLIB.  Rerunning  INSTEP2  will  cause  any

residual  unprocessed  subroutine path names in the respective "@" file

to be processed and subsequently invoke the procedure LIBR  to  rebuild

the object library with single pass ordering.



     The procedure COMRPL (compile  and  replace),  despite  its  name,

never  actually  puts  the  object modules in the object libraries.  It

only stages the object  module  to  one  or  more  $LIBR  subdirectory.

Object  library  updating  is  only  done  either  manually  or  by the

procedure LIBR.  Apart from INSTEP2,  the  only  other  place  LIBR  is

invoked  is  in  the  procedure  LINK which will check for any updating

required of the object libraries included in the link list for programs

from  a  given  directory,  then invoke LIBR to do it.  Recall that the

object library link lists for programs from the various program  source

code  areas  are also defined in $SYSLOCAL/LIBR.DAT.  One of the design

features of LIBR is that it locks the target SUBLIB to avoid collisions

that  often  result in corrupted object libraries.  The UNIX world does

not always protect against such collisions.







3.2  DEVICE LOGICALS



     Since INSTEP2 can take quite  a  while  to  complete,  while  it's

grinding  away  is  a  good  time  to  address the definition of device

logicals for the execution of AIPS programs.  The  files  ASSNLOCAL.CSH

(C  shell  syntax) and ASSNLOCAL.SH (Bourne/Korn shell syntax) are used

to define the AIPS system device logicals in the  form  of  environment

variables.    The  $SYSUNIX/ASSNLOCAL.*  files  are  heavily  commented

paraforms  that  should  be  copied  to   $SYSLOCAL   and   customized.

ASSNLOCAL.*  is  used  at login time to define the device logicals (see

"Login Procedures").



     Among the "devices" that are defined in ASSNLOCAL.* are AIPS  data

areas   (required),   tape   drives   (optional),   reserved  terminals

(optional), the default task message terminal (required), special  task

message terminals (optional), graphics terminals (optional), TV devices

(optional), line printer (required), laser  printer/plotter  (optional)

and batch error file/terminal (required).







3.2.1  Data Areas



     There must be at least one disk data area  for  AIPS  data  files.

AIPS  data  area  logicals  have names of the form DA0x, where x is the

1-relative hexadecimal AIPS disk number 1-F (i.e., when  running  AIPS,

INDISK=1  corresponds  to  the logical DA01).  The environment variable

DA00 should be defined as the full path name to a directory where  AIPS

"system"  files  are  to  be  stored.   The  remaining DA0x environment

variables should be defined as the full  path  name  to  the  directory

where AIPS "user" data files are to be stored for as many data areas as

INSTALLATION STEP 2                                            Page 3-4

DEVICE LOGICALS                                            9 April 1990





your system will have.  DA00 and DA01 can be defined identically (i.e.,

can  be  the  same  path name), but we find it useful to segregate AIPS

system files from user data files even if the  difference  is  only  in

directory  path  name  (i.e.,  $DA00  and  $DA01  are  on the same file

system).



     The  remaining  DA0x  environment  variables  should  have  unique

directory  path  name definitions.  It does little good to have several

directories on the same file system defined as AIPS data areas.  If you

have  a  choice,  you should probably keep the AIPS "system", including

$DA00 on one file system and put user data on other file systems.  This

will  keep  AIPS  users from consuming all available space (as is their

habit) and making any AIPS programming  nearly  impossible.   The  AIPS

system  files written to $DA00 must also occasionally expand (e.g., the

accounting file) and if there's no room, it can impair AIPS  usage  for

everyone.  Also, as mentioned above, it's useful to configure user data

areas on as many different disks and disk controllers as  possible  (to

reduce  I/O  contention)  and  users  should  be strongly encouraged to

practice I/O load leveling.  In particular, $DA01  is  the  only  place

where  certain  user  files  are  stored (e.g., message files, SAVE/GET

files, TGET/TGET files) and when space  on  $DA01  is  exhausted,  AIPS

usage  can  be impaired.  When running AIPS, users can set the "adverb"

BADDISK to prevent scratch file creation on $DA01.  Of course, they may

not  have  any  choice  if  $DA01 is the only disk in the system or its

usage for scratch files is necessary in order to  run  their  job.   At

NRAO,  we have an "extra" disk that appears as normal to the AIPS user,

however, an AIPS system parameter is set such that only  scratch  files

may  be created there.  You may find it useful to establish one or more

such a scratch disks in your AIPS system.  Furthermore, the same system

parameter can be set such that only specified user numbers are allow to

create files (of any type) on a particular disk  (see  "Running  SETPAR

and SETTVP").







3.2.2  Tape Drives



     The MT0x tape drive logicals require special consideration because

there  are  so  many  ways  to handle it.  The UNIX world in general is

rather weak in this area and highly inconsistent.  For  the  same  tape

drive  unit, UNIX systems typically have several alias device names and

the naming conventions seem to be as numerous  as  there  are  vendors.

The aliases are used to distinguish the desired "modes" of the drive in

question.  For example, the device /dev/rmt12 on the NRAO-CV Convex C-1

means  the  first  drive  on the system, "raw" mode, no rewind on close

(these represent the required modes for use with AIPS programs)  and  a

density  of 1600 BPI.  The device alias for the same tape unit with the

same properties except 6250 BPI, is /dev/rmt16.



     Another feature that UNIX systems often  lack  is  the  notion  of

"allocating"  a  given  tape drive to a specific user or process.  That

is, tapes can be read and/or written (unless write protected) by anyone

on  the system as long as the drive is not already opened by some other

process.  Some vendors provide rudimentary tape allocation schemes that

INSTALLATION STEP 2                                            Page 3-5

DEVICE LOGICALS                                            9 April 1990





will at least limit use to a specific user id.  Other vendors recognize

that on a large multi-user, multi-drive  system,  precautions  must  be

taken   to   prevent   users  from  colliding,  often  with  disastrous

consequences.  For  example,  Convex  systems  offer  a  VMS-like  tape

allocation  utility  that we use to prevent collisions.  Even so, since

we conduct most AIPS usage from the same account (i.e., run AIPS  under

the  same  user  id)  we  have to take additional measures against user

collisions.



     AIPS tape drive logicals have names of the form MT0x, where  x  is

the 0-relative (not very consistent, are we?) AIPS tape drive number in

hexadecimal (i.e., MT00 is the logical for AIPS tape  drive  number  1,

MT01  is  drive number 2, etc.).  AIPS has "verbs" to intended to issue

software mounts/dismounts.  The relevant Z-routine is called ZMOUN2 and

will  undoubtably require local development if a tape allocation scheme

is supported on your system and you  want  to  or  must  use  it.   The

problem  is  how  to  assign  the  proper alias device name to the MT0x

logical involved for a specified drive  and  density.   ZMOUN2  can  be

developed  to do this, but perhaps a simpler if only temporary solution

is to establish a convention for AIPS tape drives where,  for  example,

if  your system has a single multi-density tape drive, assign its alias

for one density to MT00 (i.e., AIPS drive #1), the  alias  for  another

density  to MT01 (i.e., AIPS drive #2), etc. .  Then in AIPS, densities

can be selected by drive number (instead of density) when in  fact  you

only  have  one physical drive.  To do this, you'll also have to lie to

AIPS via the system parameter  file  regarding  the  actual  number  of

physical  drives.   This  is  just one possibility.  The bottom line is

that a good solution will require a bit of imagination.







3.2.3  Reserved Terminals



     An AIPS feature that you may or may not want to take advantage  of

is  the  notion  of  reserved  terminals.   This  is a terminal that is

reserved for AIPSn (e.g., AIPS1) execution.  For example,  at  NRAO  we

have  AIPSn  work stations located in the vicinity of premium resources

such as the TV display devices and graphics terminals.  Users must sign

up  for  these  work stations since they are given "social" priority in

terms of access  to  these  devices  as  well  as  execution  priority.

Reserved terminals are purely optional and can be added later simply by

defining them in your ASSNLOCAL.* files.  It should also  be  mentioned

that  in order to create a reserved terminal, the terminal must be hard

wired to a specific terminal port on a specific machine.







3.2.4  Message Terminals



     As in the case  of  reserved  terminals,  the  notion  of  message

terminals  is  also  purely  optional.   These  are  terminals that are

devoted to displaying the messages from AIPS tasks that are running  as

subprocesses.  These are normally associated with reserved terminals as

part of the notion of an AIPS work station.  This may be a luxury  that

INSTALLATION STEP 2                                            Page 3-6

DEVICE LOGICALS                                            9 April 1990





you cannot afford since it requires that the terminal be connected to a

port, but taken out of the interactive group.  This makes it  otherwise

useless,  however,  it  doesn't  have  to be a very smart terminal.  In

fact, at NRAO we have recycled otherwise  obsolete  terminals  as  AIPS

message  terminals.  Nevertheless, these terminals still tie up a port.

Like reserved terminals, message terminals can be added later by simply

defining them in your ASSNLOCAL.* files.







3.2.5  Graphics Terminals



     In  AIPS,  a  "graphics"  terminal  means  a  Tektronix  4010/4012

compatible  device.   Among  the possible command line arguments to the

AIPS startup procedure is the "REMOTE" option, which  will  define  the

user  terminal  as  the  device  for graphics terminal I/O.  If AIPS is

started up with this option and any TK* verbs or  tasks  are  executed,

the  user  terminal will be used for graphics terminal I/O.  If so, the

terminal had better be Tektronix 4010/4012 compatible.   Alternatively,

independent  graphics  terminals  may  be  defined.   As in the case of

message terminals, the physical graphics terminals defined in this  way

must  be  taken  out  of  the  interactive group and are otherwise dumb

devices.  The AIPS startup procedure makes the actual device assignment

and  may  require  some customization.  It defines the logical TKDEV as

"TKDEV0", "REMOTE", or "TKDEVn".  The routine ZWHOMI will translate the

value  of  TKDEV.   If  the  value  is  "TKDEV0", no graphics device is

assigned.  If the value is "REMOTE", TEKTK1n will be used where "n"  is

the assigned POPS number.  All TEKTK1n logicals are defined as /dev/tty

(i.e., the  user's  control  terminal).   If  the  value  of  TKDEV  is

"TKDEVn", the "n" is extracted and subsequently used to establish which

TEKTKn is the assigned graphics device.  Much of this is  necessary  to

keep  areas  in  the  image  catalog (an AIPS system file) separate for

different users and devices and is admittedly, rather confusing.   It's

probably   worth   looking   at   the  AIPS  startup  procedure  (i.e.,

$SYSUNIX/AIPS) and the routine ZWHOMI  (i.e.,  $APLUNIX/ZWHOMI.FOR)  to

get a better understanding of what's going on.







3.2.6  TV Display Devices



     TV display devices, if any, should be defined in your  ASSNLOCAL.*

files  as  environment variables with names of the form TVDEV1, TVDEV2,

..., TVDEVF up to the number (hexadecimal)  of  such  devices  on  your

system.   The AIPS startup procedure will recognize if more than one TV

is defined and prompt you to select one by number.   The  AIPS  startup

procedure  makes  the  actual  device  assignment  and may require some

customization.  It defines the logical  TVDEV  as  either  "TVDEV0"  or

"TVDEVn".   The  routine  ZWHOMI will translate the value of TVDEV.  If

the value is "TVDEV0", no TV device is assigned.  By  definition,  this

is  always  the case for "AIPS REMOTE".  If the value is "TVDEVn", with

"n" > 0, the "n" is extracted and subsequently used to establish  which

TVDEVn  is the assigned TV device.  As in the case of graphics terminal

assignments, it's probably worth looking at the AIPS startup  procedure

INSTALLATION STEP 2                                            Page 3-7

DEVICE LOGICALS                                            9 April 1990





(i.e.,     $SYSUNIX/AIPS)     and    the    routine    ZWHOMI    (i.e.,

$APLUNIX/ZWHOMI.FOR) to get a better understanding of what's going on.







3.2.7  Batch Error Terminal/File



     If you elect to have AIPS batch  streams  (i.e.,  where  jobs  run

sequentially with lower execution priority), a provision should be made

for catastrophic error logging.   The  environment  variable  BATCH_OUT

should  be  defined as either a terminal or a simple disk file for this

purpose.  The system console is a good choice since it's often  a  hard

copy  device (i.e., teletype-like), but a simple disk file will do just

as well.  The point is that the error messages should  be  captured  in

some semi-permanent form.







3.2.8  Printers And Plotters



     Under UNIX, AIPS line printer output is written to a disk file  in

the  directory  defined by the environment variable LPRNTR using a file

name of the form ZLPOPN.*.  The extension  generated  is  unique.   The

routine  that  closes  this file (ZLPCLS as called by ZCLOSE) will also

call a the routine ZLPCL2 and pass it the name of the  $LPRNTR/ZLPOPN.*

file involved.  ZLPCL2 will invoke a shell script, which is also called

ZLPCL2.  The ZLPCL2 script will probably require some local development

and  should  reside in the $SYSLOCAL directory.  Examples of the ZLPCL2

script can be found in the various  subdirectories  of  $SYSUNIX.   The

sole  purpose  of  the  $SYSLOCAL/ZLPCL2  script  is  to  spool a given

/tmp/ZLPCL2.* file to a printer.  The routine  ZLPCL2  (i.e.,  not  the

script ZLPCL2) will take care of deleting the file.



     Output files targeted for printer/plotters are handled in the same

way.   The  environment  variable  PLOTTER  should  be  defined  as the

directory where uniquely named,  temporary  plotter  files  are  to  be

generated, unless overridden by an output file name specified using the

OUTFILE adverb.  The directory /tmp which has the advantage that it  is

publicly  writable  and  on  system  reboots, files in /tmp are usually

purged.  This simplifies disk management, but the file system on  which

/tmp  resides  can  sometimes  be  too small to accommodate some of the

larger plotter files.



     These days, laser printers are the best supported plotting devices

in  AIPS.   Tasks exist for generating graphics output for a variety of

laser printers and graphics languages including QMSPL (QMS/QUIC), LWPLA

(LaserWriter/postscript)  and CANPL (Canon LBP-8/language?).  QMSPL and

CANPL make use of the ZLAS* routines to create, open, close and dispose

laser  printer output files.  The routine ZLASC2 invokes a shell script

called ZLASCL to spool it  to  the  appropriate  device.   The  routine

ZLASCL  will  take  care  of  deleting  the output file, if appropriate

(i.e., if OUTFILE is not specified).  The  script  ZLASCL  may  require

some  local development and should reside in $SYSLOCAL.  The task LWPLA

uses similar routines called ZLW* that use similar techniques.

INSTALLATION STEP 2                                            Page 3-8

DEVICE LOGICALS                                            9 April 1990





     A task still exists that has fallen into disuse at NRAO but  still

may  be  useful  at  other  AIPS sites.  Its called PRTPL which calls a

routine by the name of ZDOPRT.  Several versions of ZDOPRT can be found

in   $APLVMS  for  various  printer-plotter  devices  (e.g.,  Versatec,

Printronix).  The ZDOPRT routines will require  local  development  for

UNIX  systems  since  NRAO  has  never  had  such devices on any of its

UNIX/AIPS systems, past or present.  A ``quick version of PRTPL used to

exists  in $APGVMS called QWKPL, but it requires two Z-routines, ZQWKPL

and ZSBIT that have never been developed for  the  UNIX  implementation

(i.e.,  since  it  has  always  been  an  otherwise VMS specific task).

Futhermore, QWKPL has yet to be  overhauled  to  meet  the  new  coding

standards,  and may never be.  The tasks IMGPL and PRIMG that also used

to be found in $APGVMS might have served well as a starting  point  for

the  development  of  a plotting task for Imagen devices, but these too

have not yet been and may never be overhauled  to  meet  the  new  AIPS

coding standards.



     Other printer/plotter tasks may also be of interest.  For example,

KNTR,  which  is  based  on  the  task CNTR, but generates contour plot

commands suitable for pen plotters.  Also, TXPL, which displays a  plot

file  on  a  terminal  or  line  printer  using different characters to

approximate grey scale intensities.



     Alternatively,  if  you  have  a  laser  printer   with   graphics

capability,  you  may want to use the task QMSPL and the ZLAS* routines

as models for a task to exploit  it.   In  any  case,  the  environment

variable  PLOTTER should be defined as a directory path name where plot

files are to be generated and that will ultimately be spooled  to  your

plot device.

























                               CHAPTER 4



                      INSTALLATION STEPS 3 AND 4







4.1  RUNNING INSTEP3



     The INSTEP3 procedure can be fairly lengthy,  but  not  nearly  as

long as INSTEP2.  To initiate INSTEP3, simply type:



INSTEP3





     The  purpose  of  INSTEP3  is  to  compile   a   selected   subset

(approximately  20)  of  all  the  possible programs in the AIPS system

(approximately 220 and growing) and to link them with one or more times

with one or more object library link lists (as determined by LIBR.DAT).

The resulting executable modules are moved to  the  appropriate  $LOADn

directory.  The subset represents:



     1.  the stand-alone program FILAIP which creates the  AIPS  system

         files and initializes all but the POPS memory files



     2.  the stand-alone program  POPSGN  which  initializes  the  POPS

         memory files that are created by FILAIP



     3.  the stand-alone  programs  SETPAR  (general)  and  SETTVP  (TV

         oriented)  for  setting  values  in  the system parameter file

         created by FILAIP



     4.  the system specific AIPS startup program ZSTRTA



     5.  the tasks DISKU and NOBAT simply to exercise task initiation



     6.  the subset of tasks known as the "Dirty Dozen" (actually  more

         than a dozen) which includes UVLOD, IMLOD, UVSRT, UVMAP, COMB,

         APCLN, SUBIM, CCMRG, ASCAL, MX, VTESS, PRTAC, UVDIF and FITTP





     INSTEP3 begins by searching for the source code of these  programs

and  building an "@" file called INSTEP3.LIS containing the source code

path names.  It then uses INSTEP3 to drive the procedure  COMLNK  which

compiles  the  programs  and links the resulting object module with the

$LIBR/*/SUBLIBs as prescribed in $SYSLOCAL/LIBR.DAT.

INSTALLATION STEPS 3 AND 4                                     Page 4-2

RUNNING FILAIP                                             9 April 1990





4.2  RUNNING FILAIP



     Once INSTEP3 has completed, you will need to  execute  (in  order)

FILAIP,  POPSGN  and SETPAR.  For those systems with TV display devices

it may be necessary to execute SETTVP as well, however, this  can  wait

until  you are ready to actually load images to the device.  To execute

FILAIP, simply type:



RUN FILAIP





     The  generic  procedure  RUN,  which  resides  in  the   directory

$SYSUNIX,  is  designed to locate in the directory $LOAD the executable

module for the specified program  and  start  it  up.   Make  sure  the

environment  variable  AIPS_VERSION  is set to $NEW (or $TST, whichever

you have defined as the version of AIPS you are installing).  Executing

$CDNEW  (or  $CDTST)  is  the  safest  way  to  ensure  that  all  AIPS

programming logicals are defined consistently.  RUN will tell you which

version of the program it is starting up.



     Those of you who  are  familiar  with  the  VMS/AIPS  installation

procedures may think "FILAIP" is a typo and should be "FILAI2" instead.

That's because FILAI2 is used by the VMS/AIPS installation procedure to

perform the function of FILAIP.  FILAIP prompts the user for its inputs

whereas FILAI2 is driven by a file called  "SYSPARM."  (yes,  the  file

name  ends  with  a ".").  However, "SYSPARM." is created by a VMS/AIPS

installation procedure which does not and may never exist for UNIX/AIPS

installations.  Also, FILAI2 initializes many more of the parameters in

the system parameter file that  it  creates,  whereas  FILAIP  must  be

followed by an execution of SETPAR to do this.  FILAIP no longer issues

the silly error messages about files that it  cannot  find  because  it

hasn't  created  them  yet.   The  following is an example execution of

FILAIP based on our AIPS configuration on the Convex C-1 at NRAO-CV:



RUN FILAIP

Starting up FILAIP (RELEASE OF 15APR90)

This software is the subject of a User agreement and

is confidential in nature. It shall not be sold or

otherwise made available or disclosed to third parties.

# disks, # cat entries/disk (<0 => private catlgs) (2 I)

6 -100

# interactive AIPS, # batch queues (2 I)

8 2

# TV, # TK devices (2 I)

2 16

# tape drives (I)

4

Image device No. 1 #gray, #graph, #img/gray, #ISUs (4 I)

4 4 64 0

Image device No. 2 #gray, #graph, #img/gray, #ISUs (4 I)

3 4 256 0

FILAI1: Init POPS memory files 1 through 11 with program POPSGN

FILAI1: Done!

STOP:

INSTALLATION STEPS 3 AND 4                                     Page 4-3

RUNNING FILAIP                                             9 April 1990









     Your response for the "# disks" should be for the number  of  user

data  areas  in  your AIPS configuration.  These correspond to the DA01

through DA0x environment variables  defined  in  $SYSLOCAL/ASSNLOCAL.*.

The  "#  cat  entries/disk"  response is not as critical as it once was

since user catalog files are now expandable.  It  used  to  be  a  user

could   not   exceed  this  number  of  entries  without  AIPS  manager

assistance.  100 is a reasonable starting point.   However,  making  it

negative  (i.e., -100) selects user based private catalogs (rather than

one big public catalog).  This is the preferred mode of operation these

days.



     Your response for "# interactive AIPS" tells the system  how  many

interactive  AIPS  sessions  are  to  be  allowed simultaneously.  Each

session is assigned a "POPS" number,  1  through  N.   Similarly,  your

response  for  "#  batch  queues"  tells the system how many AIPS batch

streams are allowed, each  one  requiring  a  separate  queue.   "POPS"

numbers  in  AIPS  are  limited  to  1  through  F  (hexadecimal).  The

combination of interactive sessions and batch  queues  in  the  example

above  causes  FILAIP  to  create  11  "POPS" memory files.  The number

created is always # interactive AIPS + # batch queues +  1.   Expanding

your  configuration  later  is  possible but more complicated.  You can

give comfortable values now and  restrict  AIPS  usage  through  system

parameter  values  set  via the program SETPAR later.  The memory files

are specific to a given release of AIPS and are stored in the directory

$AIPS_VERSION/MEMORY  with  names of the form MEx0000n;1 where "f" is a

letter indicating the data format revision level.



File type    Bytes    Number of files



MEf0000n;1  386048    #interactive AIPS + #batch_queues + 1



     As FILAIP will tell you, memory files  1  through  N  need  to  be

initialized with the program POPSGN (see below).



     If your respond with a value greater than zero for the  number  of

TV  display  devices in your AIPS configuration, FILAIP will prompt you

for some TV parameters.  It's best to know these answers ahead of time.

If  you  don't  know  the answers to these questions now, they "can" be

reset later via the program SETTVP, but the files  FILAIP  will  create

will have to be recreated later via the program FILINI.  In short, it's

far simpler to provide the appropriate values to FILAIP.  The number of

TV  and  tape  drives  you  specify  should correspond to the number of

TVDEVx, and MT0x logical devices you defined in  $SYSLOCAL/ASSNLOCAL.*,

respectively.   The  number  of  TK  devices should always be 16.  This

provides for the maximum number  of  graphics  terminals  possible  and

allows  for  "remote"  sessions  with a POPS number as high as 15 (i.e,

"F") where  the  users  control  terminal  serves  as  the  device  for

Tektronix output.



     FILAIP will create a number  of  system  files  in  the  directory

defined   as   logical  device  DA00  in  $SYSLOCAL/ASSNLOCAL.SH.   The

following is a summary of the files created by the example execution of

INSTALLATION STEPS 3 AND 4                                     Page 4-4

RUNNING FILAIP                                             9 April 1990





FILAIP above:



File type     Bytes   Number of files



ACf00000;1   102400   1

BAf00qnn;1    10240   #batch_queues*(#interactive_AIPS+#batch_queues-1)

BQf00000;1     2048   1

ICf00000;1    25600   1

ICf00001;1   275456   1 (IIS model 70 w/ #gray=4, #graph=4, img/gray=64)

ICf00002;1   809984   1 (IVAS         w/ #gray=3, #graph=4, img/gray=256)

IDf0000n;1     1024   # of TVs

PWf00000;1    50176   1

SPf00000;1     1024   1

TCf00000;1   126976   1

TDf00000;1    47104   1

TPf0010n;1     1024   # of tape drives





     FILAIP will also create the file MSf00100.001;1 in  the  directory

defined  as  logical device DA01 in $SYSLOCAL/ASSNLOCAL.*.  This is the

message file for user #1 and the "f" will be a letter  code  indicating

the data format revision level (e.g., "A" as of release 15OCT86, "B" as

of release 15JAN87 thru 15APR89 and "C" as of release  15OCT89).   When

we find it necessary to change the data format in a given AIPS release,

we will change the data format code.  This way, data from an  old  AIPS

release can peacefully coexist with the data of a new AIPS system until

the update is complete and you're ready to update user data to the  new

format (see "UPDATING USER DATA FORMATS").







4.3  PASSWORDS



     Among the files  created  by  FILAIP  is  a  password  file.   All

passwords  are initially blank except for user #1 which is reserved for

the AIPS manager.  The password for user  #1  is  initially  "AMANAGER"

(yes,  upper  case).  Since the password entry for user #1 is initially

non-blank, whenever programs run as  user  #1,  the  password  will  be

required.   The  stand-alone  utility  programs such as FILAIP, POPSGN,

SETPAR, SETTVP, etc. run as user #1 by default.  For example, if  after

successfully  running FILAIP as described above, you were to re-run it,

the first prompt you would get would be for the password  (i.e.,  since

the  password  file now exists).  When typing the password, it will not

be echoed on the terminal and you will only be given a few  chances  to

get  it  right before the program will give up and exit.  Passwords may

be changed for the current user via the PASSWORD verb in AIPS.  If  the

password  is  forgotten for user #1, the only recourse is to delete the

entire password file (i.e., $DA00/PWf*) and recreate it via the program

FILINI.   AIPS  users  don't usually make use of the password facility.

In fact, most  don't  even  realize  that  it  exists.   However,  it's

important  to  restrict  the  usage  of  the  system management utility

programs since their abuse can wreak havoc.

INSTALLATION STEPS 3 AND 4                                     Page 4-5

RUNNING POPSGN                                             9 April 1990





4.4  RUNNING POPSGN



     "POPS" is the command language of AIPS.   The  POPS  memory  files

created by FILAIP in the directory $AIPS_VERSION must be initialized as

a separate step.  If you fail to do this, AIPS won't have the  foggiest

idea what you're talking about, not even the EXIT command.  This is the

sole purpose of the program POPSGN which prompts you  for  its  inputs.

To execute POPSGN, simply type:



RUN POPSGN





     The  following  is  an  example  execution  of  POPSGN  that  will

initialize the 11 memory files created from the FILAIP example above:



RUN POPSGN

Starting up POPSGN (RELEASE OF 15APR90)

Enter Npops1, Npops2, Idebug, Mname, Version (3 I's, 2 A's)

1 11 0 POPSDAT NEW

>

POPSG1: Popsgen complete

POPSG1: Account: NEW  Cpu=   15.90  Real=   190.0  IOcount=      1163

STOP:





     Npops1  and  Npops2  represent  the  range  of  memory  files   to

initialize,  in  this case, 1 through 11.  Your response should be 1 to

the number of memory files created in $AIPS_VERSION/MEMORY  by  FILAIP.

The  Idebug  response  should always be zero.  Otherwise, your terminal

will be  flooded  with  debug  messages  that  only  POPS  "gurus"  can

interpret.   Your  response  for Mname should always be "POPSDAT" (yes,

uppercase).  A file called  POPSDAT.HLP  is  stored  in  the  directory

$HLPFIL  which contains the initialization values for the memory files.

POPSGN will accept a different name and  version  for  this  file,  but

until  you  know  what  you're  doing,  don't  try it.  In order to add

"adverbs" and/or "verbs" to the AIPS command  set,  $HLPFIL/POPSDAT.HLP

(or  a  copy of it) must be modified to incorporate the new definitions

and POPSGN must be rerun to re-initialize the POPS memory files.   (See

the  "Going  AIPS"  programming  manuals  for  more on adding verbs and

adverbs.) The final input to POPSGN is  the  "version"  of  the  memory

files  to  initialize.   This  should be given as "OLD", "NEW" or "TST"

(without the double quotes), whichever corresponds to  the  release  of

AIPS  that  you  are  installing.   This  can also be used to specify a

private version of of POPSDAT.HLP (or a different file  name  with  the

same contents and



     .HLP extension), but this can be difficult to do under UNIX.   The

reason is that it requires that you give the path name of the directory

in which the desired version of  POPSDAT.HLP  resides  (maximum  of  24

characters),  but POPSGN will convert all characters the directory name

to upper case which is hardly ever the proper case for a UNIX directory

name.  The same is true for the name of the POPSDAT.HLP file.

INSTALLATION STEPS 3 AND 4                                     Page 4-6

RUNNING POPSGN                                             9 April 1990





     After entering this information, POPSGN  will  grind  away  for  a

while and eventually issue a ">" prompt.  Simply type a carriage return

at this point.  When POPSGN completes, the next  step  is  to  run  the

program SETPAR and and perhaps the program SETTVP to set any parameters

not initialized by FILAIP during its creation of the  system  parameter

file.







4.5  RUNNING SETPAR AND SETTVP



Even though FILAIP creates the system parameter  file  and  initializes

some  of  the  parameters, it does not initialize all of them.  For the

moment, it is not particularly crucial to set the remaining parameters.

The  following  is  an  example  execution  of SETPAR and the parameter

values are from our AIPS environment on the NRAO-CV Convex C-1:



RUN SETPAR

Starting up SETPAR (RELEASE OF 15APR90)

Enter:  1=Start Over, 2=Change parameters, 3=Change DEVTAB, 4=Quit

2

  1  No. of AIPS data disks                  6

  2  No. of tape drives                      4

  3  No. of lines per CRT page              24

  4  No. of lines per print page            61

  5  No. of batch queues                     2

  6  Plotter no. of X dots per page       2112

  7  Plotter no. of Y dots per page       1600

  8  Plotter no. of X dots per character    20

  9  Plotter no. of Y dots per character    25

 10  No. of interactive AIPS                 8

 11  No. of words in AP (in 1024s)          64

 12  No. of TV devices available             2

 13  No. of graphics devices available      16

 14  No. of X dots per mm on printer     7.830

 15  No. of X dots per mm on tektronix   5.000

 16  No. of POPS allowed access to TVs      15

 17  No. of POPS allowed access to TKs      15

 18  No. entries in private catalogs       100

 19  Local system identification (A20)  UNKNOWN AIPS SITE

 20  Maximum user number (<= 4095)        4095

 21  TIMDEST minima disks  1 -  3 days   14.  14.  14.

 21  TIMDEST minima disks  4 -  6 days   14.  14.  14.

 22  TIMDEST limit: SAVE/GET files        28.

 23  TIMDEST/EXIT limit: messages          3.

 24  TIMDEST limit: scratch files          3.

 25  TIMDEST limit: empty CA files       0.250

 26  No AP batch starts: weekend hours  15.00016.500

     No AP batch starts: weekday hours  13.00017.000

 27  AP roll interval minutes            5.000

     AP patience: (1)*N+(2)*N*N minutes  5.000 1.000

 28  Line printer width (72 - 132)         132

 29  Pseudo-AP 2nd memory (1024s)            0

 30  Max length of "short" vector            0

INSTALLATION STEPS 3 AND 4                                     Page 4-7

RUNNING SETPAR AND SETTVP                                  9 April 1990





 31  Graphics (TK) screen size: x, y      1024   780

 32  Graphics (TK) character size: x, y     14    22

 33  Disk & reserved users or -1 scratch (9 I)

     Disk  2 Users    0

     Disk  3 Users    0

     Disk  4 Users    0

     Disk  5 Users    0

     Disk  6 Users    0

Enter number to change or  0 = Print, -1 = Return

19

 19  Local system identification (A20)  UNKNOWN AIPS SITE

NRAO1 Convex C-1 7.1

Enter number to change or  0 = Print, -1 = Return

20

 20  Maximum user number (<= 4095)        4095

1800

Enter number to change or  0 = Print, -1 = Return

29

 29  Pseudo-AP 2nd memory (1024s)            0

192

Enter number to change or  0 = Print, -1 = Return

0

  1  No. of AIPS data disks                  6

  2  No. of tape drives                      4

  3  No. of lines per CRT page              24

  4  No. of lines per print page            61

  5  No. of batch queues                     2

  6  Plotter no. of X dots per page       2112

  7  Plotter no. of Y dots per page       1600

  8  Plotter no. of X dots per character    20

  9  Plotter no. of Y dots per character    25

 10  No. of interactive AIPS                 8

 11  No. of words in AP (in 1024s)          64

 12  No. of TV devices available             2

 13  No. of graphics devices available      16

 14  No. of X dots per mm on printer     7.830

 15  No. of X dots per mm on tektronix   5.000

 16  No. of POPS allowed access to TVs      15

 17  No. of POPS allowed access to TKs      15

 18  No. entries in private catalogs       100

 19  Local system identification (A20)  NRAO1 Convex C-1 7.1

 20  Maximum user number (<= 4095)        1800

 21  TIMDEST minima disks  1 -  3 days   14.  14.  14.

 21  TIMDEST minima disks  4 -  6 days   14.  14.  14.

 22  TIMDEST limit: SAVE/GET files        28.

 23  TIMDEST/EXIT limit: messages          3.

 24  TIMDEST limit: scratch files          3.

 25  TIMDEST limit: empty CA files       0.250

 26  No AP batch starts: weekend hours  15.00016.500

     No AP batch starts: weekday hours  13.00017.000

 27  AP roll interval minutes            5.000

     AP patience: (1)*N+(2)*N*N minutes  5.000 1.000

 28  Line printer width (72 - 132)         132

 29  Pseudo-AP 2nd memory (1024s)          192

INSTALLATION STEPS 3 AND 4                                     Page 4-8

RUNNING SETPAR AND SETTVP                                  9 April 1990





 30  Max length of "short" vector            0

 31  Graphics (TK) screen size: x, y      1024   780

 32  Graphics (TK) character size: x, y     14    22

 33  Disk & reserved users or -1 scratch (9 I)

     Disk  2 Users    0

     Disk  3 Users    0

     Disk  4 Users    0

     Disk  5 Users    0

     Disk  6 Users    0

Enter number to change or  0 = Print, -1 = Return

-1

Password:

Enter:  1=Start Over, 2=Change parameters, 3=Change DEVTAB, 4=Quit

4

SETPA1: Account: OLD  Cpu=    0.49  Real=    85.0  IOcount=        18

STOP:





     Most of the parameters are self-explanatory whereas others require

explanation  beyond the scope of this document.  Most systems will have

very similar parameters apart from some  of  the  more  obvious  cases,

however,  the AP memory parameters are worth mentioning.  The value for

"No.  of words in AP (in 1024s)" should be non-zero even if you have no

AP  on your system.  The pseudo AP routines depend on this parameter as

well and pseudo AP installations  should  leave  this  value  as  "64".

Before setting it to any other value, it's recommended that you consult

with the AIPS group  at  NRAO.   The  "Pseudo-AP  2nd  memory  (1024s)"

parameter  should be left as "0" for most systems.  However, the pseudo

AP implementation for Alliant and Convex systems take advantage of this

parameter and it should be set to "192", as in the case above.



     SETTVP is used to set TV specific parameters,  and  the  following

example  execution  is for the IIS model 70 on our Convex C-1 system at

NRAO-CV:



RUN SETTVP

Starting up SETTVP (RELEASE OF 15APR90)

Enter 1=Init, 2/3=Change parms, 4=ISU, 5=quit and the TV # (2I2)

2 1

1  No. of gray-scale planes         (I)     4

2  No. of graphics overlay planes   (I)     4

3  No. of images / gray-plane       (I)    64

4  X,Y size of TV planes (pixels) (2 I)   512   512

5  Maximum gray-scale intensity     (I)   255

6  Peak intensity out of LUT        (I)   255

7  Peak intensities in/out of OFM (2 I)  1023  1023

8  X,Y min. scroll increments     (2 I)     1     1

9  Maximum zoom: (>0) power of 2    (I)     3

      (< 0) Max factor = 1 - MAXINT

10 Type of split-screen allowed     (I)     4

      1=Vert, 2=Hori, 3=Either, 4=Both

11 # X,Y pixels in TV characters  (2 I)     7     9

12 X-axis image write mode(s)       (I)     1

      0 - None, 1 -> Right, 2 -> Left

INSTALLATION STEPS 3 AND 4                                     Page 4-9

RUNNING SETPAR AND SETTVP                                  9 April 1990





13 Y-axis image write mode(s)       (I)     2

      0 - None, 1 -> Up, 2 -> Down

Enter number to change, 0=print, -1=return (I2)

-1

Enter 1=Init, 2/3=Change parms, 4=ISU, 5=quit and the TV # (2I2)

5 0

SETTV1: Account: OLD  Cpu=    0.16  Real=    25.0  IOcount=        17

STOP:





     Of course, if your system has no TV display  device,  you  needn't

concern yourself with SETTVP.







4.6  EXERCISING AIPS



4.6.1  AIPS Start-up Procedure



     The generic procedure for initiating an interactive  AIPS  session

is   $SYSUNIX/AIPS   (a   lower   case  link  is  also  provide,  i.e.,

$SYSUNIX/aips).  Similarly, to initiate a BATER (i.e., AIPS  batch  job

submission  program), there is a procedure in $SYSUNIX called BATER (as

well as bater).  Both are designed to take command line arguments which

are explained in the comments at the beginning of each procedure.  When

you invoke these procedures, various environment variables are  defined

or  toggled  based  on  the  command line arguments, and the respective

startup program is executed, ZSTRTA for AIPS or ZSTRTB for BATER.   The

major  purpose of the ZSTRT* programs is to assign the lowest available

POPS number to the current job not reserved for another terminal and to

invoke  the  respective executable module as a process with a name such

as AIPSx, where "x" is the assigned POPS number.  Tasks initiated  from

an  AIPSx  session  inherit  this  POPS number and have similar process

names (e.g., MXx).  In addition, for those systems with more  than  one

TV  display  device  (i.e.,  if  the  environment  variable  TVDEV2  is

defined), the startup procedure will query the user to  select  such  a

device by number.  To startup AIPS, simply type:



AIPS NEW (or TST, whichever is appropriate)









4.6.2  Task Initiation



     Assuming AIPS in fact starts up, you're ready to start  exercising

it  a  bit.   In  particular, two of the executable modules that should

have been generated by the INSTEP3 procedure are useful for trying  out

task initiation.  These are DISKU and NOBAT, neither of which depend on

the existence of any data on disk.  In fact, DISKU is  used  to  report

disk usage.  NOBAT is a null program that when executing, prevents AIPS

batch jobs from running, thereby giving interactive  AIPS  jobs  better

response.   All  NOBAT  does  is  startup  and  execute  for  the  time

specified, sleeping most of the time and only waking up to see if  it's

INSTALLATION STEPS 3 AND 4                                    Page 4-10

EXERCISING AIPS                                            9 April 1990





time  to terminate.  Both of these programs are harmless candidates for

testing task initiation.







4.6.3  Tape Interface



     Once you are satisfied that task initiation works, you're ready to

move on to more substantive tasks, like reading in data from tape.  The

tasks involved here are UVLOD (reads UV data tapes)  and  IMLOD  (reads

map  data  tapes).   Their success or failure depends critically on the

integrity of  the  tape  interface  routine  ZTAP2  which  will  almost

certainly  require  local  development  in  the  case  of  ports to new

systems.  Versions of ZTAP2 already exist in the various subdirectories

of  $APLUNIX for several systems (e.g., $APLALLN, $APLCVEX, $APLSUN and

$APLVAX) which may work without modification.  The  $APLUNIX  directory

contains  a  stubbed  version  of  ZTAP2.   If this is the version that

actually gets  processed  by  the  INSTEP2  phase  and  added  to  your

Z-routine  object  library,  programs linked with it will tell you that

ZTAP2 requires local development  whenever  any  tape  manipulation  is

attempted.







4.6.4  "Dirty Dozen" Tasks



     The other executable modules generated by INSTEP3 will  allow  you

to do quite a range of typical AIPS processing.  After you're satisfied

that the system is functioning properly, you can generate the remaining

executable modules of the AIPS system.







4.6.5  Running Under A Debugger



     The routine that actually forks  and  executes  a  process  (i.e.,

sheds  an  AIPS  task)  is  called ZACTV9.  If the environment variable

DBUGR is defined as  the  absolute  path  name  of  a  debugger  (e.g.,

/bin/adb,  /bin/dbx, etc.), ZACTV9 will startup the prescribed debugger

instead.  The user can then execute the task under  its  control.   The

startup procedures AIPS and BATER take the command line option "DEBUG".

If selected, the user will be queried for the simple  command  name  of

the  desired  debugger  (e.g.,  dbx).  The procedure will then check to

make sure that the debugger specified is legitimate and if  not,  query

the  user  again.   The  criteria  for  "legitimate" is simply that the

procedure was able to locate  the  specified  file  using  the  current

execution  search  path  (i.e.,  $PATH) and that the file is executable

(debuggers are not the only file that meet this criteria, so users  can

in  fact  produce  some  rather  bizarre  but  harmless effects).  Once

satisfied with  the  user's  answer,  the  procedure  will  define  the

environment  variable  DBUGR  as  the  full  path  name of the debugger

specified.  The reason for this is that UNIX systems often have several

debuggers  from  which to choose.  The procedure will then ask the user

whether to run  AIPS  (or  BATER)  itself  under  the  control  of  the

INSTALLATION STEPS 3 AND 4                                    Page 4-11

EXERCISING AIPS                                            9 April 1990





specified  debugger.   If so, a special environment variable (AIPSDBUGR

in the case of AIPS and BATERDBUGR in the case of BATER) is defined  to

be  the full path name of the specified debugger.  ZACTV9 will test for

these definitions and take the appropriate action.  If not,  then  only

subprocesses will be executed in debug mode (and only if SETDEBUG(n) is

issued in AIPS with "n" > 10).  The reason for this is that  running  a

process  like  AIPS  under  the  control  of  a debugger as well as its

subprocesses can be very confusing,  if  not  simply  undesirable.   To

clarify  which process is prompting the user in debug mode, the process

(which is actually the debugger  execution)  is  renamed  to  the  AIPS

program  name  using  the  normal AIPS process naming convention (i.e.,

program name plus POPS number suffix) and  this  name  appears  as  the

parenthesized  debugger  prompt  instead of the normal debugger command

name.  ZACTV9 will also automatically put the  parent  process  into  a

wait state while executing its children in debug mode (i.e., regardless

of the value assigned to the AIPS adverb DOWAIT).







4.6.6  The VERSION Adverb



     The adverb VERSION in AIPS is used to point to task executables in

different  directories.   The  intention  is  that,  in addition to the

normal selection (i.e., OLD, NEW, TST, etc.), the user should  be  able

to  point  to a private edition by specifying the full path name of the

directory containing the  desired  executable.   The  requirements  for

executing private versions of tasks are somewhat different from the VMS

implementation.  A version of the task HELP file  (i.e.,  ".HLP"  file)

must  reside  in  the  same directory as the executable module, just as

under VMS, but that's where the similarity ends.  The  stumbling  block

here is that case distinction for the values assigned to string adverbs

in AIPS  has  been  discontinued.   At  one  time,  AIPS  allowed  case

distinction  in  string  inputs,  however,  this  totally  confused the

VMS/AIPS user community and was therefore unimplemented.  Someday  this

may be reinstated, but until then, all such string values are converted

to upper case.  This makes it very difficult to specify path names that

contain  lower  case  characters.   Therefore,  the kludge solution for

string  adverbs  like  VERSION,  INFILE,  OUTFILE,  etc.,  is  to   use

predefined  environment  variables  (i.e., defined prior to starting up

AIPS) whose definitions  are  the  path  names  to  files  that  cannot

otherwise  be  represented  because they contain lower case characters.

The names chosen for these environment variables must,  of  course,  be

entirely  upper case.  Deep in the bowels of the UNIX Z-routines, these

environment variables are translated in order to extract  the  required

path name.



     Therefore, in order to execute a private version of  a  task,  you

must  first  define an upper case environment variable as the path name

of the directory in which both the desired executable  module  and  its

corresponding  ".HLP" file reside.  These names of these files must, of

course, also be entirely upper case.  When you start up AIPS,  you  can

then  specify  the  name  of  the  environment  variable (without the $

prefix) as the value of the VERSION adverb.  For example, if we want to

execute  a  private  version  of  the task FOO, and FOO.EXE and FOO.HLP

INSTALLATION STEPS 3 AND 4                                    Page 4-12

EXERCISING AIPS                                            9 April 1990





reside in /nrao1/aips/pgmr/khilldru/tasklib, then  we  must  define  an

environment variable, for instance, MYVAR as:



setenv MYVAR /nrao1/aips/pgmr/khilldru/private   (C shell)



or



MYVAR=/nrao1/aips/pgmr/khilldru/private          (Bourne or Korn shell)

export MYVAR



then in AIPS, after we set VERSION='MYVAR', we  can  type  INPUTS  FOO,

HELP  FOO,  EXPLAIN  FOO  or GO FOO, and AIPS should find the necessary

files.







4.7  RUNNING INSTEP4



     The INSTEP4 procedure can take as long or longer than INSTEP2.  To

initiate INSTEP4, simply type:



INSTEP4





     INSTEP4 will cycle through all the major program source code areas

in the following order:



$AIPPGM

$AIPGUNIX

$APLPGM

$APGNOT

$QPGM

$QPGNOT

$QYPGM

$QYPGNOT

$YPGM

$YPGNOT





     and build "@" files for all the programs found, then use  the  "@"

files  to  drive the execution of COMLNK, as in the case of INSTEP3 but

on a much larger scale (approximately 220 programs in all).



     Once program object modules are generated, they  are  left  around

unless  you  indicate  in  $SYSLOCAL/LDOPTS.SH  to  delete  them  after

successful  links.   They  take  up  about  as  much   space   as   the

corresponding   unpreprocessed   program  source  code,  but  have  the

advantage that if you simply want to re-link a program, you don't  have

to  suffer  the  pain  of  re-compiling it as well.  COMLNK invokes the

procedure SEARCH which is designed to replace, if  necessary,  whatever

form  of  the  program the user specified (i.e., unpreprocessed source,

preprocessed source or object module) with the most up-to-date form  of

the  program.  For example, if the user types "COMLNK $AIPPGM/AIPS.FOR"

but $AIPPGM/AIPS.o exists and is  up-to-date,  SEARCH  will  substitute

INSTALLATION STEPS 3 AND 4                                    Page 4-13

RUNNING INSTEP4                                            9 April 1990





$AIPPGM/AIPS.o  and  simply  invoke  the  procedure LINK to re-link it.

This is true even when "INCLUDE" files change that  are  "included"  in

the  program  source  code.   That is, if the user specifies the object

form and SEARCH detects that an "INCLUDE" file has  been  modified,  it

will  substitute  the  unpreprocessed  form  of the program source code

which induces COMLNK to  preprocess  and  compile  again,  all  in  the

interest  of  maintaining  system  integrity (not to mention programmer

sanity).

























                              APPENDIX A



                       Z-ROUTINES AND Z-PROGRAMS







     The following is a collection of notes  regarding  Z-routines  for

UNIX AIPS.







A.1  HISTORY



     The original implementation of  AIPS  under  UNIX  occurred  as  a

result  of  the  pioneering  efforts  of David Garrett in the Astronomy

Department at the University of  Texas,  Austin.   At  NRAO,  the  UNIX

implementation  has  evolved  under  a number of systems beginning with

Amdahl's UTS implementation of Version 7 UNIX.  As painful as  it  was,

the  UTS  port may have been a blessing in disguise.  Given that it was

an implementation of Version 7 UNIX, an implementation under UTS  could

be  considered  largely  portable.  A Masscomp MC 500 at NRAO Greenbank

running Bell's System III UNIX has also served as a test bed from  time

to  time  although  never  as  a production machine.  We now have three

Convex C-1's running 4.3bsd UNIX (one in Charlottesville and another at

the VLA), several Sun 3s and most recently, a Sun 4.  We've also ported

AIPS to the Alliant FX architecture and a port of AIPS to Cray's UNICOS

is  in  progress.  Non-NRAO sites have also ported AIPS to a variety of

UNIX environments.  The result has  been  the  evolution  of  a  rather

robust, portable implementation, however, NRAO must continue to rely on

sites that are running flavors of UNIX or that have hardware  different

from  ours  to  contribute  the  special  code  that  these systems may

require.  This has already produced a subset of routines that may  very

well  prove  to  be  generic  for  UNIX/AIPS, but we need to know about

variations, improvements and  most  importantly  cases  where  what  we

believe to be generic is not in fact the case at all.







A.2  STANDARDS.



     In general, all is fair in love, war and Z-routines.  However,  we

are  striving  to  develop a set of generic Z-routines for UNIX and, to

some extent, the rest of the computing world.  So, just because you can

get  away  with  it  in no way implies that it's standard.  Practically

every vendor seems to feel obliged to add extensions that often  seduce

the  unwitting  into  writing  non-portable  code.   For  example, many

Z-ROUTINES AND Z-PROGRAMS                                      Page A-2

STANDARDS.                                                 9 April 1990





systems that will allow you to EQUIVALENCE data items of type CHARACTER

with  data  items  of other types (an ANSI standard violation).  Making

use of this would mean that on such systems, many Z-routines  could  be

written  in FORTRAN rather than the local assembler language.  Wherever

routines can be written in ANSI standard FORTRAN 77, they should be, so

that  they  can be used by any system that has a 77 compiler.  The real

authority for this is the somewhat difficult to read American  National

Standard  Programming  Language  FORTRAN, ANSI X3.9-1978.  DEC provides

VMS FORTRAN users with very nice manuals  that  highlight  non-standard

constructs  in blue ink, however, some VMS programmers have contributed

code where they have disregarded the different colored ink, if not  the

portability effort entirely.



     The situation for Z-routines that must be written  in  C  is  less

clear.   An  ANSI  standard  for  C  is in the works, but until this is

firmed up, we will have to rely on the most common usage.  At NRAO this

is  achieved  by comparing our rather large library of vendor reference

manuals for various flavors  of  UNIX  as  well  as  other  sources  of

                                     _
standards  information  including  ATT's System V Interface Definition.

However, NRAO cannot have one of everything nor will we always  get  it

right.  It is our sincere hope that other sites running AIPS under UNIX

sites will contribute their variations and improvements to  the  system

dependent areas.  We will endeavor to pass these on to other sites and,

as time and standards permit, incorporate them into the generic set.







A.3  ZDCHI2



     Several system  parameters  defined  in  the  routine  ZDCHI2  are

critical  to the successful exchange of data between systems, primarily

via tape or pseudo tape.  These include  the  values  assigned  to  the

/DCHCOM/  variables  BYTFLP, SPFRMT and DPFRMT.  The values assigned to

several other, less critical system parameters in ZDCHI2  also  warrant

attention.  These include the values assigned to the /DCHCOM/ variables

NSHORT, TTYCAR, SYSTYP and SYSVER.







A.3.1  BYTFLP



     The value assigned to BYTFLP is used to indicate whether the  host

uses  byte  or  word  flip,  or  both, or neither (most common) for its

internal representation of data.  Byte/word flipped data is  where  the

order  of  the  bytes  in  data  items  is  "flipped"  ("little endian"

ordering) compared to the more common  order  ("big  endian"  ordering)

found  in  the  computing  industry.   It  could be construed as a real

advantage if you restricted yourself to these  architectures,  however,

it  certainly  impacts the exchange of data between dissimilar systems.

For this reason, AIPS has been designed such that it converts its input

from  the outside world (i.e., tape and pseudo-tape data) into the byte

order of the host and on output, converts it back to the more  industry

compatible  order.   This  means  that on most machines, the conversion

routines do nothing to perturb the order of bytes/words  (but  must  be

Z-ROUTINES AND Z-PROGRAMS                                      Page A-3

ZDCHI2                                                     9 April 1990





called  nevertheless).   This  also  puts  the burden of reordering the

bytes on those machines whose designers chose to be "different".



     The value given to BYTFLP is critical since its  value  determines

how  the  data conversion Z-routines will re-order integer bytes in the

data read from and written to tape or FITS-disk  files  (pseudo  tape).

By  far  the  majority  of  processors these days use "big endian" byte

ordering for their internal representation of integer data (a la  IBM).

In  these cases, there are no byte sex problems and data can be read to

and from tape without conversion.  BYTFLP should  be  left  as  "0"  on

these  system.   This  is  true  for  practically all processors except

VAXes, DECstations (MIPS) and  Intel  (e.g.,  80286)  based  processors

which  use  "little  endian"  byte  ordering.  In these cases, the mask

value for BYTFLP should be  set  to  "3"  (i.e.,  both  byte  and  word

flipped).   It  should  be  noted that not all MIPS-based processor use

little endian ordering.  Like the MC 88000  and  AMD  29000-based  RISC

processors,   MIPS-based  processors  actually  support  both  ordering

schemes, selectable only at power-up.   However,  the  highest  profile

MIPS-based  processor  is easily the DECstation 3100 and DEC apparently

decided that it was more important to maintain data compatibililty with

their existing VAX machines.



     The following Z-routines are sensitive to byte/word flip:



   ZBYTFL       ZBYTF2       ZI16IL       ZI32IL       ZILI16

   ZILI32       ZIPACK       ZR32RL       ZR64RL       ZRLR32

   ZRLR64







A.3.2  SPFRMT And DPFRMT



     The notion of floating-point format codes was introduced as of the

15OCT87  release,  but  the codes have not actually been used until the

15OCT89 release.  SPFRMT and DPFRMT are floating-point format indicator

codes   used   to   indicate  the  host  single  and  double  precision

floating-point  formats.   The  values  assigned  to  these  are   also

critical.   AIPS  uses  these  to  determine  how  to  convert the host

floating-point data format to IEEE format before writing it  to  "tape"

and, conversely, how to convert IEEE floating-point data read from tape

to the host format.  Note that the DECstation still does not have  full

data  compatibility with the VAX since the VAX floating-point format is

not IEEE!  Most processors brought to market in recent years  use  IEEE

float-point  format.   Versions  of the IEEE/host floating-point format

conversion Z-routines exist already for hosts that use  IEEE  (trivial,

of  course)  and  VAX F floating-point.  The routines that perform such

conversions (ZR32RL, ZRLR32, ZR64RL and ZRLR64) are  designed  to  stop

dead  in  their  tracks  if  they  see  an  unsupported  floating-point

indicator code.

Z-ROUTINES AND Z-PROGRAMS                                      Page A-4

ZDCHI2                                                     9 April 1990





A.3.3  NSHORT, TTYCAR, SYSTYP And SYSVER



     The value of NSHORT  should  be  the  number  of  iterations  that

characterizes  a loop as "short".  Some loop terminating values are not

known at compile time.  NSHORT provides a means by which  we  might  be

able  to  code  alternate,  scalar code to which execution would branch

upon detecting that the loop is "short".



     The value of TTYCAR (0 or 1) is simply used to toggle  whether  or

not carriage control is required for terminal I/O.  If you aren't sure,

try a few simple experiments to see if FORMATed terminal I/O requires a

leading blank (see $APLGEN/ZTTYIO.FOR).



     SYSTYP and SYSVER are CHARACTER variables  used  to  indicate  the

operating  system  (e.g.,  'UNIX'  versus  'VMS') and SYSVER is used to

indicate the version (e.g., 'BSD 4.3', '5.0').







A.4  ROUTINES THAT REQUIRE LOCAL DEVELOPMENT



     Some Z-routines may require local development, however, the  union

of  the$APLGEN  and/or $APLUNIX areas contains at least one of each, if

even only a stubbed version.  The  stubbed  versions  are  designed  to

print an error message to that effect and to either return a reasonable

error code or stop the  execution  of  the  program.   In  many  cases,

working  versions  of  routines  exist  that are suited to a particular

vendor's environment (e.g., $APLALLN, $APLCVEX and $APLSUN).  These are

environments with which we have either had first hand experience or for

which non-NRAO sites have submitted code.   However,  there  are  those

routines that will probably require some local development for ports to

platforms not currently supported in the Z-routine directory structure.



     The routines that potentially require  local  development  include

tape  manipulation  (ZTAP2  and  ZMOUN2),  line printer output spooling

(ZLPCL2;  at  least  the  required  shell  script),   IEEE   to   local

floating-point  conversion  (ZR32RL,  ZR64RL,  ZRLR32  and ZRLR64), VLA

archive tape data handling (ZDM2DL, ZMCACL, ZRDMF and ZRM2RL)  as  well

as  many  of  the other data conversion routines (e.g., ZI16IL, ZILI16,

etc.) if you are installing AIPS on a 64-bit machine.  Others  include,

getting  accumulated  CPU  time  (ZCPU; make sure the units are right),

parsing the output of the local "df" command (ZFRE2) and  perhaps,  the

TV oriented Z-routines (e.g., ZM70*) if your system has such a device.



     In the  early  stages  of  an  installation,  the  most  important

Z-routines  to  work  on  are ZDCHI2 and ZTAP2.  In ZDCHI2, you want to

make sure that the values for BYTFLP, SPFRMT,  DPFRMT  and  TTYCAR  are

proper  for  the  target  system.   ZTAP2 may take a bit of research to

determine the proper status bit values for  detecting  such  things  as

file  marks and beginning or end of tape.  The other Z-routines are not

so critical and can be worked on as the need arises.

Z-ROUTINES AND Z-PROGRAMS                                      Page A-5

UNIX Z-ROUTINES                                            9 April 1990





A.5  UNIX Z-ROUTINES



A.5.1  Descriptions



     The following are  brief  descriptions  of  the  Z-routines,  past

(most) and present (all):



   ARCOS.FOR .......(defunct).



   ARSIN.FOR .......(defunct).



   DARCOS.FOR ......(defunct).



   DARSIN.FOR ......(defunct).



   IAND.C ..........performs bitwise logical AND on INTEGER arguments

                    (this is an intrinsic function under VMS and

                    perhaps your system;  if so, eliminate it).



   IEOR.C ..........performs bitwise exclusive OR on INTEGER arguments

                    (this is an intrinsic function under VMS and

                    perhaps your system;  if so, eliminate it).



   IOR.C ...........performs bitwise inclusive OR on INTEGER arguments

                    (this is an intrinsic function under VMS and

                    perhaps your system;  if so, eliminate it).



   JIAND.C .........(defunct).



   ZABOR2.C ........establishes ZABORS as the routine to which programs

                    should branch when catchable signals are received.

                    Hangup, Interrupt (except for programs AIPS and

                    BATER) and quit are ignored.  The generic version

                    includes all the Bell version 7 UNIX catchable

                    signals.  ZABOR2 is only called by ZABORT.



   ZABORS.C ........abort handler established by ZABOR2.



   ZABORT.FOR ......establishes abort handling to clean up for AIPS and

                    tasks in the event of an ABORTTASK or otherwise fatal

                    signal.  It calls ZABOR2 which actually establishes

                    up the abort handler (ZABORS).  ZABORT is only called

                    by ZDCHIN, however, it is designed so that it can also

                    be called to have ZABOR2 invoke an illegal instruction

                    (i.e., as a debugging aid to get a core dump or trace

                    back).  This routine replaced ZESTEX some time ago.



   ZACTV8.FOR ......called by AU2, among others, to shed tasks.

                    Determines the full path name of the executable

                    module for the desired task and passes it on to

                    ZACTV9.  It now returns the process id returned by

                    ZACTV9 which can then be used to simplify task

                    monitoring and aborting (see ZTKILL and ZTACT*

                    below).  The Z-programs ZSTRTA and ZSTRTB stored in

Z-ROUTINES AND Z-PROGRAMS                                      Page A-6

UNIX Z-ROUTINES                                            9 April 1990





                    $AIPGUNIX also call ZACTV8.



   ZACTV9.C ........does actual task initiation via "vfork" (use "fork"

                    if "vfork" is not supported on your system) followed by

                    "execl" with the full path name of the executable module

                    provided by ZACTV8.  The second argument to "execl"

                    gives the process the name XXXXXn where "XXXXX" is the

                    name of the task and "n" is the "POPS" number of the

                    AIPS shedding the task (e.g., AIPS1 sheds UVMAP1).  It

                    now returns the process id as returned by "vfork" (or

                    "fork") and which can then be used to simplify task

                    monitoring and aborting (see ZTKILL and ZTACT* below).



   ZADDR.C .........determines if the address of two arguments is the

                    same.



   ZARGC2.FOR ......close an ARGS TV device (called only by ZARGCL;

                    stubbed).



   ZARGCL.FOR ......close an ARGS TV device (calls ZARGC2 to perform

                    the actual close).



   ZARGMC.FOR ......issues a master clear to an ARGS TV device.



   ZARGO2.FOR ......open ARGS TV device (only called by ZARGOP;

                    stubbed).



   ZARGOP.FOR ......open ARGS TV device (calls ZARGO2 to perform the

                    actual open).



   ZARGS.FOR .......sends command to/from the ARGS TV device (stubbed).



   ZARGXF.FOR ......translates IIS Model 70 commands into calls to

                    ZARGS for ARGS TV devices.



   ZB2ASC.C ........converts binary integer to ASCII and places right

                    justified in a string of specified length padded

                    with zeroes.



   ZBKLD1.FOR ......initializes the host environment in preparation for

                    the execution of ZBKLD2 under the task BAKLD (fast

                    user data restoration using "tar").



   ZBKLD2.FOR ......processes input tape for the task BAKLD.



   ZBKLD3.FOR ......cleans up the host environment upon termination of

                    the task BAKLD.



   ZBKTP1.FOR ......initializes the host environment in preparation for

                    the execution of ZBKTP2 under the task BAKTP (fast

                    user data backup using "tar").



   ZBKTP2.FOR ......writes a file and its extensions to the output tape

                    using "tar" under the task BAKTP.

Z-ROUTINES AND Z-PROGRAMS                                      Page A-7

UNIX Z-ROUTINES                                            9 April 1990







   ZBKTP3.FOR ......cleans up the host environment upon termination of

                    the task BAKTP.



   ZBYMOV.C ........moves a string of bytes (8-bit variety, not AIPS-

                    bytes) from one buffer to another.



   ZBYTF2.C ........only called by ZBYTFL to performs any required byte

                    interchanging.



   ZBYTFL.FOR ......interchanges all lower-ordered and higher-ordered

                    bytes in the words of an input buffer and places

                    the results in an output buffer (byte flip dependent;

                    no interchange is done for machines with no byte flip).



   ZC8CL.FOR .......extracts 8-bit ASCII standard characters in a buffer

                    and stores them in another buffer in local character

                    form (opposite of ZCLC8).



   ZCH2R4.FOR ......copies specified number of characters from a

                    CHARACTER array to a REAL (or otherwise numeric)

                    array and performs alternate RETURN if necessary

                    (used in transformation of ENCODE statements into

                    internal WRITEs by preprocessor;  word flip

                    dependent; defunct).



   ZCLC8.FOR .......converts local characters in a buffer to standard

                    8-bit ASCII (opposite of ZC8CL).



   ZCLOSE.FOR ......closes files associated with logical unit numbers

                    (LUN), removes exclusive use and clears file table

                    (FTAB) array entries (calls ZLPCL2 for line printer

                    files, ZTTCLS for terminals and ZDACLS for disk

                    files).



   ZCMPR2.C ........performs file compression (only called by ZCMPRS).



   ZCMPRS.FOR ......releases unused disk space in files (calls ZCMPR2

                    to perform the actual "compression").



   ZCPU.C ..........returns CPU time of calling process (should return

                    the i/o count as well, but this information is not

                    readily accessible under UNIX although some flavors

                    support "getrusage"; see $APLBERK/ZCPU.C).  The means

                    of simply getting the CPU time seems to differ from

                    UNIX to UNIX.  Before you invent yet another way,

                    check the generic, stubbed version.  You will probably

                    find that it will work if you use "#include <times.h>"

                    (e.g., Berkeley based systems) instead of

                    "#include <sys/times.h>" (e.g., Bell based systems).

                    Even so, the units of "user" and "system" time may

                    be different.



   ZCRDIR.C ........given the name of a directory, creates it (called

Z-ROUTINES AND Z-PROGRAMS                                      Page A-8

UNIX Z-ROUTINES                                            9 April 1990





                    only by the program IMPFIT).



   ZCREA2.C ........performs actual creation of files (lower-level

                    routine called only by ZCREAT).



   ZCREA3.FOR ......(defunct).



   ZCREAT.FOR ......creates all AIPS files read/written by the ZFI* and

                    ZMI* routines (calls ZEXIST to check for the files

                    pre-existence, then ZCREA2 to do the actual file

                    creation).



   ZCRLOG.C ........attempts to define or redefine a "logical" (i.e.,

                    environment variable).  Only called by some

                    versions of ZMOUN2.



   ZDACLS.C ........performs actual close of disk files (lower-level

                    routine called only by ZCLOSE, ZMSGCL, ZTPCLS and

                    ZTPOPN).



   ZDAOPN.C ........performs actual disk file opens for map and non-map

                    i/o (lower-level routine called only by ZOPEN,

                    ZMSGOP and ZTPOPN).



   ZDATE.C .........returns local date.  Another example of a simple

                    idea different from UNIX to UNIX.  Again, you will

                    probably find that the stubbed generic version

                    will work if you "include" <sys/time.h> (Berkeley

                    based systems) instead of <time.h> (Bell based

                    systems) or vice versa.



   ZDCHI2.FOR ......called only by ZDCHIN to initialize only those

                    system values in the device characteristics

                    common (DCHCOM) that are likely to require

                    modification by an installer including SPFRMT,

                    DPFRMT, NSHORT, TTYCAR, SYSTYP and SYSVER.



   ZDCHIC.C ........makes various "device characteristics" as defined

                    in ZDCHIN and ZDCHI2 available to routines written

                    in C (as external variables).  It also determines

                    some of these in a machine independent way and

                    calculates other useful "system constants" which

                    are also made available to other routines written

                    in C. ZDCHIC is only called by ZDCHIN.



   ZDCHIN.FOR ......called near the beginning of every main program,

                    this routine initializes the disk characteristics

                    common (DCHCOM). Some of these are hard coded, others

                    are read from the system parameter (SP) file.

                    ZDCHIN calls ZDCHI2 to get some of these values and

                    calls ZDCHIC to determine other "system constants"

                    in a machine independent way and to make them and

                    others available to routines written in C (as

                    external variables.

Z-ROUTINES AND Z-PROGRAMS                                      Page A-9

UNIX Z-ROUTINES                                            9 April 1990







   ZDEAC2.FOR ......special close for DeAnza type TV device (only

                    called by ZDEACL; stubbed).



   ZDEACL.FOR ......special close for DeAnza type TV device (calls

                    ZDEAC2 to peform the actual close).



   ZDEAMC.FOR ......issues master clear to DeAnza type TV device.



   ZDEAO2.FOR ......special open for DeAnza type TV device (only

                    called by ZDEAOP; stubbed).



   ZDEAOP.FOR ......special open for DeAnza type TV device (calls

                    ZDEAO2 to perform the actual open).



   ZDEAX2.FOR ......queues an I/O operation to a DeAnza type TV (only

                    called by ZDEAXF; stubbed).



   ZDEAXF.FOR ......queues an I/O operation to a DeAnza type TV

                    device (calls ZDEAX2 to perform the actual I/O).



   ZDELA2.C ........called by ZDELAY to issue actual delay (this is a

                    FORTRAN routine on Alliant systems).  The delay

                    requested can be fractional seconds, however, on

                    some systems there is no facility other than "sleep"

                    which has a resolution of 1 second at best.  This

                    makes interactive TV functions clumsy (e.g.,

                    TVBLINK).



   ZDELAY.FOR ......causes delay of specified time (calls ZDELA2 to

                    perform actual delay; we could probably rewrite

                    this in C and eliminate ZDELA2 except some C

                    compilers may not accept floating point literals

                    and we're not supposed to call Z-routines written

                    in the local assembler directly from the machine

                    independent code).



   ZDEST2.C ........performs the actual deletion of files (lower level

                    routine only called by ZDESTR).



   ZDESTR.FOR ......destroys (i.e., deletes) disk files (calls ZDEST2

                    to perform the actual file deletion).



   ZDHPRL.FOR ......convert 64-bit HP floating buffer to local DOUBLE

                    PRECISION values.



   ZDIR.FOR ........given a file type known to AIPS, a version and a

                    file name, builds the full path name to the file.



   ZDM2DL.C ........converts Modcomp R*6 or R*8 floating point data into

                    local double precision floating point. It's only

                    called by the non-standard tasks FILLR and FILLM

                    which can read archive tapes from the VLA Modcomp

                    synchronous system and create UV datasets under

Z-ROUTINES AND Z-PROGRAMS                                     Page A-10

UNIX Z-ROUTINES                                            9 April 1990





                    AIPS;  analogous to FILLER + EXPVIS on the VLA

                    DEC-10 + AIPS task UVLOD).



   ZDOPR2.C ........(defunct; see APLVMS version).



   ZDOPR3.FOR ......(defunct; see APLVMS version).



   ZDOPR4.FOR ......(defunct; see APLVMS version).



   ZDOPRT.FOR ......read a bit map such as produced by PRTDRW and convert

                    it into a FORTRAN file that can be spooled to the

                    VERSATEC printer-plotter as a plot.  This version

                    spools the plot to the device queue with the logical

                    name PLOTTER (a null operation under UNIX as it

                    stands now; see _$APLVMS/ZDOPR[2-5] for examples of

                    implementations for other printer/plotter devices).



   ZEDIT.C .........(defunct).



   ZENDPG.FOR ......advances the line printer to avoid "burn-out" on

                    electrostatic type line printers.



   ZERRO2.C ........returns the error message associated with a given

                    system error code (only called by ZERROR).



   ZERROR.FOR ......system error processing routine.



   ZESTEX.C ........(defunct; replaced by ZABORT).



   ZEXIS2.C ........performs actual test of file existence (lower-level

                    routine called only by ZEXIST).



   ZEXIST.FOR ......determines if a given file exists (calls ZEXIS2 to

                    actually determine the files existence and its size).



   ZEXIT.C .........(defunct).



   ZEXPN2.C ........performs actual file expansion (lower-level routine

                    called only by ZEXPND and ZMSGXP).



   ZEXPND.FOR ......increases the size of a non-map file (calls ZEXPN2

                    to perform the actual expansion).



   ZFI2.C ..........performs actual non-map disk i/o (lower-level

                    routine called by ZFI3 and ZFIO).



   ZFI3.FOR ........performs non-map (i.e., single buffered) i/o (calls

                    ZFI2 for disk devices and ZTKFI2 for graphics

                    devices to perform the actual data transfer; same

                    as ZFIO below only it takes pseudo I*4 arguments

                    and is being phased out; defunct).



   ZFIO.FOR ........performs non-map (i.e., single buffered) i/o (calls

                    ZFI2 for disk devices and ZTKFI2 for graphics

Z-ROUTINES AND Z-PROGRAMS                                     Page A-11

UNIX Z-ROUTINES                                            9 April 1990





                    devices to perform the actual data transfer; same

                    as ZFI3 above only it takes true I*4 arguments and

                    will eventually replace all ZFI3 calls).



   ZFRE2.C .........lower-level routine of ZFREE that examines $DA00,

                    $DA01, $DA02, ..., $DA0n AIPS disks and reports

                    free space (parses output of "df" command, but

                    should be rewritten to make use of "ustat" on Bell

                    UNIX systems and to use "statfs" on Berkeley

                    systems).



   ZFREE.FOR .......displays free disk space info returned by ZFRE2.



   ZFULLN.FOR ......convert file name to full pathname with no

                    logicals.



   ZGETC2.C ........(defunct; replaced by ZGETCH.C).



   ZGETCH.C ........extracts a single character from a word and places

                    it in the least significant bits of an otherwise

                    zero integer (the opposite of ZPUTCH).



   ZGNAME.FOR ......gets the name of the calling process (i.e., arg0).

                    This may have to be a C routine on some systems

                    (e.g., Version 7 UTS).



   ZGTBIT.C ........gets N bits from a word starting at a given address

                    and returns each bit in a different element of an

                    array (the opposite of ZPTBIT).



   ZGTBY2.C ........(defunct; replaced by ZGTBYT.C).



   ZGTBYT.C ........gets the specified byte of an integer and puts it

                    in the lower-ordered byte of another otherwise zero

                    integer (byte flip dependent;  the opposite of

                    ZPTBYT; defunct).



   ZGTDIR.FOR ......(defunct).



   ZHEX.C ..........encode an integer into hexadecimal characters.



   ZI16IL.FOR ......extracts 16-bit 2's complement integers from a buffer

                    and puts them into the local integer form (byte flip

                    dependent; calls ZBYTFL to ensure the proper byte

                    order).



   ZI32IL.FOR ......extracts 32-bit 2's complement integers from a buffer

                    and puts them into the local integer form (word

                    flip dependent; calls ZBYTFL to ensure the proper byte

                    order).



   ZI8L8.FOR .......converts 8-bit unsigned binary numbers to "bytes"

                    (1/2 of a local integer; defunct).



Z-ROUTINES AND Z-PROGRAMS                                     Page A-12

UNIX Z-ROUTINES                                            9 April 1990





   ZI8IL.FOR .......convert 8-bit unsigned integers in buffer to local

                    integers.



   ZILI16.FOR ......converts a buffer of local integers to a buffer

                    standard 16-bit, 2's complement integers (calls

                    ZBYTFL to ensure proper byte order).



   ZILI32.FOR ......takes local integers from a buffer and creates

                    a buffer of 32-bit, 2's complement integers (word

                    flip dependent; calls ZBYTFL to ensure proper

                    byte order).



   ZIPACK.FOR ......pack/unpack long integers into short integer

                    buffer.



   ZITOCH.C ........(defunct).



   ZIVSOP.FOR ......opens an IIS model IVAS TV device using the IIS

                    software package.



   ZKDUMP.FOR ......dumps an array in various formats.



   ZLASC2.C ........disposes laser printer output by invoking a

                    script by the same name, then deletes it, if

                    appropriate (only called by ZLASCL).



   ZLASCL.FOR ......closes laser printer output disk file and calls

                    ZLASC2 to dispose it to the printer, then delete

                    it if appropriate.



   ZLASIO.FOR ......performs laser printer I/O (calls ZLASOP to

                    open disk files for laser printer output; calls

                    ZLASCL to close, dispose and if appropriate,

                    delete laser printer output disk files.



   ZLASOP.FOR ......creates/opens laser printer output disk files.



   ZLDFIL.FOR ......old version of ZPHFIL designed solely for public

                    data files.



   ZLOCK.C .........opens (if necessary) and applies either a shared

                    or exclusive lock to a disk file.



   ZLPCL2.C ........spools file to the line printer (lower level

                    routine only called by ZLPCLS).  Whenever AIPS

                    writes to the line printer, the output is actually

                    written to a disk file.  When the "line printer" is

                    closed, ZLPCL2 is called to simply print this disk

                    file.  This is done via a call to "system" invoking

                    the system dependent shell script ZLPCL2.



   ZLPCLS.FOR ......closes a line printer file, spools it to the line

                    printer and deletes it (calls ZLPCL2 to perform

                    the actual spooling; only called by ZCLOSE).

Z-ROUTINES AND Z-PROGRAMS                                     Page A-13

UNIX Z-ROUTINES                                            9 April 1990







   ZLPOP2.FOR ......peforms the actual creation/open of a line

                    printer output disk file (only called by ZLPOPN).



   ZLPOPN.FOR ......opens a line printer file (lower level routine

                    called only by ZOPEN; calls ZLPOP2 to peform

                    the actual creation/open).



   ZLWIO.FOR .......much like ZLASIO (only called by the task LWPLA).



   ZLWOP.FOR .......creates and opens LWPLA laser printer output disk

                    file (only called by ZLWIO).



   ZM70C2.C ........performs the actual close on IIS model 70 and model

                    75 type TV devices (lower level routine only called

                    by ZM70CL).



   ZM70CL.FOR ......special close for IIS model 70 and model 75 type TV

                    devices (calls ZM70C2 to perform the actual close).



   ZM70M2.C ........performs the actual master clear on IIS model 70

                    model 75 type TV devices (lower level routine only

                    called by ZM70MC).



   ZM70MC.FOR ......issues master clear to IIS model 70 and model 75

                    type TV devices (calls ZM70M2 to perform the actual

                    master clear).



   ZM70O2.C ........performs the actual open on an IIS model 70 or model

                    75 type TV device (lower level routine only called

                    by ZM70OP).



   ZM70OP.FOR ......special open for IIS model 70 and model 75 type TV

                    devices (calls the lower level routine ZM70O2 to

                    perform the actual open).



   ZM70X2.C ........performs the actual i/o on a IIS model 70 or model

                    75 type TV device (lower level routine only called

                    by ZM70XF).



   ZM70XF.FOR ......queues an I/O operation to a IIS model 70 or model

                    75 type TV device (calls ZM70X2 to perform the

                    actual i/o).



   ZMATH4.FOR ......does I*4 arithmetic on pseudo I*4 arguments (word

                    flip dependent).



   ZMCACL.C ........convert Modcomp compressed ASCII to Hollerith

                    characters (only called by the task FILLR).



   ZMI2.C ..........performs the actual "map" (double buffered,

                    asynchronous i/o) on disk files (lower level

                    routines called only by ZMIO).



Z-ROUTINES AND Z-PROGRAMS                                     Page A-14

UNIX Z-ROUTINES                                            9 April 1990





   ZMI3.FOR ........performs random access, large record, map i/o (i.e.,

                    double buffered, asynchronous i/o)  It calls ZMI2

                    to perform the actual data transfer.  It's the same

                    as ZMIO below only it takes pseudo I*4 arguments and

                    is being phased out (defunct).



   ZMIO.FOR ........performs random access, large record, map i/o (i.e.,

                    double buffered, asynchronous i/o)  It calls ZMI2

                    to perform the actual data transfer.



   ZMKTMP.C ........makes a unique temporary file name.



   ZMOUN2.C ........performs software mount/dismount of tapes (lower-

                    level routine called only by ZMOUNT).  As in

                    the case of tape manipulation, the way tapes are

                    mounted varies from UNIX to UNIX.  Sometimes they

                    are devices that are always on-line (i.e., mounted)

                    and in other systems, a special mount request or

                    device assignment must be made.  The routine ZCRLOG

                    can be used to set the MT0x environment variables

                    to the desired tape device alias (e.g.,/dev/rmt12).



   ZMOUNT.FOR ......lower-level routine of ZTAPE that in turn calls

                    ZMOUN2 to perform software mounting of tapes.



   ZMOVE.C .........general purpose character string moving routine

                    (defunct).



   ZMSGCL.FOR ......special version of ZCLOSE for message files to

                    avoid recursion.



   ZMSGDK.FOR ......special version of ZFIO for message files to

                    avoid recursion.



   ZMSGER.FOR ......special version of ZERROR for message files

                    to avoid recursion.



   ZMSGOP.FOR ......special version of ZOPEN for message files to

                    avoid recursion.



   ZMSGWR.FOR ......a routine whose sole purpose is to take a

                    CHARACTER buffer containing the text of a message,

                    copy it to the REAL array MSGTXT using for

                    messages and calls MSGWRT with a given message

                    level code (simplifies issuing messages from

                    routines written in C so that they get into the

                    user's message file).

 

   ZMSGXP.FOR ......special version of ZEXPN2 to avoid recursion.



   ZMYVER.FOR ......determines the default VERSION (OLD, NEW or TST)

                    by extracting the values of the environment variables

                    OLD, NEW and TST plus AIPS_VERSION and looking for

                    match.

Z-ROUTINES AND Z-PROGRAMS                                     Page A-15

UNIX Z-ROUTINES                                            9 April 1990







   ZOPEN.FOR .......upper-level open routine for map and non-map disk

                    files, input terminal and line printer (to perform

                    the actual opens, it calls the lower level routines

                    ZDAOPN for disk files, ZTTOPN for the input

                    terminal and ZLPOPN for the line printer).



   ZP4I4.FOR .......(defunct).



   ZPATH.C .........converts a file name 'Logical:file' to full path

                    name.



   ZPARS.C .........(defunct; replaced by ZTXMA2).



   ZPHFIL.FOR ......builds full path names of files given type, disk,

                    version, etc. for both private and public systems

                    (replaces ZLDFIL).



   ZPHOL1.FOR ......constructs old style physical file name containing

                    volume id for; used for converting pre-15APR86

                    data files to newer formats (defunct).



   ZPHOLD.FOR ......old version of ZPHFIL (defunct).



   ZPHOLV.FOR ......constructs physical file names containing a specific

                    format version code; used by the program UPDAT.



   ZPRI2.C   .......lower level routine called only by ZPRIO.

                    Changing your execution priority under UNIX works

                    okay as long as you want to decrease it, however,

                    going the other way requires superuser privilege,

                    so ZPRI2 simply ignores these requests.



   ZPRIO.FOR .......changes the calling program's execution priority

                    between that of AIPS "batch" and AIPS

                    "interactive".  Actually priority changing is

                    done in ZPRI2.



   ZPRIO2.C ........(defunct; replaced by ZPRI2).



   ZPRMPT.C ........issues terminal prompts without new line.



   ZPRPAS.C  .......prompts the user with the string "Password:", then

                    reads back an 8 character "password" without

                    echoing what's typed.  It returns a 12 character,

                    left justified string to its caller padded on the

                    right with blanks.



   ZPTBIT.C ........gets N bits from different elements of an array

                    containing the bit pattern starting at a given

                    array index and puts the bits in word (the opposite

                    of ZGTBIT).



   ZPTBY2.C ........(defunct; replaced by ZPTBYT.C).

Z-ROUTINES AND Z-PROGRAMS                                     Page A-16

UNIX Z-ROUTINES                                            9 April 1990







   ZPTBYT.C ........gets the lower-ordered byte of an integer and puts

                    it in the specified byte of another integer (byte

                    flip dependent; the opposite of ZGTBYT; defunct).



   ZPUTC2.C ........(defunct; replaced by ZPUTCH.C).



   ZPUTCH.C ........puts the least significant bits (one character worth)

                    of a given word into the specified byte of another

                    word (byte flip dependent;  the opposite of ZGETCH).



   ZQASSN.C ........(defunct; replaced by ZTKOP2, ZTPOP2 and, for

                    example, ZM70O2).



   ZQCLOS.C ........(defunct; replaced by ZDACLS).



   ZQCRE3.C ........(defunct; replaced by ZCREA2).



   ZQCREA.C ........(defunct; replaced by ZCREA2).



   ZQDASS.C ........(defunct; replaced by ZTKCL2, ZTPCL2 and, for

                     example, ZM70C2).



   ZQDEVN.C ........(defunct; replaced by ZERRO2).



   ZQEXP.C .........(defunct; replaced by ZEXPN2).



   ZQIOV.C .........(defunct; not used by the UNIX implementation).



   ZQMSCL.C ........called only by ZQMSIO and ZLWIO after a close of a

                    QMS or Postscript output file.  Its sole purpose in

                    life is to queue the output file for printing.  It

                    does this by invoking a shell script by the same

                    name (i.e., ZQMSCL). (defunct; replaced by ZLASCL).



   ZQMSG.C .........(defunct; replaced by ZERRO2).



   ZQMSGX.C ........(defunct; replaced by ZEXPN2).



   ZQMSIO.FOR ......opens, writes to and closes a file for printing

                    a plot on a QMS Lasergraphix device (defunct;

                    replaced by ZLASIO).



   ZQOPEN.C ........(defunct; replaced by ZDAOPN).



   ZQRENA.C ........(defunct; replaced by ZRENA2).



   ZQTAPE.C ........(defunct; replaced by ZTAP2).



   ZQTRUN.C ........performs actual disk file truncation (lower-level

                    routine called only by ZCMPRS; defunct; replaced

                    by ZCMPR2).



   ZQWIO.C .........(defunct; replaced by ZWAI2 and ZTPWA2).

Z-ROUTINES AND Z-PROGRAMS                                     Page A-17

UNIX Z-ROUTINES                                            9 April 1990







   ZQWKPR.FOR ......(defunct; not used by the UNIX implementation).



   ZR32RL.FOR ......converts from 32 bit IEEE floating format to local

                    single precision.



   ZR42CH.C ........copies a specified number of characters from a REAL

                    or otherwise numeric array to a CHARACTER array (used

                    mostly if not exclusively in the transformation of

                    DECODE statements into internal READ constructs by

                    the preprocessor; defunct).



   ZR64RL.FOR ......converts from 64 bit IEEE floating format data to

                    local double precision (or corresponding 64 bit

                    precision).



   ZR8P4.FOR .......general conversion routine for pseudo I*4 to/from

                    REAL*8 based on opcodes (word flip dependent).



   ZRDMF.C .........converts data packed in DEC-Magtape format (DMF) to

                    pairs of local integers (only used by the task

                    FILLR which can read archive tapes from the VLA

                    Modcomp synchronous system and create UV datasets

                    under AIPS;  analogous to FILLER + EXPVIS on the VLA

                    DEC-10 + AIPS task UVLOD.



   ZRENA2.C ........performs actual renaming of disk files (lower-level

                    routine called only by ZRENAM).



   ZRENAM.FOR ......renames disk files (calls ZRENA2 to perform actual

                    rename).



   ZRHPRL.FOR ......converts from 32 bit Hewitt-Packard floating format

                    to local single precision.



   ZRLR32.FOR ......converts from local single precision to 32 bit IEEE

                    floating format.



   ZRLR64.FOR ......converts from local double precision (or corresponding

                    64 bit precision) to 64 bit IEEE floating format.



   ZRM2RL.C ........converts Modcomp single precision floating point data

                    into local single precision floating point.  It's only

                    called by the tasks FILLM and FILLR which can read

                    archive tapes from the VLA Modcomp synchronous

                    system and create UV datasets under AIPS; analogous

                    to FILLER + EXPVIS on the VLA DEC-10 + AIPS task UVLOD).



   ZSBIT.FOR .......(defunct).



   ZSETUP.FOR ......performs any system level operations which can be

                    done only after VERNAM, TSKNAM and NPOPS have been

                    determined, such as setting AIPS batch execution

                    priority.

Z-ROUTINES AND Z-PROGRAMS                                     Page A-18

UNIX Z-ROUTINES                                            9 April 1990







   ZSHCMD.C ........executes a "shell" command string (used only by the

                    tasks BAKLD and BAKTP).



   ZSPACE.C ........reads AIPS data area directories accumulating

                    user based statistics regarding disk usage.  Only

                    called by the system specific program SPACE used

                    for reporting disk hog information (only developed

                    for NRAO Convexs).



   ZSTAI2.C ........queries user about tapes still mounted on exit from

                    AIPS (Convex implementation only).



   ZSTAIP.FOR ......although it's intended to clean up at the end of

                    an interactive AIPS session, we haven't found this

                    necessary for UNIX/AIPS.  Therefore, this is a

                    null routine (except for the $APLCVEX version which

                    calls ZSTAI2).



   ZSTRTP.C ........sets the execution priority of the current process

                    based on its POPS number (only called by ZSTRTA

                    program).



   ZSUSPN.C ........(defunct).



   ZTACT2.C ........determines if a given AIPS task is currently running

                    (lower-level routine called only by ZTACTQ).  If

                    provided a non-zero process id, otherwise it looks for

                    a /tmp lock file name as created by ZACTV9 and extracts

                    the pid extension.  Task existence is determined via

                    "kill(0)".



   ZTACTQ.FOR ......determines if a given AIPS task is currently running

                    (calls ZTACT2 to perform actual determination).



   ZTAP2.C .........performs actual tape manipulation (lower-level

                    routine called only by ZTAPE). Tape manipulation

                    is highly system dependent.  Even the UNIX manuals

                    tell you this (under MTIO(4)).  A good example to

                    copy is the version of ZTAP2 found in $APLUNIX

                    which is stubbed.  The information that you have to

                    extract from your tape controller vendor is the

                    status bits for end of file (tape mark) and beginning

                    of tape (load point).  Actually, you can detect

                    tape marks by issuing a read and testing for zero

                    bytes transferred.  Detecting the load point can

                    only be done via the status bits and must be done

                    for the tape oriented verbs and tasks to function

                    properly.



   ZTAPE.FOR .......general tape manipulation (calls ZTAP2 to perform

                    actual manipulation).



   ZTAPIO.C ........opens, reads and closes a tape (called only by the

Z-ROUTINES AND Z-PROGRAMS                                     Page A-19

UNIX Z-ROUTINES                                            9 April 1990





                    program IMPFIT).



   ZTCLOS.FOR ......closes text files.



   ZTFILL.FOR ......initializes the file table control block (i.e.,

                    FTAB)



   ZTIME.C .........returns local time.  Again, different from UNIX to

                    to UNIX.  Again, you will probably find that the

                    stubbed generic version will work if you "include"

                    <sys/time.h> instead of <time.h> or vice versa.



   ZTKBUF.FOR ......puts lower-ordered byte of integer in a specified

                    element of the graphics device output buffer.



   ZTKCL2.C ........called only by ZTKCLS to perform actual device

                    reset and closing.



   ZTKCLS.FOR ......close for graphics device provided for any special

                    actions required.



   ZTKFI2.C   ......performs the actual i/o on a Tektronix-like device

                    (lower level routine only called by ZFI3 and ZFIO).

 

   ZTKILL.C ........given the name or pid of a task, kills it with prejudice.

                    If fed a non-zero "pid" (process id), it kills that

                    process, otherwise it looks for a /tmp lock

                    file name as created by ZACTV9, extracts the pid

                    extension, and if active, kills the process.



   ZTKOP2.C ........performs actual open of a Tektronix-like device

                    (lower level routine only called by ZTKOPN).



   ZTKOPN.FOR ......open for graphics device provided for any special

                    actions required.



   ZTKQIO.C ........(defunct; replaced by ZTKFI2).



   ZTOPE2.FOR ......performs actual open of text file (only called

                    by ZTOPEN).



   ZTOPEN.FOR ......opens text files (calls ZTOPE2 to perform the

                    actual text file open).



   ZTPCL2.C ........performs the actual closing of a tape drive (lower

                    level routine only called by ZTPCLS).



   ZTPCLD.FOR ......closes a sequential disk file "device" used as a

                    pseudo-tape drive (lower level routine only called

                    by ZTPCLS).



   ZTPCLS.FOR ......closes the tape drive associated with LUN as well

                    as its disk control file removing any exclusive use

                    state and clear the corresponding FTAB entries

Z-ROUTINES AND Z-PROGRAMS                                     Page A-20

UNIX Z-ROUTINES                                            9 April 1990





                    (calls ZTPCL2 to actually closes the tape drive,

                    ZDACLS to actually close the disk control file, and

                    ZTPCLD to actually close a sequential type disk

                    file being used as a pseudo-tape).



   ZTPMI2.C ........performs actual tape i/o (lower-level routine called

                    only by ZTPMIO).



   ZTPMID.FOR ......low level SEQUENTIAL access, large record, double

                    buffered pseudo-tape disk I/O.  This is for TAPIO

                    type operations only: i.e., LRECL=2880, FTAB(FIND+5

                    and 6) = I*4 logical record number.



   ZTPMIO.FOR ......low level sequential access, large record, double

                    buffered tape device I/O (all tape I/O is done

                    through the routine TAPIO these days; calls ZTPMI2

                    or ZTPMID to perform any actual I/O).



   ZTPOP2.C ........performs the actual opening of a tape drive for

                    "map" (double buffered, asynchronous) I/O (lower

                    level routine only called by ZTPOPN).



   ZTPOPD.FOR ......opens logical, sequential (pseudo-tape) disk files.

                    Sequential disk files are done with random access

                    FORTRAN files (exclusive use and wait to open are

                    assumed; lower level routine only called by

                    ZTPOPN).



   ZTPOPN.FOR ......opens a tape drive (as well as the corresponding

                    disk control file) for sequential, "map" (double

                    buffered, asynchronous) I/O or opens a pseudo-tape

                    sequential disk file (calls ZTPOP2 or ZTPOPD to

                    perform the actual open).



   ZTPWA2.C ........performs any actual wait servicing for asynchronous

                    tape I/O operations and returns the completion status

                    and 8-bit byte count (lower level routine only

                    called by ZTPWAT).



   ZTPWAD.FOR ......waits until an I/O operation is complete for

                    sequential pseudo-tape disk files and returns its

                    status (lower level routine only called by ZTPWAT).





   ZTPWAT.FOR ......waits for an asynchronous tape or pseudo-tape I/O

                    operation to complete (calls ZTPWA2 or ZTPWAD to

                    perform any actual wait servicing and to obtain

                    the I/O completion status and transfer count).



   ZTQSP2.C ........issues appropriate "ps" command to display either

                    information on AIPS login processes or all

                    processes on the system (only called by ZTQSPY).



   ZTQSPY.FOR ......displays information on either AIPS login processes

Z-ROUTINES AND Z-PROGRAMS                                     Page A-21

UNIX Z-ROUTINES                                            9 April 1990





                    or all processes on the system (calls ZTQSP2 to

                    actually display the process information).



   ZTREAD.FOR ......reads text files.



   ZTRIM.C .........(defunct).



   ZTRLOG.C ........translates a logical (i.e., gets the value of an

                    environment variable).  This routine will

                    ultimately replace ZXTLOG.



   ZTRSUM.C ........(defunct).



   ZTTBUF.FOR ......reads terminal input with no prompt or wait

                    (simulates TV trackball).



   ZTTCLS.FOR ......closes a terminal (actually a null op in the UNIX

                    implementation since this is both unnecessary as

                    well as expensive).



   ZTTOP2.C ........performs the actual reassignment of UNIT 6 to a

                    dedicated message terminal (only called by ZTTOPN).



   ZTTOPN.FOR ......re-opens a terminal read/write (calls ZTTOP2 to

                    reassign UNIT 6 to a dedicated message terminal,

                    if necessary).



   ZTTYIO.FOR ......performs all terminal I/O (uses TTYCAR to

                    determine whether carriage control should be

                    used).



   ZTVQIO.C ........(defunct; replaced by, for example, ZM70X2).



   ZTXIO.FOR .......read/write a line from/to a text file.



   ZTXMA2.C ........reads a directory and finds all files which match a

                    given file specification (lower level routine only

                    called by ZTXMAT).



   ZTXMAT.FOR ......builds list of files in a specified directory that

                    match a given file specification (e.g., UV*.HLP).



   ZTXOP2.FOR ......translates a logical to form the full path name to

                    text file and opens it (only called by ZTXOPN).



   ZTXOPN.FOR ......opens a text file for reading or writing (calls

                    ZTXOP2 to perform the actual open).



   ZUNADD.FOR ......(defunct).



   ZUNSGN.FOR ......(defunct).



   ZUVPAK.FOR ......Pack visibility data, 1 correlator per real with

                    magic value blank.

Z-ROUTINES AND Z-PROGRAMS                                     Page A-22

UNIX Z-ROUTINES                                            9 April 1990







   ZUVXPN.FOR ......expands packed visibility data and adds weight.



   ZV20C2.FOR ......close Comtal Vision 1/20 TV device.



   ZV20CL.FOR ......close a Comtal Vision 1/20 TV device.



   ZV20MC.FOR ......issue a master clear to the 1/20 TV (for Comtal

                    this is a No-Op).



   ZV20O2.FOR ......opens Comtal Vision 1/20 TV device



   ZV20OP.FOR ......open Comtal Vision 1/20 TV device



   ZV20X2.FOR ......does I/O to Comtal Vision 1/20 TV device



   ZV20XF.FOR ......read/write data to Comtal Vision 1/20 TV device





   ZVLBIN.FOR ......performs the equivalence necessary for NRAO/SAO

                    DECODE format VLBI data.



   ZVTVC2.FOR ......close virtual TV connection to remote, real-TV

                    computer.



   ZVTVC3.FOR ......close connection in real-TV computer to client,

                    virtual-TV computer.



   ZVTVCL.FOR ......close connection in client (virtual-TV) to server

                    (remote, real-TV).



   ZVTVGC.FOR ......close & reopen connection in server (real-TV) to

                    client (virtual-TV).



   ZVTVO2.FOR ......open connection in client (virtual-TV) to server

                    (remote, real-TV).



   ZVTVO3.FOR ......open connection in server (real-TV) to client

                    (virtual-TV).



   ZVTVOP.FOR ......opens connection from client (virtual-TV) to server

                    (real-TV).



   ZVTVRC.FOR ......closes channel in server (real-TV) to client

                    (virtual-TV).



   ZVTVRO.FOR ......open socket in server (real-TV) to any client

                    (virtual-TV).



   ZVTVRX.FOR ......does IO for server (real TV) to client (Virtual-TV)

                    including close/reopen.



   ZVTVX2.FOR ......writes/reads to/from server for the client (virtual

                    TV) machine.

Z-ROUTINES AND Z-PROGRAMS                                     Page A-23

UNIX Z-ROUTINES                                            9 April 1990







   ZVTVX3.FOR ......reads/writes from/to client (virtual TV) for the

                    server (real TV).



   ZVTVXF.FOR ......sends data from the client (virtual TV) to server

                    (real TV).



   ZWAI2.C .........returns the error status of a an i/o operation not

                    waited for by ZMI2 (lower-level routine called only

                    by ZWAIT).



   ZWAIT.FOR .......waits until an i/o operation is complete (calls

                    ZWAI2 to perform any actual wait servicing).



   ZWHOMI.FOR ......gets "POPS" number "n" of AIPSn when it starts up

                    (also where process shell variable values should be

                    checked for such things as reserved terminals, TV

                    and graphics display device assignments/priorities,

                    etc.; see VMS version as an example of a full

                    blown implementation).



   ZX2I16.C ........(defunct).



   ZX8XL.FOR .......converts a FITS table bit array to an AIPS bit

                    array.



   ZXCLOG.C ........(defunct; replaced by ZCRLOG).



   ZXFREE.C ........(defunct; replaced by ZFRE2).



   ZXHEX.C .........(defunct; replaced by ZHEX).



   ZXLOC.C .........(defunct; replaced by ZADDR).



   ZXLPRT.C ........(defunct; replaced by ZLPCL2).



   ZXLX8.FOR .......converts an AIPS table bit array to a FITS bit

                    array.



   ZXMKTM.C ........(defunct; replaced by ZMKTMP).



   ZXMOUN.C ........(defunct; replaced by ZMOUN2).



   ZXMSGS.C ........(defunct; replaced by ZTTOP*).



   ZXSIGC.C ........(defunct; replaced by ZABOR2).



   ZXTLOG.C ........(defunct; replaced by ZTRLOG).



   ZXTPIO.C ........(defunct; replaced by ZTPMI2).



   ZXTSPY.C ........(defunct; replaced by ZTQSP2).



   ZXUID.C .........(defunct).

Z-ROUTINES AND Z-PROGRAMS                                     Page A-24

UNIX Z-ROUTINES                                            9 April 1990







   ZXXIST.C ........(defunct; replaced by ZEXIS2).



.header level 2 Cross Reference

.index Z-routines>cross reference



The following table represents a cross reference listing of which

Z-routines (first column) are called by which AIPS modules (2nd, 3rd,

4th, ... columns) , including other Z-routines.  It was compiled from

the implementation of AIPS on the NRAO-CV Convex C-1, thus the prefix

"APLCVEX:".  This means the collection of Z-routines used came from

the standard set for Convex implementations (apart for some local

customizations). However, the same routines should ideally exist for

all other UNIX implementations. A tool that can be used to generate

local cross reference listings (for all of AIPS) is under development

and will be made available at a future date.



.literal

APLCVEX:ZABOR2  APLCVEX:ZABORT  



APLCVEX:ZABORS  APLCVEX:ZABOR2  



APLCVEX:ZABORT  APLCVEX:ZDCHIN  



APLCVEX:ZACTV8  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:AIPSC    

APLCVEX:ZACTV8  AIPPGM:BATER    AIPPGM:BSTRT1   AIPPGM:QMNGR    

APLCVEX:ZACTV8  AIPSUB:AU2      AIPSUB:AUA      



APLCVEX:ZACTV9  APLCVEX:ZACTV8  



APLCVEX:ZADDR   APLCVEX:ZBYTFL  



(ANCAL):ZAPEXT  APGNOT:ANCAL    



(INDXR):ZAPEXT  APGNOT:INDXR    



??????:ZARG01   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG02   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG03   APLCVEX:ZARGS   



??????:ZARG04   APLCVEX:ZARGS   



??????:ZARG05   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG06   APLCVEX:ZARGS   



??????:ZARG07   APLCVEX:ZARGS   



??????:ZARG09   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG10   APLCVEX:ZARGS   APLCVEX:ZARGXF  



Z-ROUTINES AND Z-PROGRAMS                                     Page A-25

UNIX Z-ROUTINES                                            9 April 1990





??????:ZARG11   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG12   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG13   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG14   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG15   APLCVEX:ZARGS   APLCVEX:ZARGXF  



??????:ZARG16   APLCVEX:ZARGS   APLCVEX:ZARGXF  



APLCVEX:ZARGC2  APLCVEX:ZARGCL  



APLCVEX:ZARGO2  APLCVEX:ZARGOP  



APLCVEX:ZARGS   APLCVEX:ZARGMC  



APLCVEX:ZBKLD1  APGNOT:BAKLD    



APLCVEX:ZBKLD2  APGNOT:BAKLD    



APLCVEX:ZBKLD3  APGNOT:BAKLD    



APLCVEX:ZBKTP1  APGNOT:BAKTP    



APLCVEX:ZBKTP2  APGNOT:BAKTP    



APLCVEX:ZBKTP3  APGNOT:BAKTP    



APLCVEX:ZBYMOV  APGNOT:FILLM    APLNOT:GTF3D    APLNOT:PTF3D    

APLCVEX:ZBYMOV  APLPGM:PRTTP    



APLCVEX:ZBYTF2  APLCVEX:ZBYTFL  



APLCVEX:ZBYTFL  APGNOT:FILLM    APGNOT:FILLR    APLCVEX:ZI16IL  

APLCVEX:ZBYTFL  APLCVEX:ZI32IL  APLCVEX:ZILI16  APLCVEX:ZILI32  

APLCVEX:ZBYTFL  APLCVEX:ZR32RL  APLCVEX:ZR64RL  APLCVEX:ZRLR32  

APLCVEX:ZBYTFL  APLCVEX:ZRLR64  APLPGM:PRTTP    



APLCVEX:ZC8CL   AIPPGM:AIPMAN   AIPPGM:GR2TEX   AIPPGM:GRITP    

APLCVEX:ZC8CL   AIPPGM:RDFITS   AIPSUB:FWRITE   AIPSUB:UWRITE   

APLCVEX:ZC8CL   APGNOT:FILLM    APGNOT:FILLR    APGNOT:IMLOD    

APLCVEX:ZC8CL   APGNOT:MK3IN    APGNOT:UVLOD    APLCVEX:ZMCACL  

APLCVEX:ZC8CL   APLNOT:R3DTAB   APLNOT:TPIOHD   APLPGM:PRTTP    

APLCVEX:ZC8CL   APLSUB:CHAVRT   APLSUB:DWRITE   APLSUB:EXTREQ   

APLCVEX:ZC8CL   APLSUB:SKPBLK   APLSUB:TABLIN   APLSUB:TPHEAD   



APLCVEX:ZCLC8   AIPPGM:GRITP    AIPSUB:UWRITE   APGNOT:FITTP    

APLCVEX:ZCLC8   APGNOT:UVLOD    APLPGM:PROFL    APLPGM:PRTPL    

APLCVEX:ZCLC8   APLPGM:PRTTP    APLSUB:CHAVRT   APLSUB:CHLTOU   

APLCVEX:ZCLC8   APLSUB:MKYBUF   YM70:YCHRW      



APLCVEX:ZCLOSE  AIPPGM:AIPLAS   AIPPGM:AIPMAN   AIPPGM:AIPS     

Z-ROUTINES AND Z-PROGRAMS                                     Page A-26

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZCLOSE  AIPPGM:AIPSB    AIPPGM:AIPSC    AIPPGM:BATER    

APLCVEX:ZCLOSE  AIPPGM:BSTRT1   AIPPGM:DELSG    AIPPGM:FILAI2   

APLCVEX:ZCLOSE  AIPPGM:FILAIP   AIPPGM:FILINI   AIPPGM:FIXCAT   

APLCVEX:ZCLOSE  AIPPGM:FIXUSR   AIPPGM:GR2TEX   AIPPGM:GRIPR    

APLCVEX:ZCLOSE  AIPPGM:GRITP    AIPPGM:POPSGN   AIPPGM:QMNGR    

APLCVEX:ZCLOSE  AIPPGM:RDFITS   AIPPGM:RECAT    AIPPGM:SETPAR   

APLCVEX:ZCLOSE  AIPPGM:SETTVP   AIPPGM:UPDAT    AIPSUB:AU1      

APLCVEX:ZCLOSE  AIPSUB:AU1A     AIPSUB:AU2      AIPSUB:AU2A     

APLCVEX:ZCLOSE  AIPSUB:AU3A     AIPSUB:AU3B     AIPSUB:AU6B     

APLCVEX:ZCLOSE  AIPSUB:AU7      AIPSUB:AU7A     AIPSUB:AU8      

APLCVEX:ZCLOSE  AIPSUB:AU8A     AIPSUB:AU9B     AIPSUB:AUA      

APLCVEX:ZCLOSE  AIPSUB:AUB      AIPSUB:AUC      AIPSUB:CATCR    

APLCVEX:ZCLOSE  AIPSUB:CATLST   AIPSUB:INIT     AIPSUB:PRTMSG   

APLCVEX:ZCLOSE  AIPSUB:RENUMB   AIPSUB:SGLAST   AIPSUB:SGLOCA   

APLCVEX:ZCLOSE  AIPSUB:STORES   AIPSUB:TASKWT   APGNOT:ASCOR    

APLCVEX:ZCLOSE  APGNOT:AVER     APGNOT:AVSPC    APGNOT:BAKTP    

APLCVEX:ZCLOSE  APGNOT:BLOAT    APGNOT:BSMAP    APGNOT:CANDY    

APLCVEX:ZCLOSE  APGNOT:CANPL    APGNOT:CCMRG    APGNOT:DBCON    

APLCVEX:ZCLOSE  APGNOT:DESCM    APGNOT:DFTPL    APGNOT:FETCH    

APLCVEX:ZCLOSE  APGNOT:FILLM    APGNOT:FILLR    APGNOT:GAPLT    

APLCVEX:ZCLOSE  APGNOT:GNPLT    APGNOT:IMFIT    APGNOT:IMFLT    

APLCVEX:ZCLOSE  APGNOT:IMLOD    APGNOT:IMMOD    APGNOT:INDXR    

APLCVEX:ZCLOSE  APGNOT:JMFIT    APGNOT:KNTR     APGNOT:LISTR    

APLCVEX:ZCLOSE  APGNOT:LWPLA    APGNOT:MANDL    APGNOT:MK3IN    

APLCVEX:ZCLOSE  APGNOT:MULTI    APGNOT:MWFLT    APGNOT:NINER    

APLCVEX:ZCLOSE  APGNOT:NNLSQ    APGNOT:PATGN    APGNOT:PLCUB    

APLCVEX:ZCLOSE  APGNOT:PRTGA    APGNOT:PRTSD    APGNOT:PRTUV    

APLCVEX:ZCLOSE  APGNOT:SDCAL    APGNOT:SDTUV    APGNOT:SELSD    

APLCVEX:ZCLOSE  APGNOT:SLCOL    APGNOT:SLICE    APGNOT:SNPLT    

APLCVEX:ZCLOSE  APGNOT:SPLIT    APGNOT:TAMRG    APGNOT:TASRT    

APLCVEX:ZCLOSE  APGNOT:TXPL     APGNOT:USUBA    APGNOT:UVAVG    

APLCVEX:ZCLOSE  APGNOT:UVCOP    APGNOT:UVDGP    APGNOT:UVFIL    

APLCVEX:ZCLOSE  APGNOT:UVFIX    APGNOT:UVFLG    APGNOT:UVIMG    

APLCVEX:ZCLOSE  APGNOT:UVLOD    APGNOT:UVMOD    APGNOT:UVPLT    

APLCVEX:ZCLOSE  APGNOT:UVSIM    APGNOT:UVSRT    APGNOT:VBCAL    

APLCVEX:ZCLOSE  APGNOT:VBMRG    APGNOT:VBPLT    APGNOT:VLBIN    

APLCVEX:ZCLOSE  APGNOT:WTMOD    APLCVEX:ZDCHIN  APLNOT:AKCLOS   

APLCVEX:ZCLOSE  APLNOT:BMSHP    APLNOT:BPASET   APLNOT:BPGET    

APLCVEX:ZCLOSE  APLNOT:CALCOP   APLNOT:EMPTY1   APLNOT:EMPTY2   

APLCVEX:ZCLOSE  APLNOT:FILL1    APLNOT:FILL2    APLNOT:GRIDTB   

APLCVEX:ZCLOSE  APLNOT:ITBSRT   APLNOT:OTBSRT   APLNOT:PLEND    

APLCVEX:ZCLOSE  APLNOT:PLNPUT   APLNOT:SDGET    APLNOT:TVFOAD   

APLCVEX:ZCLOSE  APLNOT:UVDOUT   APLNOT:UVDPAD   APLNOT:UVGET    

APLCVEX:ZCLOSE  APLPGM:CLIP     APLPGM:CNTR     APLPGM:CORER    

APLCVEX:ZCLOSE  APLPGM:CORFQ    APLPGM:DISKU    APLPGM:FUDGE    

APLCVEX:ZCLOSE  APLPGM:GREYS    APLPGM:IMEAN    APLPGM:IMVIM    

APLCVEX:ZCLOSE  APLPGM:ISPEC    APLPGM:PCNTR    APLPGM:PROFL    

APLCVEX:ZCLOSE  APLPGM:PRTAB    APLPGM:PRTAC    APLPGM:PRTAN    

APLCVEX:ZCLOSE  APLPGM:PRTCC    APLPGM:PRTIM    APLPGM:PRTPL    

APLCVEX:ZCLOSE  APLPGM:PRTTP    APLPGM:QMSPL    APLPGM:SL2PL    

APLCVEX:ZCLOSE  APLPGM:SLFIT    APLPGM:STARS    APLPGM:SWPOL    

APLCVEX:ZCLOSE  APLPGM:TAFFY    APLPGM:TAFLG    APLPGM:TAPLT    

APLCVEX:ZCLOSE  APLPGM:TKPL     APLPGM:TRANS    APLPGM:UVCMP    

APLCVEX:ZCLOSE  APLPGM:UVDIF    APLPGM:UVFND    APLPGM:UVHGM    

Z-ROUTINES AND Z-PROGRAMS                                     Page A-27

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZCLOSE  APLPGM:UVMTH    APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZCLOSE  APLPGM:XMOM     APLPGM:XPLOT    APLPGM:XSMTH    

APLCVEX:ZCLOSE  APLPGM:XSUM     APLSUB:ACOUNT   APLSUB:BATQ     

APLCVEX:ZCLOSE  APLSUB:CATDIR   APLSUB:CATIO    APLSUB:CATKEY   

APLCVEX:ZCLOSE  APLSUB:CATOPN   APLSUB:DIE      APLSUB:EXTINI   

APLCVEX:ZCLOSE  APLSUB:EXTIO    APLSUB:FILCLS   APLSUB:GFINIS   

APLCVEX:ZCLOSE  APLSUB:GTPARM   APLSUB:GTTELL   APLSUB:HICLOS   

APLCVEX:ZCLOSE  APLSUB:HIOPEN   APLSUB:ISTAB    APLSUB:MAPCLS   

APLCVEX:ZCLOSE  APLSUB:MAPCOP   APLSUB:MERGE    APLSUB:PASWRD   

APLCVEX:ZCLOSE  APLSUB:PEAKFN   APLSUB:PLNGET   APLSUB:RELPOP   

APLCVEX:ZCLOSE  APLSUB:RESCAL   APLSUB:RESCSL   APLSUB:SNDY     

APLCVEX:ZCLOSE  APLSUB:TABCOP   APLSUB:TABINI   APLSUB:TABIO    

APLCVEX:ZCLOSE  APLSUB:TABMRG   APLSUB:TKCATL   QNOT:ALGSUB     

APLCVEX:ZCLOSE  QNOT:APIO       QNOT:CONV1      QNOT:CONV2      

APLCVEX:ZCLOSE  QNOT:CONV3      QNOT:CONV4      QNOT:DISPTV     

APLCVEX:ZCLOSE  QNOT:GRDCOR     QNOT:UVGRID     QNOT:UVTBGD     

APLCVEX:ZCLOSE  QNOT:UVTBUN     QNOT:UVUNIF     QNOT:VISDFT     

APLCVEX:ZCLOSE  QPGM:RSTOR      QPGNOT:ASCAL    QPGNOT:BLCAL    

APLCVEX:ZCLOSE  QPGNOT:BPASS    QPGNOT:CALIB    QPGNOT:CONVL    

APLCVEX:ZCLOSE  QPGNOT:CVEL     QPGNOT:FFT      QPGNOT:GRIDR    

APLCVEX:ZCLOSE  QPGNOT:IM2UV    QPGNOT:PCAL     QPGNOT:VSCAL    

APLCVEX:ZCLOSE  QSUB:APROLL     QSUB:PASS1      QSUB:PASS2      

APLCVEX:ZCLOSE  QYPGM:APCLN     QYPGNOT:APGS    QYPGNOT:APVC    

APLCVEX:ZCLOSE  QYPGNOT:MX      QYPGNOT:SDCLN   QYPGNOT:STEER   

APLCVEX:ZCLOSE  QYPGNOT:UVMAP   YM70:YCINIT     YM70:YCOVER     

APLCVEX:ZCLOSE  YM70:YCREAD     YM70:YCWRIT     YM70:YFIND      

APLCVEX:ZCLOSE  YM70:YLOCAT     YM70:YTVCLS     YM70:YTVOPN     

APLCVEX:ZCLOSE  YPGM:BLANK      YPGM:BLSUM      YPGM:TVPL       

APLCVEX:ZCLOSE  YPGNOT:TVFLG    



APLCVEX:ZCMPR2  APLCVEX:ZCMPRS  



APLCVEX:ZCMPRS  AIPSUB:PRTMSG   APGNOT:ASCOR    APGNOT:AVER     

APLCVEX:ZCMPRS  APGNOT:AVSPC    APGNOT:BLOAT    APGNOT:DESCM    

APLCVEX:ZCMPRS  APGNOT:FILLM    APGNOT:FILLR    APGNOT:MK3IN    

APLCVEX:ZCMPRS  APGNOT:MULTI    APGNOT:SDCAL    APGNOT:SDTUV    

APLCVEX:ZCMPRS  APGNOT:SELSD    APGNOT:SPLIT    APGNOT:UVAVG    

APLCVEX:ZCMPRS  APGNOT:UVCOP    APGNOT:UVDGP    APGNOT:UVFIL    

APLCVEX:ZCMPRS  APGNOT:UVFIX    APGNOT:UVLOD    APGNOT:UVMOD    

APLCVEX:ZCMPRS  APGNOT:UVSIM    APGNOT:VBCAL    APGNOT:VBMRG    

APLCVEX:ZCMPRS  APGNOT:VLBIN    APGNOT:WTMOD    APLNOT:BPASET   

APLCVEX:ZCMPRS  APLNOT:CALCOP   APLPGM:CLIP     APLPGM:CORER    

APLCVEX:ZCMPRS  APLPGM:FUDGE    APLPGM:PRTAC    APLPGM:SWPOL    

APLCVEX:ZCMPRS  APLPGM:UVMTH    APLSUB:GFINIS   APLSUB:TABIO    

APLCVEX:ZCMPRS  QPGNOT:BPASS    QPGNOT:CALIB    QPGNOT:CVEL     

APLCVEX:ZCMPRS  QPGNOT:IM2UV    QPGNOT:PCAL     



APLCVEX:ZCPU    APLSUB:ACOUNT   APLSUB:DTINIT   APLSUB:DTTIME   

APLCVEX:ZCPU    QPGNOT:GRIDR    QYPGNOT:MX      QYPGNOT:UTESS   

APLCVEX:ZCPU    QYPGNOT:UVMAP   QYPGNOT:VTESS   



APLCVEX:ZCREA2  APLCVEX:ZCREAT  



APLCVEX:ZCREAT  AIPPGM:AIPSC    AIPPGM:FILAI2   AIPPGM:FILAIP   

Z-ROUTINES AND Z-PROGRAMS                                     Page A-28

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZCREAT  AIPPGM:FILINI   AIPSUB:AU2      AIPSUB:CATCR    

APLCVEX:ZCREAT  AIPSUB:SGLAST   AIPSUB:SGLOCA   AIPSUB:STORES   

APLCVEX:ZCREAT  APLNOT:OTBSRT   APLPGM:TAFLG    APLSUB:CATDIR   

APLCVEX:ZCREAT  APLSUB:CATOPN   APLSUB:EXTINI   APLSUB:FILCR    

APLCVEX:ZCREAT  APLSUB:GINIT    APLSUB:HICREA   APLSUB:MCREAT   

APLCVEX:ZCREAT  APLSUB:RESCAL   APLSUB:SCREAT   APLSUB:TABCOP   

APLCVEX:ZCREAT  APLSUB:TABINI   APLSUB:UVCREA   



APLCVEX:ZCRLOG  APLCVEX:ZMOUN2  



APLCVEX:ZDACLS  APLCVEX:ZCLOSE  APLCVEX:ZMSGCL  APLCVEX:ZTPCLS  

APLCVEX:ZDACLS  APLCVEX:ZTPOPN  



APLCVEX:ZDAOPN  APLCVEX:ZMSGOP  APLCVEX:ZOPEN   APLCVEX:ZTPOPN  



APLCVEX:ZDATE   AIPPGM:BATER    AIPPGM:FILAIP   AIPPGM:GR2TEX   

APLCVEX:ZDATE   AIPPGM:GRIPR    AIPSUB:AU2      AIPSUB:AU3A     

APLCVEX:ZDATE   AIPSUB:AUB      AIPSUB:AUC      AIPSUB:CATCR    

APLCVEX:ZDATE   AIPSUB:PRTALN   AIPSUB:PRTMSG   AIPSUB:SGLAST   

APLCVEX:ZDATE   AIPSUB:STORES   APGNOT:ACFIT    APGNOT:ANCAL    

APLCVEX:ZDATE   APGNOT:BAKTP    APGNOT:BSMAP    APGNOT:CANDY    

APLCVEX:ZDATE   APGNOT:CCMRG    APGNOT:CLCAL    APGNOT:CLCOR    

APLCVEX:ZDATE   APGNOT:CSCOR    APGNOT:FARAD    APGNOT:FETCH    

APLCVEX:ZDATE   APGNOT:FILLM    APGNOT:FILLR    APGNOT:FITTP    

APLCVEX:ZDATE   APGNOT:GAL      APGNOT:GAPLT    APGNOT:GETJY    

APLCVEX:ZDATE   APGNOT:GNPLT    APGNOT:IRING    APGNOT:KNTR     

APLCVEX:ZDATE   APGNOT:LTESS    APGNOT:MANDL    APGNOT:MK3IN    

APLCVEX:ZDATE   APGNOT:PATGN    APGNOT:PFPL1    APGNOT:PFPL2    

APLCVEX:ZDATE   APGNOT:PFPL3    APGNOT:PLCUB    APGNOT:PLROW    

APLCVEX:ZDATE   APGNOT:POSSM    APGNOT:QUACK    APGNOT:SDTUV    

APLCVEX:ZDATE   APGNOT:SETAN    APGNOT:SETJY    APGNOT:SLICE    

APLCVEX:ZDATE   APGNOT:SNPLT    APGNOT:SOLCL    APGNOT:STESS    

APLCVEX:ZDATE   APGNOT:TABED    APGNOT:TAMRG    APGNOT:UNCAL    

APLCVEX:ZDATE   APGNOT:UVFIL    APGNOT:UVLOD    APGNOT:UVPLT    

APLCVEX:ZDATE   APGNOT:UVSIM    APGNOT:VBPLT    APGNOT:VLBIN    

APLCVEX:ZDATE   APLCVEX:ZTQSPY  APLNOT:OTBSRT   APLPGM:DISKU    

APLCVEX:ZDATE   APLPGM:GREYS    APLPGM:IMEAN    APLPGM:IMVIM    

APLCVEX:ZDATE   APLPGM:ISPEC    APLPGM:PRTAC    APLPGM:SL2PL    

APLCVEX:ZDATE   APLPGM:SLFIT    APLPGM:STARS    APLPGM:TACOP    

APLCVEX:ZDATE   APLPGM:TAFLG    APLPGM:TAPLT    APLPGM:UVHGM    

APLCVEX:ZDATE   APLSUB:ACOUNT   APLSUB:BATPRT   APLSUB:CATIME   

APLCVEX:ZDATE   APLSUB:CATOPN   APLSUB:COMLAB   APLSUB:EXTINI   

APLCVEX:ZDATE   APLSUB:GINIT    APLSUB:HIMERG   APLSUB:HIPLOT   

APLCVEX:ZDATE   APLSUB:HISCOP   APLSUB:MCREAT   APLSUB:PRTLIN   

APLCVEX:ZDATE   APLSUB:SCREAT   APLSUB:TABCOP   APLSUB:TABINI   

APLCVEX:ZDATE   APLSUB:UVCREA   QPGM:RSTOR      QPGNOT:BLCAL    

APLCVEX:ZDATE   QPGNOT:BPASS    QPGNOT:CALIB    QPGNOT:GRIDR    

APLCVEX:ZDATE   QPGNOT:PCAL     QYPGM:APCLN     QYPGNOT:APGS    

APLCVEX:ZDATE   QYPGNOT:APVC    QYPGNOT:MX      QYPGNOT:SDCLN   

APLCVEX:ZDATE   QYPGNOT:STEER   QYPGNOT:UTESS   QYPGNOT:UVMAP   

APLCVEX:ZDATE   QYPGNOT:VTESS   YPGNOT:TVFLG    



APLCVEX:ZDCHI2  APLCVEX:ZDCHIN  



Z-ROUTINES AND Z-PROGRAMS                                     Page A-29

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZDCHIC  APLCVEX:ZDCHIN  



APLCVEX:ZDCHIN  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:AIPS     

APLCVEX:ZDCHIN  AIPPGM:AIPSB    AIPPGM:AIPSC    AIPPGM:AJAX     

APLCVEX:ZDCHIN  AIPPGM:BATER    AIPPGM:BSTRT1   AIPPGM:GRIPR    

APLCVEX:ZDCHIN  AIPPGM:QMNGR    AIPPGM:SETPAR   AIPSUB:AIPINI   

APLCVEX:ZDCHIN  APGNOT:ACFIT    APGNOT:ADDIF    APGNOT:ANCAL    

APLCVEX:ZDCHIN  APGNOT:ASCOR    APGNOT:AVER     APGNOT:AVSPC    

APLCVEX:ZDCHIN  APGNOT:BAKLD    APGNOT:BAKTP    APGNOT:BLFIT    

APLCVEX:ZDCHIN  APGNOT:BLOAT    APGNOT:BSMAP    APGNOT:CANDY    

APLCVEX:ZDCHIN  APGNOT:CANPL    APGNOT:CCMOD    APGNOT:CLCAL    

APLCVEX:ZDCHIN  APGNOT:CLCOR    APGNOT:CSCOR    APGNOT:DBCON    

APLCVEX:ZDCHIN  APGNOT:DCONV    APGNOT:DESCM    APGNOT:DFTPL    

APLCVEX:ZDCHIN  APGNOT:FARAD    APGNOT:FETCH    APGNOT:FILLM    

APLCVEX:ZDCHIN  APGNOT:FILLR    APGNOT:FITTP    APGNOT:GAL      

APLCVEX:ZDCHIN  APGNOT:GAPLT    APGNOT:GETJY    APGNOT:GNMRG    

APLCVEX:ZDCHIN  APGNOT:GNPLT    APGNOT:IMFLT    APGNOT:IMLOD    

APLCVEX:ZDCHIN  APGNOT:IMMOD    APGNOT:INDXR    APGNOT:IRING    

APLCVEX:ZDCHIN  APGNOT:KNTR     APGNOT:LISTR    APGNOT:LTESS    

APLCVEX:ZDCHIN  APGNOT:LWPLA    APGNOT:MANDL    APGNOT:MK3IN    

APLCVEX:ZDCHIN  APGNOT:MULTI    APGNOT:MWFLT    APGNOT:NINER    

APLCVEX:ZDCHIN  APGNOT:NNLSQ    APGNOT:PATGN    APGNOT:POSSM    

APLCVEX:ZDCHIN  APGNOT:PRTGA    APGNOT:PRTSD    APGNOT:PRTUV    

APLCVEX:ZDCHIN  APGNOT:QUACK    APGNOT:SDCAL    APGNOT:SDTUV    

APLCVEX:ZDCHIN  APGNOT:SELSD    APGNOT:SETAN    APGNOT:SETJY    

APLCVEX:ZDCHIN  APGNOT:SOLCL    APGNOT:SPLIT    APGNOT:STESS    

APLCVEX:ZDCHIN  APGNOT:TABED    APGNOT:TBIN     APGNOT:TBOUT    

APLCVEX:ZDCHIN  APGNOT:TXPL     APGNOT:UNCAL    APGNOT:USUBA    

APLCVEX:ZDCHIN  APGNOT:UVAVG    APGNOT:UVCOP    APGNOT:UVDGP    

APLCVEX:ZDCHIN  APGNOT:UVFIL    APGNOT:UVFIT    APGNOT:UVFIX    

APLCVEX:ZDCHIN  APGNOT:UVFLG    APGNOT:UVIMG    APGNOT:UVLOD    

APLCVEX:ZDCHIN  APGNOT:UVMOD    APGNOT:UVPLT    APGNOT:UVSEN    

APLCVEX:ZDCHIN  APGNOT:UVSIM    APGNOT:UVSRT    APGNOT:VBCAL    

APLCVEX:ZDCHIN  APGNOT:VBMRG    APGNOT:VBPLT    APGNOT:VLBIN    

APLCVEX:ZDCHIN  APGNOT:WARP     APGNOT:WTMOD    APLPGM:AVTP     

APLCVEX:ZDCHIN  APLPGM:CLIP     APLPGM:CNTR     APLPGM:COMB     

APLCVEX:ZDCHIN  APLPGM:CORER    APLPGM:CORFQ    APLPGM:DISKU    

APLCVEX:ZDCHIN  APLPGM:FUDGE    APLPGM:GREYS    APLPGM:IMEAN    

APLCVEX:ZDCHIN  APLPGM:IMVIM    APLPGM:ISPEC    APLPGM:MCUBE    

APLCVEX:ZDCHIN  APLPGM:NOBAT    APLPGM:PCNTR    APLPGM:PROFL    

APLCVEX:ZDCHIN  APLPGM:PRTAB    APLPGM:PRTAC    APLPGM:PRTAN    

APLCVEX:ZDCHIN  APLPGM:PRTCC    APLPGM:PRTIM    APLPGM:PRTPL    

APLCVEX:ZDCHIN  APLPGM:PRTTP    APLPGM:QMSPL    APLPGM:SL2PL    

APLCVEX:ZDCHIN  APLPGM:SLFIT    APLPGM:SQASH    APLPGM:STARS    

APLCVEX:ZDCHIN  APLPGM:SUBIM    APLPGM:SWPOL    APLPGM:TACOP    

APLCVEX:ZDCHIN  APLPGM:TAFFY    APLPGM:TAFLG    APLPGM:TAPLT    

APLCVEX:ZDCHIN  APLPGM:TASAV    APLPGM:TKPL     APLPGM:TRANS    

APLCVEX:ZDCHIN  APLPGM:UVDIF    APLPGM:UVFND    APLPGM:UVHGM    

APLCVEX:ZDCHIN  APLPGM:UVMTH    APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZDCHIN  APLPGM:XMOM     APLPGM:XPLOT    APLPGM:XSMTH    

APLCVEX:ZDCHIN  APLPGM:XSUM     APLSUB:IOSET    APLSUB:SETUP    

APLCVEX:ZDCHIN  QPGM:RSTOR      QPGNOT:ASCAL    QPGNOT:BLCAL    

APLCVEX:ZDCHIN  QPGNOT:BPASS    QPGNOT:CALIB    QPGNOT:CONVL    

APLCVEX:ZDCHIN  QPGNOT:CVEL     QPGNOT:FFT      QPGNOT:GRIDR    

Z-ROUTINES AND Z-PROGRAMS                                     Page A-30

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZDCHIN  QPGNOT:IM2UV    QPGNOT:IMERG    QPGNOT:PCAL     

APLCVEX:ZDCHIN  QPGNOT:UVSUB    QPGNOT:VSCAL    QYPGM:APCLN     

APLCVEX:ZDCHIN  QYPGNOT:APGS    QYPGNOT:APVC    QYPGNOT:MX      

APLCVEX:ZDCHIN  QYPGNOT:SDCLN   QYPGNOT:STEER   QYPGNOT:UTESS   

APLCVEX:ZDCHIN  QYPGNOT:UVMAP   QYPGNOT:VTESS   YPGM:BLANK      

APLCVEX:ZDCHIN  YPGM:BLSUM      YPGM:TVPL       YPGNOT:TVFLG    

APLCVEX:ZDCHIN  YPGNOT:TVHLD    YPGNOT:TVHXF    



APLCVEX:ZDEAC2  APLCVEX:ZDEACL  



APLCVEX:ZDEAO2  APLCVEX:ZDEAOP  



APLCVEX:ZDEAX2  APLCVEX:ZDEAXF  



APLCVEX:ZDEAXF  APLCVEX:ZDEACL  APLCVEX:ZDEAOP  

APLCVEX:ZDELA2  APLCVEX:ZDELAY  



APLCVEX:ZDELAY  AIPPGM:AIPSB    AIPPGM:QMNGR    AIPSUB:AU2      

APLCVEX:ZDELAY  AIPSUB:AU5      AIPSUB:AU8A     AIPSUB:TASKWT   

APLCVEX:ZDELAY  AIPSUB:TVBLNK   AIPSUB:TVMOVI   APLCVEX:ZCREA2  

APLCVEX:ZDELAY  APLCVEX:ZMSGOP  APLCVEX:ZOPEN   APLCVEX:ZTKOPN  

APLCVEX:ZDELAY  APLCVEX:ZTPOPN  APLPGM:NOBAT    APLSUB:CATOPN   

APLCVEX:ZDELAY  APLSUB:TKCLR    APLSUB:TKLAB    QNOT:DISPTV     

APLCVEX:ZDELAY  QSUB:APROLL     QYPGM:APCLN     QYPGNOT:APGS    

APLCVEX:ZDELAY  QYPGNOT:APVC    QYPGNOT:MX      QYPGNOT:SDCLN   

APLCVEX:ZDELAY  QYPGNOT:STEER   YM70:YCURSE     YM70:YTVMC      

APLCVEX:ZDELAY  YPGNOT:TVFLG    YSUB:DLINTR     



APLCVEX:ZDEST2  APLCVEX:ZDESTR  



APLCVEX:ZDESTR  AIPPGM:AIPSB    AIPPGM:AIPSC    AIPPGM:BATER    

APLCVEX:ZDESTR  AIPPGM:DELSG    AIPPGM:FILAI2   AIPPGM:FILINI   

APLCVEX:ZDESTR  AIPPGM:RECAT    AIPSUB:AU1      AIPSUB:AU2A     

APLCVEX:ZDESTR  AIPSUB:AU3A     AIPSUB:AU8      AIPSUB:AUB      

APLCVEX:ZDESTR  AIPSUB:RENUMB   AIPSUB:SGLAST   AIPSUB:STORES   

APLCVEX:ZDESTR  APGNOT:ANCAL    APGNOT:CCMRG    APGNOT:DFTPL    

APLCVEX:ZDESTR  APGNOT:GAPLT    APGNOT:GNPLT    APGNOT:INDXR    

APLCVEX:ZDESTR  APGNOT:KNTR     APGNOT:PLCUB    APGNOT:SLICE    

APLCVEX:ZDESTR  APGNOT:SNPLT    APGNOT:TAMRG    APGNOT:UVPLT    

APLCVEX:ZDESTR  APGNOT:VBPLT    APLNOT:CCMERG   APLNOT:OTBSRT   

APLCVEX:ZDESTR  APLNOT:PLEND    APLNOT:RMEXT    APLPGM:CNTR     

APLCVEX:ZDESTR  APLPGM:GREYS    APLPGM:IMEAN    APLPGM:IMVIM    

APLCVEX:ZDESTR  APLPGM:PCNTR    APLPGM:PROFL    APLPGM:SL2PL    

APLCVEX:ZDESTR  APLPGM:STARS    APLPGM:TAFLG    APLPGM:TAPLT    

APLCVEX:ZDESTR  APLPGM:UVHGM    APLSUB:CATDIR   APLSUB:EXTINI   

APLCVEX:ZDESTR  APLSUB:FILDES   APLSUB:GINIT    APLSUB:HICREA   

APLCVEX:ZDESTR  APLSUB:MDESTR   APLSUB:RESCAL   APLSUB:SNDY     

APLCVEX:ZDESTR  APLSUB:TABCOP   APLSUB:TABINI   APLSUB:TABMRG   

APLCVEX:ZDESTR  QPGNOT:ASCAL    QPGNOT:VSCAL    



APLCVEX:ZDHPRL  APGNOT:MK3IN    



APLCVEX:ZDIR    APLCVEX:ZTOPEN  APLCVEX:ZTXMAT  



Z-ROUTINES AND Z-PROGRAMS                                     Page A-31

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZDM2DL  APGNOT:FILLM    APGNOT:FILLR    APLPGM:PRTTP    



APLCVEX:ZDOPRT  APLPGM:PRTPL    



APLCVEX:ZENDPG  AIPSUB:AU1A     AIPSUB:AU7      AIPSUB:PRTMSG   

APLCVEX:ZENDPG  APGNOT:IMFIT    APGNOT:JMFIT    APGNOT:LISTR    

APLCVEX:ZENDPG  APGNOT:PRTGA    APGNOT:PRTSD    APGNOT:PRTUV    

APLCVEX:ZENDPG  APGNOT:TXPL     APLPGM:CORER    APLPGM:PRTAB    

APLCVEX:ZENDPG  APLPGM:PRTAC    APLPGM:PRTAN    APLPGM:PRTCC    

APLCVEX:ZENDPG  APLPGM:PRTIM    APLPGM:PRTTP    APLPGM:UVDIF    

APLCVEX:ZENDPG  APLPGM:UVFND    YPGM:BLSUM      



APLCVEX:ZERRO2  APLCVEX:ZERROR  APLCVEX:ZMSGER  



APLCVEX:ZERROR  APLCVEX:ZACTV8  APLCVEX:ZARGCL  APLCVEX:ZARGOP  

APLCVEX:ZERROR  APLCVEX:ZCLOSE  APLCVEX:ZCMPRS  APLCVEX:ZCREAT  

APLCVEX:ZERROR  APLCVEX:ZDEACL  APLCVEX:ZDEAOP  APLCVEX:ZDEAXF  

APLCVEX:ZERROR  APLCVEX:ZDESTR  APLCVEX:ZEXIST  APLCVEX:ZEXPND  

APLCVEX:ZERROR  APLCVEX:ZFIO    APLCVEX:ZLASIO  APLCVEX:ZLPCLS  

APLCVEX:ZERROR  APLCVEX:ZLPOPN  APLCVEX:ZLWIO   APLCVEX:ZM70CL  

APLCVEX:ZERROR  APLCVEX:ZM70MC  APLCVEX:ZM70OP  APLCVEX:ZM70XF  

APLCVEX:ZERROR  APLCVEX:ZMIO    APLCVEX:ZMOUNT  APLCVEX:ZOPEN   

APLCVEX:ZERROR  APLCVEX:ZPRIO   APLCVEX:ZRENAM  APLCVEX:ZTAPE   

APLCVEX:ZERROR  APLCVEX:ZTKCLS  APLCVEX:ZTKOPN  APLCVEX:ZTOPEN  

APLCVEX:ZERROR  APLCVEX:ZTPCLS  APLCVEX:ZTPMIO  APLCVEX:ZTPOPN  

APLCVEX:ZERROR  APLCVEX:ZTPWAT  APLCVEX:ZTXCLS  APLCVEX:ZTXIO   

APLCVEX:ZERROR  APLCVEX:ZTXOP2  APLCVEX:ZV20CL  APLCVEX:ZV20OP  

APLCVEX:ZERROR  APLCVEX:ZV20XF  APLCVEX:ZWAIT   



APLCVEX:ZEXIS2  APLCVEX:ZEXIST  APLCVEX:ZMSGXP  



APLCVEX:ZEXIST  AIPPGM:AJAX     AIPPGM:FILAI2   AIPPGM:FILAIP   

APLCVEX:ZEXIST  AIPPGM:FILINI   AIPPGM:RECAT    AIPSUB:AU3A     

APLCVEX:ZEXIST  AIPSUB:AU8      AIPSUB:CATCR    APGNOT:FILLM    

APLCVEX:ZEXIST  APGNOT:MK3IN    APLCVEX:ZEXPND  APLPGM:DISKU    

APLCVEX:ZEXIST  APLPGM:TAFLG    



APLCVEX:ZEXPN2  APLCVEX:ZEXPND  APLCVEX:ZMSGXP  



APLCVEX:ZEXPND  AIPPGM:AIPSC    AIPSUB:AU2      AIPSUB:BBUILD   

APLCVEX:ZEXPND  AIPSUB:CHGRIP   AIPSUB:PREAD    APGNOT:FILLM    

APLCVEX:ZEXPND  APGNOT:MK3IN    APLPGM:SLFIT    APLSUB:ACOUNT   

APLCVEX:ZEXPND  APLSUB:CATDIR   APLSUB:CATKEY   APLSUB:EXTIO    

APLCVEX:ZEXPND  APLSUB:GPHWRT   APLSUB:HIIO     APLSUB:TABIO    



APLCVEX:ZFI2    APLCVEX:ZFIO    APLCVEX:ZMSGDK  



APLCVEX:ZFIO    AIPPGM:AIPLAS   AIPPGM:AIPSB    AIPPGM:AIPSC    

APLCVEX:ZFIO    AIPPGM:BATER    AIPPGM:BSTRT1   AIPPGM:DELSG    

APLCVEX:ZFIO    AIPPGM:FILAI2   AIPPGM:FILAIP   AIPPGM:FILINI   

APLCVEX:ZFIO    AIPPGM:FIXUSR   AIPPGM:GR2TEX   AIPPGM:GRIPR    

APLCVEX:ZFIO    AIPPGM:GRITP    AIPPGM:POPSGN   AIPPGM:QMNGR    

APLCVEX:ZFIO    AIPPGM:RECAT    AIPPGM:SETPAR   AIPPGM:SETTVP   

APLCVEX:ZFIO    AIPPGM:UPDAT    AIPSUB:AU1      AIPSUB:AU2      

Z-ROUTINES AND Z-PROGRAMS                                     Page A-32

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZFIO    AIPSUB:AU2A     AIPSUB:AU3A     AIPSUB:AU7      

APLCVEX:ZFIO    AIPSUB:AU8      AIPSUB:AU8A     AIPSUB:AUA      

APLCVEX:ZFIO    AIPSUB:AUB      AIPSUB:AUC      AIPSUB:BBUILD   

APLCVEX:ZFIO    AIPSUB:CATCR    AIPSUB:CATLST   AIPSUB:CHGRIP   

APLCVEX:ZFIO    AIPSUB:INIT     AIPSUB:PREAD    AIPSUB:RENUMB   

APLCVEX:ZFIO    AIPSUB:SGLAST   AIPSUB:SGLOCA   AIPSUB:STORES   

APLCVEX:ZFIO    AIPSUB:TASKWT   AIPSUB:TKGMPL   AIPSUB:TKRSPL   

APLCVEX:ZFIO    AIPSUB:TKSLPL   APGNOT:CANPL    APGNOT:IMLOD    

APLCVEX:ZFIO    APGNOT:LWPLA    APGNOT:SLCOL    APGNOT:SLICE    

APLCVEX:ZFIO    APGNOT:TXPL     APLCVEX:ZDCHIN  APLNOT:OTBSRT   

APLCVEX:ZFIO    APLPGM:DISKU    APLPGM:GREYS    APLPGM:PRTAC    

APLCVEX:ZFIO    APLPGM:PRTPL    APLPGM:QMSPL    APLPGM:SL2PL    

APLCVEX:ZFIO    APLPGM:SLFIT    APLPGM:TAFLG    APLPGM:TKPL     

APLCVEX:ZFIO    APLSUB:ACOUNT   APLSUB:BATQ     APLSUB:CATDIR   

APLCVEX:ZFIO    APLSUB:CATIO    APLSUB:CATKEY   APLSUB:CATOPN   

APLCVEX:ZFIO    APLSUB:EXTINI   APLSUB:EXTIO    APLSUB:FILIO    

APLCVEX:ZFIO    APLSUB:FNDCOL   APLSUB:GPHWRT   APLSUB:GTPARM   

APLCVEX:ZFIO    APLSUB:GTTELL   APLSUB:HICOPY   APLSUB:HIIO     

APLCVEX:ZFIO    APLSUB:HIMERG   APLSUB:HIOPEN   APLSUB:ISTAB    

APLCVEX:ZFIO    APLSUB:PASWRD   APLSUB:RELPOP   APLSUB:RESCSL   

APLCVEX:ZFIO    APLSUB:TABCOP   APLSUB:TABINI   APLSUB:TABIO    

APLCVEX:ZFIO    APLSUB:TABMRG   APLSUB:TEKFLS   APLSUB:TKCATL   

APLCVEX:ZFIO    APLSUB:TKCURS   APLSUB:TKSLIN   QYPGNOT:SDCLN   

APLCVEX:ZFIO    YM70:YCINIT     YM70:YCOVER     YM70:YCREAD     

APLCVEX:ZFIO    YM70:YCWRIT     YM70:YFIND      YM70:YISLOD     

APLCVEX:ZFIO    YM70:YLOCAT     YM70:YTVCLS     YM70:YTVOPN     

APLCVEX:ZFIO    YPGM:TVPL       



APLCVEX:ZFRE2   APLCVEX:ZFREE   

APLCVEX:ZFREE   AIPSUB:AU3A     



APLCVEX:ZFULLN  APGNOT:VLBIN    APLCVEX:ZLASIO  APLCVEX:ZLPOPN  

APLCVEX:ZFULLN  APLCVEX:ZLWIO   APLCVEX:ZTOPEN  APLCVEX:ZTPOPD  

APLCVEX:ZFULLN  APLCVEX:ZTXMAT  APLCVEX:ZTXOP2  



APLCVEX:ZGETCH  APLCVEX:ZC8CL   APLCVEX:ZI8IL   APLCVEX:ZKDUMP  

APLCVEX:ZGETCH  APLSUB:CHCOMP   APLSUB:CHCOPY   APLSUB:CHFILL   

APLCVEX:ZGETCH  APLSUB:CHMATC   APLSUB:H2CHR    APLSUB:SPFIL    

APLCVEX:ZGETCH  APLSUB:TKCURS   APLSUB:UNPACK   



APLCVEX:ZGNAME  APLCVEX:ZABORS  APLCVEX:ZWHOMI  APLSUB:WHOAMI   



APLCVEX:ZGTBIT  APGNOT:FITTP    APGNOT:IMLOD    APGNOT:MK3IN    

APLCVEX:ZGTBIT  APGNOT:TBOUT    APLCVEX:ZARGXF  APLCVEX:ZX8XL   

APLCVEX:ZGTBIT  APLCVEX:ZXLX8   APLNOT:LG2BIT   APLPGM:MCUBE    

APLCVEX:ZGTBIT  APLPGM:PROFL    APLPGM:PRTAB    APLPGM:PRTPL    

APLCVEX:ZGTBIT  APLSUB:CHLTOU   APLSUB:PASENC   YM70:YALUCT     

APLCVEX:ZGTBIT  YM70:YCHRW      YM70:YCRCTL     YM70:YFDBCK     

APLCVEX:ZGTBIT  YM70:YGRAFE     YM70:YGRAPH     YM70:YGYHDR     

APLCVEX:ZGTBIT  YM70:YIFM       YM70:YSCROL     YM70:YSHIFT     

APLCVEX:ZGTBIT  YM70:YSTCUR     



APLCVEX:ZHEX    AIPGUNIX:ZSTRTB APLCVEX:ZBKLD1  APLCVEX:ZBKLD2  

APLCVEX:ZHEX    APLCVEX:ZBKLD3  APLCVEX:ZBKTP1  APLCVEX:ZBKTP2  

Z-ROUTINES AND Z-PROGRAMS                                     Page A-33

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZHEX    APLCVEX:ZDIR    APLCVEX:ZKDUMP  APLCVEX:ZPHFIL  

APLCVEX:ZHEX    APLCVEX:ZPHOLV  APLCVEX:ZTAPE   APLPGM:QMSPL    



APLCVEX:ZI16IL  AIPSUB:UWRITE   APGNOT:FILLM    APGNOT:IMLOD    

APLCVEX:ZI16IL  APGNOT:MK3IN    APGNOT:UVLOD    APGNOT:VLBIN    

APLCVEX:ZI16IL  APLCVEX:ZMCACL  APLCVEX:ZR8P4   APLCVEX:ZVTVXF  

APLCVEX:ZI16IL  APLCVEX:ZX8XL   APLNOT:R3DTAB   APLNOT:TPIOHD   

APLCVEX:ZI16IL  APLPGM:PRTTP    APLSUB:CHAVRT   APLSUB:DWRITE   

APLCVEX:ZI16IL  APLSUB:REAVRT   APLSUB:TAPIO    APLSUB:TPHEAD   

APLCVEX:ZI16IL  APLSUB:UNYBUF   



APLCVEX:ZI32IL  APGNOT:FILLM    APGNOT:IMLOD    APGNOT:MK3IN    

APLCVEX:ZI32IL  APGNOT:UVLOD    APLCVEX:ZDHPRL  APLCVEX:ZR8P4   

APLCVEX:ZI32IL  APLNOT:R3DTAB   APLPGM:PROFL    APLPGM:PRTPL    

APLCVEX:ZI32IL  APLPGM:PRTTP    APLSUB:CHLTOU   YM70:YCHRW      



APLCVEX:ZI8IL   APGNOT:IMLOD    APGNOT:MK3IN    APGNOT:UVLOD    

APLCVEX:ZI8IL   APLCVEX:ZDHPRL  APLCVEX:ZRHPRL  



APLCVEX:ZILI16  AIPSUB:UWRITE   APGNOT:FILLR    APGNOT:FITTP    

APLCVEX:ZILI16  APGNOT:IMLOD    APGNOT:UVLOD    APLCVEX:ZR8P4   

APLCVEX:ZILI16  APLCVEX:ZXLX8   APLPGM:PRTTP    APLSUB:CHAVRT   

APLCVEX:ZILI16  APLSUB:MKYBUF   APLSUB:REAVRT   APLSUB:VBOUT    



APLCVEX:ZILI32  APGNOT:FITTP    APLCVEX:ZR8P4   



APLCVEX:ZIPACK  APGNOT:FILLR    APGNOT:VLBIN    APLCVEX:ZDEAXF  

APLCVEX:ZIPACK  APLCVEX:ZM70XF  APLCVEX:ZV20XF  YM70:YRHIST     



APLCVEX:ZKDUMP  AIPPGM:POPSGN   AIPSUB:KWICK    



APLCVEX:ZLASC2  APLCVEX:ZLASCL  



APLCVEX:ZLASCL  APLCVEX:ZLASIO  APLCVEX:ZLWIO   



APLCVEX:ZLASIO  AIPPGM:AIPLAS   AIPPGM:AIPMAN   APGNOT:CANPL    

APLCVEX:ZLASIO  APLPGM:QMSPL    



APLCVEX:ZLASOP  APLCVEX:ZLASIO  



APLCVEX:ZLOCK   APLCVEX:ZCREA2  APLCVEX:ZDAOPN  APLCVEX:ZDEST2  

APLCVEX:ZLOCK   APLCVEX:ZRENA2  



APLCVEX:ZLPCL2  APLCVEX:ZLPCLS  



APLCVEX:ZLPCLS  APLCVEX:ZCLOSE  



APLCVEX:ZLPOP2  APLCVEX:ZLPOPN  



APLCVEX:ZLPOPN  APLCVEX:ZOPEN   



APLCVEX:ZLWIO   APGNOT:LWPLA    



APLCVEX:ZLWOP   APLCVEX:ZLWIO   

Z-ROUTINES AND Z-PROGRAMS                                     Page A-34

UNIX Z-ROUTINES                                            9 April 1990







APLCVEX:ZM70C2  APLCVEX:ZM70CL  



APLCVEX:ZM70CL  YM70:YTVCL2     



APLCVEX:ZM70M2  APLCVEX:ZM70MC  



APLCVEX:ZM70MC  APLCVEX:ZM70XF  YM70:YTVMC      



APLCVEX:ZM70O2  APLCVEX:ZM70OP  



APLCVEX:ZM70OP  YM70:YTVOP2     



APLCVEX:ZM70X2  APLCVEX:ZM70XF  



APLCVEX:ZM70XF  APLCVEX:ZM70CL  YM70:YALUCT     YM70:YCONST     

APLCVEX:ZM70XF  YM70:YCRCTL     YM70:YFDBCK     YM70:YGGRAM     

APLCVEX:ZM70XF  YM70:YGRAFE     YM70:YIFM       YM70:YIMGIO     

APLCVEX:ZM70XF  YM70:YISDRM     YM70:YISDSC     YM70:YISJMP     

APLCVEX:ZM70XF  YM70:YISMPM     YM70:YLUT       YM70:YMNMAX     

APLCVEX:ZM70XF  YM70:YOFM       YM70:YRHIST     YM70:YSCROL     

APLCVEX:ZM70XF  YM70:YSHIFT     YM70:YSPLIT     YM70:YSTCUR     

APLCVEX:ZM70XF  YM70:YZOOMC     YPGNOT:TVHLD    



APLCVEX:ZMCACL  APGNOT:FILLR    



APLCVEX:ZMI2    APLCVEX:ZMIO    



APLCVEX:ZMIO    AIPSUB:AU7A     APLNOT:FILL2    APLPGM:MCUBE    

APLCVEX:ZMIO    APLPGM:PRTPL    APLPGM:TRANS    APLSUB:MDISK    

APLCVEX:ZMIO    APLSUB:MINIT    APLSUB:MINSK    APLSUB:MSKIP    

APLCVEX:ZMIO    APLSUB:UVDISK   APLSUB:UVINIT   



APLCVEX:ZMKTMP  APLCVEX:ZFULLN  



APLCVEX:ZMOUN2  APLCVEX:ZMOUNT  



APLCVEX:ZMOUNT  APLCVEX:ZTAPE   



APLCVEX:ZMSGCL  AIPPGM:BATER    AIPSUB:AUB      AIPSUB:PRTMSG   

APLCVEX:ZMSGCL  AIPSUB:STORES   APLSUB:MSGWRT   



APLCVEX:ZMSGDK  AIPSUB:PRTMSG   APLSUB:MSGWRT   

APLCVEX:ZMSGER  APLCVEX:ZMSGDK  APLCVEX:ZMSGOP  APLCVEX:ZTTYIO  



APLCVEX:ZMSGOP  AIPPGM:BATER    AIPSUB:AUB      AIPSUB:PRTMSG   

APLCVEX:ZMSGOP  AIPSUB:STORES   APLSUB:MSGWRT   



APLCVEX:ZMSGWR  APLCVEX:ZABORS  APLCVEX:ZBYTF2  APLCVEX:ZCREA2  

APLCVEX:ZMSGWR  APLCVEX:ZDM2DL  APLCVEX:ZLASC2  APLCVEX:ZLPCL2  

APLCVEX:ZMSGWR  APLCVEX:ZMI2    APLCVEX:ZMSGCL  APLCVEX:ZRDMF   

APLCVEX:ZMSGWR  APLCVEX:ZRM2RL  APLCVEX:ZSTAI2  APLCVEX:ZTXMA2  



APLCVEX:ZMSGXP  APLSUB:MSGWRT   

Z-ROUTINES AND Z-PROGRAMS                                     Page A-35

UNIX Z-ROUTINES                                            9 April 1990







APLCVEX:ZMYVER  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:AIPS     

APLCVEX:ZMYVER  AIPPGM:AJAX     AIPPGM:BATER    AIPPGM:BSTRT1   

APLCVEX:ZMYVER  AIPPGM:POPSGN   AIPSUB:AIPINI   



APLCVEX:ZOPEN   AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:AIPLAS   

APLCVEX:ZOPEN   AIPPGM:AIPMAN   AIPPGM:AIPS     AIPPGM:AIPSB    

APLCVEX:ZOPEN   AIPPGM:AIPSC    AIPPGM:BATER    AIPPGM:BSTRT1   

APLCVEX:ZOPEN   AIPPGM:DELSG    AIPPGM:FILAI2   AIPPGM:FILAIP   

APLCVEX:ZOPEN   AIPPGM:FILINI   AIPPGM:FIXUSR   AIPPGM:GR2TEX   

APLCVEX:ZOPEN   AIPPGM:GRIPR    AIPPGM:GRITP    AIPPGM:POPSGN   

APLCVEX:ZOPEN   AIPPGM:QMNGR    AIPPGM:RDFITS   AIPPGM:RECAT    

APLCVEX:ZOPEN   AIPPGM:SETPAR   AIPPGM:SETTVP   AIPPGM:UPDAT    

APLCVEX:ZOPEN   AIPSUB:AIPINI   AIPSUB:AU1A     AIPSUB:AU2      

APLCVEX:ZOPEN   AIPSUB:AU2A     AIPSUB:AU3A     AIPSUB:AU6B     

APLCVEX:ZOPEN   AIPSUB:AU7      AIPSUB:AU7A     AIPSUB:AUA      

APLCVEX:ZOPEN   AIPSUB:AUB      AIPSUB:AUC      AIPSUB:CATCR    

APLCVEX:ZOPEN   AIPSUB:INIT     AIPSUB:PREAD    AIPSUB:PRTMSG   

APLCVEX:ZOPEN   AIPSUB:RENUMB   AIPSUB:SGLAST   AIPSUB:SGLOCA   

APLCVEX:ZOPEN   AIPSUB:STORES   AIPSUB:TASKWT   APGNOT:ASCOR    

APLCVEX:ZOPEN   APGNOT:AVER     APGNOT:AVSPC    APGNOT:BLOAT    

APLCVEX:ZOPEN   APGNOT:BSMAP    APGNOT:CANDY    APGNOT:CANPL    

APLCVEX:ZOPEN   APGNOT:DBCON    APGNOT:DCONV    APGNOT:DESCM    

APLCVEX:ZOPEN   APGNOT:FETCH    APGNOT:FILLM    APGNOT:FILLR    

APLCVEX:ZOPEN   APGNOT:IMFIT    APGNOT:IMFLT    APGNOT:IMLOD    

APLCVEX:ZOPEN   APGNOT:IMMOD    APGNOT:INDXR    APGNOT:JMFIT    

APLCVEX:ZOPEN   APGNOT:LISTR    APGNOT:LWPLA    APGNOT:MANDL    

APLCVEX:ZOPEN   APGNOT:MK3IN    APGNOT:MULTI    APGNOT:MWFLT    

APLCVEX:ZOPEN   APGNOT:NINER    APGNOT:NNLSQ    APGNOT:PATGN    

APLCVEX:ZOPEN   APGNOT:PRTGA    APGNOT:PRTSD    APGNOT:PRTUV    

APLCVEX:ZOPEN   APGNOT:SDCAL    APGNOT:SDTUV    APGNOT:SELSD    

APLCVEX:ZOPEN   APGNOT:SPLIT    APGNOT:TXPL     APGNOT:USUBA    

APLCVEX:ZOPEN   APGNOT:UVAVG    APGNOT:UVCOP    APGNOT:UVDGP    

APLCVEX:ZOPEN   APGNOT:UVFIL    APGNOT:UVFIX    APGNOT:UVFLG    

APLCVEX:ZOPEN   APGNOT:UVIMG    APGNOT:UVLOD    APGNOT:UVMOD    

APLCVEX:ZOPEN   APGNOT:UVSIM    APGNOT:UVSRT    APGNOT:VBCAL    

APLCVEX:ZOPEN   APGNOT:VBMRG    APGNOT:VLBIN    APGNOT:WTMOD    

APLCVEX:ZOPEN   APLCVEX:ZDCHIN  APLNOT:AKOPEN   APLNOT:BMSHP    

APLCVEX:ZOPEN   APLNOT:BPASET   APLNOT:BPGET    APLNOT:CALCOP   

APLCVEX:ZOPEN   APLNOT:EMPTY1   APLNOT:EMPTY2   APLNOT:FILL1    

APLCVEX:ZOPEN   APLNOT:FILL2    APLNOT:GRIDTB   APLNOT:ITBSRT   

APLCVEX:ZOPEN   APLNOT:OTBSRT   APLNOT:PLNPUT   APLNOT:SCINTP   

APLCVEX:ZOPEN   APLNOT:SCLOAD   APLNOT:SDGET    APLNOT:TVFOAD   

APLCVEX:ZOPEN   APLNOT:UVDOUT   APLNOT:UVDPAD   APLNOT:UVGET    

APLCVEX:ZOPEN   APLPGM:CLIP     APLPGM:COMB     APLPGM:CORER    

APLCVEX:ZOPEN   APLPGM:CORFQ    APLPGM:DISKU    APLPGM:FUDGE    

APLCVEX:ZOPEN   APLPGM:IMVIM    APLPGM:PRTAB    APLPGM:PRTAC    

APLCVEX:ZOPEN   APLPGM:PRTAN    APLPGM:PRTCC    APLPGM:PRTIM    

APLCVEX:ZOPEN   APLPGM:PRTPL    APLPGM:PRTTP    APLPGM:QMSPL    

APLCVEX:ZOPEN   APLPGM:SWPOL    APLPGM:TAFFY    APLPGM:TAFLG    

APLCVEX:ZOPEN   APLPGM:TKPL     APLPGM:TRANS    APLPGM:UVCMP    

APLCVEX:ZOPEN   APLPGM:UVDIF    APLPGM:UVFND    APLPGM:UVMTH    

APLCVEX:ZOPEN   APLPGM:XBASL    APLPGM:XGAUS    APLPGM:XMOM     

APLCVEX:ZOPEN   APLPGM:XPLOT    APLPGM:XSMTH    APLPGM:XSUM     

Z-ROUTINES AND Z-PROGRAMS                                     Page A-36

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZOPEN   APLSUB:ACOUNT   APLSUB:BATQ     APLSUB:CATDIR   

APLCVEX:ZOPEN   APLSUB:CATIO    APLSUB:CATKEY   APLSUB:CATOPN   

APLCVEX:ZOPEN   APLSUB:EXTINI   APLSUB:FILOPN   APLSUB:GINIT    

APLCVEX:ZOPEN   APLSUB:GTPARM   APLSUB:GTTELL   APLSUB:HIOPEN   

APLCVEX:ZOPEN   APLSUB:ICOPEN   APLSUB:ISTAB    APLSUB:MAPOPN   

APLCVEX:ZOPEN   APLSUB:MAPSNC   APLSUB:MERGE    APLSUB:NXTMAP   

APLCVEX:ZOPEN   APLSUB:OPEXT    APLSUB:PASWRD   APLSUB:PEAKFN   

APLCVEX:ZOPEN   APLSUB:PLNGET   APLSUB:RELPOP   APLSUB:RESCAL   

APLCVEX:ZOPEN   APLSUB:TABCOP   APLSUB:TABINI   APLSUB:TKCATL   

APLCVEX:ZOPEN   QNOT:ALGSUB     QNOT:APIO       QNOT:CONV1      

APLCVEX:ZOPEN   QNOT:CONV2      QNOT:CONV3      QNOT:CONV4      

APLCVEX:ZOPEN   QNOT:DISPTV     QNOT:GRDCOR     QNOT:UVGRID     

APLCVEX:ZOPEN   QNOT:UVTBGD     QNOT:UVTBUN     QNOT:UVUNIF     

APLCVEX:ZOPEN   QNOT:VISDFT     QPGM:RSTOR      QPGNOT:ASCAL    

APLCVEX:ZOPEN   QPGNOT:BLCAL    QPGNOT:BPASS    QPGNOT:CALIB    

APLCVEX:ZOPEN   QPGNOT:CONVL    QPGNOT:CVEL     QPGNOT:FFT      

APLCVEX:ZOPEN   QPGNOT:GRIDR    QPGNOT:IM2UV    QPGNOT:PCAL     

APLCVEX:ZOPEN   QPGNOT:VSCAL    QSUB:APROLL     QSUB:PASS1      

APLCVEX:ZOPEN   QSUB:PASS2      QYPGM:APCLN     QYPGNOT:APGS    

APLCVEX:ZOPEN   QYPGNOT:APVC    QYPGNOT:MX      QYPGNOT:SDCLN   

APLCVEX:ZOPEN   QYPGNOT:STEER   QYPGNOT:UVMAP   YM70:YTVOPN     

APLCVEX:ZOPEN   YPGM:BLANK      YPGM:BLSUM      YPGM:TVPL       

APLCVEX:ZOPEN   YPGNOT:TVFLG    



APLCVEX:ZPATH   APLCVEX:ZDAOPN  APLCVEX:ZDEST2  APLCVEX:ZEXIS2  

APLCVEX:ZPATH   APLCVEX:ZFULLN  APLCVEX:ZLOCK   APLCVEX:ZRENA2  



APLCVEX:ZPHFIL  AIPPGM:AIPLAS   AIPPGM:AIPMAN   AIPPGM:AIPS     

APLCVEX:ZPHFIL  AIPPGM:AIPSB    AIPPGM:AIPSC    AIPPGM:AJAX     

APLCVEX:ZPHFIL  AIPPGM:BATER    AIPPGM:BSTRT1   AIPPGM:DELSG    

APLCVEX:ZPHFIL  AIPPGM:FILAI2   AIPPGM:FILAIP   AIPPGM:FILINI   

APLCVEX:ZPHFIL  AIPPGM:FIXUSR   AIPPGM:GR2TEX   AIPPGM:GRIPR    

APLCVEX:ZPHFIL  AIPPGM:GRITP    AIPPGM:POPSGN   AIPPGM:QMNGR    

APLCVEX:ZPHFIL  AIPPGM:RDFITS   AIPPGM:RECAT    AIPPGM:SETPAR   

APLCVEX:ZPHFIL  AIPPGM:SETTVP   AIPPGM:UPDAT    AIPSUB:AU1      

APLCVEX:ZPHFIL  AIPSUB:AU1A     AIPSUB:AU2      AIPSUB:AU2A     

APLCVEX:ZPHFIL  AIPSUB:AU3A     AIPSUB:AU6B     AIPSUB:AU7A     

APLCVEX:ZPHFIL  AIPSUB:AU8      AIPSUB:AUA      AIPSUB:AUB      

APLCVEX:ZPHFIL  AIPSUB:AUC      AIPSUB:CATCR    AIPSUB:CHGRIP   

APLCVEX:ZPHFIL  AIPSUB:HELPS    AIPSUB:INIT     AIPSUB:PRTMSG   

APLCVEX:ZPHFIL  AIPSUB:RENUMB   AIPSUB:SGLAST   AIPSUB:SGLOCA   

APLCVEX:ZPHFIL  AIPSUB:STORES   AIPSUB:TASKWT   APGNOT:ANCAL    

APLCVEX:ZPHFIL  APGNOT:ASCOR    APGNOT:AVER     APGNOT:AVSPC    

APLCVEX:ZPHFIL  APGNOT:BAKLD    APGNOT:BAKTP    APGNOT:BLOAT    

APLCVEX:ZPHFIL  APGNOT:BSMAP    APGNOT:CANDY    APGNOT:CANPL    

APLCVEX:ZPHFIL  APGNOT:CCMRG    APGNOT:DBCON    APGNOT:DCONV    

APLCVEX:ZPHFIL  APGNOT:DESCM    APGNOT:DFTPL    APGNOT:FETCH    

APLCVEX:ZPHFIL  APGNOT:FILLM    APGNOT:FILLR    APGNOT:GAL      

APLCVEX:ZPHFIL  APGNOT:GAPLT    APGNOT:GNPLT    APGNOT:IMFLT    

APLCVEX:ZPHFIL  APGNOT:IMLOD    APGNOT:IMMOD    APGNOT:INDXR    

APLCVEX:ZPHFIL  APGNOT:IRING    APGNOT:KNTR     APGNOT:LTESS    

APLCVEX:ZPHFIL  APGNOT:LWPLA    APGNOT:MANDL    APGNOT:MK3IN    

APLCVEX:ZPHFIL  APGNOT:MULTI    APGNOT:MWFLT    APGNOT:NINER    

APLCVEX:ZPHFIL  APGNOT:NNLSQ    APGNOT:PATGN    APGNOT:PLCUB    

Z-ROUTINES AND Z-PROGRAMS                                     Page A-37

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZPHFIL  APGNOT:POSSM    APGNOT:SDCAL    APGNOT:SDTUV    

APLCVEX:ZPHFIL  APGNOT:SELSD    APGNOT:SLICE    APGNOT:SNPLT    

APLCVEX:ZPHFIL  APGNOT:SPLIT    APGNOT:STESS    APGNOT:TAMRG    

APLCVEX:ZPHFIL  APGNOT:TXPL     APGNOT:USUBA    APGNOT:UVAVG    

APLCVEX:ZPHFIL  APGNOT:UVCOP    APGNOT:UVDGP    APGNOT:UVFIL    

APLCVEX:ZPHFIL  APGNOT:UVFIX    APGNOT:UVFLG    APGNOT:UVIMG    

APLCVEX:ZPHFIL  APGNOT:UVLOD    APGNOT:UVMOD    APGNOT:UVPLT    

APLCVEX:ZPHFIL  APGNOT:UVSIM    APGNOT:UVSRT    APGNOT:VBCAL    

APLCVEX:ZPHFIL  APGNOT:VBMRG    APGNOT:VBPLT    APGNOT:VLBIN    

APLCVEX:ZPHFIL  APGNOT:WTMOD    APLCVEX:ZARGOP  APLCVEX:ZBKTP2  

APLCVEX:ZPHFIL  APLCVEX:ZDCHIN  APLCVEX:ZDEAOP  APLCVEX:ZM70OP  

APLCVEX:ZPHFIL  APLCVEX:ZTKOPN  APLCVEX:ZTPOPN  APLCVEX:ZV20OP  

APLCVEX:ZPHFIL  APLCVEX:ZVTVOP  APLNOT:BPASET   APLNOT:CALCOP   

APLCVEX:ZPHFIL  APLNOT:CCMERG   APLNOT:DSKFFT   APLNOT:EMPTY1   

APLCVEX:ZPHFIL  APLNOT:EMPTY2   APLNOT:FILL1    APLNOT:FILL2    

APLCVEX:ZPHFIL  APLNOT:GRIDTB   APLNOT:ITBSRT   APLNOT:OTBSRT   

APLCVEX:ZPHFIL  APLNOT:PLMAKE   APLNOT:PLNPUT   APLNOT:RMEXT    

APLCVEX:ZPHFIL  APLNOT:SCINTP   APLNOT:SCLOAD   APLNOT:SDGET    

APLCVEX:ZPHFIL  APLNOT:TVFOAD   APLNOT:UVDOUT   APLNOT:UVDPAD   

APLCVEX:ZPHFIL  APLNOT:UVGET    APLPGM:AVTP     APLPGM:CLIP     

APLCVEX:ZPHFIL  APLPGM:CNTR     APLPGM:COMB     APLPGM:CORER    

APLCVEX:ZPHFIL  APLPGM:CORFQ    APLPGM:DISKU    APLPGM:FUDGE    

APLCVEX:ZPHFIL  APLPGM:GREYS    APLPGM:IMEAN    APLPGM:IMVIM    

APLCVEX:ZPHFIL  APLPGM:ISPEC    APLPGM:PCNTR    APLPGM:PROFL    

APLCVEX:ZPHFIL  APLPGM:PRTAB    APLPGM:PRTAC    APLPGM:PRTCC    

APLCVEX:ZPHFIL  APLPGM:PRTPL    APLPGM:PRTTP    APLPGM:QMSPL    

APLCVEX:ZPHFIL  APLPGM:SL2PL    APLPGM:SWPOL    APLPGM:TAFFY    

APLCVEX:ZPHFIL  APLPGM:TAFLG    APLPGM:TAPLT    APLPGM:TKPL     

APLCVEX:ZPHFIL  APLPGM:TRANS    APLPGM:UVCMP    APLPGM:UVHGM    

APLCVEX:ZPHFIL  APLPGM:UVMTH    APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZPHFIL  APLPGM:XMOM     APLPGM:XPLOT    APLPGM:XSMTH    

APLCVEX:ZPHFIL  APLPGM:XSUM     APLSUB:ACOUNT   APLSUB:BATQ     

APLCVEX:ZPHFIL  APLSUB:CATDIR   APLSUB:CATIO    APLSUB:CATKEY   

APLCVEX:ZPHFIL  APLSUB:CATOPN   APLSUB:EXTINI   APLSUB:FILCR    

APLCVEX:ZPHFIL  APLSUB:FILDES   APLSUB:FILOPN   APLSUB:GTPARM   

APLCVEX:ZPHFIL  APLSUB:GTTELL   APLSUB:HICREA   APLSUB:HIIO     

APLCVEX:ZPHFIL  APLSUB:HIOPEN   APLSUB:ICOPEN   APLSUB:ISTAB    

APLCVEX:ZPHFIL  APLSUB:MAPOPN   APLSUB:MAPSNC   APLSUB:MCREAT   

APLCVEX:ZPHFIL  APLSUB:MDESTR   APLSUB:MERGE    APLSUB:MSGWRT   

APLCVEX:ZPHFIL  APLSUB:NXTMAP   APLSUB:OPEXT    APLSUB:PASWRD   

APLCVEX:ZPHFIL  APLSUB:PEAKFN   APLSUB:PLNGET   APLSUB:RELPOP   

APLCVEX:ZPHFIL  APLSUB:RESCAL   APLSUB:SCREAT   APLSUB:TABCOP   

APLCVEX:ZPHFIL  APLSUB:TABINI   APLSUB:TABMRG   APLSUB:TAPIO    

APLCVEX:ZPHFIL  APLSUB:TKCATL   APLSUB:UVCREA   QNOT:ALGSUB     

APLCVEX:ZPHFIL  QNOT:APCONV     QNOT:APIO       QNOT:FFTIM      

APLCVEX:ZPHFIL  QNOT:GRDCOR     QNOT:UVGRID     QNOT:UVTBGD     

APLCVEX:ZPHFIL  QNOT:UVTBUN     QNOT:UVUNIF     QNOT:VISDFT     

APLCVEX:ZPHFIL  QPGM:RSTOR      QPGNOT:ASCAL    QPGNOT:BLCAL    

APLCVEX:ZPHFIL  QPGNOT:BPASS    QPGNOT:CALIB    QPGNOT:CONVL    

APLCVEX:ZPHFIL  QPGNOT:CVEL     QPGNOT:FFT      QPGNOT:GRIDR    

APLCVEX:ZPHFIL  QPGNOT:IM2UV    QPGNOT:IMERG    QPGNOT:PCAL     

APLCVEX:ZPHFIL  QPGNOT:VSCAL    QSUB:APROLL     QYPGM:APCLN     

APLCVEX:ZPHFIL  QYPGNOT:APGS    QYPGNOT:APVC    QYPGNOT:MX      

APLCVEX:ZPHFIL  QYPGNOT:SDCLN   QYPGNOT:STEER   QYPGNOT:UTESS   

Z-ROUTINES AND Z-PROGRAMS                                     Page A-38

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZPHFIL  QYPGNOT:UVMAP   QYPGNOT:VTESS   YM70:YTVOPN     

APLCVEX:ZPHFIL  YPGM:BLANK      YPGM:BLSUM      YPGM:TVPL       

APLCVEX:ZPHFIL  YPGNOT:TVFLG    



APLCVEX:ZPHOLV  AIPPGM:UPDAT    



APLCVEX:ZPRI2   APLCVEX:ZPRIO   



APLCVEX:ZPRIO   APLCVEX:ZSETUP  



APLCVEX:ZPRMPT  AIPSUB:PREAD    AIPSUB:RDUSER   



APLCVEX:ZPRPAS  AIPSUB:AUC      APLSUB:PASWRD   



APLCVEX:ZPTBIT  APGNOT:TBIN     APLCVEX:ZARGXF  APLCVEX:ZX8XL   

APLCVEX:ZPTBIT  APLCVEX:ZXLX8   APLNOT:LG2BIT   APLPGM:MCUBE    

APLCVEX:ZPTBIT  APLPGM:PROFL    APLPGM:PRTPL    APLSUB:CHLTOU   

APLCVEX:ZPTBIT  APLSUB:PASENC   YM70:YALUCT     YM70:YCHRW      

APLCVEX:ZPTBIT  YM70:YCRCTL     YM70:YFDBCK     YM70:YGRAFE     

APLCVEX:ZPTBIT  YM70:YGRAPH     YM70:YGYHDR     YM70:YIFM       

APLCVEX:ZPTBIT  YM70:YMKHDR     YM70:YSHIFT     YM70:YSTCUR     



APLCVEX:ZPUTCH  APLCVEX:ZCLC8   APLCVEX:ZTKBUF  APLSUB:CHCOPY   

APLCVEX:ZPUTCH  APLSUB:CHFILL   APLSUB:CHR2H    APLSUB:PASENC   

APLCVEX:ZPUTCH  APLSUB:SPFIL    APLSUB:UNPACK   



APLCVEX:ZR32RL  APGNOT:IMLOD    APGNOT:UVLOD    APLNOT:R3DTAB   

APLCVEX:ZR32RL  APLSUB:REAVRT   



APLCVEX:ZR64RL  APLNOT:R3DTAB   APLSUB:REAVRT   



APLCVEX:ZR8P4   AIPSUB:UWRITE   APGNOT:FILLR    APGNOT:IMLOD    

APLCVEX:ZR8P4   APGNOT:UVLOD    APLPGM:PRTTP    APLSUB:DWRITE   



APLCVEX:ZRDMF   APGNOT:FILLR    



APLCVEX:ZRENA2  APLCVEX:ZRENAM  



APLCVEX:ZRENAM  AIPPGM:UPDAT    AIPSUB:RENUMB   APLSUB:RESCAL   



APLCVEX:ZRHPRL  APGNOT:MK3IN    



APLCVEX:ZRLR32  APGNOT:FITTP    APGNOT:VLBIN    APLSUB:REAVRT   



APLCVEX:ZRLR64  APGNOT:FITTP    APGNOT:VLBIN    APLSUB:REAVRT   



APLCVEX:ZRM2RL  APGNOT:FILLM    APGNOT:FILLR    



APLCVEX:ZSETUP  APLSUB:GTPARM   



APLCVEX:ZSHCMD  APLCVEX:ZBKLD1  APLCVEX:ZBKLD2  APLCVEX:ZBKLD3  

APLCVEX:ZSHCMD  APLCVEX:ZBKTP1  APLCVEX:ZBKTP2  APLCVEX:ZBKTP3  



APLCVEX:ZSTAI2  APLCVEX:ZSTAIP  

Z-ROUTINES AND Z-PROGRAMS                                     Page A-39

UNIX Z-ROUTINES                                            9 April 1990







APLCVEX:ZSTAIP  AIPPGM:AIPS     



APLCVEX:ZSTRTP  AIPGUNIX:ZSTRTA 



APLCVEX:ZTACT2  APLCVEX:ZTACTQ  



APLCVEX:ZTACTQ  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:AIPSC    

APLCVEX:ZTACTQ  AIPPGM:BATER    AIPPGM:BSTRT1   AIPPGM:QMNGR    

APLCVEX:ZTACTQ  AIPSUB:AU2      AIPSUB:AUA      AIPSUB:DESCR    

APLCVEX:ZTACTQ  AIPSUB:TASKWT   APLPGM:NOBAT    



APLCVEX:ZTAP2   APLCVEX:ZTAPE   APLCVEX:ZTPOPN  



APLCVEX:ZTAPE   AIPPGM:GR2TEX   AIPPGM:GRITP    AIPPGM:RDFITS   

APLCVEX:ZTAPE   AIPSUB:AU4      APGNOT:FILLM    APGNOT:FILLR    

APLCVEX:ZTAPE   APGNOT:FITTP    APGNOT:IMLOD    APGNOT:MK3IN    

APLCVEX:ZTAPE   APGNOT:UVLOD    APLCVEX:ZBKTP1  APLNOT:TPIOHD   

APLCVEX:ZTAPE   APLPGM:AVTP     APLPGM:PRTTP    APLSUB:FNDEOT   

APLCVEX:ZTAPE   APLSUB:TAPIO    APLSUB:TPHEAD   



APLCVEX:ZTCLOS  AIPPGM:AIPS     AIPPGM:AIPSC    AIPPGM:BATER    

APLCVEX:ZTCLOS  AIPPGM:GRIPR    AIPSUB:AU1A     AIPSUB:AU2      

APLCVEX:ZTCLOS  AIPSUB:AU2A     AIPSUB:HELPS    AIPSUB:OERROR   

APLCVEX:ZTCLOS  AIPSUB:PREAD    



APLCVEX:ZTFILL  APLSUB:LSERCH   



APLCVEX:ZTIME   AIPPGM:BATER    AIPPGM:FILAIP   AIPPGM:GR2TEX   

APLCVEX:ZTIME   AIPPGM:GRIPR    AIPSUB:AU2      AIPSUB:AU3A     

APLCVEX:ZTIME   AIPSUB:AU6      AIPSUB:AU6A     AIPSUB:AU6B     

APLCVEX:ZTIME   AIPSUB:AUB      AIPSUB:AUC      AIPSUB:CATCR    

APLCVEX:ZTIME   AIPSUB:GRLUTS   AIPSUB:GRPOLY   AIPSUB:HIENH    

APLCVEX:ZTIME   AIPSUB:PRTALN   AIPSUB:PRTMSG   AIPSUB:SGLAST   

APLCVEX:ZTIME   AIPSUB:STORES   AIPSUB:TVMOVI   AIPSUB:TVROAM   

APLCVEX:ZTIME   APGNOT:ACFIT    APGNOT:ANCAL    APGNOT:BSMAP    

APLCVEX:ZTIME   APGNOT:CANDY    APGNOT:CCMRG    APGNOT:CLCAL    

APLCVEX:ZTIME   APGNOT:CLCOR    APGNOT:CSCOR    APGNOT:FARAD    

APLCVEX:ZTIME   APGNOT:FETCH    APGNOT:FILLM    APGNOT:FILLR    

APLCVEX:ZTIME   APGNOT:GAL      APGNOT:GAPLT    APGNOT:GETJY    

APLCVEX:ZTIME   APGNOT:GNPLT    APGNOT:IRING    APGNOT:KNTR     

APLCVEX:ZTIME   APGNOT:LTESS    APGNOT:MANDL    APGNOT:MK3IN    

APLCVEX:ZTIME   APGNOT:PATGN    APGNOT:PFPL1    APGNOT:PFPL2    

APLCVEX:ZTIME   APGNOT:PFPL3    APGNOT:PLCUB    APGNOT:PLROW    

APLCVEX:ZTIME   APGNOT:POSSM    APGNOT:QUACK    APGNOT:SDTUV    

APLCVEX:ZTIME   APGNOT:SETAN    APGNOT:SETJY    APGNOT:SLICE    

APLCVEX:ZTIME   APGNOT:SNPLT    APGNOT:SOLCL    APGNOT:STESS    

APLCVEX:ZTIME   APGNOT:TABED    APGNOT:TAMRG    APGNOT:UNCAL    

APLCVEX:ZTIME   APGNOT:UVFIL    APGNOT:UVLOD    APGNOT:UVPLT    

APLCVEX:ZTIME   APGNOT:UVSIM    APGNOT:VBPLT    APGNOT:VLBIN    

APLCVEX:ZTIME   APLCVEX:ZTQSPY  APLNOT:OTBSRT   APLPGM:DISKU    

APLCVEX:ZTIME   APLPGM:GREYS    APLPGM:IMEAN    APLPGM:IMVIM    

APLCVEX:ZTIME   APLPGM:ISPEC    APLPGM:PRTAC    APLPGM:PRTAN    

APLCVEX:ZTIME   APLPGM:SL2PL    APLPGM:SLFIT    APLPGM:STARS    

Z-ROUTINES AND Z-PROGRAMS                                     Page A-40

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZTIME   APLPGM:TACOP    APLPGM:TAFLG    APLPGM:TAPLT    

APLCVEX:ZTIME   APLPGM:UVHGM    APLSUB:ACOUNT   APLSUB:BATPRT   

APLCVEX:ZTIME   APLSUB:CATIME   APLSUB:CATOPN   APLSUB:COMLAB   

APLCVEX:ZTIME   APLSUB:DTINIT   APLSUB:DTTIME   APLSUB:EXTINI   

APLCVEX:ZTIME   APLSUB:GINIT    APLSUB:HIMERG   APLSUB:HIPLOT   

APLCVEX:ZTIME   APLSUB:HISCOP   APLSUB:PRTLIN   APLSUB:RANDIN   

APLCVEX:ZTIME   APLSUB:TABCOP   APLSUB:TABINI   QNOT:VISDFT     

APLCVEX:ZTIME   QPGM:RSTOR      QPGNOT:BLCAL    QPGNOT:BPASS    

APLCVEX:ZTIME   QPGNOT:CALIB    QPGNOT:GRIDR    QPGNOT:PCAL     

APLCVEX:ZTIME   QSUB:QROLL      QYPGM:APCLN     QYPGNOT:APGS    

APLCVEX:ZTIME   QYPGNOT:APVC    QYPGNOT:MX      QYPGNOT:SDCLN   

APLCVEX:ZTIME   QYPGNOT:STEER   QYPGNOT:UTESS   QYPGNOT:UVMAP   

APLCVEX:ZTIME   QYPGNOT:VTESS   YPGM:BLANK      YPGM:BLSUM      

APLCVEX:ZTIME   YPGNOT:TVFLG    YPGNOT:TVHLD    YPGNOT:TVHXF    

APLCVEX:ZTIME   YSUB:DLINTR     YSUB:GRBOXS     YSUB:IENHNS     

APLCVEX:ZTIME   YSUB:TVFIDL     



APLCVEX:ZTKBUF  AIPSUB:TKGGPL   AIPSUB:TKGMPL   AIPSUB:TKRSPL   

APLCVEX:ZTKBUF  AIPSUB:TKSLPL   APLPGM:TKPL     APLPGM:XBASL    

APLCVEX:ZTKBUF  APLPGM:XGAUS    APLPGM:XPLOT    APLSUB:TKCHAR   

APLCVEX:ZTKBUF  APLSUB:TKCLR    APLSUB:TKCURS   APLSUB:TKDVEC   

APLCVEX:ZTKBUF  APLSUB:TKLAB    



APLCVEX:ZTKCL2  APLCVEX:ZTKCLS  

APLCVEX:ZTKCLS  AIPSUB:AU9A     AIPSUB:AU9B     AIPSUB:TKSLAC   

APLCVEX:ZTKCLS  APLPGM:TKPL     APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZTKCLS  APLPGM:XPLOT    



APLCVEX:ZTKFI2  APLCVEX:ZFIO    



APLCVEX:ZTKILL  AIPSUB:AU2      



APLCVEX:ZTKOP2  APLCVEX:ZTKOPN  



APLCVEX:ZTKOPN  AIPSUB:AU9A     AIPSUB:AU9B     AIPSUB:TKSLAC   

APLCVEX:ZTKOPN  APLPGM:TKPL     APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZTKOPN  APLPGM:XPLOT    



APLCVEX:ZTOPE2  APLCVEX:ZTOPEN  



APLCVEX:ZTOPEN  AIPPGM:AIPSC    AIPPGM:BATER    AIPPGM:FILAI2   

APLCVEX:ZTOPEN  AIPPGM:GRIPR    AIPPGM:POPSGN   AIPPGM:UPDAT    

APLCVEX:ZTOPEN  AIPSUB:AU1A     AIPSUB:AU2      AIPSUB:AU2A     

APLCVEX:ZTOPEN  AIPSUB:HELPS    



APLCVEX:ZTPCL2  APLCVEX:ZTPCLS  APLCVEX:ZTPOPN  



APLCVEX:ZTPCLD  APLCVEX:ZTPCLS  



APLCVEX:ZTPCLS  AIPPGM:AIPMAN   AIPPGM:GR2TEX   AIPPGM:GRITP    

APLCVEX:ZTPCLS  AIPPGM:RDFITS   APGNOT:BAKLD    APGNOT:BAKTP    

APLCVEX:ZTPCLS  APGNOT:FITTP    APLCVEX:ZBKLD1  APLCVEX:ZBKTP1  

APLCVEX:ZTPCLS  APLPGM:AVTP     APLSUB:TAPIO    



Z-ROUTINES AND Z-PROGRAMS                                     Page A-41

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZTPMI2  APLCVEX:ZTPMIO  



APLCVEX:ZTPMID  APLCVEX:ZTPMIO  



APLCVEX:ZTPMIO  AIPPGM:AIPMAN   AIPPGM:GR2TEX   AIPPGM:GRITP    

APLCVEX:ZTPMIO  AIPPGM:RDFITS   APLSUB:FNDEOT   APLSUB:TAPIO    



APLCVEX:ZTPOP2  APLCVEX:ZTPOPN  



APLCVEX:ZTPOPD  APLCVEX:ZTPOPN  



APLCVEX:ZTPOPN  AIPPGM:AIPMAN   AIPPGM:GR2TEX   AIPPGM:GRITP    

APLCVEX:ZTPOPN  AIPPGM:RDFITS   APGNOT:BAKLD    APGNOT:BAKTP    

APLCVEX:ZTPOPN  APLPGM:AVTP     APLSUB:TAPIO    



APLCVEX:ZTPWA2  APLCVEX:ZTPWAT  



APLCVEX:ZTPWAD  APLCVEX:ZTPWAT  



APLCVEX:ZTPWAT  AIPPGM:AIPMAN   AIPPGM:GR2TEX   AIPPGM:GRITP    

APLCVEX:ZTPWAT  AIPPGM:RDFITS   APLSUB:FNDEOT   APLSUB:TAPIO    



APLCVEX:ZTQSP2  APLCVEX:ZTQSPY  



APLCVEX:ZTQSPY  AIPSUB:AU2      



APLCVEX:ZTREAD  AIPPGM:AIPSC    AIPPGM:BATER    AIPPGM:FILAI2   

APLCVEX:ZTREAD  AIPPGM:GRIPR    AIPPGM:POPSGN   AIPPGM:UPDAT    

APLCVEX:ZTREAD  AIPSUB:AU1A     AIPSUB:AU2      AIPSUB:AU2A     

APLCVEX:ZTREAD  AIPSUB:HELPS    AIPSUB:PREAD    



APLCVEX:ZTRLOG  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB APLCVEX:ZACTV8  

APLCVEX:ZTRLOG  APLCVEX:ZBKLD1  APLCVEX:ZBKLD2  APLCVEX:ZBKTP1  

APLCVEX:ZTRLOG  APLCVEX:ZBKTP2  APLCVEX:ZCREA2  APLCVEX:ZDIR    

APLCVEX:ZTRLOG  APLCVEX:ZIVSOP  APLCVEX:ZM70O2  APLCVEX:ZMYVER  

APLCVEX:ZTRLOG  APLCVEX:ZPATH   APLCVEX:ZSTRTP  APLCVEX:ZTKOP2  

APLCVEX:ZTRLOG  APLCVEX:ZTPOP2  APLCVEX:ZTTOPN  APLCVEX:ZWHOMI  



APLCVEX:ZTTCLS  APLCVEX:ZCLOSE  APLCVEX:ZMSGCL  



APLCVEX:ZTTOP2  APLCVEX:ZTTOPN  



APLCVEX:ZTTOPN  APLCVEX:ZMSGOP  APLCVEX:ZOPEN   



APLCVEX:ZTTYIO  AIPGUNIX:ZSTRTA AIPGUNIX:ZSTRTB AIPPGM:BATER    

APLCVEX:ZTTYIO  AIPPGM:FILAI2   AIPPGM:RECAT    AIPPGM:SETPAR   

APLCVEX:ZTTYIO  AIPPGM:SETTVP   AIPPGM:UPDAT    AIPSUB:AUB      

APLCVEX:ZTTYIO  AIPSUB:PRTALN   AIPSUB:STORES   APGNOT:LISTR    

APLCVEX:ZTTYIO  APGNOT:PRTSD    APGNOT:PRTUV    APGNOT:UVSIM    

APLCVEX:ZTTYIO  APLPGM:PRTAC    APLPGM:PRTIM    APLPGM:UVDIF    

APLCVEX:ZTTYIO  APLPGM:UVFND    APLPGM:XBASL    APLPGM:XGAUS    

APLCVEX:ZTTYIO  APLPGM:XPLOT    APLSUB:INQFLT   APLSUB:INQGEN   

APLCVEX:ZTTYIO  APLSUB:INQINT   APLSUB:INQSTR   APLSUB:MSGWRT   

APLCVEX:ZTTYIO  APLSUB:PRTLIN   YPGM:BLANK      YPGM:BLSUM      

Z-ROUTINES AND Z-PROGRAMS                                     Page A-42

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZTTYIO  YPGNOT:TVFLG    



APLCVEX:ZTXCLS  AIPPGM:GR2TEX   APGNOT:ANCAL    APGNOT:FARAD    

APLCVEX:ZTXCLS  APGNOT:FETCH    APGNOT:MK3IN    APGNOT:POSSM    

APLCVEX:ZTXCLS  APGNOT:SETAN    APGNOT:SLCOL    APGNOT:TBIN     

APLCVEX:ZTXCLS  APGNOT:TBOUT    APGNOT:UVFIL    APGNOT:UVFLG    

APLCVEX:ZTXCLS  APGNOT:UVSIM    APGNOT:VLBIN    APGNOT:XTRAN    

APLCVEX:ZTXCLS  APLPGM:IMEAN    APLPGM:STARS    



APLCVEX:ZTXIO   AIPPGM:GR2TEX   APGNOT:FARAD    APGNOT:FETCH    

APLCVEX:ZTXIO   APGNOT:POSSM    APGNOT:SETAN    APGNOT:SLCOL    

APLCVEX:ZTXIO   APGNOT:TBIN     APGNOT:TBOUT    APGNOT:UVSIM    

APLCVEX:ZTXIO   APGNOT:XTRAN    APLNOT:KEYIN    APLPGM:IMEAN    

APLCVEX:ZTXIO   APLPGM:STARS    



APLCVEX:ZTXMA2  APLCVEX:ZTXMAT  



APLCVEX:ZTXMAT  APLSUB:TXTMAT   



APLCVEX:ZTXOP2  APLCVEX:ZTXOPN  



APLCVEX:ZTXOPN  AIPPGM:GR2TEX   APGNOT:ANCAL    APGNOT:FARAD    

APLCVEX:ZTXOPN  APGNOT:FETCH    APGNOT:MK3IN    APGNOT:POSSM    

APLCVEX:ZTXOPN  APGNOT:SETAN    APGNOT:SLCOL    APGNOT:TBIN     

APLCVEX:ZTXOPN  APGNOT:TBOUT    APGNOT:UVFIL    APGNOT:UVFLG    

APLCVEX:ZTXOPN  APGNOT:UVSIM    APGNOT:XTRAN    APLPGM:IMEAN    

APLCVEX:ZTXOPN  APLPGM:STARS    



APLCVEX:ZUVPAK  APGNOT:AVSPC    APGNOT:FILLM    APGNOT:MK3IN    

APLCVEX:ZUVPAK  APGNOT:SPLIT    APGNOT:UVFIX    APGNOT:UVLOD    

APLCVEX:ZUVPAK  APGNOT:VLBIN    APLPGM:UVCMP    QPGNOT:CVEL     



APLCVEX:ZUVXPN  APGNOT:AVSPC    APGNOT:FITTP    APGNOT:UVFIX    

APLCVEX:ZUVXPN  APLNOT:DATGET   APLPGM:UVCMP    QPGNOT:BPASS    

APLCVEX:ZUVXPN  QYPGNOT:MX      



APLCVEX:ZV20C2  APLCVEX:ZV20CL  



APLCVEX:ZV20MC  APLCVEX:ZV20XF  



APLCVEX:ZV20O2  APLCVEX:ZV20OP  



APLCVEX:ZV20X2  APLCVEX:ZV20XF  



APLCVEX:ZVLBIN  APGNOT:VLBIN    



APLCVEX:ZVTVC2  APLCVEX:ZVTVCL  



APLCVEX:ZVTVC3  APLCVEX:ZVTVRC  



APLCVEX:ZVTVGC  APLCVEX:ZVTVRX  



APLCVEX:ZVTVO2  APLCVEX:ZVTVOP  



Z-ROUTINES AND Z-PROGRAMS                                     Page A-43

UNIX Z-ROUTINES                                            9 April 1990





APLCVEX:ZVTVO3  APLCVEX:ZVTVRO  



APLCVEX:ZVTVX2  APLCVEX:ZVTVXF  



APLCVEX:ZVTVX3  APLCVEX:ZVTVRX  



APLCVEX:ZWAI2   APLCVEX:ZWAIT   



APLCVEX:ZWAIT   AIPSUB:AU7A     APLNOT:FILL2    APLPGM:MCUBE    

APLCVEX:ZWAIT   APLPGM:PRTPL    APLPGM:TRANS    APLSUB:MDISK    

APLCVEX:ZWAIT   APLSUB:MINIT    APLSUB:MSKIP    APLSUB:UVDISK   

APLCVEX:ZWAIT   APLSUB:UVINIT   



APLCVEX:ZWHOMI  AIPPGM:AIPS     



APLCVEX:ZX8XL   APLNOT:R3DTAB   



APLCVEX:ZXLX8   APGNOT:FITTP    







A.6  UNIX Z-PROGRAMS



     The only Z-programs developed for UNIX/AIPS  at  NRAO  are  ZSTRTA

(interactive  AIPS  startup)  and ZSTRTB (batch AIPS startup).  Generic

versions of ZSTRTA and ZSTRTB can be found  in  $AIPGUNIX.   ZSTRTA  is

executed  as  part  of  the  AIPS startup procedure $SYSUNIX/AIPS.  The

purpose of ZSTRTA is  to  determine  the  lowest  available/appropriate

"POPS" number, "n".  This is determined from the existence of processes

with names of the form AIPSn where "n" ranges from  1  to  the  maximum

number  of  interactive  AIPSs  allowed  as  specified  in  the  system

parameter file ($DA00/SP* file).  This value is set via the stand-alone

utility  program  SETPAR  and  limited  by  the  number of memory files

generated via FILAIP (or FILINI) and  initialized  by  POPSGN.   ZSTRTA

could,  and  probably  should, do more to establish the environment for

the AIPS  session  (set  process  shell  variables,  create  lock  file

directories).   Like  ZSTRTA,  ZSTRTB  is executed as part of the BATER

startup procedure $SYSUNIX/BATER.  BATER is an  AIPS-like  program  for

preparing and submitting AIPS batch jobs.

























                              APPENDIX B



                             RELEASE NOTES







B.1  INTRODUCTION



     The purpose of this chapter is to give installers some  notion  of

the system dependent changes in AIPS that may affect local development.

The  same  change  information  can  usually  be  extracted  from   the

AIPSletter,  but  its impact may not be obvious.  If this is your first

installation of AIPS, these notes are probably of little interest,  but

they  may give you some idea what kind of future changes might trip you

up when you update your system.







B.2  NOTES FOR THE 15OCT86 RELEASE



B.2.1  Introduction



     The 15OCT86 release was the first release of AIPS under UNIX after

a  rather lengthy hiatus.  Massive changes were made since the previous

release (15JUL85) and it would be futile to try to describe  them  all.

Apart  from  locally  developed  Q, Y and Z-routines, there is probably

little that can be salvaged from 15JUL85 and it is recommended that you

start afresh.







B.3  NOTES FOR THE 15JAN87 RELEASE



B.3.1  Introduction



     Very few UNIX or system specific changes were made for the 15JAN87

release.







B.3.2  Changes Of Interest



     In $APLUNIX/ZPHFIL, the logical  name  for  the  Tektronix  device

during  a "remote" AIPS session was changed to TEKTK1n where "n" is the

POPS number assigned at startup time.  Unfortunately, neither the  AIPS

startup  procedure  nor  $APLUNIX/ZWHOMI.FOR  were changed and "remote"

RELEASE NOTES                                                  Page B-2

NOTES FOR THE 15JAN87 RELEASE                              9 April 1990





AIPS Tektronix usage quit working.



     The new areas $APLNRAO1, $APLVLAC1, $SYSNRAO1 and  $SYSVLAC1  have

been  created  and  defined  in  $SYSUNIX/AREAS.DAT  for Z-routines and

"system"  specific  files  on  the  NRAO-CV  and   NRAO-VLA   Convexes,

respectively.



     The new routines ZR32RL, ZRLR32, ZR64RL and ZR64RL for  converting

between   local   floating-point  formats  and  the  IEEE  format  were

introduced.  Generic and Convex specific  versions  are  provided,  but

local  development  may be required, especially for those machines that

do not use IEEE floating-point format.  At the moment,  these  routines

only  come  into  play  during  the processing of FITS tapes containing

binary extension files (e.g., generated via FITTP with DONEWTAB=1).







B.4  NOTES FOR THE 15APR87 RELEASE



B.4.1  Introduction



     Some rather major changes  were  made  for  the  15APR87  release.

Effort  has  begun  to  replace  routines that have names and functions

assuming a VMS environment with routines that have  both  more  generic

names  as  well  as  functionality across many operating systems.  This

notion will accelerate in future  releases  and  the  first  Z-routines

generic  to  multiple  operating  systems  will  begin to appear in the

currently virgin  $APLGEN  (i.e.,  $APL/DEV)  directory.   This  should

facilitate   maintenance  and  add  coherency  to  the  development  of

Z-routines from the standpoint of the AIPS group and at the same  time,

isolate  the  truly  system  dependent  implementation  aspects  into a

smaller number of simpler, lower level routines.  At some point it  may

be  that  some  of  the upper level routines will disappear entirely as

Z-routines  and  instead  become  absorbed  as  part  of  the   machine

independent code.







B.4.2  Changes Of Interest



     The format of LIBR.DAT has been  changed  to  accommodate  systems

with  diversified  peripherals,  for  example, systems with multiple TV

displays of different makes or models.  Such systems  require  multiple

executable module libraries which implies multiple links with alternate

object libraries.  All procedures that depend  on  LIBR.DAT  were  also

changed.    SEARCH.DAT,   which  is  generated  automatically  whenever

LIBR.DAT changes,  has  been  renamed  to  SEARCHn.DAT  where  the  "n"

represents  an alternate module search path ("0" is the default and for

most systems this will be the only SEARCHn.DAT file).   Local  versions

of LIBR.DAT developed for previous releases of AIPS cannot be used with

15APR87, however, with simple editing they can be updated.

RELEASE NOTES                                                  Page B-3

NOTES FOR THE 15APR87 RELEASE                              9 April 1990





     Both the AIPS and BATER startup  procedures  have  be  changed  to

simplify  the  execution of "local" versions of AIPS.EXE and BATER.EXE,

respectively.  Optional execution under the control of a  debugger  has

also been simplified.  Tektronix and TV device logicals and assignments

are handled differently in general.  In particular, for  those  systems

with more than one TV display device (i.e., if the environment variable

TVDEV2 is defined), the AIPS startup procedure will query the  user  to

select  such a device by number.  Startup procedures that may have been

developed locally for  previous  releases  of  AIPS  will  need  to  be

upgraded.



     $AIPGUNIX/ZSTRTA.FOR and $AIPGUNIX/ZSTRTB.FOR have been changed to

facilitate the execution of "local" versions of AIPS.EXE and BATER.EXE,

respectively, and execution under the control of a debugger.



     $APLUNIX/ZWHOMI.FOR  has  been  changed  to  accommodate  the  way

Tektronix and TV device assignments are handled.



     Unfortunately, the Berkeley UNIX specific command  "printenv"  got

into  our  programming  procedures and cannot be un-implemented without

great effort and confusion.  Largely this was a result of  yielding  to

pressure  to  make the use of environment variables more similar to the

use of logicals in a VMS environment.  In any case, the  source  module

$SYSUNIX/PRINTENV.C is a program intended to serve the same purpose for

all systems and should be compiled to produce the executable  PRINTENV.

The  programming procedures no longer invoke "printenv", but "PRINTENV"

instead.



     The new routine ZTRLOG.C has been introduced and  will  eventually

replace  its predecessor, ZXTLOG.C.  Like ZXTLOG, ZTRLOG is intended to

be called only by other Z-routines.  Local code  that  makes  calls  to

ZXTLOG should be converted to call ZTRLOG instead.



     The new routines ZABORT.C and ZABOR2.C have  been  introduced  and

replace   their  predecessors,  ZESTEX.C  and  ZXSIGC.C,  respectively.

ZABORT (as was ZESTEX) is only called  by  ZDCHIN  to  establish  abort

handling.  ZABOR2 is the abort handler.



     The new routines ZERROR.FOR and ZERRO2.C have been introduced  and

will  eventually  replace  their  predecessors,  ZQMSG.C  and ZQDEVN.C.

Local code that calls ZQMSG should be converted to call ZERROR instead.



     The new routine  ZMSGWR.FOR  has  been  introduced  to  facilitate

message handling from routines written in C.  It simply takes a message

level indicator and a buffer containing the message  text,  copies  and

reformats  the  text  into  the  normal  message  buffer  (i.e., REAL*4

MSGTXT(20))  and  calls  MSGWRT  with  the  specified  message   level.

Formerly, to do this in C required some rather fragile trickery.







B.5  NOTES FOR THE 15JUL87 RELEASE



RELEASE NOTES                                                  Page B-4

NOTES FOR THE 15JUL87 RELEASE                              9 April 1990





B.5.1  Introduction



     There have been no major changes since the 15APR87 release.







B.5.2  Changes Of Interest



     There have been no changes of special interest since  the  15APR87

release.







B.6  NOTES FOR THE 15OCT87 RELEASE



B.6.1  Introduction



     The 15OCT87 release includes  the  first  installment  of  the  so

called  generic  Z-routines  which  are stored in the APLGEN area.  The

routines in this area are designed to be either functionally generic to

a wide range of systems (if not all systems) or ``stubbed'' in the case

of those routines that are invariably  implementation  dependent.   The

stubbed  routines issue error messages to that effect and either return

a suitable  error  code  or  STOP  the  program.   These  will  require

development  for  implementations  of  AIPS  under  systems not already

supported by NRAO.  All the APLGEN area routines  should  at  least  be

complete  in  terms of documentation of their purpose (e.g., ZMCACL and

ZRDMF), and in some cases, they may even be complete to  the  point  of

being  functional except that some system specific value may need to be

substituted (e.g., ZTPWAD).  In future releases, still  others  may  be

provided  that are ``conditionally'' generic.  These may branch to code

appropriate  to  the  host  based   on   system   constants   such   as

floating-point  format  codes  or  may  be functionally generic only to

those systems  where  16-bit  integers  are  supported,  but  otherwise

stubbed.



     UNIX sites with previous releases of AIPS will note that a  number

of  Z-routines  such  as ZEXIST, ZCREAT, ZOPEN, ZCLOSE, ZDESTR, etc. no

longer exist in any of the UNIX Z-routine  directories.   Instead,  the

APLGEN  versions  of these routines are used for UNIX much like the COS

and VMS implementations ultimately  will.   The  restructuring  of  the

Z-routine   design   has   entailed   a  modest  amount  of  additional

``layering'' or isolation of functionality.  Whereas this increases the

total  number  of  routines  required  for  a given implementation, the

number of these routines that need  to  be  system  specific  has  been

substantially   reduced.    For   example,  the  effect  for  the  UNIX

implementation is that the number of UNIX specific Z-routines has  been

reduced  by  about  one  third  from  the  15JUL87  release.  A further

reduction in the number of UNIX specific routines to about one half  of

those in the 15JUL87 release appears likely.



     In addition to the use of the APLGEN routines, the 15OCT87 release

also includes a rather major overhaul of the routines found in the UNIX

specific Z-routine directories.  The new C routine ZDCHI2 as called  by

RELEASE NOTES                                                  Page B-5

NOTES FOR THE 15OCT87 RELEASE                              9 April 1990





ZDCHIN  is  central  to  many  of  these  changes  (see ZDCHI2 for UNIX

Systems).  Its purpose is largely two  fold.   First,  it  is  used  to

determine, in a machine independent fashion, many of the values for the

variables in the device characteristics common (i.e., /DCHCOM/).  These

``system  constants''  were  formerly  provided  by means of hard coded

assignment statements in  ZDCHIN.   ZDCHI2  eliminates  this  potential

source  of  installation  error,  however,  there are several that MUST

still be assigned manually (i.e., BYTFLP and NWDPLO) as  well  as  some

new  ones that MUST also be assigned manually (i.e., SPFRMT, DPFRMT and

NVOLSC).  Secondly, ZDCHI2 provides a means by  which  these  centrally

defined  system  constants can be made available to other C routines as

external variables.  It also  calculates  a  variety  of  other  useful

system  constants  which  are  also made available to other C routines.

These system constants have been  used  to  make  the  UNIX  Z-routines

highly generic regardless of host word size.







B.6.2  Changes Of Interest



     The changes  of  interest  to  the  UNIX  implementation  are  too

numerous to mention here.  A copy of the sections pertinent to the UNIX

implementation from the 15OCT87 AIPSletter should  accompany  the  UNIX

installation kits.  The following is just a summary.



     File locking has been introduced in the  UNIX  implementation  for

the 15OCT87 release.  The locking mechanism is not implemented for text

files since text file I/O  is  performed  using  FORTRAN  logical  unit

numbers  and  UNIX  file locking is limited to C file descriptors.  The

Berkeley and  Bell  UNIX  file  locking  techniques  are  substantially

different and we have no in-house implementation of AIPS on a Bell UNIX

system.  So, whereas the implementation for Berkeley UNIX  systems  has

been  well tested, the implementation for Bell UNIX systems should only

be regarded as a starting point for local development.  In  particular,

the  implementation  of  file locking for Bell UNIX systems is based on

the System V 2.0 mechanism which only allows ``exclusive'' locks.  This

will  not  suffice for AIPS since multiple opens are often performed on

the  same  file.   The  documentation  suggests  that  the  notion   of

``shared''  locks are supported under System V 2.0+, but we do not have

the resources to experiment with this at NRAO.  In any case, UNIX  file

locking mechanisms are currently only cooperative, not mandatory.



     The lengths of FORTRAN CHARACTER arguments as passed  to  routines

written  in  C  are  now  passed  explicitly in many of the Z-routines.

Ultimately, all such routines will  be  converted  to  this  technique.

These  lengths  are  normally ``extra'' arguments passed as part of the

FORTRAN/C procedure interface on UNIX systems.  Unfortunately, there is

no  standard  for  their position in the argument list (as we painfully

discovered on Alliant systems).  Passing these lengths  explicitly  has

reduced  the  number of Alliant specific Z-routines substantially (from

34 to 13) with room for further reduction.

RELEASE NOTES                                                  Page B-6

NOTES FOR THE 15OCT87 RELEASE                              9 April 1990





     As part of the effort to establish a generic set of Z-routines for

all  systems,  the  names of many of the lower level routines have also

been changed to something more generic.   In  previous  releases,  some

lower level routines had names of the form ZQ*, a reference to VMS QIO.

Others had names of the form  ZX*  which  implied  routines  that  were

required by the UNIX implementation but otherwise had no counterpart in

say, the VMS implementation.  A more generic naming convention has been

adopted whereby lower level routines have names similar to the names of

the higher level routines that call  them.   For  example,  ZEXIST  now

calls  ZEXIS2, which was formerly known as ZXXIST, and ZRENAM now calls

ZRENA2, which was formerly known as  ZQRENA.   Several  routines  still

have  the  old  fashioned  names  (e.g.,  ZQTRUN,  ZXTSPY), but will be

renamed to comply with the new convention as time permits.   It  should

be  noted  that  the  routines  that  have  been renamed in the 15OCT87

release also include those routines  which  almost  invariably  require

local  development.  Therefore, any extant local versions of these from

previous installations will have to be similarly renamed in order to be

compatible  with  the  calling  routines  of  the  15OCT87 release.  In

particular, these include ZXMOUN which is now known as  ZMOUN2,  ZQTAPE

which  is  now  known  as  ZTAP2,  ZXTPIO which is now known as ZTPMI2,

ZXFREE which is now known as ZFRE2, and ZXLPRT which is  now  known  as

ZLPCL2.   Calls  to  ZXTLOG  are also being replaced by calls to ZTRLOG

everywhere, but this process has not  been  completed  in  the  15OCT87

release.   Therefore, the routine ZXTLOG must still exist.  The routine

ZQASSN, which was formerly called  to  handle  the  actual  opening  of

Tektronix-like as well as tape and TV devices, has been replaced by the

routines ZTKOP2, ZTPOP2 and, for example, ZM70O2 for  these  respective

device types.



     Finally, the calling sequences of  several  lower  level  routines

have  been  changed.   These include ZEXIS2 which was formerly known as

ZXXIST, ZCREA2 which was formerly known as ZQCREA, ZM70M2 which now has

an  error  return  argument, ZM70X2 which was formerly known as ZTVQIO,

ZQMSCL which now has an argument for the length of the file name  being

passed,  ZTXMA2  which  was  formerly  known as ZPARS, ZTKFI2 which was

formerly known as ZTKQIO, ZPRI2 which was formerly known as ZPRIO2  and

ZFRE2 which was formerly known as ZXFREE.  Most of these involve highly

generic routines and any change in calling  sequence  should  cause  no

concern.   However,  the  difference  between  the calling sequences of

ZFRE2 and its predecessor ZXFREE should be  noted  since  this  routine

usually needs to be developed locally.







B.7  NOTES FOR THE 15JAN88 RELEASE



B.7.1  Introduction



     The 15JAN88 release was canceled.

RELEASE NOTES                                                  Page B-7

NOTES FOR THE 15JAN88 RELEASE                              9 April 1990





B.7.2  Changes Of Interest



     The 15JAN88 release was canceled.







B.8  NOTES FOR THE 15APR88 RELEASE



B.8.1  Introduction



     There are only minor differences between the 15OCT87  and  15APR88

releases.







B.8.2  Changes Of Interest



     ZTQSPY has been made generic.  It  now  calls  ZTQSP2  instead  of

ZXTSPY.   The  various  versions  ZXTSPY have not been removed from the

UNIX implmentation Z-routine directories, but they will  eventually  be

deleted.  Both $APLBELL and $APLBERK versions of ZTQSP2 exist which are

extremely simplified from the old ZXTSPY.  They simply invoke "ps"  via

"system"  using the appropriate Bell UNIX or Berkeley UNIX options.  No

attempt is made to parse the output of "ps" as was the case of ZXTSPY.



     Included source text handling has been changed in two ways.  It is

now  possible  for  users  to  define  their own search path (i.e., the

environment variable INCS), otherwise, the standard system search  path

is  used.  PP will issue warning messages if a non-standard search path

is being used.  SEARCH has also been modified to use  the  non-standard

search  path  in its determination of which form of a module is most up

to date.  SEARCH has  also  be  modified  to  test  for  newer  C-style

included  text  (i.e.,  files  specified in #include statements).  This

required a change to INCLUDES.SED.  The former versions of  SEARCH  and

INCLUDE.SED   have   been  preserved  in  $SYSUNIX  as  SEARCH.OLD  and

INCLUDES.OLD.



     The UNIX system and installation procedures have been modified  to

eliminate  incompatibilities  with System V UNIX.  In particular, "grep

-e" has been eliminated and "grep -s" has been worked around to achieve

the same effect.



     The programs (tasks) BAKLD, BAKTP (system utility backup),  KONTR,

OUTPLT  and  PRFPL (Zeta plotter oriented) have been moved to eliminate

them as problems for generic UNIX installations.  They may or  may  not

ever  reappear.   Similarly,  the  troublesome  external subroutines on

which some of the above depend have  been  moved,  including  ZBK*  and

COMPLOT.







B.9  NOTES FOR THE 15JUL88 RELEASE



RELEASE NOTES                                                  Page B-8

NOTES FOR THE 15JUL88 RELEASE                              9 April 1990





B.9.1  Introduction



     There are only minor differences between the 15APR88  and  15JUL88

releases,  mostly  the  elimination  of the constraint of having to run

AIPS from the AIPS account.







B.9.2  Changes Of Interest



     The program CHAIPS, formerly used to change the  ownership  and/or

set  the  effective  user  id  bit  of  executables  generated  via the

procedure LINK  to  that  of  the  AIPS  login,  has  been  eliminated.

Similarly,  the  routine ZXUID, which was formerly called by ZSTRTA and

ZSTRTB (only) and used to set the effective user id to that of the AIPS

login  at  execution  time, has also been eliminated.  As a result, the

former constraint of having to execute AIPS from  the  AIPS  login  has

been  eliminated.  The routine ZXMKTM has been replaced by ZMKTMP.  The

calling sequence of ZMKTMP is different from that of ZXMKTM.







B.10  NOTES FOR THE 15OCT88 RELEASE



B.10.1  Introduction



     The differences between  the  15JUL88  and  15OCT88  releases  are

rather  minor,  mostly changes to programming scripts to fix small bugs

or improve portability.







B.10.2  Changes Of Interest



     The "umask 000" command formerly executed in ASSNLOCAL.SH has been

moved  to  the  AIPS  startup  script  in preparation for the switch to

ASSNLOCAL.CSH to be executed at login time.



     A new option, called NOOPT, has been added to  the  compiling  and

linking  programming  scripts  that  is  intended to disable any of the

OPT[0-9] optimization levels you might otherwise get and to enable  any

host  compiler  options that are necessary to suppress all optimization

and enhance source code debugging.



     The extraction of many of the common routines in the TESS*  family

of tasks into external modules required that an additional cycle of the

QNOT object library be inserted in the link list  for  tasks  from  the

$QYPGNOT area.



     The  use  of  the  Berkeley  UNIX  specific  "ps  -#pid"  in   the

$SYSUNIX/LIBR script has been replaced with "kill -0 pid".

RELEASE NOTES                                                  Page B-9

NOTES FOR THE 15OCT88 RELEASE                              9 April 1990





     The problem in the $SYSUNIX/LIBR and $SYSUNIX/LINK  scripts  where

"arg  list  too  long"  errors occurred for large number of $LIBR/*/*.o

files has been fixed.



     In $SYSUNIX/MAKEAT, the superfluous "-type  f"  in  the  predicate

list  of  the "find" command has been eliminated so that symbolic links

(Berkeley UNIX) can be found.



     In  $INSUNIX/INSTEP2,  "chmod  777"  has  been   added   for   the

directories  containing  binary files (i.e., AIPS data files and object

code).  A loop has also been  added  to  $INSUNIX/INSTEP2  for  testing

whether  all  object  libraries that depend on a given source code area

have been built (i.e., not just the library used to build  the  default

LOAD area executables) before skipping the compilations for that area.



     A new script called FSC has been added to the $SYSUNIX area.   FSC

performs an "fsplit" compilation that is often the only work-around for

internal compiler errors on task compilations.



     The auto-editing of "@" files in all programming scripts that  use

such  files  has  been  changed  from  using  "ed"  to using "sed" plus

temporary files.







B.11  NOTES FOR THE 15JAN89 RELEASE



B.11.1  Introduction



     The differences between  the  15OCT88  and  15JAN89  releases  are

rather minor, mostly small changes to Z-routines to fix bugs or improve

portability.







B.11.2  Changes Of Interest



     The AIPS programming  ``logical''  $SYSTEM  has  been  renamed  to

$SYSAIPS  and  for  the  first  time,  files  are  being stored in this

directory.



     The optional 3rd argument has been added as a  dummy  argument  to

the call to ``setitimer'' in the $APLBERK version of ZDELA2 which makes

it work on Alliant systems.  This now gives millisecond time resolution

on execution delay requests on Alliant systems.



     An ``obsolete'' C construct has been replaced in the  $APLBERK  of

ZTKCL2  which  seems to cure the hung Tektronix device problem reported

on some systems.



     The ``statfs'' function  has  been  implemented  in  the  $APLBERK

version  of  ZCREA2  which  means  a check for sufficient space is done

prior  to  attempting  to  create  the  requested  file.    A   similar

implementation  may  be  possible  for  System V based systems by using

RELEASE NOTES                                                 Page B-10

NOTES FOR THE 15JAN89 RELEASE                              9 April 1990





``ustat''.



     A test for ``errno == EPERM'' (i.e., not owner) after the call  to

``kill  (0,  pid)''  has  been added to indicate that the process id is

active.  This may clear up the problem of multiple  executions  of  the

same program under the same POPS number reported by some sites.







B.12  NOTES FOR THE 15APR89 RELEASE



B.12.1  Introduction



     Given the AIPS group's preoccupation with  the  protracted  source

code overhaul, there are no substantive differences between the 15JAN89

and 15APR89 releases.   15JUL89  is  targeted  as  the  first  publicly

available  release of the overhauled or "new" AIPS.  Sites are STRONGLY

encouraged to update to the "new" AIPS as soon as  possible.   The  DDT

procedures,  however,  have  been modified to use CCMRG and a new, high

dynamic range dataset for the large case.  CCMRG is used to merge clean

components  prior  to  the  ASCAL  step.  The intent is to speed up the

"large" case ASCAL problem which has always dominated execution time in

the  past.   A  new DDT master tape has been generated and is available

for certifying and benchmarking installations.







B.12.2  Changes Of Interest



     The routine ZSTRTP is now  being  called  by  $AIPGUNIX/ZSTRTA  to

establish  the  execution  priority of the current process based on its

POPS number and  determined  by  the  existence  and  definition  of  a

corresponding  PRIOn  environmnent variable.  For example, if $PRIO5 is

"-5", then ZSTRTA will attempt to  startup  AIPS1  with  priority  "-5"

(NOTE:   elevating  priority  requires  superuser privilege which means

$LOAD/ZSTRTA.EXE must be owned by "root" with its effective user id bit

set).   If  no  such PRIOn environment variable is defined, ZSTRTP does

nothing.  Also, if elevated priority is requested and  $LOAD/ZSTRTA.EXE

is  not  privileged,  ZSTRTP  issues  a message to this effect and does

nothing.







B.13  NOTES FOR THE 15JUL89 RELEASE



B.13.1  Introduction



     The 15JUL89 release, orginally targeted as the  first  release  of

the overhauled or "new" AIPS, was canceled (sigh).

RELEASE NOTES                                                 Page B-11

NOTES FOR THE 15JUL89 RELEASE                              9 April 1990





B.13.2  Changes Of Interest



     Don't worry.  Be happy.







B.14  NOTES FOR THE 15OCT89 RELEASE



B.14.1  Introduction



     The 15OCT89 release is the first publicly available release of the

overhauled system.







B.14.2  Changes Of Interest



     No more #%!$@ INTEGER*2 (and hardly any hollerith  data  anymore).

Lots  of  other  changes  too  numerous  to  mention  (see  memo titled

"Conversion of Old  AIPS  Software  to  Run  Under  15OCT89  and  Later

Releases"  which  should  accompany  installation kits for the next few

releases).  There is ONLY one way to convert  data  on  disk  generated

from  previous  releases to the new data format required by the 15OCT89

release.  This is by writing the old data to tape using FITTP under the

old  system,  then  read  the  data from tape into the new system using

IMLOD or UVLOD.   The  overhauled  code  runs  about  as  fast  as  the

pre-overhauled code.  The AIPS group has been reorganized.







B.15  NOTES FOR THE 15JAN90 RELEASE



B.15.1  Introduction



     The differences between  the  15OCT89  and  15JAN90  releases  are

rather  minor, mostly changes in how area logicals are defined and some

minor changes to the directory structure and LOGIN.* procedures.







B.15.2  Changes Of Interest



     $SYSUNIX/AREAS.CSH and $SYSUNIX/AREAS.SH  are  pre-generated  from

$SYSAIPS/AREAS.DAT and should not be modified.  Local area logicals are

no longer defined in the AREAS.* files, but  in  the  $SYSLOCAL/CDVER.*

files these days (see "Local Area Logicals").



     Many of the areas logicals for never-used  directories  and  which

only  served  to  clutter  up  the  environment,  have  been eliminated

including $APLNUNIX, $QPGUNIX, $QYPGUNIX and $YPGUNIX.  These have also

been  eliminated  from the distributed LIBR.DAT files and should not be

included in the local LIBR.DAT as of the 15JAN90  release.   Otherwise,

some of the AIPS programming procedures will fail.

RELEASE NOTES                                                 Page B-12

NOTES FOR THE 15JAN90 RELEASE                              9 April 1990





     The LOGIN.* login procedures have also been  modified  to  include

more  area  logical  definitions and to define device logicals at login

time, rather than when the startup procedures AIPS, BATER  or  RUN  are

invoked.   The  latter  may  cause environment saturation problems.  In

addition to the 15MMMYY directory tree, a TEXT directory tree  is  also

contained  on  the  distribution  tape.  This tree contains directories

that are not version specific and were formerly stored under  $DOC  and

with  the  area  logicals  $DOCGRIP,  $DOCPUBL and $DOCWHO, but are now

defined as $AIPSGRIP, $AIPSPUBL  and  $AIPSWHO,  respectively,  in  the

LOGIN.* procedures , all of which are distributed as empty directories.

However, a brand new directory  (TEXT/IONS)  defined  as  $AIPSIONS  at

login  time, contains data files for use in corrections for ionospheric

effects.



     A directory structure change was  made  to  eliminate  a  conflict

induced  by  the  program  directory  $YVTVPGM  being located beneath a

subroutine directory $YVTV.   The  directory  $YVTV/PGM  (area  logical

$YVTVPGM)  has  been  moved  to  $YPGM/VDEV  (area  logical  $YPGVDEV).

Formerly, INSTEP2 would pick up $YVTVPGM  programs,  compile  them  and

stage   them  for  inclusion  in  some  of  the  $LIBR/*/SUBLIB  object

libraries.  This caused all sorts of installation problems.



     The procedure SEARCH has  been  made  a  factor  of  4  faster  by

replacing calls to "test" with Bourne shell "case" constructs.







B.16  NOTES FOR THE 15APR90 RELEASE



B.16.1  Introduction



     The most important changes since the 15JAN90 release  involve  the

login procedures, when device logicals are established and the start-up

procedures.  Some changes have also been  made  to  the  abort  handler

routines.







B.16.2  Changes Of Interest



     The definition of the execution search path (i.e., $PATH)  in  the

LOGIN.* and CDVER.* scripts has been changed to put the current working

directory followed by $SYSLOCAL followed by $SYSUNIX at the  beginning.

Formerly,  $SYSLOCAL  and  $SYSUNIX were at the end.  The rearrangement

should avert problems command name conflicts that arise sometimes  from

"local"  utilities.   These  days for example, a common conflict is CC,

the name of the AIPS C compilation procedure as well as the name  of  a

freeware C++ translator.



     The definition of local device logicals  has  been  moved  to  the

        s
LOGIN.  scripts  (i.e.,  ".   $SYSLOCAL/ASSNLOCAL.SH"  in  LOGIN.SH and

"source      $SYSLOCAL/ASSNLOCAL.CSH"      in      LOGIN.CSH).       ".

$SYSLOCAL/ASSNLOCAL.SH  has  been  removed  from  all  the  distributed

versions of startup procedures (i.e., AIPS, BATER, RUN, etc.).

RELEASE NOTES                                                 Page B-13

NOTES FOR THE 15APR90 RELEASE                              9 April 1990





     Several new Q-routines have been  added  to  all  the  distributed

versions of OPT2.LIS.



     A "make" file  $YSVU/MAKEFILE  has  been  added  to  simplify  the

generation of the SSS executable.



     The text  of  $SYSSUN/SSS.TXT  has  changed  with  respect  to  TV

parameters.



     The $APLSUN version of ZABOR2.C has been changed  to  handle  IEEE

floating-point exceptions differently.  Otherwise, some invalid numbers

get through unnoticed.  Exceptions should be reported as bugs.



     The routine ZABORS has been changed to eliminate the  preservation

of "core" files and the core file preservation script, $SYSUNIX/ZABOR2,

has been deleted.



     A special version of the ZLASCL script called ZLASCL.PS  has  been

created  in  $SYSUNIX  for spooling LWPLA output to PostScript printers

(i.e., it needs to be copied to $SYSLOCAL/ZLASCL and made executable).

























                              APPENDIX C



                         SYSTEM SPECIFIC NOTES







C.1  INTRODUCTION



     Not all UNIX systems are equal and NRAO supports some better  than

others  (i.e.,  Berkeley  UNIX,  Convex  and Sun), largely because NRAO

can't afford one of everything.  The notes below may be somewhat  dated

and  many  of  the  problems will have been resolved as a result of the

source code overhaul (i.e., 15OCT89 and later releases).  However,  you

may  still  be  able  to glean some solutions to problems you encounter

from the notes below.







C.1.1  System V



     Although the earliest (1982-85) ports of AIPS to UNIX environments

at  NRAO  were  done  under Bell UNIX (Version 7 and System III), since

about 1986, UNIX/AIPS  development  has  been  dominated  by  ports  to

Berkeley  UNIX  platforms.  Our System V experience is therefore rather

dated and  the  routines  in  the  $APLBELL  branch  of  the  Z-routine

directory  tree  should be regarded as suspect.  However, most System V

oriented  platforms  support  Berkeley  UNIX  extensions  these   days.

Including the $APLBERK directory in the host search path for Z-routines

(i.e.,  in  $SYSLOCAL/LIBR.DAT)  or  otherwise  substituting   $APLBERK

routines  for  selected  $APLBELL  (e.g.,  ZLOCK.C)  or $APLUNIX (e.g.,

ZCMPR2.C,  ZTXMA2.C)  routines  ``may''  resolve   porting/installation

                                                    .
problems.   Also,  the  $APLBERK  versions  of  ZVTV.C (which depend on

Berkeley UNIX ``sockets'' for the Virtual TV implementation) may work.



     The procedure $SYSUNIX/LIBR has a reference to "ranlib" which does

not  exist  under  System  V.   The  simple  work  around  is to "touch

$SYSLOCAL/ranlib" and "chmod $SYSLOCAL/ranlib".  Alternatively, make  a

copy  of  $SYSUNIX/LIBR  in  $SYSLOCAL  and  modify it to eliminate the

reference to "ranlib".  You may also want  to  convert  the  loop  that

performs  "ar" for each object module into a wild-card expression using

"xargs" to avoid "arg list too long" errors.  A special version of LIBR

for System V platforms may be provided in the future.

SYSTEM SPECIFIC NOTES                                          Page C-2

INTRODUCTION                                               9 April 1990





C.1.2  Alliant Systems



     We have ported AIPS to Alliant FX/series  machines  several  times

now  and  the following is based on our most recent Alliant experience.

That is, September 1988 using AIPS release 15APR88 with FORTRAN 3.1.33,

libmath_v4.0,  striped  disk,  ACEs  and  System Configuration for FX80

supermkt (serial # 109 ):

   Memory Size   = 96 Mb

   CE-Cache Size = 512 Kb

   User Memory   = 90.6 Mb

   Paging File   = 134.1 Mb

   Swapping File = 109.7 Mb

   Number of IPs = 6

   M012/M020/VME = 0/0/6

   Number of CEs = 8

   Detach/Attach = 0/8



     1) For single CE  configurations,  Q-routines  and  those  modules

listed in $SYSCVEX/OPT2.LIS (yes, $SYSCVEX) should probably be compiled

with optimization level "-Ogv -DAS".  All  other  FORTRAN  code  should

probably be compiled "-Og -DAS".



     2) For  multi-CE  configurations,  Q-routines  and  those  modules

listed in $SYSCVEX/OPT2.LIS (yes, $SYSCVEX) should probably be compiled

with optimization level "-O -DAS -alt".  All other FORTRAN code  should

probably  be  compiled  "-Ogv -DAS".  Compiling all code "-O -DAS -alt"

does not seem to  improve  performance  significantly  and  results  in

execution  errors  in  a  few  routines  (i.e., $APLSUB/PASENC, ZR32RL,

XRLR32, ZR64RL ZRLR64 and probably others that were  not  exercised  by

our "Dirty Dozen Test").



     3) In multi-CE configurations with detached singleton  CEs,  those

programs  NOT  involving concurrent or vector/concurrent code (e.g., no

Q-routines or $SYSCVEX/OPT2.LIS  modules)  should  probably  be  linked

using  the  "-nc"  option  which prevents them from executing on the CE

cluster.  It may be easiest to  make  OPT0="-nc"  with  LINK="-v  $OPT0

$DEBUG"  in  LDOPTS.SH and relink the smaller number of programs you DO

want to execute on the CE cluster via "LINK NOOPT0 <module>.o".



     4) The WHNALT.o file found in $QALN was derived  from  proprietary

Alliant  source code that we cannot distribute.  WHNALT.o should always

be incorporated into your pseudo AP object  library.   WHNALT  is  only

called by $QALN/QCLNSU.FOR.



     5) The WHNALT routine has been known to fail in  a  data-dependent

fashion  (e.g.,  the DDT "large" case APCLN problem) on Alliant systems

configured with ACEs.  WHNALT has worked for years without problems  on

CE  configured  Alliants.   The modified version of QCLNSU below can be

used as a workaround (i.e., in place  of  $QALN/QCLNSU.FOR)  until  the

problem  can  be  resolved.   The  problem is that sometimes one of the

values in the array  of  indices  returned  by  WHNALT  is  zero.   The

workaround  simply  checks for this condition and if so, recalls WHNALT

(see kludge immediately following statement label 110).



SYSTEM SPECIFIC NOTES                                          Page C-3

INTRODUCTION                                               9 April 1990





      SUBROUTINE QCLNSU (COMP, LMAP, L1MAP, L2MAP, IBX, IBY, JNDEX,

     *   INDEX)

C-----------------------------------------------------------------------

C   QCLNSU does a CLEAN on a list of residuals using a given beam

C   patch

C    Inputs:

C      COMP(4)  R*4  Component vector:

C                 0 => intensity

C                 1 => x in cells

C                 2 => Y in cells

C                 3 => CLEAN loop gain (fractional)

C      LMAP     I*4  number of residuals

C      L1MAP    I*4  First residual in Y window

C      L2MAP    I*4  Last residual in Y window

C      IBX,IBY  I*4  Beam patch half width in X and Y

C                    Residuals with delta X or Y from the component

C                    position in COMP .GE. IBX,IBY are to be ignored.

C      JNDEX    I*4  0 - rel Index in FLUX, IX, IY of next residual

C                    to sub.

C   Input From Vector Work common:

C      IWVEC3   I*4  = IX, X pixel location of residuals

C      IWVEC4   I*4  = IY, Y pixel location of residuals

C      WKVEC5   R*4  = FLUX, Residual flux density

C      WKVEC6,7 R*4  = BEAM, BEAM patch.

C   Output:

C      INDEX    I*4  Index in FLUX of next residual.

C   Useage notes:

C     The following common work vectors are used:

C      IWVEC8   = IDXRAY  => array of x pixel offsets

C      IWVEC9   = IB      => indirect address array

C

C   Alliant version (same as Convex version).

C-----------------------------------------------------------------------

      INTEGER*4 ISAMAX, KMAX, INCX, IDXRAY(1), IB(1), IX(1), IY(1)

      INTEGER*4 L21MAP, NIB, JNDEX

      INTEGER*4 LMAP, IBX, IBY, L1MAP, L2MAP, INDEX, BOFF, BEMADR,

     *   LROW, ADDR, LOOP, XCOMP, YCOMP, N1

      LOGICAL   RECALL

      REAL*4    SUBT, COMP(4), BEAM(1), FLUX(1)

      INCLUDE 'INCS:DAPC.INC'

      INCLUDE 'INCS:CAPC.INC'

      INCLUDE 'INCS:EAPC.INC'

      EQUIVALENCE (IX, IWVEC3), (IY, IWVEC4), (FLUX, WKVEC5),

     *   (BEAM, WKVEC6)

      EQUIVALENCE (IDXRAY, IWVEC8), (IB, IWVEC9)

      DATA N1 /1/

C-----------------------------------------------------------------------

      LROW = 2 * IBY - 1

      BOFF = (IBX-1) * LROW + IBY

      IF (LMAP.LE.0) GO TO 999

C                                        Get component to be CLEANed

      XCOMP = COMP(2) + 0.5

      YCOMP = COMP(3) + 0.5

      SUBT = COMP(1) * COMP(4)

SYSTEM SPECIFIC NOTES                                          Page C-4

INTRODUCTION                                               9 April 1990





C                                       Get residual offsets

      INCLUDE 'INCS:ZVND.INC'

      DO 100 LOOP = L1MAP,L2MAP

         IDXRAY(LOOP) = IX(LOOP+JNDEX) - XCOMP

 100     CONTINUE

C                                        Compress x window

      L21MAP = L2MAP - L1MAP + 1

 110  CALL WHNALT (L21MAP, IDXRAY(L1MAP), N1, IBX, IB, NIB)

C                                       Kludge to get around Alliant

C                                       ACE "bug" where WHNALT may

C                                       return a zero value in the array

C                                       of indices (i.e., IB).  If so,

C                                       recall WHNALT.

      RECALL = .FALSE.

      DO 120 LOOP = 1,NIB

         IF (IB(LOOP).EQ.0) RECALL = .TRUE.

 120     CONTINUE

      IF (RECALL) GO TO 110

C                                        Subtraction loop

      INCLUDE 'INCS:ZVND.INC'

      DO 200 LOOP = 1,NIB

         ADDR = IB(LOOP) + L1MAP - 1

C                                        Get beam address

         BEMADR = BOFF + (IDXRAY(ADDR) * LROW)

     *      + (IY(ADDR+JNDEX) - YCOMP)

         FLUX(ADDR+JNDEX) = FLUX(ADDR+JNDEX) - SUBT * BEAM(BEMADR)

 200     CONTINUE

C                                        Find largest mag. residual

      INCX = 1

C                                       Call Alliant provided Linpack

C                                       routine = ISAMAX.

      KMAX = ISAMAX (LMAP, FLUX(1+JNDEX), INCX)

      COMP(1) = FLUX (KMAX+JNDEX)

      COMP(2) = IX(KMAX+JNDEX)

      COMP(3) = IY(KMAX+JNDEX)

C                                        Save index of next max.

      INDEX = KMAX

C

 999  RETURN

      END





     6) The call of $QALN/SCFFT.o by $QALN/QCFFT.FOR has been  replaced

by  a  call  to  CFFT1D  from Alliant's libmath.a.  Both QCLNSU.FOR and

QMULCL.FOR in $QALN still call ISAMAX, but Alliant's  libmath.a  should

now contain this BLAS level 1 LINPACK routine.  The line "-lmath:  ..."

should appear in the link lists (as defined in $SYSLOCAL/LIBR.DAT)  for

all   programs   linked   with   the   Q-routine  object  library  (see

$SYSALLN/LIBR.DAT).  The former ISAMAX.o and SCFFT.o  as  well  as  the

versions of QCFFT.FOR that call CFFT and SCFFT have been saved in $QALN

as ISAMAX.O, SCFFT.O, QCFFT.CFFT and QCFFT.SCFFT, respectively, just in

case  your  Alliant's  libmath.a does not contain ISAMAX or CFFT1D yet.

Let us know, otherwise we will  eventually  delete  ISAMAX.O,  SCFFT.O,

QCFFT.CFFT and QCFFT.SCFFT.

SYSTEM SPECIFIC NOTES                                          Page C-5

INTRODUCTION                                               9 April 1990





C.1.3  Convex Systems



     NRAO has 3 Convex C-1s that serve as  AIPS  work  horses,  one  in

Charlottesville  configured  with  both an IIS model 70E and IVAS image

display device and two at the VLA, one configured  with  an  IIS  model

70E.  All three are configured with several Gbytes of striped disk.  As

of the 15OCT89 release, we are running  AIPS  compiled  with  the  IEEE

floating-point  selected via the "-fi" compiler switch.  Since the only

way to migrate disk data generated under releases prior to  15OCT89  to

later  releases  is  by  writing  it  to tape using FITTP under the old

system, then reading it from tape using IMLOD or UVLOD  under  the  new

system,  this is an opportune time to switch to IEEE floating-point (if

you haven't already and you have the necessary hardware).  AIPS is also

in production on other Convex models including the C-2 series, however,

we are unaware of any installations that  take  advantage  of  parallel

processing (any volunteers?).



     1) The $SYSCVEX directory contains a number of files used in  AIPS

programming  that are setup for Convexes.  These files should be copied

to your $SYSLOCAL directory instead of the versions found in  $SYSUNIX.

The  $SYSNRAO1  and $SYSVLAC1 directories are the $SYSLOCAL directories

for  the  NRAO-CV  and  NRAO-VLA  Convex  C-1s,  respectively.    These

directories may also contain files of interest to other Convex sites.



     2) The $APLGEN versions  of  ZR32RL,  ZR64RL,  ZRLR32  and  ZRLR64

should  suffice  for  either  "native"  (quasi-VAX  F) or IEEE floating

point.  Just make sure SPFMRT and DPFRMT are set properly in ZDCHI2 and

the  proper  compiler/loader  floating-point option is selected via the

$SYSLOCAL/*OPTS.SH files (i.e., "-fi" for IEEE, "-fn" for "native").



     3) The routine QRECT.S in the directory $QVEX will  now  work  for

either "native" or IEEE floating-point.



     4) You should imitate the MT0x  environment  variable  definitions

found  in  the $SYSNRAO1 and $SYSVLAC1 versions of ASSNLOCAL.SH if tape

allocation is enabled on their system (i.e., "tpalloc/tpdealloc").   If

not,  the  $APLCVEX  version  of  ZMOUN2.C  should  copied to the local

Z-routine directory and modified to  eliminate  the  use  of  "tpalloc/

tpdealloc"  and  the  definition  of the MT0x environment variables via

ZCRLOG.



     5) The Convex FORTRAN compiler "fc" contains a bug in version  5.0

which involves a new feature called "global register allocation".  This

bug is NOT fixed in version 5.1, but should be fixed  in  version  5.2.

Until then, it is suggested that you use the undocumented compiler flag

"-ngr" when compiling code with the optimization flags "-O1"  or  "-O2"

level,  for  example,  Q-routines  (see $SYSCVEX/OPT2.LIS).  Otherwise,

incorrect results are possible.







C.1.4  Cray Systems



     The port of AIPS to UNICOS  (based  on  System  V  UNIX)  on  Cray

SYSTEM SPECIFIC NOTES                                          Page C-6

INTRODUCTION                                               9 April 1990





Research,  Inc.  systems is still in a high state of flux, however, the

partial implementation is included on the  15APR90  distribution  tape.

Two  X-MP/416 systems have been involved in NRAO's efforts, one at Cray

Research, Inc.  running UNICOS 5.0.13 followed by 5.1.8, the  other  at

the  Minnesota  Supercomputing  Center  running UNICOS 5.0.?  There are

differences in the level  of  Berkeley  UNIX  extensions  supported  in

respective  versions  of UNICOS that affect several Z-routines.  Cray 2

systems may have different requirements.



     See $SYSCRI/0README.







C.1.5  Sun Systems



     The NRAO has a number of Sun 3 systems  on  which  AIPS  has  been

installed,   all   configured   with  Motorola  MC68881  floating-point

coprocessors.  AIPS, however, is not currently  being  used  in  public

production  mode  on  any  of  these  machines.   As  a  result, NRAO's

execution experience is somewhat  limited.   The  following  notes  are

based  on  our  own experiences as well as that of others, however, the

majority of our experience is under SunOS 3.x (we just made it to 4.0.3

not  too  long ago).  Perhaps by the next release, we will have come up

to speed with SunOS 4.1.  Many of the  problems  cited  here  "may"  be

remedied    by    the   protracted   and   long   overdue   AIPS   code

overhaul/modernization.  The first publicly available  release  of  the

overhaul system the 15OCT89 version (15JUL89 was canceled).  Others are

due to problems in the Sun operating systems and/or  compilers.   Sites

are  encouraged  to  report any additional problems they experience and

any work arounds they may have found.  Please specify which release  of

AIPS  (e.g., 15APR90) as well as which model of Sun (e.g.  Sun 3 versus

Sun 4) is involved as well as which release of SunOS (e.g., 4.0.3)  and

FORTRAN compiler (e.g.  FORTRAN 1.2) is involved.



     1) As of SunOS 4.0, the  Sun  FORTRAN  compiler  is  an  unbundled

product.   The  sample file $SYSSUN/FCOPTS.SH reflects the old compiler

options, which may  not  be  appropriate  for  the  new  compiler.   In

general,  Q-routines  should be compiled using the highest optimization

level available (e.g., "-O3").  A very conservative optimization  level

should be used for all else (e.g., "-O1")



     2) OS 3.5 "f77 -O"  compilations  can  get  into  infinite  loops.

Compilations  that  apparently succeed can nevertheless yield execution

errors (e.g., infinite loops, bus  errors).   What  little  performance

improvement  you  get from "-O" optimization (about 10-20%) is probably

not worth either the installation or execution problems it  can  cause.

Compiling  "f77  -P" also fails on a handful of modules and is probably

even less worthwhile to pursue.  A  very  important  exception  to  the

above  is  the Q-routine library which should always be compiled at the

highest optimization level possible.  Modules written in C are also  an

exception   and   can  be  safely  compiled  using  "cc  -O".   Perhaps

non-Q-routine FORTRAN code  can  also  be  safely  compiled  at  higher

optimization levels after the AIPS code overhaul is complete.

SYSTEM SPECIFIC NOTES                                          Page C-7

INTRODUCTION                                               9 April 1990





     3) On Sun 3 systems, special care  should  be  taken  to  properly

define the default floating point compiler option for f77.  This may be

done either by defining the environment variables COMP and LINK in your

local versions of FCOPTS.SH and LDOPTS.SH, respectively, to include the

the desired floating  point  option  or  by  defining  the  environment

variable   FLOAT_OPTION   as   part   of  your  login  procedure.   The

documentation for f77 describes the  various  floating  point  options.

NRAO's  first  hand  experience  is limited to "-f68881" and AIPS ports

well under this option.  The  default  option  is  "-fsoft"  which  has

problems.   This  is  not  the  preferred option anyway.  Most Suns are

configured  with  at  least   the   Motorola   MC68881   floating-point

coprocessor.   No  serious  problems have been reported with the "ffpa"

option.  This option is, of course, highly desirable for AIPS code,  in

particular  for  the  Q-routines,  but  is  only meaningful for systems

configured with a floating point accelerator.  Such sites have reported

performance enhancements of 4-5x on compute intensive tasks such as MX,

making the modestly priced FPA quite a bargain.   Our  experience  with

the "-fswitch" option indicates that it is probably safe, but generates

slow code (about 2x slower).



     4) Under OS 4.0, program LINK's may fail with "_units  undefined".

The   following  will  probably  suffice  as  a  work  around.   Create

$SYSLOCAL/SYSTEM.C containing:

          system_(s,n)

          char *s;

          int n;

          {

              system(s);

              return;

          }



     then CC $SYSLOCAL/SYSTEM.C and modify $SYSLOCAL/LDOPTS.SH  to  say

LINK="$DEBUG $SYSLOCAL/SYSTEM.o /usr/lib/libc.a"



     5) There is a change in the fpa floating-point exception  handling

as of OS 4.0.  In $APLSUN/ZABORS.C, the call to "sigfpe_handler" should

be changed to a call to "fpa_handler".  On Sun 4 systems, the reference

to "sigfpe_handler" (or "fpa_handler") should be eliminated entirely.



     6) Under OS 4.0, in $APLUNIX/ZTPCL2.C, errno 1 (not owner)  occurs

while  closing the 2nd "dup'ed" (see $APLUNIX/ZTPOP2.C) file descriptor

for the tape drive.  The work around is to  copy  $APLUNIX/ZTPCL2.C  to

your   local  Z-routine  directory  and  simply  ignore  the  error  by

                                       i
commenting out the statement that sets ierr = 1, i.e.,



                                        /* Close second buffer file   */

                                        /* descriptor.                */

   fd = *(fcb + Z_mfcb + Z_fcbfd);

   if (close (fd) != 0 && *ierr == 0) {

      *(fcb + Z_mfcb + Z_fcberr) = errno;

/*

      *ierr = 1;

*/

      }

SYSTEM SPECIFIC NOTES                                          Page C-8

INTRODUCTION                                               9 April 1990









     DO NOT comment out the close statement itself.  Even though it may

return  an  error,  it  is  nevertheless  necessary.  It's curious that

$APLUNIX/ZDAOPN.C and $APLUNIX/ZDACLS.C  do  very  similar  open's  and

close's on disk files, but ZDACLS.C doesn't get this error.



     7) On some systems (perhaps only  those  with  Xylogics  472  tape

controllers),  the  routine ZTPMI2 fails on partial record reads (e.g.,

TPHEAD).  The workaround is to always read 32K bytes into  a  temporary

buffer  (i.e., despite the actual number of bytes requested), then copy

the actual number of bytes requested to the  output  buffer.   It  also

seems  to require compilation using the "-g" option (e.g., COMRPL DEBUG

..).  The following hack seems to work:



#include <errno.h>



ztpmi2_(oper, fcb, buff, nbytes, ierr)

/*--------------------------------------------------------------------*/

/*! read/write from/to a tape device                                  */

/*# IO-basic Tape                                                     */

/*--------------------------------------------------------------------*/
/*;  Copyright (C) 1995                                               */
/*;  Associated Universities, Inc. Washington DC, USA.                */
/*;                                                                   */
/*;  This program is free software; you can redistribute it and/or    */
/*;  modify it under the terms of the GNU General Public License as   */
/*;  published by the Free Software Foundation; either version 2 of   */
/*;  the License, or (at your option) any later version.              */
/*;                                                                   */
/*;  This program is distributed in the hope that it will be useful,  */
/*;  but WITHOUT ANY WARRANTY; without even the implied warranty of   */
/*;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the    */
/*;  GNU General Public License for more details.                     */
/*;                                                                   */
/*;  You should have received a copy of the GNU General Public        */
/*;  License along with this program; if not, write to the Free       */
/*;  Software Foundation, Inc., 675 Massachusetts Ave, Cambridge,     */
/*;  MA 02139, USA.                                                   */
/*;                                                                   */
/*;  Correspondence concerning AIPS should be addressed as follows:   */
/*;         Internet email: aipsmail@nrao.edu.                        */
/*;         Postal address: AIPS Project Office                       */
/*;                         National Radio Astronomy Observatory      */
/*;                         520 Edgemont Road                         */
/*;                         Charlottesville, VA 22903-2475 USA        */
/*--------------------------------------------------------------------*/
/*--------------------------------------------------------------------*/

/*  Read/write "nbytes" 8-bit bytes of data from/to a tape device     */

/*  using "map" I/O (i.e., double buffered, asynchronous I/O).        */

/*  Inputs:                                                           */

/*     oper     C*4    Operation code "READ" or "WRIT"                */

/*     fcb      I(*)   File control block for opened tape drive       */

/*     buff     I(*)   I/O buffer                                     */

/*     nbytes   I      Number of 8-bit bytes to be transferred        */

/*  Output:                                                           */

/*     ierr     I      Error return code: 0 => no error               */

/*                        2 => bad opcode                             */

/*                        3 => I/O error                              */

/*  Generic UNIX version - sysnchronous I/O actually, reports IO error*/

/*  but not End Of File                                               */

/*  SunOS 4.x partial record read bug fix version.                    */

/*--------------------------------------------------------------------*/

char oper[], buff[];

int *fcb, *nbytes, *ierr;

/*--------------------------------------------------------------------*/

{

                                        /* Offsets to entries in the  */

                                        /* file control blocks        */

   extern int Z_fcbfd, Z_fcbreq, Z_fcberr, Z_fcbxfr, Z_fcbsiz,

      Z_fcbsp1, Z_fcbsp2, Z_fcbsp3, Z_fcbsp4;



   extern int errno;

   int fd;

   register int i;

   char op[5], scratch[32767];

/*--------------------------------------------------------------------*/

SYSTEM SPECIFIC NOTES                                          Page C-9

INTRODUCTION                                               9 April 1990





   *ierr = 0;

                                        /* Form null terminated       */

                                        /* opcode.                    */

   for (i = 0; i < 4; i++)

      op[i] = oper[i];

   op[4] = '\0';

                                        /* Get file descriptor from   */

                                        /* the file control block as  */

                                        /* stored there by ZTPOP2.    */

   fd = *(fcb + Z_fcbfd);

                                        /* Record byte request in the */

                                        /* file control block.        */

   *(fcb + Z_fcbreq) = *nbytes;

                                        /* Also, zero error status &  */

                                        /* transfer count entries.    */

   *(fcb + Z_fcberr) = 0;

   *(fcb + Z_fcbxfr) = 0;

                                        /* Zero byte request just     */

                                        /* initiates double buffered  */

                                        /* I/O.                       */

   if (*(fcb + Z_fcbreq) != 0) {

                                        /* Perform the I/O and record */

                                        /* the # of bytes transferred */

                                        /* in *(fcb + Z_fcbxfr).      */

                                        /* Record the system error    */

                                        /* code (if any) in           */

                                        /* *(fcb + Z_fcberr).         */

/*

      if (strcmp (op, "READ") == 0) {

         if ((*(fcb + Z_fcbxfr) =

            read (fd, buff, *(fcb + Z_fcbreq))) == -1) {

            *(fcb + Z_fcberr) = errno;

            *ierr = 3;

            }

         }

*/

      if (strcmp (op, "READ") == 0) {

         if ((*(fcb + Z_fcbxfr) =

            read (fd, scratch, 32767)) == -1) {

            *(fcb + Z_fcberr) = errno;

            *ierr = 3;

         }

         else {

            if (*(fcb + Z_fcbxfr) > *(fcb + Z_fcbreq))

               *(fcb + Z_fcbxfr) = *(fcb + Z_fcbreq);

            for (i = 0; i < *(fcb + Z_fcbxfr) ; i++)

               buff[i] = scratch[i];

            }

         }

      else if (strcmp (op, "WRIT") == 0) {

         if ((*(fcb + Z_fcbxfr) =

            write (fd, buff, *(fcb + Z_fcbreq))) == -1) {

            *(fcb + Z_fcberr) = errno;

            *ierr = 3;

SYSTEM SPECIFIC NOTES                                         Page C-10

INTRODUCTION                                               9 April 1990





            }

         }

                                        /* Bad opcode.                */

      else {

         *ierr = 2;

         }

      }

                                        /* Exit.                      */

   return;

}





     8) See $SYSSUN/SSS.TXT for documentation regarding the Sun  Screen

Server TV implementation.

























                              APPENDIX D



                      UPDATING USER DATA FORMATS







D.1  INTRODUCTION



     If you have no previous installation of AIPS  in  production,  you

can totally ignore this chapter.  However, if you have existing data on

disk that was created with an older version of  AIPS,  the  formats  of

some  of  the  data  files may be incompatible with the newly installed

version of AIPS.  Thus, you  may  have  to  run  data  format  updating

programs  before  AIPS  can  read  your  old  data.   As of the 15APR86

release, we have made some changes that have simplified  this  updating

process.   There  was  no  15JAN86  release of AIPS and we made no data

format changes in the 15OCT85 release.  Therefore, all data created  by

15JUL85  and  later  releases  can  be  updated,  if  necessary, by the

execution of a single program called UPDAT.   For  data  created  under

releases  prior  to  the  15JUL85  release,  any  required  data format

conversions must be performed in a stepwise fashion up to  the  15JUL85

format  followed  by  the  execution  of  UPDAT  to  perform any format

conversions required since the 15JUL85 release.







D.2  UPDATING DATA TO THE 15JUL85 FORMAT



D.2.1  Introduction



     This section describes the method by which existing AIPS user data

files  older  than  15JUL85  can be updated to the 15JUL85 data format.

Each section describes how to bring the files up to date starting  with

data  from  an  IMMEDIATELY  PRECEDING  RELEASE.  If you have data from

several releases prior  to  the  15JUL85  release,  you  MUST  run  the

conversion  processes in a stepwise fashion for each release, in order,

starting from the release immediately after yours, up  to  the  15JUL85

release.   Then  you  must  follow  the  instructions  in the preceding

section for updating user data formats for AIPS  releases  15JUL85  and

later.   All  conversion  programs  from  all the previous releases are

provided  on  each  installation.   These  are  the  $AIPPGM/CATCH*.FOR

modules.

UPDATING USER DATA FORMATS                                     Page D-2

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





D.2.2  Updating Instructions For 15JUL84 Release (SAVE/GET Ver 6)



     IGNORE THESE INSTRUCTIONS UNLESS YOU  ALREADY  HAVE  AN  OLD  AIPS

RUNNING THAT YOU WANT TO CONVERT TO THE NEW FORMAT.



Principles:  This update involves no file structure  changes  over  the

15MAY84 release.  All files may be preserved if you choose.

UPDATING USER DATA FORMATS                                     Page D-3

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





D.2.3  Updating Instructions For 15OCT84 Release (SAVE/GET Ver 7)



     IGNORE THESE INSTRUCTIONS UNLESS YOU  ALREADY  HAVE  AN  OLD  AIPS

RUNNING THAT YOU WANT TO CONVERT TO THE NEW FORMAT.



Principles:  Once again, we have  found  it  necessary  to  make  major

changes in AIPS data files.  We have changed the internal format of the

clean component files, to the new  generalized  "table"  format.   This

should  give  us  added  flexibility  in  writing programs that need to

manipulate these files.  Also, we have changed two values in  the  file

header  of  the  catalog,  the  uv  group count and the number of clean

iterations to true I*4.  This required some changes  in  the  order  of

values in the header.



     This update requires running a file reformatting program,  CATCHT,

described  below.  After the update, your old AIPS system SHOULD NOT BE

USED.  Users should be prohibited from running it.



     The program to convert the data files to the new format is  called

CATCHT.   This program must NOT be run for the same data file more than

once.   CATCHT  will  be  compiled  and  linked  by  the   installation

procedure.   To  run  this program after the installation, login to the

AIPS account and type:



RUN CATCHT



The first prompt is:



USER & DISK NUMBERS TO DO (2I4,2I2) DEFAULT=    0 #### 1 #



where the values #### and # are the highest allowable user  number  and

the  highest  disk  volume  number.   The  part of the prompt (2I4,2I2)

reminds you to enter the numbers in the  FORTRAN  format  where  blanks

count.   In  other  words, to go from user number 1 to user number 1112

and do disk 3 only, enter



000111120303



If you enter a carriage return then the default numbers  shown  in  the

prompt  will  be  used.   These numbers include all users and all disks

that are known to AIPS (these numbers are set during the installation).

This is probably what you want to do for the first run of CATCHT.  When

you run CATCHT on any demountable packs, you will  want  to  limit  the

changes to the disk volume containing that pack.



     After you enter these numbers the program  will  update  all  data

files  printing  a progress report as it goes.  If there are large gaps

between two user numbers the program may not print anything for  a  few

minutes.



     Any data recovered from system backup tapes  (e.g.,  "tar"  tapes)

that  were  written before the installation of the new system will need

CATCHT run for the particular user number involved.  FITS tapes and IBM

format tapes will be converted to the correct format automatically when

UPDATING USER DATA FORMATS                                     Page D-4

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





restored to disk.



     The SAVE/GET version for the 15OCT84  AIPS  has  increased  to  7.

Since  no OLD version can be run because of the file format changes and

the old SG files do not work with the  new  AIPS,  all  SAVE/GET  files

(files of the form $DA01/SG*) should be deleted.

UPDATING USER DATA FORMATS                                     Page D-5

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





D.2.4  Updating Instructions For 15APR85 Release (SAVE/GET Ver 7)



     IGNORE THESE INSTRUCTIONS UNLESS YOU  ALREADY  HAVE  AN  OLD  AIPS

RUNNING THAT YOU WANT TO CONVERT TO THE NEW FORMAT.



Principles:  This update involves no file structure  changes  over  the

15OCT84 release.  All files may be preserved if you choose.



     If your current system is  older  than  15OCT84,  the  file  clean

component  file structure changes in that release will prevent you from

running an OLD and a NEW since both systems access the same data  area.

If you have an older system, you must update your current data files by

following the file structure update instructions for all releases  that

follow your current release.

UPDATING USER DATA FORMATS                                     Page D-6

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





D.2.5  Updating Instructions For 15JUL85 Release (SAVE/GET Ver 7)



     IGNORE THESE INSTRUCTIONS UNLESS YOU  ALREADY  HAVE  AN  OLD  AIPS

RUNNING THAT YOU WANT TO CONVERT TO THE NEW FORMAT.



Principles:  Once again, we have  found  it  necessary  to  make  major

changes in AIPS data files.  We have removed the image headers from the

catalog files (CA files) and put each header into  its  own  individual

file  (CB  files).   This  will  give  us  (as  yet  unimplemented) the

capability of allowing catalog files to  auto-expand,  rebuilding  lost

catalogs from the CB files and give us more flexibility on backups.



     This update requires running a file reformating  program,  CATCHA,

described  below.  After the update the your old version of AIPS SHOULD

NOT BE USED.  Users should be prohibited from running it.



     The program to convert the data files to the new format is  called

CATCHA.   This program must NOT be run for the same data file more than

once.   CATCHA  will  be  compiled  and  linked  by  the   installation

procedure.   To  run this program after the installation log on to AIPS

and type :



RUN CATCHA



The first prompt is :

USER & DISK NUMBERS TO DO (2I4,2I2) DEFAULT=    0 #### 1 #

where the values #### and # are the highest allowable user  number  and

the  highest  disk  volume  number.   The  part of the prompt (2I4,2I2)

reminds you to enter the numbers in the  FORTRAN  format  where  blanks

count.   In  other  words, to go from user number 1 to user number 1112

and do disk 3 only, enter



000111120303



If you enter a carriage return then the default numbers  shown  in  the

prompt  will  be  used.   These numbers include all users and all disks

that are known to AIPS (these numbers are set during the installation).

This is probably what you want to do for the first run of CATCHA.  When

you run CATCHA on any demountable packs, you will  want  to  limit  the

changes to the disk volume containing that pack.



     After you enter these numbers the program will update all  catalog

files  printing  a progress report as it goes.  If there are large gaps

between two user numbers the program may not print anything for  a  few

minutes.



     Any data recovered from backup tapes that were written before  the

installation  of the new system will need CATCHA run for the particular

user number  involved.   FITS  tapes  and  IBM  format  tapes  will  be

converted to the correct format automatically when read in.



     Determining if CATCHA has  been  applied  to  a  catalog  file  is

relatively  easy.  Change directory to $DA01 and type ls CB*.XXX (where

XXX is the user number in hexadecimal).  If any CB  files  exist,  then

UPDATING USER DATA FORMATS                                     Page D-7

UPDATING DATA TO THE 15JUL85 FORMAT                        9 April 1990





that  data set has been converted.  You can also type ls -l CA*.XXX and

look at the size of the catalog file.  The  new  size  should  be  much

smaller than the previous size.

UPDATING USER DATA FORMATS                                     Page D-8

UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO THE CU ... 9 April 1990





D.3  UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO THE CURRENT SYSTEM



D.3.1  Introduction



     As of the 15APR86 release, the disk  volume  field  of  data  file

names  was  replaced with a letter code indicating format version.  For

example, the 15JUL85 name for map file MA201501.221;1 has been  changed

in  the 15APR86 release to MAA201501.221;1.  This letter will increment

as we make future changes in AIPS file formats.  No data format changes

occurred  between  the  15JUL85  and  15OCT85 releases and there was no

15JAN86 release, so all data created by 15JUL85 and later releases  can

be converted by running a single program called UPDAT.







D.3.2  Data Format Changes Since 15JUL85



D.3.2.1  Data Version A (First Appears In 15APR86) -



     This change was in the file names of user data files.  The  volume

number encoded in the name was replaced with a version letter.







D.3.2.2  Data Version A (15OCT86) -



     No changes from 15APR86 except in SAVE/GET files.   No  conversion

is possible for these files (all SAVE/GET files will be lost).







D.3.2.3  Data Version B (15JAN87) -



     The format version has been changed, requiring UPDAT to be run  on

data  from  any previous version.  ANtenna files will be converted to a

new tables format and CC files will  also  be  somewhat  revised.   All

files will be renamed to version B.







D.3.2.4  Data Version B (15APR87) -



     There have been no further changes since the 15JAN87 release.







D.3.2.5  Data Version B (15JUL87) -



     There have been no further changes since the 15JAN87 release.

UPDATING USER DATA FORMATS                                     Page D-9

UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO THE CU ... 9 April 1990





D.3.2.6  Data Version B (15OCT87) -



     There have been no further changes since the 15JAN87 release.







D.3.2.7  Data Version B (15APR88) -



     There have been no further changes since the 15JAN87 release.







D.3.2.8  Data Version B (15JUL88) -



     There have been no further changes since the 15JAN87 release.







D.3.2.9  Data Version B (15OCT88) -



     There have been no further changes since the 15JAN87 release.







D.3.2.10  Data Version B (15JAN89) -



     There have been no further changes since the 15JAN87 release.







D.3.2.11  Data Version B (15APR89) -



     There have been no further changes since the 15JAN87 release.







D.3.2.12  Data Version C (15JUL89) -



     A new data format version was introduced with the 15JUL89 release,

however, the 15JUL89 release was canceled.







D.3.2.13  Data Version C (15OCT89) -



     15OCT89 is the first publicly available release of AIPS after  the

source  code  overhaul.  NOTICE:  Unlike previous format changes, there

is NO provision for in-place conversion of user  data  (i.e.,  via  the

program  UPDAT).   The ONLY way to convert data to the new format is to

write it to tape (e.g., using the task FITTP) under the  "old"  system,

then  read  it  back  onto  disk  under the "new" system using IMLOD or

UVLOD.

UPDATING USER DATA FORMATS                                    Page D-10

UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO THE CU ... 9 April 1990





D.3.2.14  Data Version C (15JAN90) -



     There have been no further  changes  since  the  15OCT89  release,

however,  see  "Data  Version  C  (15OCT89)"  for  updating  disk  data

generated under releases prior to 15OCT89.







D.3.2.15  Data Version C (15APR90) -



     There have been no further  changes  since  the  15OCT89  release,

however,  see  "Data  Version  C  (15OCT89)"  for  updating  disk  data

generated under releases prior to 15OCT89.







D.3.3  Running UPDAT



     The data conversion program UPDAT will convert files from  an  old

format  to  the  current  format  and  rename  it  to  the  proper name

containing the appropriate format code letter.  UPDAT knows which  file

names  have  which format by the letter code embedded in the file name,

so it is impossible to corrupt data by running UPDAT twice for the same

data.  The program UPDAT can be run with the following command:



RUN UPDAT



The program responds with the following prompt.



ENTER : 1=RANGE OF USERS, 2=USER NUMS IN TEXT FILE :



You can choose the user numbers for which you want to run UPDAT by  two

methods:   (1)  give  it  a  range  of  users,  or  (2)  set up a file,

$AIPS_VERSION/HELP/USERLIST.HLP, containing a list of user numbers, one

to  a  line.   If you choose (1) (a range of user numbers) you will get

the following prompt:



ENTER USER NUMBER RANGE. (DEFAULT=    1 4095)  :



Other default values may appear for your system.  To select the default

just  press  carriage  return.   If  you want to run it for a different

range enter two numbers on the same line  separated  by  at  least  one

blank.  Entry is free format.  You will get two more prompts:



ENTER AIPS DISK NUM RANGE (DEFAULT=  1  1)  :



ENTER OLDEST VERSION DATE AS 15MMMYY  (DEFAULT= 15OCT85 ) :



NOTE:  Although the prompt says 15OCT85, there were no changes  between

the  15JUL85  and 15OCT85 release, so the new update procedure actually

works with 15JUL85 data also (i.e., just let it default to 15OCT85).

UPDATING USER DATA FORMATS                                    Page D-11

UPDATING FROM 15JUL85 AND LATER DATA FORMATS TO THE CU ... 9 April 1990





     The program will then display a  summary  of  the  data  you  have

entered and give you a chance to re-enter.



USER NUMBER RANGE :     1  100

DISK RANGE        :     1    1

OLDEST DATA       : 15OCT85

ENTER : 1=I MADE A MISTAKE, REENTER; 2=CONTINUE :



At this point UPDAT will go through all user numbers that you specified

and  update  their  data.   UPDAT  may  be silent for a long time as it

searches though the range of user numbers without finding any data.

                                INDEX







AC* file, 1-13                      ASSNLOCAL.CSH, 2-17, 3-3, B-8,

accounting file, 1-13                   B-12

$AIPGUNIX, 4-12                     ASSNLOCAL.SH, 2-17, 3-3, B-8,

$AIPPGM, 4-12                           B-12

AIPS, 2-31

  account, 2-1                      BA* files, 1-13

  batch, 4-3                        BADDISK, 3-4

  DEBUG, 4-11                       batch error terminal/file, 3-7

  execution from private accounts,  batch queue files, 1-13

      2-1                           batch work files, 1-13

  execution priviledges, 2-1        $BATCH_OUT, 3-7

  interactive, 4-3                  BATER, 2-31

  REMOTE, 3-6 to 3-7                  start-up procedure, B-3, B-12

  start-up procedure, 4-9, B-3,     $BATERDBUGR, 4-11

      B-12                          BQ* files, 1-13

  versions, 1-3, 2-17               BYTFLP, 1-12, A-2 to A-3, B-5

$AIPSDBUGR, 4-11

$AIPSGRIP, B-12                     CANPL, 3-7

$AIPSIONS, B-12                     catalogs

$AIPSPUBL, B-12                       private, 4-3

$AIPSUB, 3-2                          public, 4-3

$AIPSWHO, B-12                      CC, 2-29, 2-31

Alliant systems                     CCOPTS.SH, 2-29, 2-33

  CFFT1D, C-4                       $CDOLD, $CDNEW, $CDTST, 2-3, 2-17

  ISAMAX, C-4                           to 2-18

  optimization levels, C-2          CDVER.CSH, 2-3, 2-5, 2-12, 2-33,

  QCLNSU, C-2                           B-11 to B-12

  SCFFT, C-4                        CDVER.SH, 2-3, 2-5, 2-12, 2-33,

  WHNALT.o, C-2                         B-11 to B-12

alternate                           CHAIPS, B-8

  link lists, 2-25                  CHARACTER arguments to C routines,

  load libraries, 2-25                  B-5

  object libraries, 2-23            check list, 2-33

$APGNOT, 4-12                       COMLNK, 2-23, 2-27, 2-31, 4-13

$APLGEN, 3-2                        compiler and loader options, 2-29

$APLNOT, 3-2                        COMRPL, 2-23, 2-27, 2-31, 3-2 to

$APLNUNIX, B-11                         3-3

$APLPGM, 4-12                       Convex systems

$APLSUB, 3-2                          floating-point options, C-5

ar, 2-22, 2-24, 3-3                   global register allocation, C-5

area logicals, 2-5                    IEEE floating-point, C-5

  local, 2-12                         tape allocation, C-5

AREAS, 2-5

AREAS.CSH, 2-3, 2-5, B-11           $DA0*, 3-3

AREAS.DAT, 2-5, 2-12, B-2, B-11     data areas, 3-3

AREAS.SH, 2-3, 2-5, B-11            data format revision level, 4-3

AREASCSH.SED, 2-5                       to 4-4

AREASSH.SED, 2-5                    /DCHCOM/, A-2, B-5

AS, 2-29, 2-31                      DDT, 1-13, B-10

ASOPTS.SH, 2-29, 2-33               $DEBUGR, 4-11

                                    default

  file creation permissions         INSTEP4, 1-13, 3-1, 4-12

    umask, 2-1, B-8

  login shell, 2-1                  KNTR, 3-8

DEV directories, 1-7

  Q-routines, 1-9                   LDOPTS.SH, 2-29, 2-33, 4-13

  Y-routines, 1-8                   $LIBR, 2-22 to 2-23, 3-2

  Z-routines, 1-7                   LIBR, 2-24, 2-27, 2-31, 3-3, B-9,

device logicals, 3-3, B-12              C-1

directory structure, 1-2            LIBR.DAT, 2-18, 2-24, 2-27, 2-33,

  new, 1-2                              3-1 to 3-2, B-2, B-11

Dirty Dozen, 4-1, 4-10              LIBS, 2-31

Dirty Dozen Test, 1-13              LINK, 2-23, 2-27, 2-29, 2-31, B-9

disk space requirements, 1-3        link lists, 2-25

  binary files, 1-10                local directories, 2-2, 2-33

  text files, 1-3                     Q-routines, 2-2

$DOCGRIP, B-12                        $SYSLOCAL, 2-2

$DOCPUBL, B-12                        Y-routines, 2-2

$DOCWHO, B-12                         Z-routines, 2-2

DPFRMT, 1-12, A-3, B-5              logicals, 1-1

                                    login procedures, 2-14

environment saturation, 2-12        LOGIN.CSH, 2-3, 2-14, 2-18, 2-33,

execution tools, 2-30                   B-12

                                    LOGIN.SH, 2-3, 2-14, 2-18, 2-33,

FC, 2-29, 2-31                          B-12

FCOPTS.SH, 2-29, 2-33               $LPRNTR, 3-7

FILAIP, 1-13, 4-2                   LWPLA, 3-7, B-13

file locking, B-5

@ files, 1-12, 3-2, B-9             MAKEAT, 2-27, 2-31, 3-2, B-9

  MAKEAT, 2-31, 3-2                 ME* files, 1-13, 4-3

FSC, B-9                            message terminals, 3-5

fsplit, B-9                         $MT0*, 3-4

 

GR* file, 1-13                      NEWEST, 2-31, 2-33

graphics terminals, 3-6             NEWEST.C, 2-31

gripe file, 1-13                    NOOPT, B-8

                                    NSHORT, A-4

HOLLERITH, 2-32                     NVOLSC, B-5

                                    NWDPLO, B-5

I/O

  load leveling, 2-2                object libraries, 2-18, 2-22, 3-3

  scratch, 2-2                        locking, 3-3

IC* files, 1-13                     $OLD, $NEW, $TST, 1-3

ID* files, 1-13                     OPT2.LIS, 2-29, B-13, C-2, C-5

image catalog files, 1-13           OPT[0-9], B-8

INCLUDE files, 2-27, 2-32           optimization, 2-29

  directory tree, 2-28

  local, 2-32                       PA* file, 4-4

INCLUDES.SED, B-7                   password file, 1-13, 4-4

$INCNOT, 2-28                       passwords, 4-4

$INCS, 2-28, 2-33, B-7              $PLOTTER, 3-7

INCS.SH, 2-18, 2-27 to 2-28, 2-33   POPS memory files, 1-13, 4-3

$INCUNIX, 2-28                      POPSDAT.HLP, 4-5

INSTEP1, 3-1                        POPSGN, 1-13, 4-5

INSTEP2, 1-12, 2-24, 3-1, B-9       PP, 2-28, 2-31 to 2-33, B-7

INSTEP3, 1-12, 3-1, 4-1             PP.EXE, 2-32 to 2-33

PP.FOR, 2-32                        setitimer, B-9

PRINTENV, 2-31, 2-33, B-3           SETPAR, 1-13, 4-6

PRINTENV.C, 2-31                    SETTVP, 1-13, 4-8

printers and plotters, 3-7          source code overhaul, 1-2 to 1-3

$PRIOn, B-10                          conversion programs

private versions, 4-11                  CONINC, 1-3

program and object library              XEDIT, 1-3

    mappings, 2-24                      XLATE, 1-3

programming tools, 2-30             source code preprocessor, 2-31

PRTPL, 3-8                            procedure, 2-32

pseudo-AP size, 4-8                   program, 2-32

PW* file, 1-13                      source code search paths, 2-18

                                    SP* file, 1-13

Q-routines, 1-11                    SPFRMT, 1-12, A-3, B-5

  directory tree, 1-9, 2-4          SSS, B-13

$QDEV, 3-2                          statfs, B-10

QMSPL, 3-7                          $STDINC, 2-28

$QNOT, 3-2                          $STDINCS, 2-28, 2-33

$QPGM, 4-12                         SUBLIB, 2-22, 2-24, 3-3

$QPGNOT, 4-12                       subroutine and object library

$QPGUNIX, B-11                          mappings, 2-22

$QSUB, 3-2                          Sun systems

QWKPL, 3-8                            floating-point options, C-7

$QYPGM, 4-12                          monitor as TV, C-10

$QYPGNOT, 4-12                        optimization levels, C-6

$QYPGUNIX, B-11                       "_units undefined", C-7

                                      ZABORS, C-7

ranlib, 2-24, C-1                     ZTPCL2, C-7

release notes                         ZTPMI2, C-8

  15APR87, B-2                      $SYSAIPS, B-9

  15APR88, B-7                      $SYSLOCAL, 2-3, 2-17 to 2-18

  15APR89, B-10                     $SYSTEM, B-9

  15APR90, B-12                     SYSTEM

  15JAN87, B-1                        directory tree, 1-6, 2-3

  15JAN88, B-6                      SYSTEM directories, 1-6

  15JAN89, B-9                      system parameter file, 1-13

  15JAN90, B-11                     system specific notes

  15JUL87, B-4                        Alliant systems, C-2

  15JUL88, B-8                        Convex systems, C-5

  15JUL89, B-10                       Cray systems, C-5

  15OCT86, B-1                        Sun systems, C-6

  15OCT87, B-4                        System V, C-1

  15OCT88, B-8                          LIBR, C-1

  15OCT89, B-11                         ranlib, C-1

reserved disks, 3-4                 SYSTYP, A-4

reserved terminals, 3-5             $SYSUNIX, 2-17 to 2-18

$RESSTT*, 3-5                       SYSVER, A-4

RUN, 2-31

  start-up procedure, B-12          tape allocation, 3-5

running under a debugger, 4-10      tape drives, 3-4

                                    tape interface, 4-10

SEARCH, 2-27, 2-31, 4-13, B-7,      tar, 2-2

    B-12                              loading the installation tape,

SEARCHn.DAT, 2-27, B-2                    2-2

SETDEBUG, 4-11                        selective, 1-11

task communications file, 1-13      ZESTEX, B-3

task initiation, 4-9                ZEXIS2, B-6

$TASKTT*, 3-5                       ZEXIST, B-6

TC* file, 1-13                      ZFRE2, A-4, B-6

$TEKTK*, 3-6, B-2                   ZI16IL, A-3 to A-4

terminal carriage control, A-4      ZI32IL, A-3

TEXT, B-12                          ZILI16, A-3 to A-4

$TKDEV*, 3-6                        ZILI32, A-3

TTYCAR, 1-12, A-4                   ZIPACK, A-3

TV display devices, 3-6             ZLAS*, 3-7

TV parameters, 1-13, 4-3            ZLASC2, 3-7

$TVDEV*, 3-7                        ZLASCL, 2-31, 3-7, B-13

TXPL, 3-8                           ZLOCK, C-1

                                    ZLPCL2, 2-31, 3-7, A-4, B-6

UPDAT, D-10                         ZLPCLS, 3-7

updating user data formats, D-1     ZLPOPN, 3-7

  CATCHA, D-6                       ZLW*, 3-7

  CATCHT, D-3                       ZM70O2, B-6

  UPDAT, D-9                        ZM70X2, B-6

ustat, B-10                         ZMCACL, A-4

                                    ZMKTMP, B-8

VERSION adverb, 4-11                ZMOUN2, 3-5, A-4, B-6

version logicals, 1-3               ZMSGWR, B-3

                                    ZPARS, B-6

Y-routines, 1-11                    ZPHFIL, B-2

  directory tree, 1-8, 2-4          ZPRI2, B-6

$YGEN, 3-2                          ZPRIO2, B-6

$YNOT, 3-2                          ZQASSN, B-6

$YPGM, 4-12                         ZQDEVN, B-3

$YPGNOT, 4-12                       ZQMSCL, B-6

$YPGUNIX, B-11                      ZQMSG, B-3

$YSUB, 3-2                          ZQRENA, B-6

                                    ZQTAPE, B-6

Z-programs, A-43                    ZQTRUN, B-6

Z-routines, 1-11, A-1               ZQWKPL, 3-8

  descriptions, A-5                 ZR32RL, A-3 to A-4, B-2

  directory tree, 1-7, 2-3          ZR64RL, A-3 to A-4, B-2

  local development, A-4            ZRDMF, A-4

  search path, 2-22                 ZRENA2, B-6

ZABOR2, B-3, B-13                   ZRENAM, B-6

ZABORS, B-13                        ZRLR32, A-3 to A-4, B-2

ZABORT, B-3                         ZRLR64, A-3 to A-4

ZACTV9, 4-11                        ZRM2RL, A-4

ZBYTF2, A-3                         ZSBIT, 3-8

ZBYTFL, A-3                         ZSTRTA, 4-9, A-43, B-3, B-8, B-10

ZCMPR2, C-1                         ZSTRTB, 4-9, A-43, B-3, B-8

ZCPU, A-4                           ZSTRTP, B-10

ZCREA2, 2-1, B-10                   ZTAP2, 4-10, A-4, B-6

ZDCHI2, 1-12, A-2, B-5              ZTKCL2, B-9

ZDCHIN, B-5                         ZTKFI2, B-6

ZDELA2, B-9                         ZTKOP2, B-6

ZDM2DL, A-4                         ZTKQIO, B-6

ZDOPRT, 3-8                         ZTPMI2, B-6

ZERRO2, B-3                         ZTPOP2, B-6

ZERROR, B-3                         ZTQSP2, B-7

ZTRLOG, B-3, B-6                    ZXMKTM, B-8

ZTRLOG.C, 2-32                      ZXMOUN, B-6

ZTVQIO, B-6                         ZXSIGC, B-3

ZTXMA2, B-6, C-1                    ZXTLOG, B-3, B-6

ZVTV*, C-1                          ZXTPIO, B-6

ZWHOMI, 3-6 to 3-7, B-2 to B-3      ZXTSPY, B-6 to B-7

ZXFREE, B-6                         ZXUID, B-8

ZXLPRT, B-6                         ZXXIST, B-6

