*DECK NETCHEK
USETEXT AIPDEF
USETEXT NP$MODE
USETEXT NP$NWL
USETEXT NP$STAT
PROC NETCHEK;
*IF DEF,IMS
#
* NETWORK PRODUCTS DOCUMENTATION PAGE
* NAM INTERNAL SPECIFICATION DATE.
* 7.0 AIP PROGRAM STRUCTURE
*
* AS MENTIONED BEFORE AIP IS A COLLECTION OF RELOCATABLE PROCEDURES
* RESIDING IN THE APPLICATIONS FIELD LENGTH. THE NAM CALLS
* (I.E. NETON, NETGET, NETPUT) DESCRIBED IN THE NAM REFERENCE
* MANUAL ARE REALLY AIP PROCEDURE CALLS. THE FUNCTIONS OF AIP
* ARE AS FOLLOWS
*
* . BUFFER APPLICATION REQUEST IN THE NWL (NETWORK WORKLIST),
* WITHIN THE APPLICATIONS FIELD LENGTH FOR SUBSEQUENT TRANSFER
* TO NIP.
*
* . BUFFER INCOMING SUPERVISORY MESSAGES IN SMB (SUPERVISORY MSG
* BUFFER) FROM NIP FOR SUBSEQUENT DELIVERY TO THE APPLICATION
*
* . UPDATE THE VARIOUS STATUS FLAGS IN THE NSUP WORD FOR THE
* APPLICATION
*
* . DELIVER ANY NON-SUPERVISORY MESSAGE HEADERS FROM THE NWL
* TO THE APPLICATIONS HA. THESE GET PUT IN THE NWL BY NIP"S
* REPLY TO GET TYPE REQUEST IN THE NWL. (NIP WRITES ITS AWL
* BACK TO AIP"S NWL AREA)
*
* . ASSURE ORDERLY NAM CALLS (I.E. NO NETPUT BEFORE NETON ETC.)
*
* THE AIP PROCEDURES DIRECTLY CALLABLE BY THE APPLICATION ARE
*
* . NETFUNC - MODIFY AIP PROCESSING
*
* . NETON - CONNECT AN APPLICATION TO THE NETWORK
*
* . NETOFF - TERMINATE CONNECTION TO THE NETWORK
*
* . NETGET - READ A MESSAGE FROM THE SPECIFIED CONNECTION
*
* . NETGETL - READ A MESSAGE FROM ANY CONNECTION ON THE
* SPECIFIED LIST
*
* . NETGETQ - READ A MESSAGE FROM AIP-S UPLINE DATA QUEUE
* FOR A SPECIFIED CONNECTION
*
* . NETPUT - SEND A MESSAGE ON THE SPECIFIED CONNECTION
*
* . NETWAIT - WAIT UNTIL INPUT IS AVAILABLE OR FOR A SPECIFIED
* TIME
*
* . NETSETP - TURN PARALLEL PROCESSING ON OR OFF
*
* . NETCHEK - CHECK PREVIOUS REQUEST FOR COMPLETION AND UPDATE
* THE S AND I BITS IN THE NSUP WORD TO REFLECT CURRENT STATUS OF
* DATA AVAILABILITY.
*
* . NETGETF - READ A MESSAGE FROM THE SPECIFIED CONNECTION
* INTO FRAGMENTED DATA POTS
*
*
* . NETGTFL - READ A MESSAGE FROM ANY CONNECTION ON THE SPECIFIED
* LIST INTO FRAGMENTED DATA POTS
*
* . NETGTLQ - READ A MESSAGE FROM AIP-S UPLINE DATA QUEUE FOR A
* SPECIFIED LIST NUMBER
*
* . NETPUTF - WRITE A MESSAGE ON A CONNECTION GATHERING THE
* MESSAGE TEXT FROM FRAGMENTED DATA POTS.
*
* . NETPUTS - SEND A MESSAGE ON A CONNECTION IF THE UPLINE DATA
* QUEUE FEATURE IS BEING USED.
*
* INTERNAL PROCEDURES AUGMENTING THE ABOVE USER CALLABLE PROCEDURES
* ARE AS FOLLOWS: (NOTE INTERNAL ENTRY POINTS MUST BEGIN WITH NP$)
*
* . NP$DBG - RECORD AIP DEBUG INFORMATION ON FILE ZZZZZDN
*
* . NP$ERR - DAYFILE APPLICATION ERROR MESSAGES
*
* . NP$GETQ - DELIVER A DATA MESSAGE FROM THE AIP UPLINE DATA
* QUEUE
*
* . NP$GSM - DELIVER A SUPERVISORY MESSAGE TO THE CALLER
*
* . NP$RESP - PROCESS WORKLIST RESPONSE FROM NIP
*
* . NP$SEND - SET UP A WORKLIST FOR TRANSFER TO NIP
*
* . NP$XFER - DO THE ACTUAL WORKLIST TRANSFER
*
* . NP$OSIF - IS A COMPASS ROUTINE TO HANDLE OPERATING SYSTEM
* INTERFACES
*
* . NP$RCL - COMPASS ROUTINE TO GO INTO RECALL ON BIT 0 OF A WORD
* SPECIFIED AS AN INPUT PARAMETER.
*
* . NP$UCV - UPDATE NWL CONTROL VARIABLES
*
* . NP$USI - UPDATE S AND I BITS IN THE NSUP WORD
*
* THE MAJOR TABLES USED BY AIP ARE THE NWL (NP$NWL) AND THE
* SMB (NP$SMB) AS MENTIONED BEFORE.
* BOTH OF THESE WILL BE DISCUSSED IN GREATER DETAIL IN THE TABLES
* SECTION. HERE IS ONLY A DESCRIPTION OF HOW THEY ARE USED.
*
* . NP$NWL IS THE NETWORK WORK LIST AIP BUFFERS USER REQUESTS
* IN. ONLY BACK-TO-BACK PUT TYPE REQUEST ARE BUFFERED. AIP
* ASSURES THAT AFTER PROCESSING THE CURRENT REQUEST THERE
* ARE AT LEAST 4 OR 6 WORDS LEFT IN THE BUFFER. IF THERE ARE
* LESS THAN FOUR WORDS OR IF THE REQUEST IS A NETON, NETOFF,
* FORCED NETWAIT, A GET TYPE REQUEST OR A NETPUT OF BT=4, THEN
* THE NWL IS TRANSFERRED TO NIP"S WORKLIST RECEIVING BUFFER.
* EMPTYING THE NWL ON A NETPUT OF BT=4 ALLOWS THE SUPERVISORS TO
* ACCURATELY SET A TIMER SO THAT IF THE NPU DOES NOT RESPOND
* TO A SERVICE MESSAGE AFTER THE TIMEOUT PERIOD, THE SUPERVISORS
* CAN RESEND THE SERVICE MESSAGE.
* AIP ASSURES THAT THERE
* ARE 4 OR 6 WORDS LEFT IN THE NWL SO THAT WE CAN BE SURE
* THAT WE CAN FIT THE NEXT REQUEST INTO THE WORKLIST. TWO
* WORDS ARE NEEDED FOR THE NEXT REQUEST, TWO WORDS MAY BE NEEDED
* TO REQUEST DATA FROM NIP IF THE UPLINE DATA FEATURE IS BEING
* USED, AND TWO WORDS ARE
* NEEDED TO REQUEST SUPERVISORY MESSAGES FROM NIP. IN GENERAL
* THERE IS A TWO WORD HEADER IN THE WORK LIST. THE MESSAGE
* TEXT IS ALSO COPIED TO THE WORK LIST, IF IT FITS. IF NOT
* THE WORK LIST IS TRANSFERRED TO NIP. NIP WILL PROCESS
* THE WORK LIST AND FORMAT A REPLY TO ALL BUT THE PUT TYPE
* REQUESTS. THE REPLY IS WRITTEN BACK TO NP$NWL.
*
* THE DOWNLINE BUFFER FEATURE ALLOWS AN APPLICATION TO SPECIFY
* A LARGER BUFFER THAN THAT SUPPLIED BY AIP. IN THIS CASE,
* THE APPLICATION BUFFER WILL FUNCTION EXACTLY AS THE NP$NWL
* WORKLIST. WHEN IT COMES TIME TO TRANSFER THE WORKLIST TO
* NIP, A 2-WORD PUTQ ENTRY WILL BE CREATED IN THE AIP WORKLIST
* CONTAINING THE ADDRESS OF THE APPL-SUPPLIED BUFFER. THIS
* WILL IMPROVE PERFORMANCE.
*
* . NP$SMB IS THE SUPERVISORY MESSAGE BUFFER. THE SUPERVISORY
* MESSAGE BUFFER WAS DESIGNED TO MINIMIZE CPU OVERHEAD
* IN TRANSFERRING NUMEROUS SHORT MESSAGES (SUCH AS FC/BACK-S)
* BETWEEN NIP AND THE APPLICATION. FROM AIP-S POINT OF VIEW
* THE SMB IS A CIRCULAR BUFFER. LOCATION FIRST POINTS TO
* THE FIRST WORD OF THE BUFFER. HEAD POINTS TO THE FIRST
* WORD OF THE NEXT SUPERVISORY MESSAGE TO BE DELIVERED BY
* AIP, FOOT POINTS TO THE NEXT AVAILABLE WORD IN THE SMB
* INTO WHICH NIP COULD WRITE SUPERVISORY MESSAGES, AND LAST
* POINTS TO THE LAST WORD OF THE SUPERVISORY MESSAGE BUFFER.
* AS MENTIONED IN THE DISCUSSION ON NP$NWL AIP PASSES A
* REQUEST FOR SUPERVISORY MESSAGES TO NIP. THE REQUEST TO
* NIP SPECIFIES A CONTIGUOUS BUFFER IN AIP POINTING TO
* FOOT AS THE FWA AND SPECIFYING LAST-FOOT AS THE LENGTH, OR
* IF A WRAP AROUND HAS OCCURRED THAN PASSING HEAD-FOOT AS
* THE LENGTH. THIS WAY NIP IS NOT BURDENED WITH TRYING TO
* HANDLE CIRCULAR BUFFERS, AND NEITHER NIP NOR AIP HAS TO
* SPECIAL CASE A SINGLE MESSAGE WRAPPING AROUND IN THE BUFFER.
* IT DOES, HOWEVER LEAVE AIP WITH THE PROBLEM OF RECOGNIZING
* WHEN THE LAST MESSAGE IN THE BUFFER DOES NOT COMPLETELY
* FILL THE BUFFER. THIS PROBLEM IS SOLVED BY NIP ALWAYS WRITING
* A WORD OF ZEROES BEHIND THE LAST SUPERVISORY MESSAGE IT
* GIVES TO AIP.
*
#
*ENDIF
*IF DEF,IMS
#
* THE APPLICATION REQUESTS AIP TO DELIVER A SUPERVISORY MESSAGE TO
* THE APPLICATION"S TEXT AREA BY MAKING A NETGET,NETGETL,NETGETF, OR
* NETGTFL CALL ON ACN = 0 OR ALN = 0. AIP WILL COPY THE SUPERVISORY
* MESSAGE FROM THE SMB (SUPERVISORY MESSAGE BUFFER). IF THE SMB IS
* EMPTY(HEAD = FOOT), THEN AIP SENDS NIP A GSM (GET SUPERVISORY
* MESSAGE) REQUEST. WHEN AIP READS THE MESSAGES IN THE SMB, IF HEAD
* IS EQUAL TO ZERO, THEN THE MESSAGES HAVE WRAPPED AROUND AND THE
* NEXT MESSAGE TO BE READ STARTS AT INDEX FIRST. IF THE SUPERVISORY
* MESSAGE TO BE DELIVERED TO THE APPLICATION IS LONGER THAN THE
* SPACE ALLOWED BY THE APPLICATION(TLMAX), THEN THE INPUT BLOCK
* UNDELIVERABLE BIT (40) IS SET IN THE HEADER WORD AT HA (HEADER
* ADDRESS SPECIFIED BY THE APPLICATION), AND THE MESSAGE IS NOT
* DELIVERED. A SUPERVISORY MESSAGE WILL NOT FIT INTO AIP"S SMB IF
* IT IS LONGER THAN 64 (100B) WORDS.
*
* AIP ALLOWS APPLICATION PROGRAMS WHICH RESIDE IN THE HOST COMPUTER
* TO ACCESS THE NETWORK TO SEND AND RECEIVE DATA FROM REMOTE NODES
* AND OTHER APPLICATIONS. THE APPLICATION PROGRAM LOADS THE AIP
* ROUTINES FROM THE LIBRARY NETIO OR NETIOD. NETIOD HAS THE OPTIONS
* DEBUG AND STAT DEFINED TO TURN ON DEBUG MODE AND STATISTICS
* GATHERING. BOTH THESE OPTIONS CAUSE RESPECTIVE FILES ZZZZZDN AND
* ZZZZZSN TO BE OPENED AND WRITTEN ON.
*
* FOR PROPER PRESETTING OF COMMON DECK NP$MODE, A ROUTINE CALLING
* NP$XFER MUST BE CALLED BY THE APPLICATION IN THE APPLICATION"S
* MAIN OVERLAY. NP$MODE CONTAINS THE FOLLOWING FLAGS:
*
* . ACCEPTED - TRUE IF THE APPLICATION HAS COMPLETED A NETON
*
* . DEFER$PRO - TRUE IF NIP HAS NOT FINISHED PROCESSING THE
* WORKLIST FROM AIP.
*
* . DEFER$GSM - TRUE IF THE APPLICATION HAS REQUESTED A
* SUPERVISORY MESSAGE WHEN AIP"S SMB IS EMPTY
*
* . NETONNWL - TRUE IF CURRENT WORKLIST IS A NETON.
*
* . PARALLEL - TRUE IF THE APPLICATION HAS REQUESTED PARALLEL MODE
*
* . SENDGETMM - TRUE IF AIP MAY PUT A GET DATA MESSAGES
* REQUEST IN THE OUTGOING WORKLIST(NWL)
*
* . SENDGETSM - TRUE IF AIP MAY PUT A GET SUPERVISORY MESSAGE
* REQUEST IN THE OUTGOING WORKLIST(NWL)
*
* AT LOAD TIME ALL THE ABOVE FLAGS ARE FALSE.
*
* AT NETON TIME THE ADDRESS OF THE NSUP WORD IS PASSED TO AIP. THE
* NSUP WORD CONTAINS THE FOLLOWING FLAGS:
*
* . C$FLAG - TRUE IF THE OPERATION IS COMPLETE
*
* . N$FLAG - TRUE IF NAM IS AVAILABLE
*
* . I$FLAG - TRUE IF DATA INPUT IS AVAILABLE
*
* . S$FLAG - TRUE IF THERE ARE OUTSTANDING SUPERVISORY MESSAGES
*
* . D$FLAG - TRUE IF NIP HAS DELIVERABLE DATA FOR THE APPLICATION
* IF IT ISSUES A NETGETL, NETGTFL, OR NETGTLQ CALL.
*
* THE I$FLAG AND S$FLAG ARE SET OR CLEARED AFTER A NETCHEK, NETWAIT,
* NETGET-S AND NETPUT-S TO REFLECT CURRENT AVAILABILITY OF DATA.
* C,N$FLAGS ARE SET IN NP$XFER AFTER AIP HAS MADE A SSC CALL AND
* THESE FLAGS ARE ONLY VALID IN PARALLEL MODE, AS AN SSCALL IS MADE
* WITHOUT RECALL. C$FLAG AND N$FLAG ARE ALSO SET IN NETCHEK.
*
* NETSETP(0) SETS AIP CALLS TO NIP TO BE IN PARALLEL MODE. THIS
* MEANS THAT AIP"S SSCALLS WILL BE MADE WITHOUT RECALL SO THAT THE
* APPLICATION WILL NOT LOSE CONTROL OVER THE CPU FOR TOO LONG.
* HOWEVER, IN PARALLEL MODE THE USER MUST CALL NETCHEK AFTER ALL
* REQUESTS TO NIP, IN ORDER TO CHECK THAT NIP HAS RESPONDED TO
* THE REQUEST. DEFER$PRO IS FALSE IF THE NWL HAS BEEN COMPLETELY
* PROCESSED BY NIP. NP$RESP DOES AIP"S FINAL PROCESSING OF THE
* REQUESTS ONCE NIP HAS RETURNED REQUESTED INFORMATION. NP$RESP IS
* CALLED FROM NP$SEND OR NETCHEK. NP$RESP UPDATES THE NP$NWL
* POINTERS.
*
* A NETOFF REQUEST IS ALLOWED AT ANY TIME. TO PERMIT THIS, NETOFF
* SENDS NIP A SEPARATE WORKLIST CONTAINING ONLY THE NETOFF REQUEST.
* AT NETOFF TIME, IF DEBUG/STAT IS DEFINED, THEN FILE ZZZZZDN
* AND ZZZZZSN ARE RESPECTIVELY CLOSED.
*
#
#
* NETWORK PRODUCTS DOCUMENTATION PAGE
* NAM INTERNAL SPECIFICATION DATE.
* 8.0 AIP TABLE STRUCTURE
#
*ENDIF
BEGIN
*CALL NP$CRT
# #
# EXTERNAL ROUTINES: #
# #
XREF BEGIN
PROC NP$RESP; #PROCESSES NIP RESPONSE #
PROC NP$SEND; #SENDS A WORKLIST TO NIP #
*IF DEF,STAT
PROC NP$SN; #INCREMENTS STATISTICS COUNTER#
*ENDIF
PROC NP$USI; #UPDATE S AND I BITS IN NSUP #
END #XREFS#
# #
*IF DEF,IMS
#
* NETWORK PRODUCTS DOCUMENTATION PAGE
* NAM INTERNAL SPECIFICATION DATE.
* 9.0 AIP DETAILED DESCRIPTION
*1DC NETCHEK
*
* 1. PROC NAME AUTHOR DATE
* NETCHEK S.KRULEVITCH 77/3/4
*
* 2. FUNCTIONAL DESCRIPTION
* CHECKS THAT NIP HAS RETURNED A WORKLIST RESPONSE.
*
* 3. METHOD USED
* THIS ROUTINE IS RELEVANT ONLY WHEN PARALLEL OPERATION HAS BEEN
* SELECTED. IF PROCESSING OF THE WORKLIST RESPONSE HAS NOT BEEN
* POSTPONED(DEFER$PRO = FALSE)THEN NETCHEK SIMPLY RETURNS C$FLAG
* = TRUE,INDICATING AIP AND NIP ARE FINISHED WITH ALL REQUESTS.
* IF, HOWEVER DEFER$PRO = TRUE, THEN IF AIP HAS NOT RECEIVED THE
* WORKLIST RESPONSE FROM NIP,AIP SETS C$FLAG = FALSE. IF AIP HAS
* RECEIVED THE RESPONSE, THEN POSTPONED PROCESSING IS PERFORMED
* AND AIP SETS C$FLAG = TRUE. C$FLAG IS THE FIRST BIT OF THE
* NSUP WORD IN THE APPLICATION"S FIELD LENGTH.
* IF THE RESPONSE FROM NIP INDICATES THAT NIP DID NOT RECEIVE
* THE WORKLIST BECAUSE NIP WAS BUSY, NETCHEK WILL CALL NP$SEND
* TO RETRANSMIT THE SAME WORKLIST TO NIP.
* UPDATE S AND I BITS IN THE NSUP WORD.
*
* 4. ENTRY CONDITIONS
* CTL$CB - COMPLETION BIT FOR NIP PROCESSING.
* DEFER$PRO - TRUE MEANS SOME PROCESSING OF THE WORKLIST RESPONSE
* HAS BEEN DEFERRED.
* ACCEPTED - TRUE IF WORKLIST TRANSFER IS NOT A NETON
*
* 5. EXIT CONDITIONS
* C$FLAG = TRUE INDICATES OPERATION COMPLETE.
* C$FLAG = FALSE INDICATES OPERATION INCOMPLETE.
* I$FLAG - TRUE IF INPUT DATA QUEUED IN NIP
* S$FLAG - TRUE IF SMB NON-EMPTY OR SM QUEUED IN NIP
* DEFER$PRO =FALSE IF THE WORKLIST RESPONSE HAS BEEN RECEIVED
* FROM NIP.
* N$FLAG = TRUE,IF NAM IS AVAILABLE.
* = FALSE, IF NAM IS NOT AVAILABLE AT A SYSTEM CONTROL PT.
*
* 6. COMDECKS CALLED AND SYMPL TEXTS USED.
* AIPDEF CRCOM NP$MODE NP$NWL
* NP$STAT
*
* 7. ROUTINES CALLED
* NP$RESP
* NP$SEND - SENDS A WORKLIST TO NIP
* NP$SN - INCREMENTS STATISTICS COUNTER
* NP$USI - UPDATE S AND I BITS IN THE NSUP WORD
*
* 8. DAYFILE MESSAGES
*
#
*ENDIF
#**********************************************************************#
# NETCHEK EXECUTION BEGINS HERE: #
# #
*IF DEF,STAT
# #
# UPDATE STATISTICS IF STATISTICS GATHERING IS TURNED ON. #
# #
NP$SN(TYPE"CHEK"); #INCREMENT COUNTER #
*ENDIF
IF DEFER$PRO
THEN
BEGIN
IF CTL$CB[NCTL]
THEN
BEGIN
IF CTL$NONAM[NCTL]
THEN
BEGIN
N$FLAG = FALSE; #NAM NOT AVAILABLE #
C$FLAG = TRUE; #AIP COMPLETED PROCESSING #
RETURN;
END
N$FLAG = TRUE; # NAM AVAILABLE #
IF CTL$BUSY[NCTL]
THEN
BEGIN
SENDGETMM = FALSE; # DO NOT ADD ANOTHER GETMM WKLS#
SENDGETSM = FALSE; # DO NOT ADD ANOTHER GETSM WKLS#
RESEND = TRUE; # RESEND WORKLIST TO NIP #
NP$SEND; # SEND THE SAME WORKLIST TO NIP#
SENDGETMM = TRUE; # RESTORE SEND GETMM WKLST FLAG#
SENDGETSM = TRUE; # RESTORE SEND GETSM WKLST FLAG#
RESEND = FALSE; # RESTORE RESEND FLAG #
END
ELSE
BEGIN
NP$RESP;
DEFER$PRO = FALSE;
C$FLAG = TRUE;
END
END #CTL$CB EQ TRUE#
ELSE
BEGIN # CTL$CB IS NOT SET #
IF NOT ACCEPTED
THEN
BEGIN # PREVIOUS WORKLIST IS A NETON #
IF NWL$CB[NHDR+1]
THEN
BEGIN # NETON COMPLETED #
NP$RESP; # PROCESS AWL RESPONSE IF ONE #
DEFER$PRO = FALSE;
C$FLAG = TRUE;
END
END
END
END #DEFER$PRO EQ TRUE#
ELSE
BEGIN
NP$SEND ;
IF NOT DEFER$PRO
THEN # WORKLIST ISSUED AND #
BEGIN # COMPLETED #
C$FLAG = TRUE ; # SET COMPLETE FLAG #
END
END
NP$USI; # UPDATE S AND I BITS IN NSUP #
RETURN;
END #NETCHEK#
TERM