Hi, Peter. My apologies. I should have read your requirements more carefully, and actually checked what the SMSG(WAKEUP) was all about.
Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: "Farley, Peter x23353" <peter.far...@broadridge.com> To: IBM-MAIN@bama.ua.edu Date: 12/06/2011 12:22 PM Subject: Re: z/OS's basis for TCP/IP Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Well, I certainly thought of TSO SEND, but it is the "WAKEUP" part of the process (i.e., the receiving end) that I don't see a way to accomplish. How could a program running in a TSO user's address space wait for and then receive a message sent via TSO SEND? And as an extension of such a capability, how would a batch TSO process (i.e., an IKJEFTxx batch step) receive and process such a message? Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Steve Conway > Sent: Tuesday, December 06, 2011 11:28 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: z/OS's basis for TCP/IP > > Peter, > > Sounds like you want TSO SEND. Do TSO HELP SEND for syntax and usage. > > > Cheers,,,Steve <Snipped> > From: "Farley, Peter x23353" <peter.far...@broadridge.com> > To: IBM-MAIN@bama.ua.edu > Date: 12/06/2011 11:25 AM > Subject: Re: z/OS's basis for TCP/IP > Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > Chris, > > Well, I can't say I'm surprised by your answer, but thanks for your > insights anyway. > > I haven't searched around the web yet (especially the CBT site) for some > equivalent facility, but perhaps it's time I did so. Now, where did I put > those darned round tuits... :) > > Peter > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > > Behalf Of Chris Mason > > Sent: Tuesday, December 06, 2011 10:42 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: z/OS's basis for TCP/IP > > > > Peter > > > > I'm very sorry to be disappointing you! > > > > > Is there any chance that there is a z/OS equivalent of these z/VM > > commands for the general (non-authorized) user? > > > > We're on the "down slope", not the "up slope"! In other words, the > > direction in the IP component of z/OS Communications Server is to get > rid > > of these entrails of the VM heritage. The most recent to go - although > not > > strictly replaced one-for-one - is the old Pascal SMTP server to be > > "replaced" by the CSSMTP server. > > > > The other major server written in Pascal surviving from the old "TCP/IP > > for VM" days - see my first response in this thread - is the LPD server. > I > > believe there is a product which replaces this with a number of > additional > > capabilities - someone can no doubt jump in with what that is - so, in > > effect, the LPD server has already been replaced. > > > > Although not pretending to be comprehensive, this list from the > > configuration step I mentioned shows that what remains dependent on > > VMCF/TNF are a few scraps at the bottom of the barrel that nobody cares > > much about: > > > > <quote> > > > > 1.2.21.5 Step 3: Configure VMCF and TNF > > > > The Pascal socket interface uses the IUCV/VMCF services for a limited > set > > of inter-address space communication flows. As a result, if you are > using > > any applications (provided by IBM or others) that use the Pascal socket > > API, you must ensure that the Virtual Machine Communication Facility > > (VMCF) and Termination Notification Facility (TNF) subsystems are active > > before the applications are started. TCP/IP provides the following > > applications and commands that use the Pascal socket interface: > > > > - SMTP and LPD servers > > > > - TSO HOMETEST, LPQ, LPR, LPRM, LPRSET, TELNET, and TESTSITE commands > > > > If you are using any of these applications or commands, you need to set > up > > VMCF and TNF. > > > > </quote> > > > > That word "limited" is a bit of a hint that the author - in tune with > most > > of his or her readers - rather wishes there were none! > > > > Unfortunately, rather too strict an application of the rule "If it ain't > > broke, don't fix it!" much beloved by the "suits" in charge of manual > > authors, has meant that, the text - which has by now gathered much dust > - > > surrounding the suggestion that the installation should be "verified" by > > use of the HOMETEST and TESTSITE utility commands has not been > deprecated > > in some way. Thus novices still get the impression that the use of these > > commands is technically de rigeur as part of checking definitions when > > they should just have overlooked them. In any case, in an era when only > > VIPAs need names, they are well out of date! > > > > That said, it was only when one presumed novice in a recent thread > > complained that his checking with HOMETEST was failing that I discovered > - > > very late! - that the generically named TCPIP.DATA data set HOSTNAME > > statement applied to the data set for the main address spaces when the > > sockets API gethostname call was used while it applied to the data set > for > > the program address space when the Pascal API GetIdentity call was used > in > > order to extract the "host name" value. > > > > My excuse for not appreciating this point for all the years I have been > > working with "TCP/IP for MVS" and is successor is that I have always > used > > a common dynamically allocated data set. As a teacher of "hands-on" > > classes, I always used to have to rely on students probing unusual > > definition techniques - typically by accident - revealing the previously > > unknown! > > > > Chris Mason > > > > On Tue, 6 Dec 2011 09:58:58 -0500, Farley, Peter x23353 > > <peter.far...@broadridge.com> wrote: > > > > >Chris, > > > > > >Thanks for those interesting links. I had not realized that the z/OS > > Comm. Server implemented some form of VMCF and IUCV. > > > > > >The small amount of RTFM I just did based on your links seems to > indicate > > that the Comm. Server SMSG command is only supported to communicate with > > SMTP and LPD. Is there any chance that there is a z/OS equivalent of > > these z/VM commands for the general (non-authorized) user? > > > > > >From userid1: > > > > > >SMSG userid2 'message text' > > > > > >And in userid2, waiting for a message from SMSG from any other user: > > > > > >WAKEUP (SMSG > > > > > >Or any equivalent inter-user communications commands of course. I'm > not > > expecting on an *exact* equivalent of the z/VM facilities, just an equal > > capability for short message sending and reception invokable as commands > > by regular non-authorized TSO users. > > > > > >TIA for any enlightenment you can provide. > > > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
