The exec I am trying to modify is the client in a client/server situation. Both client and server userids nucxload assembler code that uses VMCF for communication.
1. The client exec uses VSCREEN to 'put up a screen' 2. The user/client enters a command which is then sent via VMCF to the server. 3. When the response comes back the client's VSCREEN WAITREAD 'wakes up' because of the VMCF interrupt. The client's nucxloaded code then stacks the reponse. At this point the WAITREAD.1 is set to UNKNOWN. 4. Client code then displays the response on the VSCREEN. I have re-written the server in RXSockets and want to massage the client code to use RXSockets as well. My problem is that when the server 'sends' the response I have no way of telling the client to 'wakeup' and receive the data. Peter. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Wednesday, March 19, 2008 11:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMS VSCREEN "From another user?" CP SEND CP ATTN maybe, but I don't see the use of it, maybe we need to get more light. Note too that a VSCREEN user cannot run in a disconnected machine... 2008/3/19, Rothman, Peter <[EMAIL PROTECTED]>: > > > > I am trying to modify an exec that uses VSCREEN WAITREAD. > Is there a way to 'force' an interrupt from another userid - something other > than a CP warning. > > The help for VSCREEN WAITREAD says: > > WAITREAD.1 is set to UNKNOWN when the System > Request key is used to generate the attention > interrupt and no other system. For example, > VM/VTAM session managers, and so forth traps the > System Request key interrupt. > > Anyone have an idea on how I can 'simulate' this from another userid? > -- Kris Buelens, IBM Belgium, VM customer support If you are not the intended recipient of this e-mail message, please notify the sender and delete all copies immediately. The sender believes this message and any attachments were sent free of any virus, worm, Trojan horse, and other forms of malicious code. This message and its attachments could have been infected during transmission. The recipient opens any attachments at the recipient's own risk, and in so doing, the recipient accepts full responsibility for such actions and agrees to take protective and remedial action relating to any malicious code. Travelport is not liable for any loss or damage arising from this message or its attachments.
