Re: CMS VSCREEN
This falls in the catgeory of "for a REXX programmer it is very hard to wait fro console input as well as something else". I have no solution, only some bypasses for specific cases, never perfect for the end-user. 2008/3/19, Rothman, Peter <[EMAIL PROTECTED]>: > 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. > > > -- Kris Buelens, IBM Belgium, VM customer support
Re: CMS VSCREEN
> I suppose another way of describing this is that in XMENU from CA there > is a SMSG option. > You put up the screen/menu with the SMSG option - if someone(server) > sends you an SMSG you wakeup and can take action. > > I am looking for a way to do this with VSCREEN. If you can tolerate the client idle waiting for a response, then have the client code open one TCP socket to the server for use in transferring data and a second UDP socket as a signaling mechanism. Do a read from the UDP socket when you want to wait for a response. The read will block if there is no data available, and will wait until something arrives, and then return. You can send your data on the first TCP socket, and just use the second socket as a "data set ready" indicator (to borrow a term from serial I/O), omitting the message and wakeup components entirely. When you want to wake up the client, send a single UDP (or use TCP if you want to be paranoid) packet from the server, and the client will wake up from the blocking read and go on. You can then process and/or discard the "DSR" packet as you wish, and read the real data from the other socket. Of course in a pure REXX program, that implies the client comes to a complete halt on the blocking read. If it's a pipes app, then (I think) you block only on the thread that is doing the blocking read.
Re: CMS VSCREEN
I suppose another way of describing this is that in XMENU from CA there is a SMSG option. You put up the screen/menu with the SMSG option - if someone(server) sends you an SMSG you wakeup and can take action. I am looking for a way to do this with VSCREEN. -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.
Re: CMS VSCREEN
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.
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
