Retro1.org codex

*DECK     NIP 
PRGM NIP; 
 CONTROL PRESET;
*IF DEF,IMS 
 #
* W        12 
*     NN         NN         A         MM          MM
*     NNN        NN        AAA        MMM        MMM
*     NNNN       NN       AA AA       MMMM      MMMM
*     NN NN      NN       AA AA       MM MM    MM MM
*     NN  NN     NN      AA   AA      MM  MM  MM  MM
*     NN   NN    NN      AA   AA      MM   MMMM   MM
*     NN    NN   NN     AA     AA     MM    MM    MM
*     NN     NN  NN     AAAAAAAAA     MM          MM
*     NN      NN NN    AAAAAAAAAAA    MM          MM
*     NN       NNNN    AA       AA    MM          MM
*     NN        NNN   AA         AA   MM          MM
*     NN         NN   AA         AA   MM          MM
 *    NETWORK PRODUCTS DOCUMENTATION        PAGE
 *    NAM INTERNAL SPECIFICATION            DATE. 
 *    NAM GENERAL DESCRIPTION 
*1DC  NAM GENERAL DESCRIPTION 
*     ***************************************************************** 
*     *      PLEASE REFER TO THE RECENT HARD COPY OF NAM IMS.         * 
*     ***************************************************************** 
* 
* 
*     THE NETWORK ACCESS METHOD(NAM) PROVIDES AN INTERFACE FOR PROGRAMS 
*     EXECUTING IN A CYBER 70/170 FOR EXCHANGING DATA WITH TERMINALS
*     IN THE NETWORK AS WELL AS OTHER EXECUTING PROGRAMS IN THE NETWORK.
* 
*     NAM PROVIDES THE FOLLOWING FEATURES AND/OR ADVANTAGES TO THE
*     APPLICATION PROGRAM 
* 
*     .ISOLATION OF APPLICATION COMMUNICATIONS FROM THE OPERATING 
*      SYSTEM 
* 
*     .MANAGEMENT OF NETWORK PROTOCOL 
* 
*     .DYNAMIC ESTABLISHMENT, MAINTENANCE AND TERMINATION OF DATA PATHS 
*      BETWEEN TERMINALS AND PROGRAMS OR BETWEEN PROGRAMS.
* 
*     .BUFFERING AND QUEUING OF DATA FOR REGULATION OF DATA FLOW
* 
*     .SUPPORT A WIDE VARIETY OF TERMINALS THROUGH NORMALIZATION OF 
*      DATA FORMATS 
* 
*     .MECHANISM FOR ANY PROGRAM TO COMMUNICATE WITH A NUMBER OF
*      TERMINALS WHICH MAY BE ADDRESSED INDIVIDUALLY OR BE GROUPED
*      TOGETHER AND ADDRESSED AS A MEMBER OF A GROUP (LIST).
* 
*     NAM IS MADE UP OF THE FOLLOWING 3 MAJOR MODULES 
* 
*     .NIP - A CP PROGRAM WRITTEN MOSTLY IN SYMPL AND RUNNING AT
*      A DEDICATED CONTROL POINT. NIP HAS SYSTEM CONTROL POINT
*      PRIVILEGES, I.E. IT CAN READ AND WRITE INTO THE FIELD LENGTH 
*      OF SO CALLED USER CONTROL POINTS UPON REQUEST OF THESE 
*      CONTROL POINTS.
* 
*     .PIP - A DEDICATED PPU PROGRAM RUNNING AT NIP"S CONTROL POINT.
*      ONE OR MORE COPIES OF PIP MAY RESIDE IN PPU-S (DEPENDING ON
*      THE EST CONFIGURATION OF ENABLED NETWORK NODES) AND WILL 
*      OCCUPY THOSE PPU-S AS LONG AS THERE ARE NETWORK NODES ENABLED. 
* 
*     .AIP - A COLLECTION OF RELOCATABLE SUBROUTINES RESIDING IN THE
*      APPLICATIONS FIELD LENGTH, WHICH ENABLE THE APPLICATION TO 
*      COMMUNICATE WITH NIP, USING THE OPERATING SYSTEM SYSTEM
*      CONTROL POINT FEATURE. 
* 
*     THE READER OF THIS DOCUMENT IS EXPECTED TO BE FAMILIAR WITH THE 
*     NAM REFERENCE MANUAL, THE NOS REFERENCE MANUAL AND DETAILS
*     OF THE NOS SYSTEM CONTROL POINT FEATURE. THE DOCUMENTATION FOR
*     THIS NOS OPERATING SYSTEM FEATURE IS PENDING. 
* 
*     THE REMAINDER OF THIS DOCUMENT IS ORGANIZED IN THE FOLLOWING
*     MANNER: 
* 
*     1.0 NIP PROGRAM STRUCTURE 
*     2.0 MESSAGE TRANSMISSION THROUGH NAM
*     3.0 NIP TABLE STRUCTURE 
*     4.0 SYSTEM CONTROL POINT COMMUNICATION
*     5.0 NIP DETAILED DESCRIPTION
*     6.0 NIP CROSS REFERENCE TABLE 
*     7.0 AIP PROGRAM STRUCTURE 
*     8.0 AIP TABLE STRUCTURE 
*     9.0 AIP DETAILED DESCRIPTION
*     10.0 AIP CROSS REFERENCE TABLE
*     11.0 PIP PROGRAM STRUCTURE
*     12.0 PIP DETAILED DESCRIPTION 
( 
* 
 *    NETWORK PRODUCTS DOCUMENTATION        PAGE
 *    NAM INTERNAL SPECIFICATION            DATE. 
 *    1.0 NIP PROGRAM STRUCTURE 
*1DC  1.0 NIP PROGRAM STRUCTURE 
* 
*     NIP GLOBAL STRUCTURE IS PICTURED BELOW
*     --------------------------------------------------------- 
*     I                                                        I
*     I                                                        I
*     I    SYSTEM COMMUNICATION, RESIDENT TABLES, CONSTANTS    I
*     I                (1100O)                                 I
*     --------------------------------------------------------- 
*     I                                                        I
*     I                                                        I
*     I                                                        I
*     I                                                        I
*     I                                                        I
*     I    MAIN PROGRAM AND FREQUENTLY USED SUBROUTINES        I
*     I                                                        I
*     I                (16000O)                                I
*     --------------------------------------------------------- 
*     I                                                        I
*     I   OVERLAYS (1400O)                                     I
*     I                                                        I
*     --------------------------------------------------------- 
*     I                                                        I
*     I   DYNAMICALLY ALLOCATED BUFFER AREA                    I
*     I                                                        I
*     --------------------------------------------------------- 
* 
*     ALL OCTAL NUMBERS INDICATING SIZES OF THE VARIOUS PORTIONS ARE
*     APPROXIMATE.
* 
*     UNDER SYSTEM COMMUNICATION OF COURSE WE HAVE THE FIRST 111O WORDS 
*     OF CORE, SOME OF WHICH IS BEING UTILIZED FOR SYSTEM CONTROL POINT 
*     COMMUNICATION. THIS AREA ALSO CONTAINS THE FOLLOWING POINTERS AND 
*     TABLES NEEDED BY NIP TO FUNCTION. 
* 
*         COPYRT     COPYRIGHT COMMON BLOCK 
*         APPSTAT    NETWORK WORKLIST PROCESSING TABLE
*         BACKBUF    SPECIAL BUFFER FOR DOWNLINE BACKS
*         FREETAB    BUFFER MANAGEMENT PROCESSING TABLE 
*         KDIS       K-DISPLAY SUPPORT TABLE
*         OVERLAY    OVERLAY PROCESSING TABLE 
*         OVLNAMEP   OVERLAY NAME TABLE 
*         PARAMP     BUFFER FOR PASSING PARAMS TO/FROM PRIMARY OVERLAYS 
*         PARAMS     BUFFER FOR PASSING PARAMS TO/FROM SECONDARY OVRLAYS
*         PITTAB     PIP INTERFACE TABLE
*         PT         POINTER TABLE
*         SSTCOM     SYSTEM CONTROL POINT FILE TRANSFER TABLE 
*         TIME       SYSTEM TIME TABLE
* 
*     THE MAIN PROGRAM FOR NIP IS ALSO CALLED NIP, AND IS THE FIRST 
*     PROGRAM ON THE PL. IT IS THE ONLY PROGRAM THAT HAS THE COMMON 
*     DECKS USED BY NIP LISTED. IN ALL OTHER ROUTINES SYMPL TEXT IS 
*     USED.  COMMON DECKS FOR SUPERVISORY MESSAGES USED THROUGHOUT
*     NETWORK HOST PRODUCTS MAY BE LISTED BY EXECUTING THE
*     FOLLOWING JOB:  
* 
*         (JOB AND ACCOUNT CARDS) 
*         (OBTAIN A COPY OF NAMPL)
*         UPDATE(Q,P=NAMPL) 
*         RFL(60000)
*         COMPASS(I)
*         7-8-9 
*         *C NP$SYM 
*         6-7-8-9 
* 
* 
*     THE STRUCTURE OF NIP ON THE PL IS AS FOLLOWS: 
*     . COMMON DECKS IN ALPHABETICAL ORDER
*     . THE MAIN PROGRAM NIP FOLLOWED BY ALL THE ROUTINES WRITTEN IN
*       SYMPL IN ALPHABETICAL ORDER (NIP THROUGH XTERMST).  NOTE THAT 
*       ROUTINES WHICH ARE OVERLAYS ARE RESIDING INTERSPERSED WITH
*       ROUTINES IN THE RESIDENT OVERLAY. THIS IS SO THAT A ROUTINE 
*       CAN BE EASILY LOCATED.
*     . THE ROUTINES WRITTEN IN COMPASS FOLLOW THE SYMPL PROGRAMS FOR 
*       OTHER NHP PRODUCTS. THESE ROUTINES ARE ALSO ARRANGED ALPHABE- 
*       TICALLY AND CURRENTLY THIS INCLUDES ALL THE ROUTINES FROM ABORT 
*       TO XTRACE.
*     . IN ADDITION TO THAT ON THE NAMPL THERE IS A COMPASS SKELETON
*       DECK (DECKNAME SKENIP) THAT CONTAINS OVERLAY CARDS FOLLOWED 
*       BY A COMPASS ROUTINE CONSISTING OF ONLY AN IDENT AND END
*       CARD FOR EACH OF THE ROUTINES IN A PARTICULAR OVERLAY.
* 
*     THUS AFTER COMPILING AND ASSEMBLING ALL OF THE NIP ROUTINES 
*     ALL ONE HAS TO DO IS REPLACE THE ROUTINES IN SKELETON WITH THE
*     CORRESPONDING REAL ROUTINES TO GET A BINARY STRUCTURE WITH THE
*     PROPER OVERLAY CARDS IN IT. 
* 
*     THE MAIN PROGRAM NIP IS JUST ABOUT A DO-NOTHING. IT SIMPLY CALLS
*     THE INITIALIZATION OVERLAY AND THEN CALLS XEXEC WHICH IS REALLY 
*     THE MAIN EXECUTIVE FOR NIP. THE LOGIC FLOW OF XEXEC IS A GOOD 
*     REPRESENTATION OF THE LOGIC FLOW FOR NIP AND MAY BE SUMMARIZED
*     AS FOLLOWS: 
* 
*     START :  CALL INIP
*     LOOP:    IF HALF A SECOND HAS ELAPSED,
*                CHECK FOR SWAPPED IN APPLICATIONS. 
*                IF 5 SECONDS HAVE ELAPSED, 
*                  CHECK FOR INACTIVE CONNECTIONS,
*                IF 10 SECONDS HAVE ELAPSED,
*                  CHECK IF GARBAGE COLLECTION NEEDS TO BE DONE,
*                    IF SO, PERFORM GARBAGE COLLECTION. 
*                IF 10 SECONDS HAVE ELAPSED,
*                  CHECK FOR EST TABLE CHANGES. 
*                CHECK IF PIP NEEDS MORE PRU BUFFERS AND ALLOCATE THEM. 
*              RELEASE ANY OUTBOUND BUFFERS PROCESSED BY PIP, 
*              IF NIP NOT IN REGULATION LEVEL 0,
*                CALL HHIR. 
*                CALL NEIB. 
*              PROCESS REGULATION LEVEL CHANGE IF ANY.
*              UPDATE NIP K-DISPLAY.
* 
*     LOOP2:   IF NO WORKLIST FROM APPLICATION OR 
*                 PIP HAS NO WORK FOR NIP TO DO OR
*                 HALF A SECOND HAS NOT ELAPSED,
*                GO INTO RECALL.
*                GO TO LOOP2. 
*              GO TO LOOP.
* 
*     AS CAN BE SEEN FROM THE ABOVE, NIP EXECUTES UNTIL 
*     NETWORK SHUTDOWN. THE ROUTINES CALLED BY XEXEC ARE THE MAJOR
*     FUNCTIONAL MODULES OF NIP AND A BRIEF DESCRIPTION FOR EACH
*     FOLLOWS:  
* 
*      . INIP IS RESPONSIBLE FOR INITIALIZING BUFFERS AND BUFFER
*        POINTERS 
*      . XSACB IS RESPONSIBLE FOR CHECKING THE STATE OF APPLICATIONS
*        AND TAKING APPROPRIATE ACTION. 
*      . XCHKPCR IS RESPONSIBLE FOR CHECKING CONNECTION FOR INACTIVITY
*        AND DETERMINE IF INTRA-HOST A TO A LOGICAL LINK EXISTS AND CAN 
*        BE DELETED.
*      . MGBGCLT IS THE GARBAGE COLLECTION ROUTINE TO COMPACT THE 
*        DYNAMICALLY ALLOCATED BUFFERS. 
*      . XCHKCET IS RESPONSIBLE FOR UPDATING THE COUPLER
*        EQUIPMENTS TABLE ( CET ).
*      . XCHKABC IS RESPONSIBLE FOR ALLOCATE MORE PRU BUFFERS IF PIP
*        REQUESTED THEM.
*      . NEIB EMPTIES THE NETWORK (PIP) INPUT BUFFER OF UPLINE DATA 
*        MESSAGES.
*      . HHIR IS RESPONSIBLE FOR PROCESSING AN INCOMING SYSTEM CONTROL
*        POINT REQUEST. HHIR CALLS NFOB TO QUEUE MESSAGES FOR PIP TO BE 
*        DELIVERED TO THE NPU.
* 
*     EACH OF THESE MAJOR MODULES CALL SEVERAL SUBMODULES. THE MAJOR
*     MODULES AS WELL AS THE SUBMODULES ARE DISCUSSED IN MORE DETAIL
*     IN CHAPTER 5, IN NIP DETAILED DESCRIPTION. IN GENERAL,HOWEVER,
*     IT SHOULD BE NOTED THAT THE FIRST LETTER OF THE ROUTINE NAME
*     HAS FUNCTIONAL SIGNIFICANCE AS FOLLOWS
*      .NAMES BEGINNING WITH A B ARE ASSOCIATED WITH NIPS BUFFERING 
*       FUNCTION (I.E. BUFFERING OF DATA BETWEEN APPLICATIONS AND 
*       THE TERMINAL.) EXAMPLES ARE BDELINK TO DELINK A DATA BLOCK FROM 
*       THE DATA RING, AND BCONV TO CONVERT INBOUND DATA FROM ASCII 
*       TO DISPLAY CODE.
*      .NAMES BEGINNING WITH AN H ARE ASSOCIATED WITH HOST SIDE PROCES- 
*       SING. THAT IS THE H ROUTINES PROCESS THE APPLICATIONS REQUEST.
*       EXAMPLES ARE HPPUT TO PROCESS A NETPUT, HPGET TO PROCESS A
*       NETGET, ETC.
*      .NAMES BEGINNING WITH AN I ARE ASSOCIATED WITH THE INITIALIZA- 
*       TION PROCESS. THUS INIP INITIALIZES NIP FETS. 
*      .NAMES BEGINNING WITH AN M ARE ASSOCIATED WITH THE MEMORY MANAGE-
*       MENT FUNCTIONS, SUCH AS MGETS, MRELS TO GET AND RELEASE MEMORY
*       SPACE.
*      .NAMES BEGINNING WITH N ARE ASSOCIATED WITH NETWORK SIDE 
*       PROCESSING, THAT IS THE MOVEMENT OF DATA BETWEEN NIP AND PIP. 
*       EXAMPLES ARE NEIB TO EMPTY THE NETWORK INPUT BUFFER, OR 
*       NGIGO TO PROCESS A GARBAGE IN GARBAGE OUT MESSAGE FROM THE
*       NETWORK 
*      .NAMES BEGINNING WITH O ARE ASSOCIATED WITH OPERATING SYSTEM 
*       INTERFACES SUCH AS OSCPSI TO SWAP IN AN APPLICATION.
*      .NAMES BEGINNING WITH R ARE FOR RECOVERY. CURRENTLY THERE IS 
*       ONLY ONE, RDUMP TO TAKE A DUMP IN CASE OF A FAILURE.
*      .NAMES BEGINNING WITH X ARE MISCELLANEOUS ROUTINES.
*      .NAMES BEGINNING WITH K ARE FOR K-DISPLAY PROCESSING ROUTINES. 
* 
*      ACB -S , ACNB-S AND NCNB-S WILL BE DESCRIBED LATER.
* 
*     THE NIP OVERLAY AREA IS DIVIDED INTO TWO BUFFERS: ALL PRIMARY 
*     OVERLAYS ARE LOADED INTO THE FIRST BUFFER AND ALL SECONDARY 
*     OVERLAYS ARE LOADED INTO THE SECOND BUFFER. BECAUSE THE BUFFERS 
*     ARE FIXED IN SIZE EXTRA CARE MUST BE TAKEN TO ASSURE THAT AN
*     OVERLAY DOES NOT EXCEED THE BUFFER SIZE. ALLOWED SIZES ARE DEFINED
*     IN CHAPTER 3 (NIP TABLE STRUCTURE OF THIS GID). 
* 
*     THE PHILOSOPHY ON PUTING THINGS INTO OVERLAYS IS OBVIOUS: IN- 
*     FREQUENTLY CALLED FUNCTIONS ARE DONE IN OVERLAYS. EXAMPLES OF 
*     SUCH FUNCTIONS ARE NETON/NETOFF PROCESSING, CREATING/DELETING/
*      SWITCHING ACB-S AND ACNB-S ETC. FOR A COMPLETE LIST SEE COMMON 
*     BLOCK OVLNAME IN CHAPTER 3. 
*     FINALLY WE SHOULD DISCUSS NIP"S DYNAMICALLY ALLOCATED BUFFER
*     AREA. NIP USES A VARIABLE LENGTH BUFFER ALLOCATION MECHANISM. 
*     WHEN SPACE IS NEEDED. THE REQUESTING ROUTINE SPECIFIES THE
*     NUMBER OF WORDS NEEDED, CALLS MGETS AND RECEIVES THE FWA OF 
*     THE ACQUIRED SPACE. THE FIRST WORD OF THE ACQUIRED BUFFER 
*     HAS THE FOLLOWING FORMAT
*     NOTE THAT HERE AS IN THE REMAINDER OF THIS IMS BITS ARE NUMBERED
*     FROM LEFT TO RIGHT, ACCORDING THE SYMPL LANGUAGE CONVENTIONS. 
* W         9 
*                         2                         5 
*        0        6       4                         9 
*        I--------I-------I-------------------------I 
*        I        I       I                         I 
*        I   ID   I   BS  I          FREE           I 
*        I        I       I                         I 
*        I--------I-------I-------------------------I 
* 
*     WHERE ID IS THE BLOCK ID, SET TO 0 WHEN THE CALLER RECEIVES 
*     THE BUFFER, AND BS IS THE ACTUAL SIZE OF THE BLOCK ACQUIRED.
*     THE CALLER MUST IMMEDIATELY SET THE BLOCK ID TO THE TYPE OF 
*     BLOCK THE BLOCK IS GOING TO BE, AND MUST NEVER CHANGE THE BLOCK 
*     SIZE FIELD. THE REMAINDER OF THE WORD AS WELL AS THE BS-1 
*     NUMBER OF WORDS FOLLOWING IT ARE AVAILABLE FOR THE CALLER 
* 
*     IF A BUFFER IS TO BE RETURNED TO THE FREE POOL,THEN THE MRELS 
*     ROUTINE MUST BE CALLED WITH THE FWA OF THE BLOCK TO BE
*     THE FORMAT OF A FREE BLOCK IN THE FREE RING IS AS FOLLOWS:  
* 
*        0     6               22                  4                5 
*                              34                  2                9 
*        1----1-----------------1------------------1----------------1 
*        1    1                 1                  1                1 
*        1 0  1      BS         1    FRBFBBP       1    FRBFBFP     1 
*        1    1                 1                  1                1 
*        1----1-----------------1------------------1----------------1 
* 
*     AS CAN BE SEEN THE FREE BUFFER ID IS ALWAYS 0. AGAIN BS 
*     REPRESENTS THE BLOCK SIZE.  FRBFBBP AND FRBFBFP ARE THE FREE
*     BUFFER BACKWARD AND FORWARD POINTER RESPECTIVELY. AT ANY ONE TIME 
*     LOCATION FREETAB IN LABELLED COMMON IS THE DOMINANT MEMBER OF 
*     THE FREE CHAIN,I.E. IT HAS FORWARD AND BACKWARD POINTERS TO 
*     THE FIRST AND LAST BLOCK, RESPECTIVELY IN THE CHAIN.
* 
*     IN ORDER TO ACQUIRE SPACE NIP WILL LOOK THROUGH THE FREE CHAIN
*     FOR THE REQUIRED SIZE OF FREE BLOCK. A BLOCK IS OBTAINED EITHER 
*     ON A FIRST OR BEST FIT BASIS, DEPENDING ON AN INSTALLATION
*     SPECIFIED UPDATE OPTION. CURRENTLY THE BUFFER WHICH IS RETURNED 
*     TO THE CALLER HAS A BS WHICH IS THE EXACT SIZE REQUESTED BY 
*     THE CALLER. HOWEVER THERE MUST BE NO CODE RELYING ON THIS FACT
*     SINCE WE MIGHT EXPERIMENT WITH NOT RETURNING THE REMAINDER
*     OF THE BUFFER TO THE FREE CHAIN IF THE REMAINDER IS ONLY A
*     FEW WORDS LONG. THE MEMORY MANAGEMENT FUNCTIONS MUST REMAIN 
*     MODULAR AND TOTALLY INDEPENDENT OF THE REST OF THE CODE.
* 
*     IF THERE IS NO ROOM IN THE FREE BUFFER CHAIN FOR A BLOCK OF THE 
*     REQUIRED SIZE MEMORY WILL BE REQUESTED FROM THE OPERATING SYSTEM. 
* 
*     IN ORDER TO RETURN A BLOCK TO THE FREE CHAIN THE BLOCK IS SIMPLY
*     INSERTED INTO THE FREE CHAIN. THE FREE CHAIN IS ORDERED BY
*     INCREASING FWA OF THE BLOCK. IN ORDER TO MINIMIZE BUFFER
*     FRAGMENTATION,IF A BLOCK BEING INSERTED INTO THE FREE CHAIN FORMS 
*     A CONTIGUOUS BLOCK WITH EITHER THE BLOCK BEFORE IT OR THE BLOCK 
*     AFTER IT,THEN THESE BLOCKS ARE COMBINED INTO A SINGLE BLOCK.
* 
*     OTHER STEPS TAKEN TO MINIMIZE BUFFER FRAGMENTATION INCLUDE
*     GARBAGE COLLECTION. GARBAGE COLLECTION CONSIST OF MOVING DOWN 
*     ALL MOVABLE BUFFERS TO LOWER ADDRESSES SO THAT FREE BUFFERS 
*     MAY BE COMBINED INTO A SINGLE FREE BUFFER AT HIGH CORE. THE 
*     BLOCK ID"S DURING THIS MOVE ARE EXTREMELY IMPORTANT. THE
*     BLOCK ID FIELD IS USED IN THE FIRST PLACE TO DETERMINE IF 
*     THE BUFFER IS MOVABLE OR NOT. BUFFERS WAITING FOR OPERATING 
*     SYSTEM ACTION (SUCH AS COMPLETION OF AN SCP SWAPIN REQUEST) 
*     OR BUFFERS INVOLVED IN PIP COMMUNICATION ARE NOT MOVABLE. 
*     ANY BUFFER THAT HAS BIT 0 OF ITS BLOCK ID SET IS A NONMOVABLE 
*     BUFFER. 
*     NOTE THAT THE SAME CORE AREA CAN ALTERNATE FROM BEING MOVABLE 
*     TO NONMOVABLE EVEN WHILE IT CONTAINS THE SAME INFORMATION.
* 
*     THE BLOCKID FIELD IS ALSO USED TO TELL THE GARBAGE COLLECTION 
*     ROUTINE WHAT SPECIFIC ACTION TO TAKE IN MOVING THE BLOCK. 
*     SOME TYPES OF BLOCK ARE MEMBERS OF SEVERAL DIFFERENT KINDS OF 
*     RINGS WITH POINTERS IN OTHER BLOCKS POINTING TO THEM, WHICH 
*     OBVIOUSLY HAVE TO BE UPDATED WHEN THE BLOCK POINTED TO IS BEING 
*     MOVED. THIS ALSO MEANS THAT ANY BLOCK WHICH IS POINTED TO BY
*     ANOTHER BLOCK MUST ITSELF HAVE A POINTER TO THAT BLOCK IN ORDER 
*     FOR THE GARBAGE COLLECTION ROUTINE TO BE ABLE TO EASILY LOCATE
*     THE BLOCK POINTING TO THE BLOCK BEING MOVED.
* 
*     FOR THE DETAILS ON WHEN GARBAGE COLLECTION TAKES PLACE SEE THE
*     DETAILED DOCUMENTATION ON XEXEC.
* 
*     SOME OF THE MORE SIGNIFICANT BLOCKS IN THE DYNAMICALLY ALLOCATED
*     BUFFER AREA ARE AS FOLLOWS: 
* 
*      . ACB ( APPLICATION CONTROL BLOCK) A ACB EXISTS FOR EACH APPL. 
*        THAT HAS NETTED ON SUCCESSFULLY, UNTIL THAT APPLICATION
*        DOES A NETOFF OR FAILS. A LLCB ALSO EXISTS FOR EACH LOGICAL
*        LINK. A LOGICAL LINK IS A LINK 
*        BETWEEN A HOST NODE (PHYSICALLY THIS CAN BE THOUGHT OF AS
*        THE COUPLER) AND A TERMINAL NODE (PHYSICALLY THIS CAN BE 
*        THOUGHT OF AS ANY 255X TO WHICH THERE ARE TERMINALS ATTACHED)
*        ON WHICH DATA TRAFFIC MAY TAKE PLACE.
*        THE ACB CONTAINS INFORMATION UNIQUE TO THE PROCESS AND 
*        PROVIDES NIP WITH A CONVENIENT WAY OF CONTROLLING ACTIVITY OF
*        THE PROCESS. 
*        THE ACB ALSO SERVES AS A ACNB ( APLLICATION CONNNECTION
*        CONTROL BLOCK) FOR CONNECTION ZERO ( SUPERVISORY MESSAGE) I.E. 
*        A CONTROL BLOCK FOR QUEUING SUPERVISORY MESSAGES AND OR SERVICE
*        MESSAGES.
*        ACB CONTAINS A POINTER TO ACNT ( APPLICATION CONNECTION TABLE) 
*        WHICH IS THE TABLE OF ALL EXISTING ACNB ( APPLICATION CONNECTION 
*        CONTROL BLOCK / EACH FOR EACH CONNECTION TO APPL. ) THE CN/ACN 
*        SERVE AS AN INDEX INTO THE TABLE. SEE THE NIP TABLES SECTION 
*        OF THIS DOCUMENT.
* 
*      . ACNB/NCNB ( APPLICATION CONNECTION CONTROL BLOCK/NETWORK 
*        CONNECTION CONTROL BLOCK). A PAIR OF THESE  EXIST FOR EACH 
*        LOGICAL CONNECTION ON THE NETWORK. A LOGICAL CONNECTION CAN
*        BE THOUGHT OF AS A CONNECTION BETWEEN AN APPLICATION AND 
*        A TERMINAL,OR A CONNECTION BETWEEN TWO APPLICATIONS. A MULTI-
*        TERMINAL SUPPORT APPLICATION WOULD HAVE A PAIR OF ACNB/NCNB FOR
*        EACH OF THE TERMINALS CONNECTED TO THAT APPL. THE ACNB/NCNB
*        PAIR HOLDS ALL INFORMATION UNIQUE TO THAT CONNECTION AND 
*        IS USED TO CONTROL ALL DATA TRAFFIC ON THAT CONNECTION. EACH 
*        ACNB IS POINTED TO BY ACNT, A TABLE OF ALL ACNB'S ASSOCIATE
*        WITH THIS APPLICATION. NCNB IS POINTED TO BY NCNT, TABLE OF
*        ALL NCNB'S ASSOCIATE WITH THIS LOGICAL LINK. 
*        ACB ALSO BY THE APPLICATION NUMBER IN THE ACNB.
* 
* 
*        MESSAGES BEING SENT ON CONNECTION ARE QUEUED ON ACNB/NCNB
*        WHICH REPRESENT THEIR DESTINATION. THUS DATA TRAFFIC THROUGH 
*        THE NETWORK IS ACCOMPLISHED BY DEQUEUING DATA FROM BUFFERS 
*        (WHERE DATA IS MIXED REGARDLESS OF DESTINATION) SUCH AS IN THE 
*        NETWORK INPUT BUFFER PROCESSED BY NEIB, OR THE HOST SIDE 
*        BUFFER PROCESSED BY HHIR, AND QUEUING MESSAGE BLOCKS ON THEIR
*        RESPECTIVE NCNB/ACNB.
* 
*      . ACNT ( APPLICATION CONNECTION TABLE ) -
*        TABLE OF ACNB ADDRESSES POINTED TO BY ACB .
*      . NCNT ( NETWORK CONNECTION TABLE ) -
*        TABLE OF NCNB ADDRESSES POINTED TO BY LLCB 
* 
* 
*      . NWL (NIP WORK LIST) IS A FIXED SIZE DYNAMICALLY
*        ALLOCATED BUFFER TO RECEIVE THE WORKLIST OF REQUESTS FROM
*        APPLICATIONS.  A POINTER TO THE NWL IS STORED IN RA.SSC, 
*        WHICH IS USED BY THE OPERATING SYSTEM TO DETERMINE WHERE TO
*        PLACE WORKLISTS FROM APPLICATIONS.  NIP WILL MAINTAIN TWO NWL
*        BUFFERS AT ALL TIMES, EXCEPT WHEN SHUTDOWN IS IN 
*        PROCESS. AFTER THE OPERATING SYSTEM HAS PLACED 
*        A WORKLIST IN THE FIRST NWL, NIP WILL UPDATE RA.SSC TO POINT 
*        TO THE SECOND NWL BEFORE IT BEGINS PROCESSING THE FIRST NWL. 
*        IF THE WORKLIST CONTAINS ANY MESSAGES TO BE QUEUED, THIS 
*        QUEUING IS DONE BY INSERTING THE MESSAGE IN THE DATA RING
*        ASSOCIATED WITH APPROPRIATE ACB/ACNB. THIS IS DONE BY
*        INSERTING APPROPRIATE FORWARD AND BACKWARD POINTERS IN THE 
*        BLOCK HEADER.  THEN WHEN ALL THE MESSAGES IN THE NWL HAVE BEEN 
*        PROCESSED, THE REST (REMAINS) OF THE NWL IS RELEASED.  A NEW 
*        NWL IS THEN ALLOCATED (EVEN IF NWL PROCESSING WAS SUSPENDED).
* 
*      . AWL (APPLICATION WORK LIST) IS A SIX WORD ENTRY IN ACB 
*        WHICH NIP FORMS ITS REPLY TO CERTAIN REQUESTS IN THE NWL.
*        THE AWL GETS SENT BACK TO AIP. 
* 
*      . PBI IS THE PIP INPUT BUFFER, ONE PER FRONT END NPU/MDI, INTO 
*        WHICH PIP DUMPS ALL UPLINE MESSAGES FROM THE NETWORK. WHENEVER 
*        PIP INDICATES THAT THE NEXT MESSAGE DOES NOT FIT INTO THE
*        REMAINDER OF THE CURRENT BUFFER NIP WILL ALLOCATE A NEW
*        INPUT BUFFER. ACCESS TO PBI IS CONTROLLED BY PSEUDO FET"S
*        IN THE PREALLOCATED LABELLED COMMON AREA BUFFTAB.
* 
*      . THE BULK OF THE DYNAMICALLY ALLOCATED BUFFER AREA IS USED FOR
*        ACTUAL MESSAGES, EITHER TO OR FROM TERMINALS (AND APPLICATIONS)
*        OR SUPERVISORY AND SERVICE MESSAGES. 
*        MESSAGES GET DEQUEUED FROM THE NWL OR PBI, QUEUED ON AN APPROP-
*        RIATE ACB/ACNB AND THEN DELIVERED TO ITS DESTINATION BY EITHER 
*        BEING QUEUED IN THE PIP OUTPUT BUFFER FOR DOWNLINE DATA, 
*        OR BEING WRITTEN TO THE APPLICATION"S FIELD LENGTH.
* 
 *    2.0 MESSAGE TRANSMISSION THROUGH NAM
*     IN ORDER TO UNDERSTAND HOW MESSAGES TRAVEL THROUGH NAM IT SEEMS 
*     BEST TO DESCRIBE THE FATE OF VARIOUS MESSAGE TYPES FROM THEIR 
*     SOURCE TO THEIR DESTINATION.
* 
*     2.1 DOWNLINE DATA 
* 
*     DOWNLINE DATA (ALSO REFERRED TO AS OUTPUT) IS TRIGGERED BY AN AIP 
*     CALL NETPUT OR NETPUTF. THE CALLER SPECIFIES THE HEADER ADDRESS 
*     AND THE FWA OF THE MESSAGE TEXT. AIP CREATES A WORKLIST ENTRY 
*     FOR THE PUT IN NP$NWL BY PUTING A ONE WORD WORKLIST IDENTIFIER
*     IN THE NEXT AVAILABLE WORD IN THE WORK LIST INDICATING THAT THIS
*     IS A PUT (AS OPPOSED TO GET, WAIT, ETC) REQUEST, COPYING THE
*     HEADER ABH BEHIND THIS WORD IN THE NP$NWL AND BY EITHER COPYING 
*     THE TEXT OF THE MESSAGE INTO NP$NWL, IF THERE IS ROOM, OR 
*     BY INSERTING A POINTER TO THE TEXT AREA INTO THE FIRST WORD 
*     (WORKLIST IDENTIFIER) OF THE ENTRY IF THERE IS NO ROOM. 
*     IN EITHER CASE AIP WILL REQUEST THE OPERATING SYSTEM TO TRANSFER
*     THIS WORK LIST TO NIP-S RECEIVING BUFFER USING A SYSTEM CONTROL 
*     POINT CALL. AIP WILL DO THIS AT THE EARLIEST OCCURANCE OF ONE 
*     OF THE FOLLOWING EVENTS:  
* 
*        A. THE WORKLIST IS FULL
*        B. THE CURRENT REQUEST EXCEEDS THE SIZE OF THE REMAINING SPACE 
*           IN THE WORKLIST 
*        C. THE APPLICATION HAS DONE A NETWAIT
*        D. THE APPLICATION HAS DONE A GET TYPE CALL
*        E. THE APPLICATION HAS DONE A NETPUTF WHICH CANNOT BE HANDLED
*           AS A NETPUT.
*        F. THE APPLICATION HAS DONE A NETPUT ABT=4.
*        G. THE APPLICATION HAS DONE A NETCHEK CALL.
* 
*     THE WORKLIST GETS TO A BUFFER IN NIP"S FL POINTED TO BY WORD
*     RA.SCC(51B). NIP PROCESSES EACH ENTRY IN THE WORK LIST
*     SEQUENTIALLY. (FOR THE FORMAT OF THE WORK LIST SEE THE TABLES 
*     SECTION OF THIS IMS) NIP WILL KNOW WHICH PARTICULAR APPLICATION 
*     THE WORKLIST CAME FROM BY TWO INDEPENDENT PIECES OF INFORMATION 
*     IN THE WORKLIST, NAMELY:  
* 
*       A. THE JOB IDENTIFIER THAT THE OPERATING SYSTEM PLACES IN FRONT 
*          OF THE WORK LIST SENT BY AIP 
*       B. THE APPLICATION NUMBER AS ESTABLISHED AT NETON TIME BY NIP 
*           AND PASSED BACK WITH EACH WORKLIST
* 
* 
*     AT ANY RATE PROCESS HHIR WILL RECOGNIZE THAT A NEW WORKLIST ENTRY 
*     ARRIVED AND WILL CALL HWLP TO PROCESS EACH WORKLIST ENTRY. HWLP 
*     RECOGNIZES THAT THE CURRENT ENTRY IS A NETPUT AND CALLS PROCESS 
*     HPPUT TO PROCESS THE REQUEST. HPPUT AND ITS HELPER ROUTINE
*     WILL PROCESS THE MESSAGE PUT BY THE APPLICATION AS FOLLOWS: 
* 
*       . IF THE MESSAGE TEXT DID NOT FIT INTO THE WORK LIST THEN READ
*         THE MESSAGE TEXT FROM THE APPLICATIONS FIELD LENGTH INTO
*         NIP-S FIELD LENGTH. 
* 
*       . IF THE MESSAGE IS A DATA MESSAGE, NIP WILL QUEUE THE MESSAGE
*         IMMEDIATELY TO THE NETWORK OUTBOUND CHAIN UNLESS THE DOWNLINE 
*         BLOCK LIMIT FOR THE CONNECTION HAS BEEN REACHED IN WHICH CASE 
*         THE MESSAGE IS QUEUED ONTO THE NCNB.  THE NCNB IS FOUND BY
*         SEARCHING THROUGH THE VARIOUS TABLES.  THE APPLICATION NUMBER 
*         ALLOWS NIP TO FIND THE APPROPRIATE APPLICATION CONTROL BLOCK
*         (ACB).  THE ACB HAS A POINTER TO THE APPLICATION CONNECTION 
*         TABLE (ACNT).  KNOWING THE APPLICATION CONNECTION NUMBER OF 
*         THE DATA MESSAGE, THE ACNT IS INDEXED TO FIND THE APPROPRIATE 
*         APPLICATION CONNECTION BLOCK (ACNB).  THE ACNB HAS A POINTER
*         TO THE CORRESPONDING NETWORK CONNECTION BLOCK (NCNB). 
* 
*       . FOR ABT=3 NIP CHECKS IF THE MESSAGE IS A SYNCHRONOUS
*         SUPERVISORY MESSAGE OR AN ASYNCHRONOUS SUPERVISORY MESSAGE. 
*         IF IT IS A SYNCHRONOUS SUPERVISORY MESSAGE, IT IS PROCESSED 
*         AS A DATA MESSAGE.  IF IT IS AN ASYNCHRONOUS SUPERVISORY
*         MESSAGE, NIP WILL PROCESS IT IF IT IS LEGAL.  IF NOT A LEGAL
*         ASYNCHRONOUS SUPERVISORY MESSAGE, NIP WILL REJECT IT AND
*         SEND AN ERROR LOGICAL SUPERVISORY MESSAGE BACK TO THE 
*         APPLICATION THAT SENT IT.  THE ASYNCHRONOUS SUPERVISORY 
*         MESSAGES WHICH MOST APPLICATIONS ARE ALLOWED TO SEND ARE: 
* 
*           . CON/ACRQ - NIP WILL CONVERT THE SUPERVISORY MESSAGE INTO A
*             CR/IAP SUPERVISORY MESSAGE AND SEND IT TO NVF.
* 
*           . CON/END - NIP WILL VERIFY THE APPLICATION HAS THE 
*             CONNECTION SPECIFIED IN THE ACN FIELD OF THIS MESSAGE.
*             IF NOT VALID, THE SUPERVISORY MESSAGE IS REJECTED AND AN
*             ERROR LOGICAL SUPERVISORY MESSAGE IS SENT TO THE
*             APPLICATION.  IF VALID, A NORMAL RESPONSE IS SENT BACK TO 
*             THE APPLICATION AND THE CONNECTION IS SWITCHED TO NVF 
*             (NVF WILL BE SENT A CR/RCN SUPERVISORY MESSAGE).
* 
*           . CON/REQ/N/A - NIP WILL CHECK THE STATE OF THE CONNECTION
*             TO VERIFY IT WAS EXPECTING THIS SUPERVISORY MESSAGE FOR 
*             THE CONNECTION SPECIFIED IN THE ACN FIELD.  IF NOT, THE 
*             SUPERVISORY MESSAGE IS REJECTED AND AN ERROR LOGICAL
*             SUPERVISORY MESSAGE IS SENT TO THE APPLICATION.  IF THE 
*             SUPERVISORY MESSAGE WAS EXPECTED AND IS AN ABNORMAL 
*             RESPONSE, THE CONNECTION IS SWITCHED BACK TO NVF.  IF 
*             IT WAS A NORMAL RESPONSE THEN A INITR NETWORK ELEMENT IS
*             SENT TO THE NETWORK AND THE STATE OF THE CONNECTION IS
*             CHANGED TO WAITING FOR AN INITN ELEMENT RESPONSE.  AN 
*             CR/ACC SUPERVISORY MESSAGE IS ALSO SENT TO NVF. 
* 
*           . DBG/STOP - IF DEBUG MODE IS ON, NIP WILL TAKE A DUMP OF 
*             ITS FIELD LENGTH, SIGNAL PIP TO STOP THE NPU(S), AND DROP.
* 
*           . DC/CICT - NIP WILL CHANGE THE INPUT CHARACTER TYPE IN 
*             THE ACNB. 
* 
*           . DC/TRU - NIP WILL SET DATA TRUNCATION BIT IN ACNB 
*             SPECIFIED BY THE ACN.  IF THE ACN VALUE IS ZERO, THEN 
*             THE ACB AND ALL ITS ACNB WILL HAVE THE FLAG SET.
* 
*           . FC/BRK - NIP WILL FORMAT A NETWORK BREAK ELEMENT (SEE 
*             CCP IMS) AND QUEUE IT DIRECTLY TO THE OUTBOUND CHAIN. 
*             ANY DOWNLINE DATA QUEUED IN THE NCNB IS DISCARDED.  THE 
*             STATE OF THE CONNECTION IS SET TO WAITING FOR A NETWORK 
*             RESET ELEMENT.  ANY UPLINE DATA RECEIVED AHEAD OF THE 
*             RESET ELEMENT IS DISCARDED. 
* 
*           . FC/INIT/N - NIP WILL FORMAT A NETWORK INITR ELEMENT (SEE
*             CCP IMS) AND QUEUE IT DIRECTLY TO THE NETWORK OUTBOUND
*             CHAIN.  ANY DOWNLINE DATA QUEUED IN THE NCNB IS DISCARDED.
*             THE STATE OF HE CONNECTION IS SET TO WAITING FOR A NETWORK
*             INITN ELEMENT.  ANY UPLINE DATA RECEIVED AHEAD OF THE 
*             INITN ELEMENT ARE QUEUED IN THE ACNB FOR THE APPLICATION. 
* 
*           . FC/RST - NIP WILL FORMAT A NETWORK RESET ELEMENT (SEE 
*             CCP IMS) AND QUEUE IT DIRECTLY TO THE NETWORK OUTBOUND
*             CHAIN UNLESS NIP WAS NOT EXPECTING THE APPLICATION TO 
*             SEND THIS SUPERVISORY MESSAGE, IN WHICH CASE NIP DISCARDS 
*             IT AND SENDS AN ERROR LOGICAL SUPERVISORY MESSAGE BACK
*             TO THE APPLICATION.  IF THE MESSAGE WAS EXPECTED, NIP 
*             WILL UPDATE THE STATE OF THE CONNECTION AND DISCONTIUE
*             DISCARDING ALL UPLINE DATA MESSAGES FOR THAT CONNECTION.
* 
*           . HOP/ALT - NIP WILL VERIFY IF THE APPLICATION IS VALIDATED 
*             FOR THE NAM K-DISPLAY.  IF NOT, THE SUPERVISORY MESSAGE 
*             IS REJECTED AND AN ERROR LOGICAL SUPERVISORY MESSAGE IS 
*             SENT TO THE APPLICATION.  IF VALID AND THE OPERATOR HAS 
*             NOT DIRECTED NIP TO IGNORE ALERTS FROM THIS APPLICATION,
*             NIP WILL POST THE APPLICATION NAME ON ITS ALERT LINE. 
* 
*           . HOP/DIS - NIP WILL VERIFY IF THE APPLICATION HAS THE
*             K-DISPLAY ASSIGNED TO IT.  IF NOT, THE SUPERVISORY MESSAGE
*             IS REJECTED AND AN ERROR LOGICAL SUPERVISORY MESSAGE IS 
*             SENT TO THE APPLICATION.  IF VALID, NIP WIL UPDATE ITS
*             K-DISPLAY BUFFERS.
* 
*           . HOP/LOG - NIP WILL WRITE THE MESSAGE TEXT TO ITS DAYFILE. 
* 
*           . INTR/APP - NIP WILL FORMAT A ICMD NETWORK ELEMENT AND 
*             SEND IT TO THE NETWORK. 
* 
*           . INTR/RSP - NIP WILL VERIFY THIS SUPERVISORY MESSAGE WAS 
*             EXPECTED FOR THE CONNECTION SPECFIED IN THE ACN FIELD.
*             IF NOT, THE MESSAGE IS REJECTED AND AN ERROR LOGICAL
*             SUPERVISORY MESSAGE IS SENT TO THE APPLICATION.  IF IT WAS
*             EXPECTED, NIP WILL FORM A ICMDR NETWORK ELEMENT AND SEND
*             IT TO THE NETWORK.  THE STATE OF THE CONNECTION WILL ALSO 
*             BE UPDATED TO NO LONGER EXPECT AN INTERRUPT RESPONSE. 
* 
*           . LST/FDX OR LST/HDX - NIP WILL CLEAR OR SET THE HALF DUPLEX
*             FLAG IN THE ACNB SPECIFIED BY ACN . IF THE ACN VALUE IS 
*             ZERO, THEN THE ACB AND ALL ITS ACCB"S WILL HAVE THE HALF
*             DUPLEX FLAG CLEARED OR SET. 
* 
*           . LST/ON OR LST/OFF - NIP WILL TURN THE LIST ON FLAG ON 
*             OR OFF IN THE ACNB SPECIFIED IN THE ACN OF THE MESSAGE. 
* 
*           . LST/SWH - NIP WILL UPDATE THE LIST NUMBER IN THE ACNB 
*             SPECIFIED BY THE ACN FIELD OF THE MESSAGE.
* 
*           . PRU/ON - NIP VERIFIES THE APPLICATION IS ALLOWED TO SEND
*             THIS SUPERVISORY MESSAGE.  IF NOT, IT IS DISCARDED AND
*             AN ERROR LOGICAL SUPERVISORY MESSAGE IS RETURNED TO THE 
*             APPLICATION.  IF VALID, THE NCNB IS FOUND AND CONVERTED 
*             TO A PCNB.  THE PCNB IS LINKED TO THE PRU CONNECTION
*             RING. 
* 
*         NIP PROCESSES ONE SPECIAL SUPERVISORY MESSAGE FROM NS.  IF
*         ANY OTHER APPLICATION SENDS THIS SUPERVISORY MESSAGE TO NIP,
*         NIP WILL REJECT THE MESSAGE AND SEND THE APPLICATION AN ERROR 
*         LOGICAL SUPERVISORY MESSAGE.  THIS SUPERVISORY MESSAGE IS THE 
*         FOLLOWING 
* 
*           . NPD/REL/R - NIP WILL SEND A HOP/REL SUPERVISORY MESSAGE 
*             TO ALL APPLICATIONS.
* 
*         NIP ALSO PROCESSES A SET OF ASYNCHRONOUS SUPERVISORY MESSAGES 
*         WHICH ARE ALLOWED ONLY FROM NVF.  IF ANY OTHER APPLICATION
*         TRIES TO SEND THEM, NIP WILL REJECT THE MESSAGE AND SEND THE
*         APPLICATION AN ERROR LOGICAL SUPERVISORY MESSAGE.  THOSE
*         SUPERVISORY MESSAGES ARE ARE THE FOLLOWING: 
* 
*           . CR/IAP/N/A - NVF HAS ACCEPTED OR REJECTED THE APPLICATION 
*             TO APPLICATION CONNECTION REQUEST.  IF NVF HAS ACCEPTED 
*             IT, NIP WILL SEND A ICN/AP/R SUPERVISORY MESSAGE TO THE 
*             NETWORK AND THE STATE OF THE CONNECTION IS UPDATED.  IF 
*             NVF HAS REJECTED THE A-A CONNECTION REQUEST, A CON/ACRQ/A 
*             SUPERVISORY MESSAGE IS SENT BACK TO THE APPLICATION AND 
*             ALL APPLICABLE TABLE STRUCTURES FOR THE CONNECTION ARE
*             CLEARED.
* 
*           . CR/ITE/N/A - NVF HAS ACCEPTED OR REJECTED THE TERMINAL
*             CONNECTION.  IF NVF HAS ACCEPTED IT, NIP WILL SEND AN 
*             ICN/TE/N SUPERVISORY MESSAGE RESPONSE AND INITR NETWORK 
*             ELEMENT TO THE NETWORK AND UPDATE THE STATE OF THE
*             CONNECTION ACCORDINGLY.  IF NVF HAS REJECTED THE TERMINAL 
*             CONNECTION, AN ICN/TE/A SUPERVISORY MESSAGE IS SENT TO
*             THE NETWORK AND ALL APPLICABLE TABLE STRUCTURES FOR THE 
*             CONNECTION ARE CLEARED. 
* 
*           . CR/RAP/N/A - NVF HAS ACCEPTED OR REJECTED THE APPLICATION 
*             TO APPLICATION CONNECTION REQUEST.  IF NVF HAS ACCEPTED 
*             IT, NIP WILL SEND AN ICN/AP/N OR ICN/EX/N SUPERVISORY 
*             MESSAGE RESPONSE AND INITR NETWORK ELEMENT TO THE NETWORK 
*             AND UPDATE THE STATE OF THE CONNECTION ACCORDINGLY. 
*             IF NVF HAS REJECTED THE A-A CONNECTION REQUEST, AN
*             ICN/AP/A OR ICN/EX/A SUPERVISORY MESSAGE IS SENT TO 
*             THE NETWORK AND ALL APPLICABLE TABLE STRUCTURES FOR THE 
*             CONNECTION ARE CLEARED. 
* 
*           . CR/RCN/N/A - NVF HAS ACCEPTED OR REJECTED THE RECONNECT 
*             OF A NETWORK CONNECTION.  IF NVF HAS ACCEPTED IT, NIP 
*             WILL SEND IT AN FC/INIT/R SUPERVISORY MESSAGE AND UPDATE
*             THE STATE OF THE CONNECTION ACCORDINGLY.  IF NVF REJECTS
*             THE RECONNECT, IT IS BECAUSE THE CONNECTION WAS BEING 
*             SWITCHED TO A SECONDARY APPLICATION AND COULD NOT BE
*             SWITCHED.  NIP WILL THEN RECONNECT THE TERMINAL TO THE
*             PRIMARY APPLICATION, SEND IT A CON/REQ/R SUPERVISORY
*             MESSAGE, AND UPDATE THE STATE OF THE CONNECTION.
* 
*           . CR/SWH/R - NVF IS SWITCHING THE CONNECTION FROM ITSELF
*             TO ANOTHER APPLICATION.  NIP WILL SWITCH THE CONNECTION 
*             TO THE SPECIFIED APPLICATION, SEND THAT APPLICATION A 
*             CON/REQ/R SUPERVISORY MESSAGE, AND UPDATE THE STATE OF
*             THE CONNECTION UNLESS THE SPECIFIED APPLICATION IS NO 
*             LONGER AVAILABLE IN WHICH CASE, NIP WILL SEND A CR/RCN/R
*             SUPERVISORY MESSAGE BACK TO NVF.  IN ANY CASE NIP ALWAYS
*             RESPONDS TO THE CR/SWH/R SUPERVISORY MESSAGE WITH A 
*             CR/SWH/N SUPERVISORY MESSAGE RESPONSE.
* 
*           . CR/TRM/R - NVF IS TERMINATING ONE OF ITS CONNECTIONS. 
*             NIP WILL CLEAN UP ANY DATA STRUCTURES ASSOCIATED WITH THE 
*             HOST SIDE PROCESSING OF THE CONNECTION AND SEND NVF A 
*             CR/TRM/N SUPERVISORY MESSAGE RESPONCE.  ON THE NETWORK
*             SIZE OF THE CONNECTION, NIP WILL SEND A TCN/TA/R
*             SUPERVISORY MESSAGE TO THE NETWORK AND UPDATE THE STATE 
*             OF THE CONNECTION ACCORDINGLY.
* 
*           . FAIL/APP/N - NIP WILL TERMINATE ALL SCP LONG AND SHORT
*             TERM CONNECTIONS IT HAS WITH THE APPLICATION.  ALL DATA 
*             STRUCTURES ASSOCIATED WITH THE APPLICATION ARE ALSO 
*             CLEARED.
* 
*           . NET/OFF/N - NIP WILL TERMINATE ALL SCP LONG AND SHORT 
*             TERM CONNECTIONS IT HAS WITH THE APPLICATION.  ALL DATA 
*             STRUCTURES ASSOCIATED WITH THE APPLICATION ARE ALSO 
*             CLEARED.
* 
*           . NET/ON/N/A - NVF HAS ACCEPTED OR REJECTED THE NETON 
*             REQUEST OF THE APPLICATION.  IF NVF HAS ACCEPTED THE
*             NETON REQUEST, NIP WILL SWAP IN THE APPLICATION, SET UP 
*             A SCP LONG TERM CONNECTION WITH THE APPLICATION AND WRITE 
*             BACK TO AIP-S FIELD LENGTH TO INFORM IT THE NETON WAS 
*             ACCEPTED.  IF NVF REJECTED THE NETON REQUEST, NIP WILL
*             SWAP IN THE APPLICATION, WRITE BACK TO AIP-S FIELD
*             LENGTH THE REASON CODE FOR WHY THE NETON WAS REJECTED,
*             AND TERMINATE THE SCP SHORT TERM CONNECTION IT HAS WITH 
*             THE APPLICATION.
* 
*       . FOR ABT= 4 NIP ASSURES THAT THE SENDER IS EITHER NS OR CS.
*         IF NOT NIP REJECTS THE MESSAGE. THESE MESSAGE HAVE A
*         SPECIAL APPLICATION BLOCK HEADER WORD THAT IS ACTUALLY A
*         NETWORK HEADER WORD.  NIP SENDS THESE ASYNCHRONOUS
*         SUPERVISORY MESSAGES TO THE NETWORK FOR THE NPU TO PROCESS. 
* 
*     IN SUMMARY THEN, A NETPUT CALL TO AIP RESULTS IN THE MESSAGE THUS 
*     PUT BEING EITHER COMPLETELY PROCESSED AND DISCARDED BY NIP
*     OR CONVERTED TO A NEW MESSAGE OR NETWORK ELEMENT AND/OR QUEUED TO 
* 
*        A. PIP OUTBOUND CHAIN (FOR PIP TO SEND TO NETWORK),
* 
*        B. A NCNB ( IF IT WAS A DATA MESSAGE OR SYNCHRONOUS SUPERVISORY
*           MESSAGE AND THE LOGICAL LINK IS IN REGULATION OR THE
*           CONNECTIONS-S DOWNLINE BLOCK LIMIT HAS BEEN REACHED.
* 
*        C. A SPECIAL NIP CHAIN (IF IT WAS A MESSAGE FOR A INTRAHOST
*           APPLICATION TO APPLICATION CONNECTION). 
* 
*        D. NVF-S ACB FOR SPECIAL ASYCHRONOUS SUPERVISORY MESSAGE 
*           PROCESSING. 
* 
*     DOWNLINE NETWORK MESSAGES ARE PLACED IN THE PIP OUTBOUND CHAIN OR 
*     NCNB OR SPECIAL NIP CHAIN BY CALLING SUBROUTINE NFOB. 
*     DOWNLINE NETWORK MESSAGES ARE ALWAYS IN ONE OF THREE PRIORITIES.
*     NIP THUS HAS THREE DIFFERENT CHAINS FOR DOWNLINE MESSAGES, ONE
*     FOR EACH PRIORITY.  THE HIGHEST PRIORITY MESSAGES ARE ASYNCHRONOUS
*     SUPERVISORY MESSAGES QUEUED FOR EITHER PIP, CCP, OR THE MDI TO
*     PROCESS.  THESE MESSAGES ORIGINATE FROM EITHER NIP, NS, OR CS.
*     DOWNLINE BACK NETWORK ELEMENTS ARE ALSO SENT ON THIS HIGHEST
*     PRIORITY CHAIN TO HELP PREVENT CCP FROM GOING INTO REGULATION.
*     THE SECOND HIGHEST PRIORITY CHAIN IS USED FOR HIGH PRIORITY 
*     CONNECTIONS.  ALL NETWORK ELEMENTS EXCEPT BACKS FOR HIGH PRIORITY 
*     CONNECTIONS ARE SENT ON THE SECOND CHAIN.  THE THIRD CHAIN IS 
*     USED FOR SENDING MESSAGES ON LOW PRIORITY CONNECTIONS.
*     THERE IS A SET OF THREE OUTBOUND CHAINS FOR EACH FRONT END NPU
*     AND MDI.
* 
*       . FOR BT = BLK, MSG, QBLK, OR QMSG, THE 8 BIT STATUS FIELD FROM 
*         THE ABH FIELD IS MOVED INTO THE NETWORK BLOCK DBC FIELD.
*         THE APPLICATION BLOCK HEADER IN CONVERTED TO A NETWORK HEADER 
*         USING ADDRESSING INFORMATION FROM THE NCNB. 
* 
*       . THE CHARACTER COUNT AND ACT FIELDS FROM THE ABH ARE PASSED
*         TO PIP IN THE CM WORD CONTAINING THE NETWORK BLOCK HEADER 
*         + OPTIONAL DBC. 
* 
*       . FOR ALL DATA MESSAGES AND SYNCHRONOUS SUPERVISORY MESSAGES, 
*         AN ACKNOWLEDGE QUEUE ENTRY IS CREATED WHEN THE MESSAGE IS 
*         QUEUED TO THE NETWORK OUTBOUND CHAIN.  THE ACK QUEUE ENTRY IS 
*         JUST A COPY OF THE ABH, EXCEPT THAT A BSN IS INSERTED IN
*         THE ADR FIELD OF THE ABH. 
* 
*     THE DOWNLINE OUTBOUND CHAIN IS CONTROLED THROUGH THE NETWORK
*     BUFFER TABLE (NBT).  THERE IS ONE NBT ENTRY FOR EACH
*     FRONT END NPU AND MDI.  THE NBT ENTRY ITSELF IS MADE UP OF
*     FIVE PSEUDO FETS.  THE FIRST TWO PSEUDO FETS ARE USED FOR UPLINE
*     MESSAGE PROCESSING.  THE LAST THREE PSEUDO FETS ARE USED FOR
*     DOWNLINE MESSAGE PROCESSING, ONE FOR EACH OF THE THREE PRIORITIES.
*     THE DOWNLINE MESSAGE PSEUDO FETS ARE DIFFERENT FROM THE USUAL 
*     CONCEPT OF A FET SINCE IT DOES NOT POINT TO A CONTIGUOUS BUFFER 
*     IN CORE, RATHER IT POINTS TO MESSAGES LINKED TOGETHER BY FORWARD
*     POINTERS. QUEUEING THE MESSAGE IN THE OUTBOUND CHAIN CONSISTS OF
*     THE FOLLOWING STEPS:  
* 
*       .INITIALLY ALL FET POINTERS EQ 0.  THEN THEY ARE USED AS FOLLOWS
* 
*           FIRST = ADDR OF FIRST BUFFER IN OUTBOUND CHAIN
*           IN    = ADDR OF LAST BUFFER QUEUED IN OUTBOUND CHAIN
*           OUT   = ADDR OF LAST BUFFER IN OUTBOUND CHAIN PROCESSED BY
*                   PIP 
*           LIMIT = UNUSED
* 
*       .IF OUT " 0, PIP HAS PROCESSED MESSAGES QUEUED ON THE OUTBOUND
*        CHAIN.  FIRST IS RESET TO OUT AND ALL MESSAGES BETWEEN FIRST 
*        AND OUT ARE RELEASED TO THE FREE BUFFER CHAIN. 
* 
*       .IF IN " 0, NIP HAS QUEUED MESSAGES TO THE OUTBOUND CHAIN.  THE 
*        FORWARD POINTER OF THE LAST ENTRY QUEUED BY NIP IS UPDATED TO
*        POINT TO THE NEW ENTRY.
* 
*       .IF IN = 0, THIS IS FIRST MESSAGE TO BE QUEUED IN THE OUTBOUND
*        CHAIN.  SET FIRST TO POINT TO THE FIRST MESSAGE. 
* 
*       .SET IN TO POINT TO THE NEW MESSAGE.
* 
*     ONCE A MESSAGE IS PUT IN PIP-S OUTPUT BUFFER IT IS A NONMOVABLE 
*     BUFFERS AND STAYS NONMOVABLE UNTIL IT GETS RELEASED TO THE FREE 
*     SPACE.
* 
*     PIP WILL READ AND DELIVER TO THE NPU MESSAGES IN PRIORITY ORDER.
*     IT WILL SEND TO THE NPU/MDI ALL THE ASYCHRONOUS SUPERVISORY 
*     MESSAGES FIRST.  THEN IT WILL SEND ALL HIGH PRIORITY CONNECTION 
*     MESSAGES UNTIL THERE ARE NONE LEFT OR AN ASYNCHRONOUS 
*     SUPERVISORY MESSAGE GETS QUEUED TO BE SENT TO THE NPU/MDI.
*     FINALLY IT WILL SEND ALL LOW PRIORITY CONNECTION MESSAGES UNTIL 
*     THERE ARE NONE LEFT OR AN HIGHER PRIORITY MESSAGE IS QUEUED.
* 
*     PIP"S PROCESSING OF AN OUTBOUND MESSAGE CONSIST OF THE FOLLOWING
*     STEPS:  
* 
*       . IF IN = OUT ALL MESSAGES IN THIS BUFFER HAVE BEEN PROCESSED 
* 
*       . IF IN " OUT THERE ARE SOME MESSAGES IN THE CHAIN TO BE
*         PROCESSED. IF OUT = 0 THE NEXT MESSAGE TO BE PROCESSED IS 
*         POINTED TO BY FIRST. IF OUT "0 THEN OUT POINTS TO THE 
*         FWA OF THE LAST MESSAGE OUTPUT. THE FORWARD POINTER IN THE
*         LAST MESSAGE THEN POINTS TO THE NEXT MESSAGE TO BE OUTPUT.
* 
*       . ONCE PIP DETERMINES WHERE THE NEXT MESSAGE IS IT READS IT UP
*         FROM CM. AFTER IT HAS READ THE MESSAGE IT DETERMINES IF THE 
*         DESTINATION NODE NUMBER IS PIP-S OWN NODE NUMBER (THE HOST
*         NODE NUMBER ORIGINALLY FOUND IN THE EST). IF IT IS, THEN
*         PIP WILL COMPLETELY PROCESS THAT MESSAGE (IT IS A MESSAGE 
*         FROM NS TO PIP. THIS IS THE MECHANISM USED TO LOAD, DUMP, OR
*         STATUS THE SAM PROGRAM OR NPU OR MDI). OTHERWISE PIP WILL 
*         REFORMAT THE MESSAGE AS FOLLOWS:  
* 
*            . IF ACT IS 4 CONVERT TO ASCII, ONE ASCII CHARACTER PER
*              12 BIT PP BYTE. 12-66 BITS OF ZEROES GET CONVERTED TO
*              A <US>.
* 
*            . CHANGE 8 BIT ASCII TO 12 BIT ASCII 
* 
*            . IF BT = BLK, MSG, QBLK, OR QMSG, TAKE THE 8 BITS FROM THE
*              HEADER AND MAKE IT THE FIRST BYTE OF THE MESSAGE TEXT
*              TO BE TRANSMITTED (DBC)
* 
*            . THUS THE MESSAGE TRAMSMITTED BY PIP TO CCP/MDI IS IN 
*              NETWORK FORMAT. FOR ITS EXACT FORMAT SEE THE NHP/CCP IFS.
*              OVER THE COUPLER THE UPPER 4 BITS OF EACH 12 BIT BYTE ARE
*              STRIPPED SO THAT ONLY THE 8 BITS ARRIVE AS 8 BIT BYTES 
*              TO BE RECEIVED BY CCP. 
* 
*       . AFTER THE MESSAGE IS PROCESSED BY PIP EITHER BY PERFORMING
*         THE APPROPRIATE ACTION OR BY SENDING THE MESSAGE OVER THE 
*         COUPLER TO THE NPU, IT WILL UPDATE THE PSEUDO FET IN NIP
*         SUCH THAT THE OUT POINTER POINTS TO THE LAST MESSAGE OUTPUT.
* 
*     NIP WILL RELEASE MESSAGES PROCESSED BY PIP BY UPDATING THE
*     FIRST POINTER (FIRST=OUT) AND BY CALLING MRELS TO RELEASE 
*     THE VARIOUS LINKED MESSAGES BETWEEN THE OLD FIRST POINTER AND 
*     THE NEW FIRST POINTER.
*     THE ONLY OTHER ASPECT TO REMEMBER ABOUT DOWNLINE DATA IS THAT 
*     ANYTHING (BLK-S, MSG-S, QBLK-S, QMSG-S, OR CMD-S) SENT ON A 
*     CONNECTION WILL BE ACKNOWLEDGED 
*     BY CCP/MDI, AND THIS ACKNOWLEDGEMENT WILL BE DELIVERED
*     TO THE APPLICATION. THE METHOD BY WHICH THIS IS DONE WILL BE
*     DISCUSSED IN THE UPLINE DATA (NEXT) SECTION OF THIS IMS.
* 
* 
*     2.2 UPLINE DATA 
* 
*     UPLINE DATA (ALSO REFERRED TO AS INPUT OR INBOUND DATA) ORIGINATES
*     FROM EITHER PIP, CCP, THE MDI, A TERMINAL DEVICE CONNECTED TO THE 
*     NETWORK, OR FROM ANOTHER APPLICATION RESIDING IN A HOST CONNECTED 
*     TO THE NETWORK. 
* 
*     AS MENTIONED EARLIER, THE NETWORK BUFFER TABLE CONTAINS TWO PSUEDO
*     FETS FOR UPLINE DATA PROCESSING.  TWO PSUEDO FETS ARE USED BECAUSE
*     A DOUBLE BUFFERING SCHEME IS USED FOR RECEIVING UPLINE DATA.  NIP 
*     INITIALLY ALLOCATES ONE BUFFER FOR RECEIVING UPLINE DATA.  THIS 
*     BUFFER IS POINTED TO BY ONE OF THE PSEUDO FET.  THE BUFFER IS BIG 
*     ENOUGH TO HOLD THE LARGEST NETWORK MESSAGE (WHICH IS 2043 
*     CHARACTERS) BUT WILL NORMALLY CONTAIN SEVERAL SMALLER MESSAGES
*     SINCE PIP WRITES MULTIPLE MESSAGES INTO THE BUFFER UNTIL THE
*     BUFFER IS NOT BIG ENOUGH FOR THE NEXT UPLINE MESSAGE.  EACH 
*     MESSAGE BEGINS WITH A BUFFER HEADER WORD WHICH CONSISTS OF A
*     BUFFER ID AND A BUFFER SIZE WHICH IS THE SIZE OF THE UPLINE 
*     MESSAGE IN WORDS INCLUDING THE BUFFER HEADER WORD.  WHEN PIP
*     DETECTS THAT THE BUFFER IS NO LONGER BIG ENOUGH, IT WILL SET A
*     FLAG IN THE PSEUDO FET INFORMING NIP THAT IT IS NO LONGER USING 
*     THE BUFFER AND NIP CAN RELEASE THE REMAINING BUFFER SPACE.
*     NIP ALLOCATES A NEW BUFFER WHEN EITHER THE EXISTING BUFFER IS OVER
*     HALF USED OR PIP HAS SET THE FLAG INDICATING IT IS THROUGH WITH 
*     THE EXISTING BUFFER AND NIP NEEDS TO ALLOCATE A NEW ONE.
*     THE NEW BUFFER IS POINTED TO BY THE FET THAT IS CURRENTLY NOT 
*     BEING USED.  THUS NIP AND PIP TOGGLE BETWEEN USING THE TWO FETS.
*     AFTER NIP ALLOCATES THE BUFFER, 
*     NIP SETS A FLAG IN THE PSEUDO FET TO INFORM PIP THAT THE PSUEDO 
*     FET CONTAINS VALID BUFFER POINTERS.  NIP PROCESSES UPLINE MESSAGES
*     FROM ONE UPLINE BUFFER AT A TIME EVEN THOUGH TWO BUFFERS MAY
*     EXIST.  NIP BEGINS PROCESSING WITH THE FIRST BUFFER ALLOCATED AND 
*     CONTINUES PROCESSING THAT UPLINE BUFFER UNTIL PIP INFORMS NIP THAT
*     IT IS THROUGH USING THE BUFFER AND IT CAN BE RELEASED.  AT THAT 
*     POINT, NIP WILL SWITCH TO THE SECOND BUFFER (IF NOT ALREADY 
*     ALLOCATED, IT IS ALLOCATED AT THIS POINT).  WHEN PIP DETECTS THAT 
*     THE UPLINE BUFFER IS IS CURRENTLY USING IS NOT BIG ENOUGH FOR THE 
*     NEXT MESSAGE, IT WILL SWITCH TO THE SECOND UPLINE DATA BUFFER IF
*     IT HAS ALREADY BEEN ALLOCATED.
* 
*     WHEN PIP IS READY TO RECEIVE DATA FROM THE LOCAL NPU, IT FUNCTIONS
*     THE COUPLER TO READ THE NPU STATUS WORD. WHEN THE NPU RETURNS A 
*     -INPUT AVAILABLE, LESS THAN 256 CHARACTERS OR LESS THAN 2043
*     CHARACTERS- STATUS, PIP PROCEEDS TO DETERMINE IF THERE IS ENOUGH
*     SPACE IN NIP-S INBOUND BUFFER TO ACCOMODATE THE INCOMING MESSAGE. 
*     IF THERE IS NOT ENOUGH BUFFER SPACE AND NIP HAS NOT ALLOCATED A 
*     SECOND BUFFER, PIP SENDS A - NOT READY FOR INPUT - ORDER WORD TO
*     NOTIFY THE NPU THE HOST IS NOT YET READY TO 
*     ACCEPT THE INPUT.  IF THERE IS SPACE
*     AVAILABLE, PIP WOULD FUNCTION THE COUPLER TO INPUT DATA AND 
*     ACTIVATE THE CHANNEL TO RECEIVE UPLINE DATA VIA THE IAM INSTRUCT- 
*     ION. INPUT DATA TRANSFER TERMINATES WHEN COUPLER DISCONNECTS THE
*     CHANNEL FOLLOWING TRANSFER OF THE LAST CHARACTER (WITH BIT 11 SET)
*     OF THE UPLINE DATA.  PIP DETERMINES 
*     THE AMOUNT OF DATA IT RECEIVES FROM THE A-REGISTER CONTENT WHEN 
*     THE IAM INSTRUCTION IS COMPLETED, SINCE THE A-REGISTER
*     NOW HOLDS THE BLOCK LENGTH (A-REGISTER CONTENT WHEN IAM 
*     IS CALLED) MINUS THE NUMBER OF REAL DATA WORDS READ. THE NETWORK
*     SENDS A MAXIMUM OF 2043 CHARACTERS FOR EACH UPLINE BLOCK.  FOR
*     SUCH LARGE BLOCKS, BECAUSE OF THE LIMITED PIP BUFFER SPACE, IT
*     MAY TAKE MORE THAN ONE INPUT OPERATIONS TO COMPLETE THE INPUT 
*     TRANSFER. PIP WRITES THE INPUT DATA TO NIP-S INBOUND BUFFER AND 
*     UPDATES THE -IN- POINTER IN THE INPUT FET TO POINT TO THE LAST
*     MESSAGE INPUT. MESSAGE TEXT LENGTH IN THE NETWORK HEADER IS ALSO
*     UPDATED TO REFLECT THE PROPER CHARACTER COUNT (CHARACTER TRANS- 
*     FERRED MINUS THE HEADER SIZE, FOR BLOCK TYPES -BLK- AND -MSG- AN
*     ADDITIONAL CHARACTER FOR THE DATA BLOCK CLARIFIER IS INCLUDED IN
*     THE HEADER).
* 
*     INBOUND DATA IS ALL DATA FROM NETWORK TO NIP. ALL DATA IS 
*     TRANSMITTED TO NIP BY PIP AND PLACED IN INBOUND MESSAGE BUFFERS 
*     PROVIDED BY NIP.
* 
*     NIP INBOUND FET PROTOCOL CONSISTS OF: 
* 
*       . FET INITIALIZATION STATE
* 
*            . WHEN NIP LINKS A BUFFER TO FET, FIRST POINTER = IN = OUT 
*              = START OF BUFFER. LIMIT POINTER = BUFFER LAST WORD
*              ADDRESS + 1 AND NIP CLEARS THE BUSY BIT IN THE LAST WORD 
*              OF THE FET.
* 
*       . IF OUT " IN, NIP USES THE OUT POINTER TO GET THE UPLINE MSG 
*         ADDRESS. NIP DELINKS A MESSAGE FROM THE INBOUND CHAIN AND 
*         UPDATES OUT TO POINT TO THE NEXT UPLINE MSG. IF IN = OUT, ALL 
*         MESSAGES HAVE BEEN PROCESSED FROM THE CURRENT BUFFER.  IF 
*         OUT IS GREATER THAN THE MIDDLE BUFFER POINTER, A NEW BUFFER IS
*         ALLOCATED FOR THE SECOND INBOUND FET.  ITS FET POINTERS ARE 
*         INITIALIZED AS MENTIONED ABOVE.  NIP ALSO SETS THE FLAG TO
*         INFORM PIP THE FET CONTAINS VALID BUFFER POINTERS.
* 
*       . IF THE RELEASE BIT IS SET IN THE INBOUND FET, NIP CHECKS IF 
*         A SECOND BUFFER HAD NOT ALREADY BEEN ALLOCATED.  IF NOT, IT 
*         ALLOCATES IT RIGHT AWAY.  IT THEN PROCESSES THE MESSAGES IN 
*         THE CURRENT INBOUND BUFFER AND RELEASES ANY REMAINING SPACE 
*         AFTER IT IS THROUGH PROCESSING ALL THE MESSAGES.
* 
*     PIP INBOUND FET PROTOCOL CONSISTS OF: 
* 
*       . PIP USES IN POINTER TO BEGIN THE POT HEADER STORAGE FOLLOWED
*         BY THE MESSAGE. PIP SETS IN = ADDRESS OF THE NEXT FREE
*         LOCATION IN THE BUFFER. 
* 
*       . IF THE MESSAGE CANNOT FIT IN BUFFER, PIP SETS THE RELEASE FLAG
*         FET.
* 
*       . IF THE RELEASE FLAG IS SET OR THE BUFFER AVAILABLE FLAG IS NOT
*         SET, PIP WILL NOT USE THIS BUFFER.
* 
*     THE NIP ROUTINE NEIB EMPTIES THE INPUT BUFFER(PBI) THAT PIP HAS 
*     FILLED WITH NETWORK DATA. 
* 
*       . IF IN = OUT THEN THE PIP INPUT BUFFER IS EMPTY AND NIP RETURNS
*         TO ITS MAIN LOOP IN XEXEC.
* 
*       . IF IN " OUT THEN THE INPUT BUFFER IS NOT EMPTY. THE CURRENT 
*         MESSAGE IS LOCATED AT OUT.
* 
*     ONCE NIP HAS RECEIVED A MESSAGE FROM PIP, NIP CONVERTS THAT 
*     MESSAGE"S NETWORK HEADER (DN,SN,CN,...) TO AN APPLICATION BLOCK 
*     HEADER (ABT,ABN,ACT,TLC...).
* 
*     IF THE MESSAGE"S CONNECTION NUMBER (CN) IS ZERO, THEN THE MESSAGE 
*     IS AN ASYNCHRONOUS SUPERVISORY MESSAGES DESTINED FOR EITHER NIP,
*     NS, OR CS TO PROCESS.  NIP DETERMINES WHO PROCESSES THE 
*     MESSAGE BASED ON THE PFC VALUE OF THE SUPERVISORY MESSAGE.
*     MESSAGES DESTINED FOR CS HAVE A PFC VALUE IN THE RANGE OF 14 TO 
*     47.  MESSAGES DESTINED FOR NS HAVE A PFC VALUE IN THE RANGE OF
*     0 TO 13.  FOR NETWORK MESSAGES DESTINED FOR CS/NS, NIP DOES NOT 
*     CREATE THE NORMAL APPLICATION BLOCK HEADER WORD.  INSTEAD THE 
*     NETWORK HEADER IS SHIFTED TO THE LEFT AND THE SPECIAL BLOCK HEADER
*     TYPE OF 4 IS ADDED.  THE MESSAGE IS THEN QUEUED TO NS/CS-S ACB. 
*     IF THE SUPERVISORY MESSAGE IS NOT IN THESE RANGES, THEN NIP CHECKS
*     IF IT IS ONE OF THE ONES FOR NIP TO PROCESS.  IF NOT, NGIGO IS
*     CALLED TO DISCARD THE MESSAGE.  NPNIPSM IS CALLED TO PROCESS ALL
*     SUPERVISORY MESSAGES DESTINED FOR NIP.
*     IF THE CURRENT MESSAGE-S CONNECTION NUMBER (CN) IS NON-ZERO, THEN 
*     THE MESSAGE IS PROCESSED BY THE NETWORK BLOCK STATE TABLE 
*     PROCESSOR UNLESS IT IS A DATA MESSAGE IN WHICH CASE THE STATE 
*     TABLE PROCESSOR IS BYPASSED.  THE MESSAGE IS QUEUED TO THE
*     ACNB OF THE APPLICATION CONNECTION CORRESPONDING TO THE NETWORK 
*     CONNECTION OF THE UPLINE MESSAGE.  PROCESSING OF THE MESSAGE BY 
*     THE NETWORK BLOCK STATE TABLE PROCESSOR IS DETERMINED BY THE STATE
*     OF THE CONNECTION AND THE BLOCK TYPE OF THE UPLINE MESSAGE. 
* 
*       . BLK,MSG,CMD,QMSG,QBLK - IF STILL BEING ESTABLISHED, NIP 
*                                 DISCARDS THESE BLOCK TYPES.  OTHERWISE
*                                 THE MESSAGE IS QUEUED TO THE ACNB 
*                                 AND THE APPLICATION IS SWAPPED IN 
*                                 IF IT HAD PREVIOUSLY BEEN SWAPPED 
*                                 OUT (OSCHAPP CALLED). 
* 
*       . BACK - NIP VERIFIES THE BSN OF THE BACK MATCHES THE ONE IT WAS
*                EXPECTED.  IF IT MATCHES, A FC/ACK SUPERVISORY MESSAGE 
*                IS CREATED AND QUEUED ON THE APPLICATION-S ACB DATA
*                RING.  THE ASSOCIATED ACKNOWLEDGE QUEUE ENTRY FOR THAT 
*                BACK IS RELEASED.  IF THE BSN DOES NOT MATCH, THE
*                ENTIRE ACKNOWLEDGE QUEUE IS SEARCHED FOR A MATCH.  IF
*                NONE IS FOUND, THE BACK BLOCK IS DISCARDED.  IF A MATCH
*                IS FOUND, A FC/NAK SUPERVISORY MESSAGE IS CREATED FOR
*                EACH ACKNOWLEDGE QUEUE ENTRY BEFORE THE MATCHING ONE.
*                A FC/ACK SUPERVISORY MESSAGE IS THEN CREATED FOR THE 
*                MATCHING ONE AND ALL ACKNOWLEDGE QUEUE ENTRIES FOR 
*                WHICH AN FC/ACK OR FC/NAK WAS CREATED ARE RELEASED.
* 
*       . BRK - NIP RELEASES ALL DATA AND SYNCHRONOUS SUPERVISORY 
*               MESSAGES QUEUED DOWNLINE IN THE NCNB.  A FC/BRK 
*               SUPERVISORY MESSAGE IS CREATED AND QUEUED TO THE
*               THE APPLICATION-S ACB DATA RING.
*               THE STATE OF THE CONNECTION IS CHANGED TO WAITING 
*               FOR FC/RST SUPERVISORY MESSAGE RESPONSE FROM THE
*               APPLICATION.
* 
*       . ICMD - NIP CREATES A INTR/USR SUPERVISORY MESSAGE AND QUEUES
*                IT TO THE APPLICATION-S ACB DATA RING.  THE STATE
*                OF THE CONNECTION IS UPDATED TO EXPECT A INTR/RSP
*                SUPERVISORY MESSAGE RESPONSE FROM THE APPLICATION. 
* 
*       . ICMDR - NIP CREATES A INTR/RSP SUPERVISORY MESSAGE AND QUEUES 
*                 IT TO THE APPLICATION-S ACB DATA RING.  THE STATE 
*                 OF THE CONNECTION IS UPDATED TO REFLECT RECEIVING 
*                 THE ICMDR BLOCK.
* 
*       . INITR - NIP RESPONDS TO THE INITR BLOCK BE SENDING A INITN
*                 BLOCK BACK TO THE NETWORK IN RESPONSE.  THE UPLINE
*                 DATA PATH HAS NOT BEEN INITIALIZED. 
* 
*       . INITN - NIP CREATES A FC/INIT SUPERVISORY MESSAGE AND QUEUES
*                 IT TO THE APPLICATION-S ACB DATA RING.  THE STATE 
*                 OF THE CONNECTION IS UPDATED TO EXPECT AN FC/INIT/N 
*                 SUPERVISORY MESSAGE FROM THE APPLICATION. 
* 
*       . RST - NIP CREATES A FC/RST SUPERVISORY MESSAGE AND QUEUES 
*               IT TO THE APPLICATION-S ACB DATA RING.  THE STATE 
*               OF THE CONNECTION IS UPDATED TO REFLECT RECEIVING 
*               THE RESET BLOCK.
* 
*       . TERM - IF THE TERM IS IN RESPONSE TO A PREVIOUS TERM SENT BY
*                NIP TO THE NETWORK, NIP RESPONDS WITH A TCN/TA/N 
*                SUPERVISORY MESSAGE AND CLEANS UP ALL DATA STRUCTURES
*                ASSOCIATED WITH THE NETWORK SIDE OF THE CONNECTION.
*                IF THE TERM IS IN RESPONSE TO A TCN/TA/R SUPERVISORY 
*                MESSAGE SENT BY NIP TO THE NETWORK, NIP RESPONDS 
*                WITH A TERM BLOCK RESPONSE.  THE STATE OF THE
*                CONNECTION IS UPDATED TO EXPECT THE TCN/TA/N 
*                SUPERVISORY MESSAGE. 
* 
*     IF THE MESSAGE IS UNRECIGNIZABLE (ILLEGAL BLOCK TYPE, ACB OR
*     ACNB NOT FOUND) THEN NGIGO IS CALLED TO DAYFILE THE MESSAGE 
*     TO NIP DAYFILE. 
* 
*     AN APPLICATION MAY READ THE MESSAGES QUEUED FOR IT BY CALLING 
*     NETGET,NETGETL,NETGETF, OR NETGTFL. THESE AIP ROUTINES COMMUNICATE
*     WITH NIP VIA SYSTEM CONTROL POINT CALLS. NIP WILL WRITE THE TEXT
*     OF THE MESSAGE DIRECTLY TO THE AREA THAT THE APPLICATION HAS
*     RESERVED FOR THE TEXT. AIP WILL WRITE THE APPLICATION BLOCK HEADER
*     TO THE HEADER AREA RESERVED BY THE APPLICATION. 
* 
*     AS TO A TEXT THAT IS LONGER THAN THE APPLICATION SPECIFIED BUFFER,
*     THERE ARE OPTION SET IN ACNB BY SENDING OR NOT SENDING DC/TRU 
*     SUPERVISORY MESSAGES FOR THE ACNB TO NIP. 
*     IF AN APPLICATION HAS NOT SENT THE DC/TRU MESSAGE, THEN THE 
*     TEXT WILL NOT BE DELIVERED AND AIP OR NIP SETS A FLAG IN ABH TO 
*     INDICATE THAT THE INPUT BLOCK WAS NOT DELIVERABLE. THE TEXT LENGTH
*     IN CHARACTERS SPECIFIED IN THE ABH WILL BE THE ACTUAL SIZE OF THE 
*     TEXT,SO THAT THE APPLICATION MAY REPEAT THE GET REQUEST WITH A
*     LARGER BUFFER SIZE.  IF AN APPLICATION HAS SENT THE DC/TRU, 
*     THEN NIP SETS A FLAG IN ABH TO INDICATE THAT THE MESSAGE IS 
*     TRUNCATED AND DELIVERS THE MESSAGE TRUNCATED TO THE LENGTH
*     OF THE SPECIFIED BUFFER.
* 
*     IF AN APPLICATION HAS REQUESTED THAT HALF DUPLEX MODE IS ON 
*     (BY SENDING NIP A LST/HDX SUPERVISORY MESSAGE), THEN AFTER
*     ONE MSG BLOCK HAS BEEN READ FROM THE HOST SIDE ACNB, A
*     TEMPORARY LIST OFF FLAG IS SET AND THIS ACNB IS LONGER
*     CHECKED FOR UPLINE DATA UNTIL THE APPLICATION SENDS A DOWN- 
*     LINE MSG OR RETURNS TO FULL DUPLEX MODE BY SENDING NIP THE
*     SUPERVISORY MESSAGE LST/FDX. HALF DUPLEX ON ALLOWS THE
*     APPLICATION TO IMPLEMENT TYPE-AHEAD FOR TERMINAL USERS. 
* 
 *    NETWORK PRODUCTS DOCUMENTATION        PAGE
 *    NAM INTERNAL SPECIFICATION            DATE. 
 *    3.0 NIP TABLE STRUCTURE 
* 
*     NAM COMMON DECKS CONTAIN TEMPLATES FOR VARIOUS TABLES, COMMON 
*     BLOCKS, AND VALUES FOR FREQUENTLY USED VARIABLES. NIP COMMON
*     DECKS ARE ARRANGED ALPHABETICALLY EXCEPT WHEN ONE COMMON DECK 
*     USES VALUES FROM ANOTHER COMMON DECK. THE DOCUMENTATION THAT
*     FOLLOWS COVERS COMMON DECKS USED BY NAM ONLY, BUT NOT 
*     THE COMMON DECKS USED THROUGHOUT NETWORK HOST PRODUCTS FOR THE
*     VARIOUS SUPERVISORY MESSAGES. THE SUPERVISORY MESSAGE FORMATS 
*     ARE DOCUMENTED IN THE NAM RM (FOR USER APPLICATION SUPERVISORY
*     MESSAGES) AND IN THE SUPERVISION (CS-NS) IMS FOR MESSAGES USED
*     BY THE SUPERVISORS. 
 #
*ENDIF
 CONTROL EJECT; 
XREF  BEGIN 
  PROC    IRECVR;            # INITIATE RECOVERY                       #
  PROC    OVLCALL;           # LOAD OVERLAY                            #
  PROC    XEXEC;             # GOTO EXECUTION CONTROL PROCEDURE        #
END 
#* * * * * * * * * * ----------  TLIST   ----------* * * * * * * * * * #
CONTROL EJECT;
# * * * * * * * * * * * * * * * --- CRCOM --- * * * * * * * * * * * * *#
*CALL CRCOM 
*CALL CYBERDEFS 
*CALL MISDEF
*IF,DEF,IMS 
*CALL IMSPT 
*CALL IMSNBT
*CALL IMSPIT
*CALL IMSCET
*CALL IMSTNT
*CALL IMSAT 
*CALL IMSLLCB 
*CALL IMSNCNT 
*CALL IMSNCNB 
*CALL IMSACB
*CALL IMSACNT 
*CALL IMSACNB 
*CALL IMSPCNB 
*CALL IMSPOA
 #
*1DC  ACKNOWLEDGE QUEUE HEADER
*     THERE IS AN ACKNOWLEDGE QUEUE OF LENGTH ABL (APPLICATION BLOCK
*     LIMIT - SEE NDL REFERENCE MANUAL) FOR EACH ACTIVE CONNECTION ON 
*     THE NETWORK. THE ACKNOWLEDGE QUEUE HAS THE ABH (APPLICATION 
*     BLOCK HEADER) OF EACH MESSAGE THAT HAS BEEN SENT FROM NIP TO
*     PIP BUT HAS NOT YET BEEN ACKNOWLEDGE BY CCP. THE ACKNOWLEDGE
*     QUEUE ENABLES NIP TO MATCH THE BLOCK SEQUENCE NUMBER RECEIVED 
*     FROM CCP TO THE CORRECT APPLICATION BLOCK NUMBER SENT BY THE
*     APPLICATION, SO THAT NIP MAY RETURN THE ABN IN THE FC/ACK 
*     MESSAGE TO THE APPLICATION. 
*     THE ACKNOWLEDGE QUEUE IS CONTROLLED BY THE ACKNOWLEDGE QUEUE
*     HEADER OF THE FOLLWING FORMAT:  
*                            2               4           5
*      0          6          4               2           9
*     I----------I----------I---------------I-------------I 
*     I          I          I               I             I 
*     I  ACKQID  I  ACKQBS  I  ACKQLBSN     I ACKNCNB     I 
*     I          I          I               I             I 
*     I----------I----------I---------------I-------------I 
* 
*     WHERE 
*       ACKQID = ACKNOWLEDGE QUEUE BLOCK ID =3
*       ACKBS  = ACKNOWLEDGE QUEUE BLOCK SIZE = ABL+1 
*       ACKQLBSN = LAST BSN BACKED FROM CCP 
*       ACBNCNB = ADDRESS OF NCNB.
* 
*     ENTRIES IN THE ACKNOWLEDGE QUEUE HAVE THE SAME FORMAT AS THE ABH, 
*     EXCEPT THAT THE ADR FIELD CONTAINS THE BSN SENT TO CCP ON THE 
*     OUTGOING MESSAGE. 
* 
*     THE ACKNOWLEDGE QUEUE IS A MOVABLE BUFFER UNDER THE DEFAULT NIP 
*     INSTALLATION OPTION PERF1 OF DYNAMIC ALLOCATION. (SEE INPARU
*     DOCUMENTATION BELOW). WHEN THE ACKNOWLEDGE QUEUE IS STATICALLY
*     ALLOCATED, IT IS MOVABLE ONLY WITH ITS QCB. UNDER STATIC
*     ALLOCATION THE ACKNOWLEDGE QUEUE IS CREATED WHEN THE NETWORK
*     SIDE QCB IS CREATED. UNDER DYNAMIC ALLOCATION, THE ACKNOWLEDGE
*     QUEUE IS ONLY CREATED WHEN IT IS NEEDED.
 #
*ENDIF
*CALL ACKHEAD 
#* * * * * * * * * * ----------  AHEADER ----------* * * * * * * * * * #
    BASED ARRAY AHEADER[0:0] P(1);  # APPLICATION BLOCK HEADER #
      BEGIN 
*CALL HEADER
      END 
*IF,DEF,IMS 
 #
*1DC  APPSTAT 
*     APPSTAT IS A COMMON BLOCK OF VARIABLES THAT DESCRIBE THE STATUS 
*     OF THE WORKLIST CURRENTLY BEING PROCESSED. SEE SYMPL LISTING
*     FOR THE LIST OF VARIABLES IN THIS COMMON BLOCK
 #
*ENDIF
*CALL APPSTAT 
#* * * * * * * * * * ----------  AWLHEAD ----------* * * * * * * * * * #
*IF,DEF,IMS 
 #
*1DC  AWL - APPLICATION WORK LIST 
*     THE AWL IS THE MIDDLE PART OF THE ACB.  IT CONTAINS NIP-S 
*     REPLY TO THE NWL (NETWORK WORK LIST).  FOR THE FORMAT OF
*     THE NWL SEE NWL DESCRIPTION BELOW. THE AWL HAS A SIZE OF 6 WORDS
*     LONG AND IS WRITTEN BACK TO AIP WHENEVER A NWL IS RECEIVED THAT 
*     REQUIRES A REPLY.  THIS WOULD BE A NWL THAT CONTAINED EITHER A
*     NETON, GET, GETL, GETF, GTFL, GETMM, OR GETSM ENTRY.  IF THE NWL
*     CONTAINS A NETON NWL ENTRY, IT WILL BE THE ONLY ENTRY AND THE AWL 
*     WILL CONTAIN THE NETON RESPONSE BEGINNING IN THE FIRST WORD OF THE
*     AWL.  FOR NORMAL AWLS THE 6 WORDS ARE DIVIDED INTO 3 TWO WORD 
*     ENTRIES.  THE FIRST 2 WORDS WILL ALWAYS CONTAIN THE GET, GETL,
*     GETF, OR GTFL RESPONSE.  THE FIRST WORD OF THE
*     TWO WORD ENTRY HAS THE FORMAT 
*                       3 5       5       5 
*     0       6         6 4       9       9 
*     I-------I---------I-I-------I-------I 
*     I       I         I I       I       I 
*     I AWLRC I GETSMND I I AWLOP I AWLCB I 
*     I       I         I I       I       I 
*     I-------I---------I-I-------I-------I 
*     WHERE:  
*       GETSMND = NO OF SUPERVISORY MESSAGES DELIVERED, WHEN AWLOP=GETSM
*       AWLOP = THE AWL OP CODE. POSSIBLE OP CODES IN THE AWL ARE 
*               WLOPGET (2) FOR NETGET
*               WLOPGETL (3) FOR NETGETL
*               WLOPGETS (4) FOR NETGETSM, I.E GET SUPERVISORY MESSAGES 
*               WLOPNON  (6) FOR NETON
*               WLOPGETF (8) FOR NETGETF
*               WLOPGTFL (10)FOR NETGTFL
*               THERE IS NO AWL ENTRY (REPLY) FOR NETOFF, NETPUT, 
*               NETPUTF, OR NETWAIT.
*       AWLCB = THE COMPLETION BIT-IN THE ORIGINAL REQUEST IT IS CLEARED
*               BY AIP, AND IT IS SET TO 1 BY NIP.
* 
*     THE FORMAT OF THE SECOND WORD OF THE AWL ENTRY DEPENDS ON THE 
*     OP CODE FIELD IN THE FIRST WORD. IF THE OP CODE IS GET, GETL, 
*     GETF OR GETL THEN THE SECOND WORD IS THE ABH FOR THE MESSAGE
*     (NOTE THAT THE TEXT OF THE MESSAGE IS WRITTEN DIRECTLY TO THE 
*     TA AREA SPECIFIED BY THE APPLICATION IN THE AIP CALL) 
* 
*     FOR AN OPCODE OF GETMM THE FORMAT IS AS FOLLOWS:  
* 
*                          4         5
*     0                    8         9
*     I--------------------I---------I
*     I                    I         I
*     I                    I GETMMNW I
*     I                    I         I
*     I--------------------I---------I
* 
*     WHERE 
*       GETMMNW = NO OF WORDS OF DATA MESSAGES DELIVERED TO AIP-S 
*                 DATA QUEUE. 
* 
* 
*     FOR AN OP CODE OF GETS (GET SUPERVISORY MESSAGES) THE FORMAT
*     OF THE SECOND WORD IS AS FOLLOWS
*                          4         5
*     0         6          8         9
*     I---------I----------I---------I
*     I         I          I         I
*     I GETSMNL I          I GETSMNW I
*     I         I          I         I
*     I---------I----------I---------I
* 
*     WHERE 
*       GETSMNL = IS THE LENGTH OF THE NEXT SUPERVISORY MESSAGE NOT YET 
*                 DELIVERED TO AIP. WHEN ZERO THERE ARE NO MORE SUPER-
*                 VISORY MESSAGES.
* 
*       GETSMNW = NO OF WORDS OF SUPERVISORY MESSAGES DELIVERED TO AIP
*                 USED BY AIP TO UPDATE ITS POINTERS TO THE CIRCULAR
*                 SUPERVISORY MESSAGE BUFFER. SEE AIP DOCUMENTATION 
*                 AND ALSO DETAILED DOCUMENTATION OF HPGETSM, IN NIP. 
* 
*     WHEN AN APPLICATION DOES A -NETON-, THE GLOBAL 5-WORD NWL WORKLIST
*     ENTRY IS NOT USED, RATHER A LOCAL (ASSOCIATED WITH THE
*     APPLICATION) 3-WORD AWL IS CREATED. THIS IS 
*     BECAUSE THERE CAN ONLY BE ONE ENTRY IN THE AWL, A NETON RESPONSE
*     ENTRY. IF THE NETON WAS REJECTED, AWLRC WILL CONTAIN THE REASON 
*     CODE FOR REJECTING THE NETON.IF THE NETON WAS ACCEPTED, THE SECOND
*     WORD OF THE AWL ENTRY WILL CONTAIN THE PROCESS NUMBER ASSIGNED TO 
*     THIS APPLICATION AND WHICH WILL BE USED BY AIP IN FUTURE
*     WORKLISTS.
* 
 #
*ENDIF
#* * * * * * * * * * ----------  AWLNTRY ----------* * * * * * * * * * #
*CALL AWLNTRY 
#* * * * * * * * * * ---------- INPARU  ----------* * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  INPARU
* 
*     INPARU IS A COMMON DECK OF INSTALLATION PARAMETERS WHICH ARE
*     AVAILABLE TO THE USERS
* 
*     THESE ARE COMPILATION TIME OPTIONS, WHICH ARE IN ADDITION TO THE
*     UPDATE TIME OPTIONS.
* 
*     THE UPDATE TIME OPTIONS THAT EFFECT NAM ARE AS FOLLOWS
* 
*                                                 SUBAREA EFFECTED
*                                                 NIP   AIP  PIP
* 
*     IMS - WHEN DEFINED IN THE UPDATE RUN IT      YES   YES  YES 
*           TURNS EXTENSIVE IMS DOCUMENTATION ON. 
*           THE RELEASE VALUE IS IMS NOT DEFINED. 
*           IN THAT STATE ONLY MINIMAL IMS DOCU-
*           MENTATION IS INCLUDED IN THE LISTING. 
* 
*     DEBUG WHEN DEFINED DEBUG WILL BE TURNED ON.  YES   YES  YES 
*           THE EFFECT OF DEBUG ON THE NAM COMPO- 
*           NENTS IS AS FOLLOWS 
*           NIP - INTERNAL TRACE BUFFERS WILL BE
*           USED BY NIP TO TRACE MESSAGES SENT
*           AND RECEIVED AS WELL AS TO TRACE
*           SUBROUTINE AND OVERLAY CALLS. 
*           DEBUG WILL ALSO EFFECT NIP-S ACTION 
*           UPON DETECTING ERROR CONDITIONS.
*           MOST OF THESE ARE DOCUMENTATED IN THE 
*           NAM ERS. ON THE RELEASE VERSION 
*           DEBUG FOR NIP IS TURNED OFF.
*           AIP - WITH DEBUG ON AIP WILL PRODUCE
*           AN AIP TRACE FILE. BOTH THE DEBUG 
*           AND NONDEBUG VERSIONS OF AIP
*           ARE RELEASED ON LIBRARIES NETIOD AND
*           NETIO RESPECTIVELY. 
* 
*           PIP - WHEN DEBUG IS ON PIP WILL HANG
*           THE PP ON CERTAIN ERROR CONDITIONS. 
*           WITH DEBUG TURNED OFF PIP WILL EITHER 
*           ATTEMPT TO CONTINUE OR JUST ABORT THE 
*           NETWORK DEPENDING ON THE PARTICULAR 
*           ERROR.
* 
*     STAT -WHEN DEFINED STATISTICS OPTION WILL BE YES   YES  NO
*           TURNED ON IN NIP AND AIP. 
*           THE RESULTS OF NIP-S STATISTICS 
*           GATHERING APPEARS IN THE NIP DAYFILE. 
*           THE FOLLOWING INFORMATION IS DAYFILED:  
* 
*           1. AT THE TIME NIP IS TERMINATED THE
*              NO OF TIMES EACH OVERLAY WAS CALLED, 
*              AS WELL AS THE STATISTICS VARIABLES
*              IN COMMON BLOCK STATTAB (FOR DOCU- 
*              MENTATION SEE BELOW).
*           2. AT THE TIME A PCB IS DELETED THE 
*              STATISTICS INFORMATION IN THE PCB. 
*              (SEE PCB DOCUMENTATION BELOW)
*           3. AT THE TIME A QCB IS DELETED OR
*              SWITCHED THE STATISTICS INFORMA- 
*              TION IN THE QCB (SEE QCB DOCUMEN-
*              TATION BELOW.) 
* 
*     THE ABOVE 3 UPDATE TIME OPTIONS ARE MADE AVAILABLE TO THE USERS 
*     BY DOCUMENTATION IN THE IHB (INSTALLATION HANDBOOK) 
*     THE ADDITIONAL UPDATE TIME OPTIONS ARE FOR USE BY THE NAM PROJECT 
*     ONLY
* 
*     BFSC - IF DEFINED, NIP WILL EXAMINE THE FREE BUFFER CHAIN 
*     FOR ANY DISCREPANCIES AFTER EVERY MGETS, MRELS OR MACQ
*     CALL. IF ERROR IS DETECTED, NIP WILL ABORT WITH DAYFILE 
*     MESSAGE. THIS OPTION WILL SLOW NIP DOWN COMSIDERABLY
*     AND SHOULD ONLY BE USED IN EXTREME DEBUG SITUATION. 
* 
*     DELAY - IF  DEFINED  NIP WILL DELAY 2 SECONDS AFTER IT HAS
*     DECIDED THAT THERE IS EXTRA CORE TO RELEASE BEFORE ACTUALLY 
*     RELEASING THAT CORE. IT WILL NOT BE DEFINED ON THE RELEASE
*     VERSION OF NIP. THAT IS, EXTRA CORE ABOVE 400B WORDS WILL BE
*     IMMEDIATELY RELEASED. SINCE WE DO KEEP THE 400B WORDS THIS IS 
*     CONSIDERED TO BE ADEQUATE TO AVOID MEMORY THRASHING.
* 
*     BESTFIT - IF DEFINED, THE MEMORY ALLOCATION ROUTINE WILL SEARCH 
*     FOR A BUFFER EXACTLY THE SAME SIZE AS REQUESTED. IF ONE IS NOT
*     FOUND, IT WILL USE THE BUFFER COMING CLOSEST (BUT ALWAYS GREATER) 
*     TO THE REQUESTED SIZE. IF NOT DEFINED, FIRST FIT BUFFER 
*     ALLOCATION SCHEME IS USED. UNDER THIS SCHEME, THE FIRST BUFFER
*     GREATER THAN OR EQUAL TO THE REQUESTED SIZE IS USED. THE RELEASE
*     VALUE IS BESTFIT NOT DEFINED. 
* 
*     LIBRES - IF DEFINED NIP WILL NOT CHECK LIBRARY RESIDENCY OF 
*     NS AND CS. THIS IS USED DURING DEVELOPMENT SO THAT NS AND CS
*     MAY RUN EXPERIMENTAL VERSIONS OFF OF A FILE. THE RELEASE
*     VALUE OF COURSE IS TO NOT HAVE LIBRES DEFINED.
* 
*     PERF1 - IF DEFINED THE ACKNOWLEDGE QUEUE IN NIP WILL BE ALLOCATED 
*     AT THE TIME THE QCB IS CREATED. IF NOT DEFINED IT WILL BE 
*     ALLOCATED AND RELEASED DYNAMICALLY. THE MORE DYNAMIC HANDLING 
*     OF ACK. Q"S OBVIOUSLY REQUIRES MORE CPU TIME BUT LESS CORE SIZE 
*     IN NIP. THE RELEASE VALUE IS TO HAVE IT ASSIGNED DYNAMICALLY. 
* 
*     ZZDN - IF DEFINED, ALL INBOUND/OUTBOUND MESSAGES WILL BE RECORDED 
*     IN A FILE CALLED ZZZZZDN, WHICH SERVES AS INPUT TO
*     POSTPROCESSOR DLFP. 
* 
*     ALL OF THE ABOVE UPDATE OPTIONS TRANSLATE INTO COMPILATION TIME 
*     OPTIONS IN NIP. THIS CAN BE READILY PERCEIVED BY LISTING, THROUGH 
*     UPDATE, ALL OF THE ACTIVE CARDS IN NIP. THEREFORE THE VARIABLES 
*     MENTIONED ABOVE SHOW UP AS VARIABLES IN THE INSTALLATION PARAMETER
*     COMMON DECKS(INPARU FOR USER AND INPAR FOR NAM PROJECT).
* 
*     THE FOLLOWING ADDITIONAL COMPILATION OPTIONS ARE AVAILABLE. 
* 
*     MAXNIP - THIS DEFINES THE MAXIMUM FIELD LENGTH THAT NIP MAY USE.
*     THE DEFAULT VALUE IS 20480=50000B. THE RANGE IN VALUE IS FROM 
*     15000B TO 377777B.
* 
*     NFBUFF - WHEN THE NUMBER OF FREE BUFFERS EXCEED NFBUFF, NIP WILL
*     START GARBAGE COLLECTION AFTER TBUF SECONDS. THE RANGE IN VALUE IS
*     FROM 2 TO 16000B. THE DEFAULT VALUE IS 64 (100B). 
* 
*     NFSIZE - WHEN THE SIZE OF THE FREE BUFFER CHAIN EXCEEDS NFSIZE
*     NUMBER OF WORDS, THEN NIP WILL CALL GARBAGE COLLECTION AFTER TBUF 
*     SECONDS. THE RANGE IN VALUE IS FROM 2 TO 16000B. THE DEFAULT IS 
*     2048. 
* 
*     NMBUF - THIS PARAMETER IS THE MINIMUM NUMBER OF IDLE FREE BUFFERS 
*     WHICH WILL INITIATE GARBAGE COLLECTION. IT IS COMPARED TO THE 
*     NUMBER OF FREE BUFFERS MINUS THE NUMBER OF CONNECTIONS (ASSUMING
*     AN AVERAGE NEED OF ONE FREE BUFFER FOR EACH CONNECTION). THE
*     DEFAULT VALUE IS 20. THE RANGE IN VALUE IS FROM 2 TO 16000B.
* 
*     NTIME - NO SWAPOUT NETWAIT TIME. THIS PARAMETER IS THE MAXIMUM
*     TIME (IN SECONDS) FOR WHICH THE APPLICATION WILL NOT BE SWAPPED 
*     OUT. THE RANGE IN VALUE IS FROM 1 TO 3777B. THE DEFAULT VALUE IS
*     TWO SECONDS. THE PARAMETER SERVES THE PURPOSE OF AVOIDING 
*     DISK ACCESS WHEN THE SWAPIN/SWAPOUT PROCESS MAY TAKE AS LONG
*     AS THE NETWAIT TIME SPECIFIED.
* 
*     TBUF - THIS PARAMETER IS THE MINIMUM TIME INTERVAL (IN SECONDS) 
*     BETWEEN CHECKS TO SEE IF NFBUFF BUFFERS OR NFSIZE WORDS ARE FREE
*     SO THAT GARBAGE COLLECTION CAN BE INITIATED. THE RANGE IN VALUE IS
*     FROM 1 TO 777777B. THE DEFAULT VALUE IS 64 SECONDS (=100B). 
* 
 #
# 
                    INSTALLATION PARAMETERS--USER 
  
 BFSC        SCAN FREE BUFFER CHAIN OPTION
  
             THIS PARAMETER TURNS ON SCAN FREE BUFFER CHAIN CODE IN 
             NIP. 
             ASSIGN BFSC A VALUE OF 0 TO TURN IT OFF (DEFAULT). 
             ASSIGN BFSC A VALUE OF 1 TO TURN IT ON.
  
 DEBUG       DEBUG OPTION 
  
             THIS PARAMETER TURNS ON/OFF DEBUG CODE IN NIP WHICH WOULD
             OTHERWISE NOT BE COMPILED. 
             THE VALUE IS 0 TO TURN IT OFF (DEFAULT). 
             THS VALUE IS 1 TO TURN IT ON.
  
 DELAY       RELEASE FL DELAY OPTION
  
             THIS PARAMETER TURNS ON/OFF DELAY OPTION CODE
             IN GARBAGE COLLECTION ROUTINE MGBGCLT TO CONTROL 
             WHETHER TO WAIT 2 SECONDS TO RELEASE EXTRA NIP FL OR NOT.
             THE VALUE IS 0 TO TURN IT OFF (DEFAULT). 
             THE VALUE IS 1 TO TURN IT ON.
  
 BESTFIT     BUFFER ALLOCATION METHOD OPTION
  
             THIS PARAMETER SPECIFIES WHETHER MGETS USES BEST FIT OR
             FIRST FIT STRATEGY WHEN A BUFFER IS DYNAMICALLY ALLOCATED. 
             THE VALUE IS 1 FOR BEST FIT. 
             THE VALUE IS 0 FOR FIRST FIT (DEFAULT).
  
 IMSLIST     IMS DOCUMENTATON OPTION
  
             THIS PARAMETER TURNS ON/OFF LISTING OF IMS DOCUMENTATION.
             THE VALUE IS 0 TO TURN IT OFF (DEFAULT). 
             THE VALUE IS 1 TO TURN IT ON.
  
 LIBRES      SYSTEM RESIDENT CHECK IPTION 
  
             THIS PARAMETER TURNS ON/OFF CHECK TO SEE IF CS AND NS ARE
             SYSTEM ORIGINATED PROGRAMS.
             THE VALUE IS 0 TO TURN IT ON (DEFAULT).
             THE VALUE IS 1 TO TURN IT OFF. 
  
 MAXNIP      MAXIMUM FIELD LENGTH 
  
             THIS PARAMETER IS THE MAXIMUM FIELD LENGTH THAT NIP MAY
             REACH. 
             THE RANGE IN VALUE IS FROM 15000B TO 377777B 
             (DEFAULT = 50000B).
  
 NFBUFF      NUMBER OF FREE BUFFERS FOR GARBAGE COLLECTION
  
             THIS PARAMETER IS THE MINIMUM NUMBER OF FREE BUFFERS 
             WHICH WILL INITIATE GARBAGE COLLECTION AFTER TBUF SECONDS. 
             THE RANGE IN VALUE IS FROM 2 TO 16000B (DEFAULT = 100B). 
  
 NFSIZE      NUMBER OF FREE WORDS FOR GARBAGE COLLECTION
  
             THIS PARAMETER IS THE MINIMUM NUMBER OF FREE WORDS 
             WHICH WILL INITIATE GARBAGE COLLECTION AFTER TBUF SECONDS. 
             THE RANGE IN VALUE IS FROM 2 TO 16000B (DEFAULT = 1500B).
  
 NMBUF       NUMBER OF IDLE FREE BUFFERS FOR GARBAGE COLLECTION 
  
             THIS PARAMETER IS THE MINIMUM NUMBER OF IDLE FREE BUFFERS
             WHICH WILL INITIATE GARBAGE COLLECTION.  IT IS COMPARED
             TO THE NUMBER OF FREE BUFFERS MINUS THE NUMBER OF
             CONNECTIONS (ASSUMING A AVERAGE NEED OF ONE FREE BUFFER
             FOR EACH CONNECTION).
             THE RANGE IN VALUE IS FROM 2 TO 16000B (DEFAULT = 24B).
  
 NTIME       NO-SWAPOUT NETWAIT TIME
  
             THIS PARAMETER IS THE MAXIMUM NETWAIT TIME (IN SECONDS)
             FOR WHICH THE APPLICATION WILL NOT BE SWAPPED OUT. 
             THE RANGE IN VALUE IS FROM 1 TO 3777B (DEFAULT = 2). 
  
 PERF1       PERFORMANCE OPTION NUMBER 1
  
             THIS PARAMETER WILL DETERMINE IF THE ACKNOWLEDGE QUEUE 
             WILL BE ALLOCATED DYNAMICALLY (I.E. ONLY WHEN NEEDED) OR 
             STATICALLY (I.E. AT QCB CREATION TIME).
             THE VALUE IS 0 TO ALLOCATE DYNAMICALLY (DEFAULT).
             THE VALUE IS 1 TO ALLOCATE STATICALLY. 
  
 STAT        STATISTICS OPTION
  
             THIS PARAMETER TURNS ON/OFF STATISTICS PRODUCING CODE IN NI
             WHICH WOULD OTHERWISE NOT BE COMPILED. 
             THE VALUE IS 0 TO TURN IT OFF (DEFAULT). 
             THE VALUE IS 1 TO TURN IT ON.
  
 TBUF        TIME INTERVAL FOR GARBAGE COLLECTION CHECK 
  
             THIS PARAMETER IS THE MINIMUM TIME INVERVAL (IN SECONDS) 
             BETWEEN CHECKS TO SEE IF NFBUFF BUFFERS OR NFSIZE WORDS
             ARE FREE SO THAT GARBAGE COLLECTION CAN BE INITIATED.
             THE RANGE IN VALUE IS FROM 1 TO 777777B (DEFAULT = 100B).
  
 ZZDN        TRACE PIP IN/OUT BOUND MESSAGES
  
             THIS OPTION WILL INCLUDE CODE TO RECORD ALL PIP IN/OUT 
             BOUND MESSAGES IN A FILE NAMED ZZZZZDN.
             SET TO 1 TO TURN IT ON.
             SET TO 0 TO TURN IT OFF (DEFAULT). 
  
# 
*ENDIF
*CALL INPARU
*CALL IMSBB 
# * * * * * * * * * * * * * --- BACKBUF --- * * * * * * * * * * * * * *#
*CALL BACKBUF 
# * * * * * * * * * * * * * * * --- BPIPBUF --- * * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  BPIPBUF 
* 
*     BPIPBUF IS A COMMON BLOCK USED BY ZZDN OPTION. WHEN NIP IS
*     GENERATED WITH ZZDN, ALL MESSAGES INBOUND OR OUTBOUND THROUGH 
*     PIP ARE RECORDED IN A FILE CALLED ZZZZZDN. BPIPBUF CONTAINS 
*     CIO BUFFER FOR ZZZZZDN AND ITS FETS.
*     INTERNAL FORMAT OF ZZZZZDN -
* 
*     HEADER WORD 0 - 
* W   7 
*                                   4 
*      0                            2 
*     I----------------------------I
*     I                            I
*     I        NIP                 I
*     I                            I
*     I----------------------------I
* 
*     WHERE 
*     THE LEFTMOST 42 BITS CONTAINS DISPLAY CODE LITERALS NIP WITH
*     ZERO FILL.
* 
*     HEADER WORD 1 - 
* W   7 
*                            2
*      0                     4
*     I---------------------I-----------------------I 
*     I                     I                       I 
*     I      SECONDS        I       MILLISECONDS    I 
*     I                     I                       I 
*     I---------------------I-----------------------I 
* 
*     WHERE 
* 
* 
*       SECONDS      = ELAPSED TIME SINCE DEADSTART IN SECS.
*       MILLISECONDS = ELAPSED TIME SINCE DEADSTART IN MILLISECONDS.
* 
*     HEADER WORD 2 - 
* 
* W   7 
*                  1     2      3     4      5
*           6      8     4      6     2      4
*     I----I------I-----I------I-----I------I-----I 
*     I    I      I     I      I     I      I     I 
*     I    I  HH  I  .  I  MM  I  .  I  SS  I  .  I 
*     I    I      I     I      I     I      I     I 
*     I----I------I-----I------I-----I------I-----I 
* 
* 
*     WHERE 
* 
*       HH    = HOUR IN DISPLAY CODE. 
*       MM    = MINUTE IN DISPLAY CODE. 
*       SS    = SECONDS IN DISPLAY CODE.
* 
* 
*     HEADER WORD 3 - 
* W   7 
*                  1     2      3     4      5
*           6      8     4      6     2      4
*     I----I------I-----I------I-----I------I-----I 
*     I    I      I     I      I     I      I     I 
*     I    I  YY  I  /  I  MM  I  /  I  DD  I  /  I 
*     I    I      I     I      I     I      I     I 
*     I----I------I-----I------I-----I------I-----I 
* 
* 
*     WHERE 
* 
*       YY    = YEAR IN DISPLAY CODE. 
*               EG. 1978 WILL BE EXPRESSED AS 4243B.
*       MM    = MONTH IN DISPLAY CODE.
*       DD    = DATE OF THE MONTH IN DISPLAY CODE.
* 
* 
*     THE HEADER IS FOLLOWED BY INDIVIDUAL ZZZZZDN ENTRY CONTAINING AN
*     INBOUND OR OUTBOUND MESSAGE.
*     INTERNAL FORMAT OF EACH ZZZZZDN ENTRY - 
* 
* 
*     WORD 0 -
* 
* W   7 
*                            2
*      0                     4
*     I---------------------I-----------------------I 
*     I                     I                       I 
*     I      SECONDS        I       MILLISECONDS    I 
*     I                     I                       I 
*     I---------------------I-----------------------I 
* 
*     WHERE 
* 
* 
*       SECONDS      = ELAPSED TIME SINCE DEADSTART IN SECS.
*       MILLISECONDS = ELAPSED TIME SINCE DEADSTART IN MILLISECONDS.
* 
* 
*     WORD 1 -
* 
* W   7 
*                          2
*                 6        3
*     I----------I----------I 
*     I          I          I 
*     I  BPIPID  I  BPIPBS  I 
*     I          I          I 
*     I----------I----------I 
* 
* 
*     WHERE 
* 
*       BPIPID     = BLOCK ID.
*                    14 FOR INBOUND, 15 FOR OUTBOUND. 
*       BPIPBS     = BLOCK SIZE. SIZE OF ZZZZZDN ENTRY MINUS ONE. 
* 
* 
*     WORD 2 -
* 
* W   5 
*            1  2     2     2  3     4     4 4
*     0   8  6  4     5     8  2     0     4 8
*     I--I--I--I-----I-----I--I-----I-----I-I--I
*     IDNISNICNINHPRIINHBNSIBTINHDBCINHACTIBICCI
*     I--I--I--I-----I-----I--I-----I-----I-I--I
* 
*     SEE NHEADER FOR EXPLANATION OF THE ABOVE FIELDS.
*     MESSAGE TEXT WILL FOLLOW THIS WORD. 
* 
 #
*ENDIF
*CALL BPIPBUF 
*CALL IMSNBT
*ENDIF
# * * * * * * * * * * * * * ----- CET ----- * * * * * * * * * * * * * *#
*CALL CET 
*CALL SMPFC 
*CALL SMAPPFC 
*CALL SMAPDEF 
*CALL SMDEF 
*IF DEF,IMS 
 #
*1DC  DBGBUF
* 
*     DBGBUF IS A PREALLOCATED COMMON BLOCK WHICH CONSISTS OF 5 TRACE 
*     BUFFERS TO RECORD ALL DATA TRAFFIC GOING THROUGH NIP. THEY ARE
*     USED PRIMARILY FOR DEBUGGING PURPOSES AND ARE COMPILED ONLY WHEN
*     THE INSTALLATION DEFINED PARAMETER -DEBUG- IS TURNED ON.
* 
*     EACH CIRCULAR TRACE BUFFER HAS A SIZE OF 1001 WORDS .IE. A HEADER 
*     WORD WHICH CONTAINS THE OFFSET POINTER OF THE NEXT AVAILABLE
*     WORD IN THE BUFFER TO BE FILLED, AND 1000-WORDS FOR LOGGING 
*     DATA MESSAGES. THESE BUFFERS ARE ALLOCATED IN THE FOLLOWING 
*     ORDER : 
* 
*        . BGET    RECORDS NON-SUPERVISORY DATA SENT TO APPLICATION(S)
*        . BGETSM  RECORDS SUPERVISORY DATA SENT TO APPLICATION(S)
*        . BPIPIN  RECORDS DATA RECEIVED FROM NPU(S)
*        . BPIPOUT RECORDS DATA SENT TO NPU(S)
*        . BPUT    RECORDS DATA RECEIVED FROM APPLICATION(S)
* 
*     EVERY TIME NIP PROCESSES NETWORK DATA (INBOUND OR OUTBOUND), IT 
*     WILL FIRST STORE IN THE TRACE BUFFERS (BPIPIN AND BPIPOUT) THE
*     ELAPSED TIME THE OPERATING SYSTEM HAS BEEN UP. TO RECOGNIZE THE 
*     WORD CONTAINING THE TIME, THE LEFTMOST PART OF THE WORD WILL
*     CONTAIN THE LETTERS -TIME- IN DISPLAY CODE. EACH NETWORK MESSAGE
*     IS PRECEDED BY A BLOCK HEADER WORD. THIS CONSISTS OF A BLOCK TYPE 
*     IN BITS 0-3 (SYMPL BIT NUMBERING SCHEME) AND A BLOCK SIZE IN BITS 
*     4-11. FOR NETWORK INBOUND MESSAGES THE BLOCK TYPE IS 14 (70B) AND 
*     FOR NETWORK OUTBOUND MESSAGES THE BLOCK TYPE IS 15 (74B) .
* 
*     EVERY TIME NIP PROCESSES AIP GET OR PUT FUNCTIONS, IT WILL FIRST
*     STORE IN THE TRACE BUFFERS (BGET, BGETSM, AND BPUT) THE PROCESS 
*     NUMBER OF THE APPLICATION WHOSE WORKLIST IS BEING PROCESSED. TO 
*     RECOGNIZE THE WORD CONTAINING THE PROCESS NUMBER, THE LEFTMOST
*     PART OF THE WORD WILL CONTAIN THE LETTERS -PN- IN DISPLAY CODE. 
*     DATA RECEIVED BY NIP FROM APPLICATIONS WILL BE PRECEDED BY THE
*     AIP OPCODE WORD IN THE BPUT TRACE BUFFER. ENTRIES IN THE BGET 
*     TRACE BUFFERS MAY HAVE DIFFERENT ACT AND/OR ADR VALUES IN THE 
*     ABH WORD THAN WHAT IS ACTUALLY SENT TO THE APPLICATION. 
* 
 #
*ENDIF
*CALL DBGBUF
*IF DEF,IMS 
                                   #
*# #
*1DC  DEQCOM
* 
*     DEQCOM IS A PREALLOCATED COMMON BLOCK CONTAINING VARIABLES WHICH
*     ARE USED IN PERFORMING CHARACTER CONVERSIONS FOR UPLINE DATA, 
*     BUFFER MOVE FOR GARBAGE COLLECTION FUNCTIONS, AND NIP-S FIELD 
*     LENGTH DUMP FOR ERROR CONDITIONS. SEE SYMPL LISTING FOR LIST
*     OF VARIABLES IN THE COMMON DECK.
* 
                                   #
                                   #
*#
*ENDIF
*CALL DEQCOM
#* * * * * * * * * * ----------  DRHDR   ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  DRHDR 
* 
*     DRHDR CONTAINS THE TEMPLATE FOR THE DATA RING HEADER WORD. EACH 
*     DATA POT IN NIP-S FIELD LENGTH HAS A DATA RING HEADER ASSOCIATED
*     WITH IT. BASICALLY IT IS USED TO CHAIN TOGETHER DATA POTS QUEUED
*     ON THE SAME CONNECTION SO AS TO SPEED UP THE QUEUEING AND DE- 
*     QUEUEING PROCESS WITHIN NIP. IT HAS THE FOLLOWING FORMAT: 
* 
*                      2         4        5 
*      0        6      4         2        9 
*     I--------I------I---------I---------I 
*     I        I      I         I         I 
*     I DRID   I DRBS I BACKPTR I NEXTPTR I 
*     I        I      I         I         I 
*     I--------I------I---------I---------I 
* 
* 
*     WHERE : 
* 
*        DRID    = DATA RING BLOCK ID = 7.
*        DRBS    = DATA RING BLOCK SIZE.
*        BACKPTR = DATA RING BACK POINTER. POINTS TO FWA OF LAST DATA 
*                  POT WHICH HEADS THIS DATA POT IN THE RING. 
*        NEXTPTR = DATA RING NEXT POINTER. POINTS TO FWA OF NEXT DATA 
*                  POT WHICH TRAILS THIS DATA POT IN THE RING.
* 
 #
*ENDIF
*CALL DRHDR 
 
#* * * * * * * * * ----------  FLIST  ---------- * * * * * * * * * * * #
 
*IF DEF,IMS 
 #
*1DC  FLIST 
* 
*     FLIST CONTAINS TEMPLATE FOR SYSTEM CONTROL POINT (SCP) FUNCTION 
*     LIST WHEN THERE IS A PCB FOR THE USER CONTROL POINT (UCP).
* 
*     SCP FUNCTION LIST IS A DYNAMICALLY MOVABLE BUFFER. IT ALLOWS NAM
*     TO ISSUE SUBSYSTEM FUNCTION REQUESTS TO THE O/S. FOR A NON-LIST 
*     SFCALL FUNCTION, IT IS A 3-WORD ENTRY WITH A HEADER WORD PLUS A 
*     2-WORD PARAMETER BLOCK ( FOR THE EXTENDED SF.READ / SF.WRIT 
*     FUNCTIONS, THERE IS A 3-WORD PARAMETER BLOCK TO ALLOW FOR THE 
*     EXTENDED TRANSFER LENGTH OF MORE THAN 100B WORDS ). FOR A LIST
*     SFCALL FUNCTION (SF.LIST), IT IS A (3+N)-WORD ENTRY WITH A HEADER 
*     WORD PLUS A 2-WORD PARAMETER BLOCK, FOLLOWED BY N CONTIGUOUS ONE
*     WORD LIST ENTRIES ( FOR AN EXTENDED LIST SFCALL FUNCTION (SF.XLST)
*     EACH LIST ENTRY IS 2 WORDS LONG WITH THE SECOND WORD RESERVED FOR 
*     ALL BUT THE EXTENDED SF.READ AND SF.WRIT FUNCTIONS ). THE FORMAT
*     IS AS FOLLOWS:  
* 
*      0         6     24                 48       59 
*     I---------I------I------------------I---------I 
*     I FLID    I FLBS I                  I   FLPN  I  HEADER WORD
*     I---------I------I------------------I---------I 
* 
*     ( 2-WORD PARAMETER BLOCK FOR SFCALL FUNCTION )
* 
*     0      6      18       36       54     58    59 
*     I------I------I--------I--------I------I------I 
*     I FLRC I FLFP I FLUCPA I FLSCPA I FLFC I FLCB I 
*     I------I------I--------I--------I------I------I 
* 
*     0                                    42       59
*     I-----------------------------------I---------I 
*     I                            FLNAME I  FLJDT  I 
*     I-----------------------------------I---------I 
* 
*     ( 1 ADDITIONAL WORD IN PARAMETER BLOCK FOR EXTENDED SF.READ / 
*     SF.WRIT FUNCTIONS ) 
* 
*     0     1     2     12            36           59 
*     I-----I-----I-----I-------------I-------------I 
*     I FLU I FLS I     I     FLXUCPA I     FLXSCPA I 
*     I-----I-----I-----I-------------I-------------I 
* 
* 
* 
*     ( CONTIGUOUS LIST ENTRIES FOR SF.LIST OR SF.XLST FUNCTIONS )
* 
*     0       6       18        36        54      58     59 
*     I-------I-------I---------I---------I-------I-------I 
*     I FLERC I FLEFP I FLEUCPA I FLESCPA I FLEFC I FLECB I   ENTRY 1 
*     I-------I-------I---------I---------I-------I-------I 
* 
*     ( SECOND WORD OF SF.XLST FUNCTION LIST ENTRY FOR EXTENDED SF.READ 
*     AND SF.WRIT FUNCTIONS ONLY )
* 
*     0      1      2     12              36             59 
*     I------I------I-----I---------------I---------------I 
*     I FLEU I FLES I     I      FLEXUCPA I      FLEXSCPA I 
*     I------I------I-----I---------------I---------------I 
*                            .
*                            .
*                            .     FUNCTION LIST ENTRIES
*                            .
*                            .
*     0       6       18        36        54      58     59 
*     I-------I-------I---------I---------I-------I-------I 
*     I FLERC I FLEFP I FLEUCPA I FLESCPA I FLEFC I FLECB I   ENTRY N 
*     I-------I-------I---------I---------I-------I-------I 
* 
*     ( SECOND WORD OF SF.XLST FUNCTION LIST ENTRY FOR OTHER SFCALL 
*     FUNCTIONS ) 
* 
*     0                                                  59 
*     I---------------------------------------------------I 
*     I                                 RESERVED          I 
*     I---------------------------------------------------I 
* 
*     WHERE : 
* 
*        FLID      = FUNCTION LIST BLOCK ID = 4.
*        FLBS      = FUNCTION LIST BLOCK SIZE. 3 TO 64 WORDS ALLOWED. 
*        FLPN      = PROCESS NUMBER OF UCP. USED ONLY BY GARBAGE
*                    COLLECTION ROUTINES WHEN MOVING THE FUNCTION 
*                    LIST BUFFER. 
* 
*        FLRC      = REPLY CODE. SET BY THE OPERATING SYSTEM IF AN
*                    ERROR IS DETECTED WHILE PROCESSING THE SF.LIST 
*                    REQUEST. IF RC = 40B, THEN THE FUNCTION LIST 
*                    MUST BE SEARCHED FOR THE FIRST LIST ENTRY WITH 
*                    A NON-ZERO RC FIELD TO DETERMINE THE ACTUAL
*                    ERROR CONDITION. FOR DETAILED RC VALUES, SEE 
*                    DOCUMENTATION ON SCPCOM COMDECK. 
*        FLFP      = FUNCTION PARAMETER. FOR SF.LIST REQUEST, THIS
*                    CONTAINS THE NUMBER OF ENTRIES IN THE LIST,
*                    INITIALLY SET BY NIP WHEN ISSUEING THE FUNCTION
*                    REQUEST AND UPDATED BY THE OPERATING SYSTEM. 
*                    IF IT RETURNS WITH A ZERO VALUE, THE ENTIRE LIST 
*                    HAS BEEN PROCESSED BY THE OPERATING SYSTEM. IF IT
*                    RETURNS WITH A NON-ZERO VALUE, IT INDICATES THAT 
*                    THE OPERATING SYSTEM HAS ABANDONED PROCESSING OF 
*                    THE LIST. THE VALUE OF FLFP IS SET TO THE NUMBER 
*                    OF ENTRIES REMAINING IN THE LIST AND FLSCPA IS 
*                    SET TO THE ADDRESS OF THE FIRST ENTRY IN THE 
*                    REMAINING LIST.
*        FLUCPA    = RELATIVE ADDRESS WITHIN THE UCP. FOR THE SF.LIST 
*                    LIST, THIS IS SET TO 0.
*        FLSCPA    = RELATIVE ADDRESS WITHIN THE SCP. THIS CONTAINS 
*                    FWA OF FIRST LIST ENTRY IN THE FUNCTION LIST.
*        FLFC      = SCP FUNCTION CODE (SF.LIST = 30B) .
*        FLCB      = SCP COMPLETION BIT. SET BY THE OPERATING SYSTEM
*                    WHEN IT COMPLETES PROCESSING OF THE SF.LIST CALL.
*        FLNAME    = A 7-CHARACTER UCP JOB NAME.
*        FLJDT     = UCP-S FNT ADDRESS. 
* 
*        FLU       = ECS ADDRESS IN UCP FLAG. BIT IS CLEARED IF 
*                    FLXUCPA IS THE UCP CM ADDRESS. 
*        FLS       = ECS ADDRESS IN SCP FLAG. BIT IS CLEARED IF 
*                    FLXSCPA IS THE SCP CM ADDRESS. 
*        FLXUCPA   = EXTENDED MODE READ / WRITE UCP CM OR ECS ADDRESS.
*        FLXSCPA   = EXTENDED MODE READ / WRITE SCP CM OR ECS ADDRESS.
*        FLERC     = REPLY CODE. SET BY THE OPERATING SYSTEM IF ERROR 
*                    IS DETECTED IN PROCESSING THE FUNCTION LIST ENTRY. 
*                    FOR DETAILED RC VALUES, SEE SCPCOM.
*        FLEFP     = FUNCTION PARAMETER FOR THE SCP REQUEST OF THE
*                    LIST ENTRY.
*        FLEUCPA   = RELATIVE ADDRESS WITHIN THE UCP. 
*        FLESCPA   = RELATIVE ADDRESS WITHIN THE SCP. 
*        FLEFC     = SCP FUNCTION CODE. FOR DETAILED SCP FUNCTIONS
*                    AVAILABLE, SEE DOCUMENTATION IN SCPCOM COMDECK.
*        FLECB     = SCP COMPLETION BIT. SET BY THE OPERATING SYSTEM
*                    WHEN IT COMPLETES PROCESSING THE SCP REQUEST OF
*                    THE LIST ENTRY.
* 
*        FLEU      = SAME AS FLU. 
*        FLES      = SAME AS FLS. 
*        FLEXUCPA  = SAME AS FLUCPA.
*        FLEXSCPA  = SAME AS FLXSCPA. 
* 
*     LIST ENTRIES ARE PROCESSED SEQUENTIALLY BY THE OPERATING SYSTEM.
* 
*     FOR MORE INFORMATION ON THE SPECIFIC FORMAT OF EACH AVAILABLE 
*     SCP FUNCTION CALLS, SEE DOCUMENTATION ON SYSTEM CONTROL POINT.
* 
 #
*ENDIF
*CALL FLIST 
*IF DEF,IMS 
                                   #
*# #
*1DC  DUMPFLG 
* 
*     DUMPFLG CONTAINS A SINGLE WORD BUFFER USED TO STORE THE REASON
*     CODES FOR DUMPING NIP-S FIELD LENGTH. IF THE INSTALLATION DEFINED 
*     OPTION -DEBUG- IS TURNED ON. RDUMP WOULD ONLY DUMP NIP-S FIELD
*     LENGTH IF THE PROBLEM AS SPECIFIED BY THE REASON CODE HAD NOT 
*     OCCURRED ONCE ALREADY.
* 
* 
                                   #
                                   #
*#
*ENDIF
*CALL DUMPFLG 
*CALL IMSAT 
*ENDIF
#* * * * * * * * * * ----------  INPAR   ----------* * * * * * * * * * #
*CALL INPAR 
#* * * * * * * * * * ----------  FREETAB ----------* * * * * * * * * * #
*IF DEF,IMS 
                                   #
*# #
*1DC  FREETAB 
* 
*     FREETAB IS A PREALLOCATED COMMON BLOCK USED TO CONTROL THE FREE 
*     CHAIN. IT IS A 3-WORD ENTRY HAVING THE FOLLOWING FORMAT : 
* 
*     0        1         23          41          59 
*     I--------I----------I-----------I-----------I 
*     I FREMFL I          I  FREFBBP  I  FREFBFP  I 
*     I--------I----------I-----------I-----------I 
*     I                                  FRENOFB  I 
*     I-------------------------------------------I 
*     I                                   FRESFB  I 
*     I-------------------------------------------I 
* 
*     WHERE : 
* 
*        FREMFL    = NIPLWA REACHES MAXNIP FLAG. SET IF THE INSTALLATION
*                    DEFINED MAXIMUM NIP FIELD LENGTH HAS BEEN REACHED
*                    WHEN MGETS TRIES TO GET A NEW BUFFER.
*        FREFBBP   = FREE RING BACKWARD POINTER. IT POINTS TO THE LAST
*                    AVAILABLE (HIGHEST ADDRESS) FREE BUFFER. IF THERE
*                    IS NO FREE BUFFERS, IT POINTS TO ITSELF. 
*        FREFBFP   = FREE RING FORWARD POINTER. IT POINTS TO THE FIRST
*                    AVAILABLE (LOWEST ADDRESS) FREE BUFFER. IF THERE 
*                    IS NO FREE BUFFERS, IT POINTS TO ITSELF. 
*        FRENOFB   = NUMBER OF FREE BUFFERS IN THE FREE RING. 
*        FRESFB    = TOTAL SIZE OF FREE BUFFER SPACE IN WORDS.
* 
*     FOLLOWING THE FRETAB ARRAY, THERE ARE 8 ADDITION WORDS USED 
*     GENERALLY BY THE MEMORY MANAGER OF NIP. 
* 
*     MAXFL                  MAXIMUN PERMISSIBLE PROGRAM LENGTH 
*     CTLSFWA                FWA OF DYNAMICALLY CONTROLLED STORAGE
*     CTLSLWA                LWA OF DYNAMICALLY CONTROLLED STORAGE
*     MCUR                   CURRENT FREE BUFFER EXAMINED BY MGBGCLT
*     MCHG                   NEW ADDRESS OF MOVED BUFFER USED BY MGBGCLT
*     MOLD                   FWA OF BLOCK TO BE COPIED BY OMOVE 
*     MNEW                   FWA OF BLOCK TO BE COPIED TO BY OMOVE
*     MSIZE                  SIZE OF BLOCK TO BE COPIED BY OMOVE
* 
*        THIS COMMON BLOCK IS USED IN ASSEMBLY ROUTINES MGETS 
*        MRELS, MSEIZE, OMOVE. ANY CHANGES TO THIS COMMON 
*        BLOCK SHOULD BE FOLLOWED BY CHANGES IN THOSE 
*        ROUTINES.
                                   #
                                   #
*#
*ENDIF
*CALL FREETAB 
*IF DEF,IMS 
#* * * * * * * * *  * * * * * --- MEM --- * * * * * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  MEM 
*     MEM IS AN EXTERNAL ARRAY WITH ADDRESS 0 USED TO 
*     ADDRESS ANY LOCATION WITHIN PROGRAM LENGTH. IT
*     IS SET IN MGETS.
 #
*ENDIF
*CALL INPARUT 
 #
*1DC KDIS 
*  KDIS IS THE COMMUNICATION AREA FOR ALL APPLICATIONS
*  USING THE K-DISPLAY
*  IT HOLDS POINTERS TO SCREEN,BUFFERS AND STATUS FLSGS 
* 
*  THE DISTAIL COMMON HOLDS THE BASIC DATA THAT SHOULD
*  ALWAYS BE DISPLAYED AT BOTTOM OF SCREEN
* 
 #
         #
***** 
*         K-DISPLAY INTERFACES
* 
*         K-DISPLAY IN NAM HAS TWO MODES - "NAM" MODE AND "APPLIACTION" 
*         MODE. 
*         THE GENERAL SCENARIO FOR USING NAM K-DISPLAY IS AS FOLLOWS. 
*         FIRST, THE HOP ASSIGNS THE K-DISPLAY TO NAM IN THE NORMAL 
*         FASHION. NEXT, THE HOP ENTERS THE COMMAND THAT SELECTS THE
*         SUPERVISORY APPLICATION WITH WHICH TO BE INTERFACED. AT THIS
*         POINT THE HOP MAY ENTER THE SELECTED APPLICATION ACCORDING TO 
*         THE SYSTAX RULES IN NAM REFERENCE MANUAL. TO CLEAR THE APPL.
*         MODE, ENTER AN ASTERISK AND K-DISPLAY WILL RETURN TO NAM MODE.
* 
*         THE GENERAL FORMAT OF THE NAM K-DISPLAY AS FOLLOWS: 
* 
*         +-------------------------------------------+ 
*         I   RESERVED FOR SYSTEM USAGE               I LINE 50 
*         I                      .                    I    .
*         I                      .                    I    .
*         I-------------------------------------------I LINE 44 
*         I                                           I LINE 43 
*         I    APPLICATION CONTROL DISPLAY            I 
*         I                  (ACD)                    I LINE 12 
*         I-------------------------------------------I 
*         I   BLANK LINE                              I      11 
*         I-------------------------------------------I 
*         I   ALERT                                   I      10 
*         I-------------------------------------------I 
*         I   BLANK LINE                              I      09 
*         I-------------------------------------------I 
*         I   APPL-NAME      TYPE IN        REPEAT MSGI      08 
*         I-------------------------------------------I 
*         I   BLANK LINE                              I 
*         I-------------------------------------------I 
*         I   RESERVED FOR SYSTEM USE                 I 
*         I                      .                    I 
*         I                      .                    I 
*         I-------------------------------------------I      00 
* 
*         K-DISPLAY COMMANDS:  (FORMAT K.-----) 
*         AP = APPLNAME     DISPLAY THE RECENT HISTORY OF THE SPECIFIED 
*                           APPLICATION.
*                           DEFAULT TO THE APPLICATION NAME ON THE LEFT 
*                           MOST ON THE ALERT LINE. 
*         IG                DISABLE ANY ALERT FROM APPLICATION NAME ON
*                           THE LEFT MOST OF THE ALERT LINE AND THEN
*                           CLEAR THIS FIELD. 
*         END               CLEAR THE K-DISPLAY OF NAM. 
*         *                 CLEAR THE APPLICATION MODE AND GET BACK TO
*                           NAM MODE. 
*         /                 ABORT THE PREVIOUS K-DISPLAY COMMAND. RESPOND 
*                           BY READY AT K-DISPLAY.
*         +                 TURN ON THE PAGE WAIT IF NOT ON. IF ON, ROLL
*                           IN THE NEXT PAGE. 
*         -                 TURN OFF THE PAGE WAIT. IGNORE IF PAGE WAIT 
*                           IS NOT ON.
*          ST               START UP NAM MODE K-DISPLAY.
*    *
     #
*CALL KDIS
*CALL DISTAIL 
*CALL KHDRX 
*CALL KSTTAB
*CALL MEM 
#* * * * * * * * * * ----------  MISCOM  ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  MISCOM
*     MISCOM IS A COMMON DECK CONTAINING VALUES DEFINED FOR APPLICATION 
*     CHARACTER TYPES, APPLICATION BLOCK TYPES AND NETWORK BLOCK TYPES. 
*     FOR DETAILS, SEE NAM REFERENCE MANUAL AND CCP IMS.
* 
 #
*ENDIF
*CALL MISCOM
*IF DEF,IMS 
 #
*1DC  MISDEF
* 
*     MISDEF IS A COMMON DECK CONTAINING VALUES DEFINED FOR BLOCK ID-S
*     KNOWN TO NIP. VALUES DEFINED FOR ENTRY SIZES ARE ALSO INCLUDED. 
* 
 #
*ENDIF
#* * * * * * * * * * ----------  MSGDEF  ----------* * * * * * * * * * #
*IF DEF,IMS 
                                   #
*# #
*1DC  MSGIDX
* 
*     MSGIDX IS A COMMON DECK CONTAINING DAYFILE MESSAGE INDEX
*     DEFINITIONS. THE MESSAGE INDEX IS USED BY VARIOUS NIP ROUTINES
*     AS AN INPUT PARAMETER TO CALL XERRMSG TO DAYFILE A SPECIFIC 
*     MESSAGE.
                                   #
                                   #
*#
*ENDIF
*CALL MSGIDX
#* * * * * * * * * * ----------  NAMLEV  ----------* * * * * * * * * * #
*CALL NAMLEV
# * * * * * * * * * * * * * ----- NBT ----- * * * * * * * * * * * * * *#
*CALL NBT 
#* * * * * * * * * * ----------  NHEADER ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  NHEADER 
* 
*     NHEADER CONTAINS THE TEMPLATE FOR THE BLOCK HEADER OF BLOCKS IN 
*     NIP-S INBOUND AND OUTBOUND BUFFERS. WE SHALL REFER TO THIS TYPE 
*     OF BLOCK HEADER AS THE NETWORK HEADER. FOR DOWNLINE BLOCKS, THE 
*     NETWORK HEADER IS FORMATTED BY NIP WHILE FOR UPLINE BLOCKS, IT IS 
*     FORMATTED BY CCP AND PIP. 
* 
*     THE NETWORK HEADER HAS THE FOLLOWING FORMAT : 
* 
*     0    8    16   24      25      28   32      40      44  48   59 
*     I----I----I----I-------I-------I----I-------I-------I---I----I
*     I DN I SN I CN I NHPRI I NHBSN I BT I NHDBC I NHACT I B I CC I
*     I----I----I----I-------I-------I----I-------I-------I---I----I
* 
*     WHERE : 
* 
*        DN      = DESTINATION NODE NUMBER
*        SN      = SOURCE NODE NUMBER 
*        CN      = CONNECTION NUMBER
*        NHPRI   = PRIORITY BIT. SET TO 1 FOR HIGH PRIORITY DATA AND 0
*                  FOR LOW PRIORITY DATA, ALL BLOCKS ON THE SAME
*                  CONNECTION ARE ASSIGNED THE SAME PRIORITY. PRIORITY
*                  OF A PCB/QCB IS SET AT CREATION TIME AND IS USED TO
*                  DETERMINE PRIORITY FOR LOGICAL LINK REGULATION.
*        NHBSN   = BLOCK SEQUENCE NUMBER (1-7). THE BSN SUPPLIED IN A 
*                  DOWNLINE BLOCK OF TYPE -MSG-, -BLK- OR -CMD- MUST
*                  BE RETURNED IN THE BSN FIELD OF THE UPLINE -BACK-
*                  WHICH ACKNOWLEDGES THAT SPECIFIC BLOCK. WHEN A -BRK- 
*                  OR -STP- IS SENT, THE BSN RETURNED MUST BE THE SAME
*                  BSN OF LAST -BACK- SENT FOR THE CONNECTION. THE BSN
*                  WILL ALWAYS BE ZERO ON OTHER UPLINE OR DOWNLINE
*                  BLOCKS. THIS FIELD ALSO CONTAIN THE ISN - INIT 
*                  SEQUENCE NUMBER WHICH IS SET UP BY NIP FOR DOWNLINE
*                  -INIT- AND BY CCP FOR UPLINE -INIT-. 
*        BT      = BLOCK TYPE. SEE CCP IMS FOR DETAILS. 
*        NHDBC   = DATA BLOCK CLARIFIER. IT EXISTS ONLY FOR BLOCK TYPES 
*                  -MSG- AND -BLK-, SEE CCP IMS FOR DETAILS.
*        NHACT   = APPLICATION CHARACTER TYPE. ONLY CHARACTER TYPE 2
*                  (ASCII-8), 3(ASCII-12) AND 4(DISPLAY CODE) ARE VALID 
*                  FOR DOWNLINE BLOCKS. UPLINE DATA IS ALWAYS IN ASCII-8
*                  FORMAT AND THIS FIELD IS ZEROED FOR UPLINE BLOCKS. 
*        B       = BLOCK TYPE FOR BAD UPLINE BLOCK. WHEN PIP DETECTS
*                  AN UPLINE DATA TRANSMISSION ERROR, THE BT FIELD IS 
*                  CLEARED SO THAT NIP MAY DAYFILE THE BAD UPLINE BLOCK.
*        CC      = TEXT LENGTH IN CHARACTERS. THIS IS SET BY NIP FOR
*                  DOWNLINE BLOCKS AND BY PIP FOR UPLINE BLOCKS.
* 
 #
*ENDIF
*CALL NHEADER 
*CALL IMSPIT
#* * * * * * * * * * ---------- NP$TAA   ---------- * * * * * * * * * *#
*CALL NP$TAA
*CALL NP$NWNC 
#* * * * * * * * * * ----------  NWLHEAD ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  NWLHEAD 
* 
*     THE NETWORK WORKLIST (NWL) IS A DYNAMICALLY ALLOCATED NON-MOVABLE 
*     BUFFER. THE NWL IS 78 WORDS LONG, OF WHICH 64 WORDS CONTAINING
*     THE HEADERS AND WORKLIST ENTRIES ARE PASSED FROM AIP, 2 WORDS 
*     CONTAINING THE APPLICATION STATUS AND IDENTIFICATION INFORMATION
*     ARE PASSED FROM THE OPERATING SYSTEM, ONE BLOCK HEADER WORD IS
*     SET UP BY NIP FOR IDENTIFYING THE WORKLIST BUFFER AND 11 EXTRA
*     WORDS ARE RESERVED FOR THE SITUATION WHEN THE APPLICATION HAS 
*     FAILED DURING THE NWL WORKLIST PROCESSING. A GLOBAL (FOR ANY
*     PROCESS) NWL BUFFER IS ALLOCATED WHENEVER THE PREVIOUS ONE HAS
*     BEEN ASSIGNED TO A NEW NWL FROM AIP. THE NWL HAS A 5-WORD HEADER
*     OF THE FOLLOWING FORMAT : 
* 
*      0          6       24                  59
*     I----------I-------I---------------------I
*     I  NWLID   I NWLBS I                     I     WORD 0 
*     I----------I-------I---------------------I
* 
*     0                   36        42        59
*     I-------------------I---------I----------I
*     I                   I NWLSTAT I NWLHADDR I     WORD 1 
*     I-------------------I---------I----------I
* 
*     0                             42        59
*     I-----------------------------I----------I
*     I                    NWLNAME  I  NWLJDT  I     WORD 2 
*     I-----------------------------I----------I
* 
*     0                                       59
*     I----------------------------------------I
*     I                                        I     WORD 3 
*     I----------------------------------------I
* 
*     0   9       22      30      42          59
*     I---I-------I-------I-------I------------I
*     I   I NWLPN I NWLNE I NWLWC I NWLAWLADDR I     WORD 4 
*     I---I-------I-------I-------I------------I
* 
*     WHERE : 
* 
*        NWLID       = NETWORK WORKLIST ID. 
*        NWLBS       = NETWORK WORKLIST BLOCK SIZE. 
* 
*        ( WORDS 1 AND 2 ARE SET UP BY THE OPERATING SYSTEM AND 
*        PASSED TO NIP )
* 
*        NWLSTAT     = APPLICATION STATUS. SET TO NON-ZERO BY THE 
*                      OPERATING SYSTEM WHEN IT DETECTS THE APPLICATION 
*                      HAD FAILED, ZERO OTHERWISE.
*        NWLHADDR    = UCP COMPLETION BIT ADDRESS. THE COMPLETION BIT 
*                      AT THE SPECIFIED ADDRESS IS SET TO 1 BY NIP
*                      WHEN PROCESSING OF THE WHOLE NWL IS COMPLETED. 
*        NWLNAME     = A 7-CHARACTER JOB NAME FOR THE APPLICATION.
*        NWLJDT      = FNT ADDRESS FOR THE APPLICATION. 
* 
*        ( WORD 4 IS SET UP BY AIP AND PASSED TO NIP TOGETHER WITH
*        THE WORKLIST ENTRIES VIA A SCP FUNCTION CALL ) 
* 
*        NWLPN       = APPLICATION PROCESS NUMBER.
*        NWLNE       = NUMBER OF WORKLIST ENTRIES IN THE NWL. 
*        NWLWC       = TOTAL NUMBER OF WORDS FOR NWL ENTRIES IN NWL.
*        NWLAWLADDR  = APPLICATION WORKLIST ADDRESS. THIS FIELD 
*                      SPECIFIES THE ADDRESS IN APPLICATION-S FIELD 
*                      LENGTH INTO WHICH THE AWL (NIP-S REPLY TO THIS 
*                      NWL) IS WRITTEN. 
* 
 #
*ENDIF
*CALL NWLHEAD 
#* * * * * * * * * * ----------  NWLNTRY ----------* * * * * * * * * * #
*IF,DEF,IMS 
 #
*1DC  NWLNTRY (NETWORK WORKLIST ENTRY)
*     A NETWORK WORKLIST ENTRY IS AN ENTRY IN A WORKLIST WHICH IS 
*     FORMATTED BY AIP AND IS PASSED TO NIP TO BE PROCESSED. AFTER
*     COMPLETING CONSTRUCTION OF A NETWORK WORKLIST, AIP WILL DO A
*     CALLSS MACRO CALL TO TRANSMIT THE WORKLIST TO NIP. UPON RECEIVING 
*     THE WORKLIST, NIP WILL IDENTIFY AND VALIDATE THE CALLER, THROUGH
*     FNT ORDINAL,  DECODE AND PROCESS EACH ENTRY SEQUENTIALLY. 
*     SOMETIMES AN OPERATION CANNOT BE COMPLETED IMMEDIATELY. NAM WILL
*     SUSPEND THE PROCESSING OF THE WORKLIST, LINK IT TO THE CORR-
*     ESPONDING HOST PCB, OR SWAP IN RING IN CASE THE APPLICATION 
*     HAS NO PCB. THE PROCESSING FOR THIS WORKLIST WILL RESUME AT A 
*     LATER TIME AS NAM SEES FIT. THERE ARE TEN DIFFERENT VALID 
*     OPERATIONS FOR NAM FROM AIP. EACH OPERATION TOGETHER WITH ITS 
*     PARAMETERS, MAKES UP AN NETWORK WORKLIST ENTRY. AS AN OPERATION 
*     IS COMPLETELY PROCESSED, ITS ENTRY SPACE IN THE NWL IS RELEASED.
*     THE INITIAL SIZE OF AN NWL IS 72 CM WORDS WITH HEADER. THE HEADER 
*     CONTAINS INFORMATION ABOUT THE APPLICATION AND THE NUMBER OF
*     ENTRIES IN THE NWL. NWL IS ALWAYS NONMOVABLE BY GBGCLT ROUTINE. 
* 
*     EACH ENTRY IN NWL HAS THE FOLLOWING FORMAT: 
* 
*     WORD 0 -
* 
* W   7 
*                          2  3            3       5       5
*      0          6        4  0            6       4       9
*     I----------I--------I--I------------I-------I-------I-------I 
*     I          I        I  I            I       I       I       I 
*     I NWLEID   I NWLEBS I  I  NWLELTAA  I NWLTA I NWLOF I NWLCB I 
*     I          I        I  I            I       I       I       I 
*     I----------I--------I--I------------I-------I-------I-------I 
* 
*     WHERE 
* 
*       NWLEID   = BLOCK ID OF THE NWLNTRY (11) 
*       NWLEBS   = BLOCK SIZE OF THE NWLNTRY. THIS INCLUDES THE TEXT
*                  AREA OR DESCRIPTION OF THE TEXT AREA FOLLOWING THE 
*                  FIRST TWO WORDS OF THE ENTRY IF ONE EXISTS.
*       NWLELTAA = USED IF OPERATION IS NETGETF, NETGETFL, NETPUTF. 
*                  THIS IS THE NUMBER OF ENTRIES IN THE TEXT AREA 
*                  DESCRIPTIONS.
*       NWLTA    = ZERO IF TEXT AREA IMMEDIATELY FOLLOWS THE FIRST TWO
*                  WORDS OF THE NWL ENTRY. IF THE TEXT IS STILL IN
*                  APPLICATION FIELD LENGTH, THIS IS THE ADDRESS
*                  POINTING TO THE FIRST WORD ADDRESS OF THE AREA.
*       NWLOP    = OPERATION CODE FIELD FOR THIS ENTRY. 
*                  A LISTING OF ALL VALID OPERATION CODES CAN BE FOUND
*                  IN NWLHEAD COMMON DECK.
*       NWLCB    = COMPLETION BIT. AFTER NAM COMPLETES THE OPERATION, 
*                  IT WILL SET THIS BIT. THIS IS THEN TRANSFERED BACK 
*                  TO APP.
* 
*     WORD 1 -
* 
*     IF THE OPERATION IS NOT NETWAIT:  
* 
* W   8 
*                          1        3       4      4      4      4
*      0          6        8        6       0      1      2      3
*     I----------I--------I--------I-------I------I------I------I------I
*     I          I        I        I       I      I      I      I      I
*     I   NWLABT I NWLADR I NWLABN I NWLACTI NWL- I NWL- I NWL- I NWL- I
*     I          I        I        I       I  IBU I  BOF I  TRU I  RFE I
*     I----------I--------I--------I-------I------I------I------I------I
* 
* 
*     WHERE 
* 
*       NWLABT   = APPLICATION BLOCK TYPE. FOR DATA MESSAGES, IT IS 1 
*                  OR 2. FOR SUPERVISORY MESSAGE, IT IS 3. FOR SERVICE
*                  MESSAGES, IT IS 4. 
*       NWLADR   = APPLICATION ADDRESS. IT CONTAINS CONNECTION NUMBER 
*                  THIS ENTRY IS REFERING TO. FOR SUPERVISORY MESSAGES
*                  THIS FIELD IS ZERO.
*                  FOR NWLABT = 4, THIS IS THE PN FIELD. THIS FIELD IS
*                  SET BY SENDER TO THE PROCESS NUMBER OF THE RECEIVER, 
*                  AND LATER SET BY NIP TO THE PN OF THE SENDER SO THAT 
*                  THE ONE RECEIVING IT KNOWS WHERE IT COMES FROM.
*       NWLABN   = APPLICATION BLOCK NUMBER. THIS CAN BE USED BY THE
*                  APP TO KEEP TRACK OF BLOCK SENT DOWNLINE. IF A BLOCK 
*                  GETS THROUGH TO THE TERMINAL, NIP WILL SEND APP
*                  A FC/ACK WITH CORRESPONDING ABN. 
*       NWLACT   = APP CHARACTER TYPE. THE CHARACTER TYPE OF THE DATA 
*                  IN THE CURRENT BLOCK.
*       NWLIBU   = INPUT BLOCK UNDELIVERABLE. SET WHEN APP REQUEST A
*                  DATA BLOCK UPLINE, BUT THE BLOCK CANNOT BE DELIVERED 
*                  BECAUSE OF SIZE RESTRICTION IF QHDATRU OFF IN QCB. 
*       NWLBOF   = BREAK OCCURRED FLAG. 
*       NWLTRU   = UPLINE DATA TRUNCATED. SET WHEN APP REQUESTS A DATA
*                  BLOCK UPLINE, AND THE BLOCK IS DELIVERED TRUNCATED 
*                  IF QHDATRU FLAG IS SET IN QCB. 
*       NWLRFE   = RESERVED FOR EXPANSION.
* 
* W   8 
*      4        4        4        4        4      5 
*      4        5        6        7        8      9 
*     I--------I--------I--------I--------I--------I
*     I        I        I        I        I        I
*     I NWLNFE I NWLXPT I NWLCAN I NWLBIT I NWLTLC I
*     I        I        I        I        I        I
*     I--------I--------I--------I--------I--------I
*                N  W  L  D  B  C 
*     WHERE 
* 
*       NWLNFE   = NO FORMAT EFFECTOR. SET WHEN THE FIRST CHARACTER 
*                  OF THE ASSOCIATED BLOCK IS NOT USED AS A FORMAT
*                  CONTROL CHARACTER. 
*       NWLXPT   = TRANSPARENT BIT. SET WHEN TRANSPARENT MODE IS ON,
*                  NO CONVERSION OF DATA TO OTHER CHARACTER TYPE IS 
*                  NEEDED.
*       NWLCAN   = CANCEL BIT.
*                  FOR UPLINE DATA, THIS MEANS THE BLOCK IS CANCELLED 
*                  BY TERMINAL OPERATOR.
*                  FOR DOWNLINE DATA, SET WHEN A LACED CARD IS REQUESTED
*                  TO BE PUNCHED IN FRONT OF THE DATA BLOCK.
*       NWLBIT  =  ON UPLINE DATA, THIS IS THE PARITY ERROR FLAG. ON
*                  DOWNLINE DATA, THIS IS THE AUTO INPUT BIT. SEE NAM 
*                  REFERENCE MANUAL APPLICATION BLOCK HEADER FOR
*                  DETAILS. 
*       NWLACT   = TEXT LENGTH IN UNITS SPECIFIED BY ACT. 
*       NWLDBC   = DATA BLOCK CLARIFIER. NWLNFE, NWLXPT, NWLCAN,
*                  NWLBIT ARE COLLECTIVELY CALLED NWLDBC. 
* 
*     THE TEXT AREA OR DESCRIPTION OF TEXT AREA IF PRESENTS WILL FOLLOW 
*     THE FIRST TWO WORDS OF THE NWLNTRY. 
* 
* 
*     IF OPERATION IS NETWAIT,
* W   7 
*                           4 
*      0         1          2 
*     I---------I----------I-----------I
*     I         I          I           I
*     I NWLFLAG I          I  NWLTIME  I
*     I         I          I           I
*     I---------I----------I-----------I
* 
*     WHERE 
* 
*       NWLFLAG  = FLAG FOR FORCE NETWAIT. SET IF OPERATION NETWAIT IS
*                  WITH FORCE OPTION. 
*       NWLTIME  = TIME LIMIT FOR NETWAIT.
* 
 #
*ENDIF
*CALL NWLNTRY 
*CALL ON
#* * * * * * * * * * -------- OVERLAY  --------- * * * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  OVERLAY 
*     COMMON BLOCK OVERLAY
*     THREE WORD BUFFER USED BY OVLCALL ROUTINE TO SET UP PARAMETER 
*     FOR LOADING OVERLAYS. 
 #
*ENDIF
*CALL OVERLAY 
#* * * * * * * * * * -------- OVLNAME ---------- * * * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  OVLNAME 
*     COMMON DECK OF DEFS OF OVERLAY LEVEL NUMBERS. IT IS USED BY SKENIP
*     AND ALL SYMPL PROGRAMS USING OVERLAYS. THE DEF MACRO FROM MACDEF
*     COMMON DECK WILL CONVERT THE VALUE OF EACH EXPRESSION ENCLOSED
*     IN THE PAIR OF TRIPLE BARS JUST AFTER THE NAME INTO 4 CHARACTERS
*     OCTAL STRING. THE FIRST 2 CHARACTERS GROUP IS THE PRIMARY 
*     LEVEL NUMBER FOR THE NAMED OVERLAY. THE SECOND 2 CHARACTERS GROUP 
*     IS THE SECONDARY LEVEL NUMBER FOR THE OVERLAY.
 #
*ENDIF
*CALL OVLNAME 
#* * * * * * * * * * * ------ OVLSTAT ----- * * * * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  OVLSTAT 
*     COMMON BLOCK TO CREATE A WORD FOR EACH EXISTING OVERLAY. IN 
*     EACH ENTRY OF THE OVLNAMP COMMON BLOCK, LEFTMOST 42 BITS CONTAIN
*     THE NAME OF THE OVERLAY LEFT JUSTIFIED AND ZERO FILLED. THE 
*     REST OF THE WORD WILL BE ZEROED INITIALLY, WHERE THE RIGHTMOST
*     18 BITS ARE USED AS A COUNT OF THE TIMES THE OVERLAY CALLED.
*     THIS INITIALIZATION WILL BE DONE BY THE ITEM MACRO WHEN CALLED
*     FROM OVLCALL ASSEMBLY ROUTINE DURING COMPILATION TIME.
*     THIS COMMON BLOCK EXISTS ONLY WHEN EITHER STATISTICS OR 
*     DEBUG IS ON.
*     NOTE - IT IS VERY IMPORTANT TO HAVE PRINUM, OVLNUM DEFINED
*     ACCURATELY. OTHERWISE, WRONG OVERLAY MAY BE LOADED, AND 
*     INCORRECT STATISTICS MAY BE COLLECTED.
* 
 #
*ENDIF
*CALL OVLSTAT 
#* * * * * * * * * --------- PARAMP ----------- * * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  PARAMP
*     COMMON BLOCK PARAMP. A TWO WORD BUFFER TO PASS PARAMETERS TO
*     PRIMARY OVERLAY.
 #
*CALL IMSPT 
*ENDIF
*CALL PARAMP
*CALL PARAMS
# * * * * * * * * * * * * * ----- PIT ----- * * * * * * * * * * * * * *#
*CALL PIT 
*CALL PT
*CALL RELFILE 
*ENDIF
#* * * * * * * * * * ----------  SCPCOM  ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  SCPCOM
*     SYSTEM CONTROL POINT COMMON DECK, CONTAINING A TEMPLATE (SCPCALL) 
*     FOR FIELDS IN SCP CALL PARAMETER WORDS, ALL POSSIBLE OPERATION
*     CODE, AND ALL POSSIBLE RETURN CODES FROM SCP CALLS. FOR MORE
*     DETAILS ABOUT SCP CALLS, READ DOCUMENTATION ON SCP FACILITY.
* 
*     THE FORMAT OF SCP PARAMETER BLOCK (SCPCALL TEMPLATE): 
* 
* W   7 
*                         2 
*      0          6       4 
*     I----------I-------I
*     I          I       I
*     I   SCPID  I SCPBS I
*     I          I       I
*     I----------I-------I
* 
* 
*     WORD 0 -
* 
*     WHERE 
* 
*       SCPID    = BLOCK ID FOR SYSTEM CONTROL POINT CALL PARAMETER 
*                  BLOCK. 
*       SCPBS    = BLOCK SIZE OF THE PARAMETER BLOCK (3 CM WORDS) 
* 
*     WORD 1 -
* 
* W   7 
*                      1         3         5
*      0       6       8         6         4
*     I-------I-------I---------I---------I-------I 
*     I       I       I         I         I       I 
*     I SCPRC I SCPFP I SCPUCPA I SCPSCPA I SCPFC I 
*     I       I       I         I         I       I 
*     I-------I-------I---------I---------I-------I 
* 
* 
*     WHERE 
* 
*       SCPRC    = RETURN CODE FOR SCP CALL 
*       SCPFP    = FUNCTION PARAMETER.
*       SCPUCPA  = USER CONTROL POINT ADDRESS. ADDRESS IN USER APP
*                  FOR TRANSFER OF INFORMATION. 
*       SCPSCPA  = SYSTEM CONTROL POINT ADDRESS. ADDRESS IN NIP OF
*                  BLOCK USED BY SFLIST, SFREAD, SFWRITE. 
*       SCPFC    = FUNCTION CODE VALID FOR SCP CALL.
*                  RIGHTMOST BIT OF SCPFC IS ALWAYS SET BY SYSTEM 
*                  WHEN THE OPERATION IS COMPLETED. 
* 
*     WORD 2 -
* 
* W   7 
*                      4
*      0               2
*     I---------------I-----------I 
*     I               I           I 
*     I    SCPNAME    I  SCPJDT   I 
*     I               I           I 
*     I---------------I-----------I 
* 
* 
*     WHERE 
* 
*       SCPNAME  = JOB SEQUENCE NUMBER OF THE APP INTERACTING WITH
*                  NAM. 
*       SCPJDT   = FNT ORDINAL OF THE APP.
 #
*ENDIF
*CALL SCPCOM
*CALL SSTCOM
      BASED ARRAY SUPMSG  P(11);
      BEGIN 
*CALL SUPMSG
*CALL SMAPPL
*CALL SMRBF 
      END 
      BASED ARRAY SMNIP  P(3);
      BEGIN 
*CALL SMNIP 
      END 
      BASED ARRAY SMNVF  P(11); 
      BEGIN 
*CALL SMNVF 
      END 
*CALL SUPABH
#* * * * * * * * * * ----------  STATTAB ----------* * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  STATTAB 
*     STATISTICS VARIABLES COMMON BLOCK. USED ONLY IF STATISTICS IS ON
*     DURING NAM GENERATION. THE COMMON BLOCK IS USED BY SYMPL AND
*     COMPASS ROUTINES. 
*     LIST OF STATISTICS VARIABLES IN THE COMMON BLOCK: 
*      1. ST$PCB    NUMBER OF PCBS ASSIGNED.
*      2. ST$PCBX   NUMBER OF PCBS DELETED. 
*      3. ST$QCB    NUMBER OF QCBS ASSIGNED.
*      4. ST$QCBX   NUMBER OF QCBS DELETED. 
*      5. ST$AQ     NUMBER OF ACKNOWLEDGEMENT QUEUES CREATED. 
*      6. ST$AQX    NUMBER OF ACKNOWLEDGEMENT QUEUES RELEASED.
*      7. ST$NIB    NUMBER OF TIMES PIP NEEDED NEW INBOUND BUFFER.
*      8. ST$INB    NUMBER OF INBOUND NON-DATA BLOCKS 
*      9. ST$INC    NUMBER OF INBOUND NON-DATA CHARACTERS 
*     10. ST$IDB    NUMBER OF INBOUND DATA BLOCKS 
*     11. ST$IDC    NUMBER OF INBOUND DATA CHARACTERS.
*     12. ST$ONB    NUMBER OF OUTBOUND NON-DATA BLOCKS. 
*     13. ST$ONC    NUMBER OF OUTBOUND NON-DATA CHARACTERS. 
*     14. ST$ODB    NUMBER OF OUTBOUND DATA BLOCKS. 
*     15. ST$ODC    NUMBER OF OUTBOUND DATA CHARACTERS. 
*     16. ST$LNB    NUMBER OF LOCAL NON-DATA BLOCKS.
*     17. ST$LNC    NUMBER OF LOCAL NON-DATA CHARACTERS.
*     18. ST$LDB    NUMBER OF LOCAL DATA BLOCKS.
*     19. ST$LDC    NUMBER OF LDCAL DATA CHARACTERS.
*     20. ST$ENB    NUMBER OF TIMES PIP INBOUND BUFFERS WERE EMPTY. 
*     21. ST$ESB    NUMBER OF TIMES SCP BUFFER EMPTY. 
*     22. ST$RCL    NUMBER OF TIMES NIP DOES RECALL.
*     23. ST$LOOP   NUMBER OF TIMES XEXEC LOOP GETS EXECUTED. 
*     24. ST$SCP    NUMBER OF SCP CALLS.
*     25. ST$SI     NUMBER OF TIMES OSWAPIN EXECUTED. 
 #
*ENDIF
*CALL STATTAB 
#* * * * * * * * * *--------- STATTAB2 ---------- * * * * * * * * * * *#
*IF,DEF,IMS 
 #
*1DC  STATTAB2
*     STATISTICS VARIABLES FOR MEMORY MANAGER. USED BY BOTH 
*     SYMPL AND COMPASS ROUTINES. 
*     LIST OF VARIABLES IN THE BLOCK: 
* 
*      1. ST$GET    NUMBER OF TIMES BUFFERS ALLOCATED.
*      2. ST$GNB    NO. OF BUFFERS TRANSVERSED BY MGETS 
*      3. ST$REL    NUMBER OF TIMES BUFFERS RELEASED. 
*      4. ST$RNB    NO. OF BUFFERS TRANSVERSED BY MRELS 
*      5. ST$FL     NUMBER OF TIMES NIP INCREASES FIELD LENGTH. 
*      6. ST$FLW    SUM OF WORDS NIP INCREASES ITS FIELD LENGTH.
*      7. ST$FLX    NUMBER OF TIMES NIP DECREASES FIELD LENGTH. 
*      8. ST$FLWX   SUM OF WORDS NIP DECREASES ITS FIELD LENGTH.
*      9. ST$FLT    FIELD LENGTH * INTERVAL.
*     10. ST$FWT    FREE WORDS * TIME INTERVAL. 
*     11. ST$FBT    FREE BUFFER NUMBER * TIME INTERVAL. 
*     12. ST$GBWM   SUM OF WORDS MOVED IN GARBAGE COLLECTION. 
*     13. ST$GBGC   NUMBER OF BUFFERS COMBINED BY GARBAGE COLLECTION. 
 #
*ENDIF
*CALL STATTAB2
#* * * * * * * * * * -------- SWAPIN  ---------- * * * * * * * * * * * #
*IF DEF,IMS 
 #
*1DC  SWAPIN
*     COMMON DECK FOR SWAP IN RING STRUCTURE. 
*     SWAPIN COMMON BLOCK IS A TWO WORD TABLE USED TO MANAGE SCP SWAPIN 
*     RING. EACH ENTRY IN THE RING IS A SCP SWAPIN CALL. ENTRIES ARE
*     ADDED TO THE RING WHEN AN APPLICATION NEEDS TO BE SWAPPED IN AND
*     IT HAS NO PCB. THE SWAPIN RING ENTRIES ARE NOT MOVABLE. 
*     EACH SWAPIN RING ENTRY HAS THE FOLLOWING FORMAT:  
* 
* 
*     WORD 0 -
* W   7 
*                          2         4        5 
*      0          6        4         2        9 
*     I----------I--------I---------I---------I 
*     I          I        I         I         I 
*     I   SWPIID I SWPIBS I SWPINBP I SWPINFP I 
*     I          I        I         I         I 
*     I----------I--------I---------I---------I 
* 
*     WHERE 
* 
*       SWPIID   = SWAP IN RING ENTRY BLOCK ID (9)
*       SWPIBS   = BLOCK SIZE OF ENTRY (4)
*       SWPINBP  = BACKWARD POINTER TO PREVIOUS ENTRY IN THE DOUBLY 
*                  LINKED SWAP IN RING. 
*       SWPINFP  = FORWARD POINTER TO FOLLOWING ENTRY.
* 
* 
*     WORD 1 -
* W   7 
*                             2         4 
*      0        1              4        2 
*     I--------I--------------I--------I--------I 
*     I        I              I        I        I 
*     I SWPINC I              I SWPIWR I SWPIFL I 
*     I        I              I        I        I 
*     I--------I--------------I--------I--------I 
* 
* 
*     WHERE 
* 
*       SWPINC   = SET WHEN THE FUNCTION LIST ASSOCIATED WITH THE 
*                  ENTRY HAS BEEN USED IN A SCP CALL PREVIOUSLY.
*       SWPIWR   = ADDRESS OF SCP WRITE BUFFER. 
*       SWPIFL   = ADDRESS OF FUNCTION LIST FOR SCP CALL. 
* 
* 
*     WORD 2 -
* 
* W   7 
*                        1          3          5
*      0       6         8          6          4
*     I--------I--------I----------I----------I--------I
*     I        I        I          I          I        I
*     I SWPIRC I SWPIFP I SWPIUCPA I SWPISCPA I SWPIFC I
*     I        I        I          I          I        I
*     I--------I--------I----------I----------I--------I
* 
* 
*     WHERE 
* 
*       SWPIRC   = RETURN CODE FROM SWAPIN SCP REQUEST. 
*       SWPIFP   = FUNCTION PARAMETER. NOT USED IN SWAPIN REQUEST.
*       SWPIUCPA = USER ADDRESS. NOT USED IN SWAPIN REQUEST.
*       SWPISCPA = SCP ADDRESS. NOT USED IN SWAPIN REQUEST. 
*       SWPIFC   = OPERATION CODE. RIGHTMOST BIT OF THIS FIELD IS THE 
*                  COMPLETION BIT.
* 
*     WORD 3 -
* 
* 
* W   7 
*                        4
*     0                  2
*     I-----------------I-----------I 
*     I                 I           I 
*     I    SWPINAME     I  SWPIJDT  I 
*     I                 I           I 
*     I-----------------I-----------I 
* 
* 
*    WHERE
* 
*       SWPINAME = JOB SEQUENCE NUMBER OF THE APP ASSOCIATED WITH THIS
*                  ENTRY. 
*       SWPIJDT  = FNT OF THE APP.
* 
 #
*ENDIF
*CALL SWAPIN
# * * * * * * * * * * * --- SYSCOMD --- * * * * * * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  SYSCOMD 
*     COMMON DECK DEFINED TO ENABLE NIP TO REFERENCE THE SYSTEM 
*     COMMUNICATION AREA
*     THE ARRAYS AND ITEMS INCLUDED IN THIS COMMON DECK IS
*     1.  PGNAME             PROGRAM NAME WORD IN RA
*     2.  LDPM               ARRAY POINTED TO RA+LWPR 
*                            LWA+1 OF MAIN OVERLAY, OVERLAY CALL TYPE 
*                            ARE IN THIS WORD 
*     3.  RASSC              ARRAY FOR RA.SSC WORD FOR SYSTEM CONTROL 
*                            INTERFACE
* 
*     WORD 0 -
* W   7 
*                          2                2       4 
*      0       1     6     3                5       2 
*     I-------I-----I-------I--------------I-------I-------I
*     I       I     I       I              I       I       I
*     I SSCLK I     I SSCXP I   SSCVF      I SSCLP I SSCAP I
*     I       I     I       I              I       I       I
*     I-------I-----I-------I--------------I-------I-------I
* 
* 
*     WHERE 
* 
*       SSCLK    = SET IF NO INCOMING WORKLIST. 
*       SSCXP    = ADDRESS OF APP EXCHANGE PACKAGE. 
*       SSCVF    = SET IF VARIABLE LENGTH WORKLIST ALLOWED. 
*       SSCLP    = LENGTH OF SCP BUFFER FOR INCOMING WORKLIST.
*       SSCAP    = ADDRESS OF SCP BUFFER
* 
 #
*ENDIF
*CALL SYSCOMD 
#* * * * * * * * * * -------- SYSTIME  ---------- * * * * * * * * * * *#
*IF DEF,IMS 
 #
*1DC  SYSTIME 
*     COMMON DECK FOR INTERFACE WITH OPERATING SYSTEM REAL TIME MACRO.
*     TIME IS A COMMON BLOCK USED BY ROUTINES IN NAM. IT CONTAINS 
*     THETIME ARRAY WHICH HAS A DESCRIPTION OF THE FIELDS IN THE
*     PARAMETER WORD FOR REAL TIME MACRO CALL. NOTE - THIS IS A NOS VER-
*     SION OF REAL TIME MACRO.
* 
*     FORMAT OF THETIME PARAMETER WORD: 
* 
*     WORD 0 -
* 
* W   7 
*                 2 
*      0          4 
*     I----------I---------I
*     I          I         I
*     I  RTSECS  I  MSECS  I
*     I          I         I
*     I----------I---------I
* 
* 
*     WHERE 
* 
*       RTSECS   = REAL TIME IN SECONDS UNIT. 
*       MSECS    = REAL TIME IN MICRO SECONDS UNIT. 
* 
 #
*ENDIF
*CALL SYSTIME 
# * * * * * * * * * * * * * ----- TNT ----- * * * * * * * * * * * * * *#
*CALL TNT 
#* * * * * * * * * * ----------  TRAF    ----------* * * * * * * * * * #
      BASED ARRAY TRAFLST P(10);
        BEGIN 
        END 
#* * * * * * * * * * ----------  USERDEF ----------* * * * * * * * * * #
 
*IF DEF,IMS 
 #
 *    NETWORK PRODUCTS DOCUMENTATION        PAGE
 *    NAM INTERNAL SPECIFICATION            DATE. 
 *    4.0 SYSTEM CONTROL POINT COMMUNICATION
* 
*     NIP, AS A SUBSYSTEM, USES THE NOS SYSTEM CONTROL POINT
*     FEATURE TO COMMUNICATE WITH OTHER PROGRAMS, WHICH WILL HERE-
*     AFTER BE REFERRED TO AS USER CONTROL POINTS (UCP).  AS PART OF
*     ITS INITIALIZATION PHASE, NIP ISSUES A RA+1 CALL TO ESTABLISH 
*     ITSELF AS A SYSTEM CONTROL POINT (SCP).  THIS IS SO THE OPERATING 
*     SYSTEM CAN KEEP TRACK OF WHICH SUBSYSTEMS ARE ACTIVE AS SYSTEM
*     CONTROL POINTS. 
* 
*     AS A SYSTEM CONTROL POINT, NIP CAN EXECUTE THE FOLLOWING
*     FUNCTIONS:  
* 
*       1) SF.ENDT     TERMINATE SHORT TERM CONNECTION BETWEEN UCP
*                      AND SCP
*       2) SF.SLTC     ESTABLISH LONG TERM CONNECTIONS BETWEEN UCP
*                      AND SCP
*       3) SF.CLTC     CLEAR LONG TERM CONNECTIONS BETWEEN UCP AND SCP
*       4) SF.WRITE    WRITE ANYWHERE IN AN UCP-S FIELD LENGTH
*       5) SF.READ     READ ANY LOCATION IN AN UCP-S FIELD LENGTH 
*       6) SF.REGR     ABORT ANY UCP AND WRITE MSG TO ITS DAYFILE 
*       7) SF.SWPO     SWAP OUT UCP 
*       8) SF.SWPI     SWAP IN UCP
*       9) SF.STAT     DETERMINE IF UCP IS SYSTEM RESIDENT
* 
*     A CLARIFICATION IS NEEDED IN THE DEFINITION OF UCP AS USED IN 
*     THE ABOVE FUNCTIONS.  AN UCP IS ANY PROGRAM THAT IS COMMUNICATING 
*     (HAS ESTABLISHED A CONNECTION) WITH A SYSTEM CONTROL POINT.  IN 
*     OUR CASE, THAT SCP IS NIP.  THEREFORE, NIP CANNOT ARBITRARILY 
*     ABORT, READ, OR OVERWRITE THE FIELD LENGTH, ETC. OF JUST ANY
*     PROGRAM RUNNING IN THE COMPUTER.
* 
*     COMMUNICATION BETWEEN AN UCP AND A SCP CAN ONLY BE INITIATED BY 
*     THE UCP.  THIS OCCURS WHEN AIP ISSUES A SSC RA+1 CALL.  THE SSC 
*     CALL INFORMS THE OPERATING SYSTEM THAT THE UCP WISHES TO SEND 
*     A WORKLIST (NWL) TO NIP.
* 
*     WHENEVER THE UCP SENDS A WORKLIST TO NIP, A SHORT TERM CON- 
*     NECTION HAS BEEN ESTABLISHED BETWEEN NIP AND THE UCP.  UNLESS 
*     THE UCP FAILS, THIS SHORT TERM CONNECTION CAN BE TERMINATED 
*     ONLY BY NIP.  THIS IS DONE WHEN NIP ISSUES THE SF.ENDT SCP
*     FUNCTION.  THE OPERATING SYSTEM ALLOWS AN UCP TO ESTABLISH UP 
*     TO SEVEN SHORT TERM CONNECTIONS BETWEEN ITSELF AND NIP.  HOWEVER, 
*     NIP AND AIP WILL ALLOW ONLY ONE WORKLIST (AND THEREFORE ONLY
*     ONE SHORT TERM CONNECTION) AT A TIME TO BE TRANSFERRED (UNLESS
*     THE SECOND WORKLIST IS A NETOFF).  NIP WILL ISSUE THE SF.ENDT SCP 
*     FUNCTION AFTER IT HAS FINISHED PROCESSING THE WORKLIST. 
* 
*     THE FIRST WORKLIST THAT AIP SENDS TO NIP MUST BE A NETON
*     WORKLIST.  IF NOT, NIP WILL ABORT THE UCP (UNLESS IT IS A 
*     NETOFF WORKLIST).  WHEN NIP RECEIVES THE NETON WORKLIST ENTRY,
*     IT WILL ISSUE A SF.STAT SCP FUNCTION TO DETERMINE IF THE UCP IS 
*     SYSTEM RESIDENT.  IF THE UCP IS NS OR CS AND LIBRES IS NOT
*     DEFINED, THE UCP MUST BE SYSTEM RESIDENT.  IF NOT, NIP
*     WILL ABORT THE UCP ASSUMING THAT A MALICIOUS UCP WAS TRYING 
*     TO MASQUERADE AS NS OR CS.  IF LIBRES IS DEFINED, NIP DOES NOT
*     CARE IF NS OR CS ARE SYSTEM RESIDENT.  IF THE UCP IS NOT NS OR CS,
*     NIP WILL CREATE A PCB AND SEND A NET/ON SUPERVISOR MESSAGE
*     TO CS, UNLESS THE NETWORK IS SHUTTING DOWN OR CS HAS NOT
*     NETTED ON YET OR NIP COULD NOT CREATE A PCB FOR THE UCP.
*     THEN NIP WILL REJECT THE NETON.  CS WILL SEND NIP A RESPONSE
*     TO THE NET/ON SUPERVISOR MESSAGE.  SINCE IT MAY TAKE SOME 
*     TIME BEFORE NIP GETS THE SUPERVISOR MESSAGE 
*     RESPONSE, THE SYSTEM CANNOT AFFORD TO HAVE THE UCP SIT AT A CON-
*     TROL POINT WAITING FOR A NETON RESPONSE, ESPECIALLY IF ITS FIELD
*     LENGTH IS QUITE LARGE.  THUS NIP WILL SWAPOUT THE UCP AND WILL
*     NOT SWAP IT BACK IN UNTIL AFTER IT GETS THE NET/ON/R FROM CS. 
*     IN THE NET/ON/R FROM CS IS A RETURN CODE.  DEPENDING ON THE 
*     VALUE OF THIS RETURN CODE, NIP WILL EITHER ABORT
*     THE UCP, REJECT THE NETON, OR ACCEPT THE NETON.  TO ABORT THE 
*     UCP, NIP WILL ISSUE A SF.REGR SCP FUNCTION.  THIS WILL SET THE
*     ERROR FLAG AT THE UCP-S CONTROL POINT AND PUT A MSG IN ITS
*     DAYFILE EXPLAINING WHY IT WAS ABORTED.  IF REJECTING THE NETON, 
*     NIP WILL CREATE A NETON AWL.  IN THIS AWL WILL BE THE REASON CODE 
*     FOR REJECTING THE NETON OF THIS UCP.  THE AWL WILL GET WRITTEN
*     TO THE UCP USING THE SF.WRITE SCP FUNCTION IN A FUNCTION LIST 
*     WHICH INCLUDES A SF.ENDT SCP FUNCTION.  IF THE NETON IS ACCEPTED
*     NIP WILL ESTABLISH A LONG TERM CONNECTION (ISSUE SF.SLTC SCP
*     FUNCTION) WITH THE UCP. 
* 
*     LONG TERM CONNECTIONS NEED TO BE ESTABLISHED BETWEEN UCP-S
*     AND SCP-S SO THAT THE OPERATING SYSTEM CAN KEEP A RECORD
*     OF WHICH SCP-S ARE COMMUNICATING WITH WHICH UCP-S EVEN IF 
*     NO SHORT TERM CONNECTIONS EXIST.  THIS WAY, IF NIP SHOULD 
*     FAIL, THE OPERATING SYSTEM KNOWS WHICH PROGRAMS IN THE
*     SYSTEM WERE COMMUNICATING WITH NIP.  TO INFORM THE UCP-S
*     THAT NIP IS GONE, THE OPERATING SYSTEM ABORTS THEM.  ALSO IF
*     THE UCP SHOULD FAIL, THE OPERATING SYSTEM KNOWS WHICH SCP-S THE 
*     UCP WAS COMMUNICATING WITH.  IT CAN THEREFORE INFORM THE SCP THAT 
*     THE UCP HAS FAILED.  THIS IS DONE BY THE OPERATING SYSTEM 
*     CREATING A WORKLIST TO SEND TO THE SCP.  IN THIS WORKLIST IS
*     THE JOBID OF THE UCP THAT FAILED PLUS A NONZERO VALUE IN THE
*     FAILED-STATUS FIELD.
* 
*     IF THE NETON IS SUCCESSFUL, THE UCP WILL BE ABLE TO START 
*     SENDING NETGET, NETPUT, NETWAIT, ETC. WORKLIST ENTRIES TO 
*     NIP.  NIP WILL PROCESS THESE WORKLIST (NWL) ENTRIES UNTIL 
*     EITHER 1) IT FINISHES PROCESSING THE LAST ENTRY, 2) IT
*     CANNOT GET THE SPACE NEEDED TO PROCESS THE CURRENT ENTRY, 3)
*     COMES ACROSS A NETWAIT WORKLIST ENTRY, 4) IT ISSUES A SCP 
*     FUNCTION AND GETS A SCP RETURN CODE 44B, OR 5) THE UCP TRIES
*     TO SEND A SUPERVISOR MESSAGE TO CS AND CS HAS REACHED ITS 
*     MAXIMUM NUMBER OF QUEUED SUPERVISOR MESSAGES.  EXCEPT FOR CASE
*     NUMBER 1, NIP WILL TEMPORARILY SUSPEND PROCESSING THE WORKLIST. 
*     PERIODICALLY XSPCB WILL BE CALLED TO CHECK IF THE SITUATION 
*     WHICH CAUSED THE WORKLIST PROCESSING TO BE SUSPENDED HAS CLEARED
*     UP.  IF SO, IT WILL RESTART WORKLIST PROCESSING FROM WHEREVER 
*     IT LEFT OFF.  FOR MOST WORKLIST PROCESSING NIP WILL BE REQUIRED 
*     TO CREATE AN AWL TO WRITE BACK TO THE APPLICATION.  THIS AWL WILL 
*     BE WRITTEN TO THE UCP AFTER NIP FINISHES PROCESSING THE WORKLIST
* 
*     IN PROCESSING NETGETS OR NETGETLS, IF NIP HAS DATA FOR THE UCP, 
*     IT WILL ISSUE A SF.WRITE SCP FUNCTION(S) TO WRITE THE TEXT BACK 
*     TO THE UCP-S FIELD LENGTH.  IF NIP HAS NO DATA, THEN IT WILL JUST 
*     CREATE AN AWL ENTRY.  IN PROCESSING NETGETFS OR NETGTFLS, NIP 
*     MAY ALSO HAVE TO FIRST ISSUE A SF.READ SCP FUNCTION TO READ THE 
*     TEXT ARRAY INTO ITS FIELD LENGTH, IF THE TEXT ARRAY DID NOT FIT IN
*     THE WORKLIST.  IN PROCESSING NETPUTS AND NETPUTFS, NIP MAY BE 
*     REQUIRED TO ISSUE SF.READ SCP FUNCTION(S) TO READ THE TEXT FROM 
*     THE UCP-S FIELD LENGTH, IF THE TEXT DID NOT FIT IN THE WORKLIST.
*     IN PROCESSING NETPUTF THERE MAY BE AN ADDITIONAL SF.READ SCP
*     FUNCTION ISSUED TO FIRST READ THE TEXT ARRAY INTO NIP-S FIELD 
*     LENGTH, IF THE TEXT ARRAY DID NOT FIT IN THE WORKLIST.
* 
*     IN SENDING NIP A NON-FORCE NETWAIT WORKLIST ENTRY, THE UCP IS 
*     SAYING IT HAS NOTHING TO DO UNTIL THERE IS SOME DATA OR 
*     SUPERVISOR MESSAGE FOR IT TO PROCESS.  THEREFORE RATHER THAN
*     HAVING THE UCP WAIT AROUND AT A CONTROL POINT FOR SOMETHING 
*     TO DO, IF NIP HAS NOTHING TO SEND TO THE UCP AND THE NETWAIT
*     TIME IS GREATER THAN THE MINIMUM SWAPOUT TIME, NIP WILL SWAP
*     THE UCP OUT (USING THE SF.SWPO SCP FUNCTION).  WHEN DATA BECOMES
*     AVAILABLE OR THE NETWAIT TIME IS UP, NIP WILL SWAP IN THE UCP 
*     (USING THE SF.SWPI SCP FUNCTION) AND CONTINUE PROCESSING THE
*     REST OF THE WORKLIST FROM WHEREVER IT LEFT OFF.  IF NIP RECEIVES
*     A FORCED NETWAIT ENTRY, IT WILL SWAP OUT THE UCP (UNLESS THE
*     NETWAIT TIME IS LESS THAN THE MINIMUM SWAPOUT TIME).  THE UCP 
*     WILL NOT BE SWAPPED IN UNTIL THE NETWAIT TIME IS UP, EVEN IF
*     DATA BECOMES AVAILABLE FOR THE UCP BEFORE THEN. 
* 
*     WHEN THE UCP NETOFFS, IT NO LONGER WISHES TO COMMUNICATE WITH 
*     NIP.  NIP WILL FIRST CHECK TO SEE IF IT HAS A RECORD (ACTIVE PCB) 
*     OF THAT UCP. IF SO, NIP KNOWS THAT THE UCP HAD SUCCESSFULLY NETTED
*     ON AND NIP HAD ESTABLISHED A LONG TERM CONNECTION WITH IT.  NIP 
*     WILL THEN ISSUE A SCP FUNCTION LIST TO CLEAR BOTH THE LONG AND
*     SHORT TERM CONNECTIONS AND ALSO INFORM CS THAT THE UCP IS NETTING 
*     OFF BY SENDING IT A NET/OFF SUPERVISOR MESSAGE (UNLESS NIP HAD
*     PREVIOUSLY INFORMED CS THAT THE UCP WAS GONE).  IF NIP HAS
*     NO RECORD OF THE UCP, IT WILL ASSUME THAT NO LONG TERM CONNECTION 
*     EXISTS AND ALSO THAT CS HAS NO RECORD OF THE UCP. NIP WILL THEN 
*     ISSUE A SCP FUNCTION TO CLEAR ONLY A SHORT TERM CONNECTION.  NIP
*     WILL ALSO NOT INFORM CS THAT THE UCP IS NETTING OFF.  WHEN THE
*     SCP FUNCTION LIST HAS BEEN COMPLETED, THE UCP WILL HAVE BECOME A
*     NORMAL PROGRAM AGAIN AND BE FREE TO CONTINUE PROCESSING OR TO 
*     TERMINATE.  IF DESIRED, THE PROGRAM CAN EVEN NETON AGAIN AND
*     REESTABLISH ITS CONNECTION WITH NIP.
* 
*     WHENEVER AN UCP FAILS, THE OPERATING SYSTEM WILL INFORM NIP.
*     NIP WILL THEN ISSUE A SF.ENDT SCP FUNCTION WITH UCPA = -1 TO
*     CLEAR ALL CONNECTIONS IT HAS WITH THE UCP.  IF NIP SHOULD GET 
*     A SCP RETURN CODE 44B, IT WILL DISCONTINUE PROCESSING THE UCP 
*     FAILURE AND ASSUME THAT THE OPERATING SYSTEM WILL INFORM NIP THAT 
*     THE UCP HAD FAILED AGAIN.  WHEN IT DOES, NIP WILL PROCESS THE SCP 
*     FAILURE AS IF IT WAS BEING NOTIFIED FOR THE FIRST TIME.  UNTIL
*     NIP SUCCESSFULLY CLEARS THE CONNECTIONS BETWEEN ITSELF AND THE
*     UCP, THE UCP WILL HANG AT THE CONTROL POINT UNABLE TO EXECUTE ITS 
*     NEXT CONTROL CARD.  AFTER CLEARING THE CONNECTIONS, IF NIP HAD
*     A PCB FOR THAT UCP AND NIP HAD NOT PREVIOUSLY INFORMED CS 
*     THAT THE UCP WAS GONE, NIP WILL SEND A FAIL/APPL SUPERVISOR 
*     MESSAGE TO CS TO INFORM IT THAT THE UCP HAD FAILED. 
* 
*     ALL SCP FUNCTIONS EXCEPT SWAPIN ARE ISSUED WITH RECALL, I.E.
*     NIP DOES NOT WANT THE CPU BACK UNTIL THE FUNCTION IS COMPLETE.
*     HOWEVER, THERE ARE MANY CASES WHERE THE FUNCTION COULD NOT BE 
*     COMPLETED.  IF THIS HAPPENS, THE OPERATING SYSTEM WILL GIVE NIP A 
*     NONZERO RETURN CODE (RC) INDICATING WHAT WENT WRONG.  FOR MOST
*     OF THESE RETURN CODE VALUES, NIP OR THE OPERATING SYSTEM DID
*     SOMETHING WRONG, SO NIP ABORTS.  THE RETURN CODES FOR WHICH NIP 
*     DOES NOT USUALLY ABORT ARE 43B, 44B, 45B, AND 46B.  THERE ARE 
*     RESPECTIVELY - BAD UCP ADDRESS, UCP IS SWAPPED OUT, UCP NOT IN
*     SYSTEM, AND UCP TEMPORARILY CANNOT BE SWAPPED IN. 
*     IF NIP GETS A SCP RC=43B, NIP ASSUMES THAT THE UCP
*     IN SYSTEM.  IF NIP GETS A SCP RC=43B, NIP ASSUMES THAT THE UCP
*     GAVE HIM A BAD ADDRESS SO NIP ABORTS THE UCP.  IF NIP GETS A SCP
*     RETURN CODE 45B, IT WILL DISCONTINUE PROCESSING THE WORKLIST AND
*     TREAT THE UCP AS HAVING FAILED.  UNDER CERTAIN CASES, IT IS 
*     EVEN POSSIBLE FOR A SCP 43B RETURN CODE TO BE FATAL.  FOR 
*     EXAMPLE, IF NIP ISSUES A SCP SF.ENDT FUNCTION, IT SHOULD NEVER
*     GET A SCP RETURN CODE 43B.
* 
*     NORMALLY, WHEN NIP GETS A SCP RETURN CODE 63B (NO CONNECTION
*     EXISTS BETWEEN THE UCP AND THE SCP), NIP ABORTS.
*     HOWEVER, THERE IS ONE SPECIAL CASE WHEN IT DOES NOT.  THAT IS 
*     WHEN HAPFAIL CALLS NIP TO PROCESS AN UCP FAILURE.  SINCE THE
*     OPERATING SYSTEM CAN INFORM NIP MORE THAN ONCE THAT THE UCP HAS 
*     FAILED,  IT IS POSSIBLE FOR NIP TO GET TWO FAILED-STATUS WORKLISTS
*     FOR THE SAME UCP.  AFTER NIP FINISHES PROCESSING THE FIRST
*     FAILED-STATUS WORKLIST, IT WILL NO LONGER HAVE ANY CONNECTIONS
*     WITH THE FAILED UCP.  IN PROCESSING THE SECOND FAILED-STATUS
*     WORKLIST, NIP WILL GET A SCP RETURN CODE 63B, WHEN IT ISSUES THE
*     SCP SF.ENDT FUNCTION (WITH UCPA = -1) FOR THIS SAME UCP.
* 
*     IN MOST CASES WHEN A SCP FUNCTION IS ISSUED, A PCB EXISTS FOR 
*     THE APPLICATION.  IF THE SCP FUNCTION GETS A RETURN CODE 44B, 
*     NIP WILL DISCONTINUE PROCESSING THE WORKLIST AND ISSUE A SF.SWPI
*     SCP FUNCTION TO SWAP IN THE UCP.  THEN NIP WILL TRY TO SET FIELDS 
*     AND POINTERS IN THE PCB SO THAT THE WORKLIST ENTRY THAT CAUSED THE
*     SCP CALL TO BE MADE CAN BE REPROCESSED FROM THE BEGINNING.
*     HOWEVER, THIS IS NOT ALWAYS POSSIBLE.  FOR EXAMPLE, IN PROCESSING 
*     A NETGETSM WORKLIST ENTRY, NIP WILL MOVE ALL THE SUPERVISOR 
*     MESSAGES INTO ONE BUFFER AFTER DELINKING THEM FROM THE PCB. 
*     THEN THE SF.WRITE SCP FUNCTION IS ISSUED TO WRITE THE SUPERVISOR
*     MESSAGES TO AIP-S SUPERVISOR MESSAGE BUFFER.  IF NIP GETS A 
*     SCP RETURN CODE 44B, IT WOULD BE TOO MUCH WORK TO LINK THE
*     SUPERVISOR MESSAGES BACK TO THE PCB.  NIP THEREFORE STORES THE
*     SCP FUNCTION LIST ADDR AND SUPERVISOR MESSAGE BUFFER ADDRESS IN 
*     THE PCB.  AFTER THE UCP IS SWAPPED IN, THE ORIGINAL SCP FUNCTION
*     LIST IS REISSUED. 
* 
*     UNFORTUNATELY THERE ARE CASES WHERE A PCB DOES NOT EXIST FOR
*     THE APPLICATION AND A SCP FUNCTION IS ISSUED WHICH GETS A RETURN
*     CODE 44B.  THEY ARE: 1) AN UCP NETOFF-S 
*     AND NIP GETS AN SCP RC=44B IN RESPONSE TO THE SF.ENDT, 2) 
*     AN UCP TRIES TO NETON AND NIP GETS A SCP RC=44B IN RESPONSE 
*     TO THE SF.STAT SCP FUNCTION, 3) AN UCP TRIES TO NETON AND NIP 
*     REJECTS IT AND NIP GETS 
*     NETON AND CS REJECTS IT (NON-FATAL) AND NIP GETS A SCP RC=44B 
*     IN RESPONSE TO THE SCP FUNCTION LIST, 5) A MALICIOUS UCP TRIES TO 
*     NETON AS NS OR CS, OR CS REJECTED ITS NETON (FATAL) AND NIP GETS
*     A SCP RC=44B IN RESPONSE TO THE SF.REGR SCP FUNCTION TO ABORT THE 
*     UCP.  FOR THESE FIVE CASES NIP WILL ISSUE A SWAPIN OF THE UCP AND 
*     CREATE A "NO PCB" SWAPIN CHAIN ENTRY.  THE SWAPIN CHAIN ENTRY 
*     WILL CONTAIN THE SCP SWAPIN CALL PLUS THE ADDRESS OF THE ORIGINAL 
*     FUNCTION LIST PLUS MAYBE AN AWL TO WRITE BACK TO THE UCP. 
*     WHEN XSPCB IS CALLED, IT WILL CHECK TO SEE IF THERE ARE ANY 
*     ENTRIES IN THIS CHAIN.  IF SO IT WILL CHECK IF THE SWAPIN HAS 
*     COMPLETED.  IF COMPLETED,  THE ORIGINAL SCP FUNCTION WILL BE
*     BE REISSUED, AND IF SUCCESSFUL, THE SWAPIN ENTRY WILL BE RELEASED 
*      NIP WILL RECEIVE A SCP RC=46B IN RESPONSE TO ONLY A SWAPIN 
*      REQUEST.  NIP WILL SIMPLY REISSUE THE SWAPIN REQUEST IMMEDIATELY.
* 
 #
*ENDIF
#**********************************************************************#
 
      BEGIN 
      PARAMP1 = LWPR[0];     # LWA + 1 OF MAIN OVERLAY                 #
      POVL4 = OVLFG[0];      # SET OVERLAY LOAD CALL TYPE              #
      OVLADR0[0] = PGNAME;   # EXECUTION FILE NAME                     #
      OVLNAME = INIPP;       # NAME OF OVERLAY PROGRAM TO LOAD         #
      OVLCALL;               # LOAD AN EXECUTE OVERLAY                 #
      CONTROL IFEQ ZZDN,1;
      OVLNAME = INIPDP;      # CHECK IF FILES ARE LOCAL                #
      OVLCALL;
      CONTROL FI; 
 
      IRECVR;                # INITIATE RECOVERY                       #
      NIPINIT = TRUE; 
 
NIP10:  
      XEXEC;                 # GOTO MAIN EXECUTION CONTROL             #
      GOTO NIP10;            # LOOP                                    #
      END 
TERM