🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: bit.listserv.appc-l
Article #418

What Received

#418
From: FOLLIS
Date: Thu, 04 Feb 1993 14:49
49 lines
2874 bytes
Subject: What Received

From: D. Follis  Y43A/920/2J32 8+296-6761    (914)-296-6761
      IBMMAIL: USIB1KG6  Internet: follis@pokvmcr3.vnet.ibm.com


>>I took this to mean that a single EXEC CICS RECEIVE would retrieve
>>*BOTH* data and status, by issuing multiple MC_RECEIVE_AND_WAITs
>>if necessary, "behind the scenes".

I think the key word in that sentence is 'would'.  It should be changed to
'may'.  All the confusion is caused because different platforms have
implemented the architected 'WHAT_RECEIVED' returned parameter differently.

The architecture says that 'WHAT_RECEIVED' contains a single value which
can be things like SEND_RECEIVED, COMPLETE_DATA_RECEIVED, etc.

VTAM's APPCCMD interface and apparently CICS (which I know essentially
nothing about) have implemented WHAT_RECEIVED as a collection of bits
where more than one at a time can be turned on.  Thus you can receive
Data and Status at once.

The SAA CPI-C interface further confuses the issue by defining two
separate parameters:  Data_Received and Status_Received.  Thus you
can receive Data_Received = Complete_Data_Received and Status_Received =
Send_Received.  APPC/MVS also implemented an MVS specific interface
that follows the CPI-C 'standard' in addition to supporting CPI-C.

Having said all that, so what?  The key here is really that the only
thing you can count on is that things will show up in the order you
sent them, but you can't depend on when they will show up.  Thus if
you issue a Send followed by a Prepare to Receive (I think the CICS
terminology is 'INVITE') you can count on the partner getting both
the data and the Send_Received eventually.  You can count on the
data being available first.  The Send_Received may or may not show
up with the data.  In general, issue Receives until you get everything
you expected or you get an error.

The timing is very dependent on the RU sizes, and I suppose one could
create an APPC application that had timing dependencies such that it
only works for a particular RU size.  I'm not sure that would be
very advisable though.

Anyway..them's my two cents.

David Follis
APPC/MVS Component Test etc.
Any sufficiently advanced technology is indistinguishable from
magic.  (or a rigged demo).
Technical Details
Message-ID: <APPC-L%93020410084679@AUVM.AMERICAN.EDU>
Path: arc1-ca.pugleaf.net!sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!POKVMCR3.VNET.IBM.COM!FOLLIS

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10aed9,5c763ffda000a805,start
X-Google-Attributes: gid10aed9,public
X-Google-ArrivalTime: 1993-02-21 06:20:18 PST
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Path: arc1-ca.pugleaf.net!sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!POKVMCR3.VNET.IBM.COM!FOLLIS
Message-ID: <APPC-L%93020410084679@AUVM.AMERICAN.EDU>
Newsgroups: bit.listserv.appc-l
Date:         Thu, 4 Feb 1993 09:49:04 EST
Sender:       APPC Discussion List <APPC-L@AUVM.BITNET>
From:         FOLLIS@POKVMCR3.VNET.IBM.COM
Subject:      What Received
Lines: 49