*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