home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / sybase / 644 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  3.5 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!mtxinu!sybase!cosmo!davidvc
  2. From: davidvc@cosmo.sybase.com (David Van Couvering)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: Open Server problem
  5. Message-ID: <27758@sybase.sybase.com>
  6. Date: 8 Jan 93 17:54:11 GMT
  7. References: <1993Jan6.101709@is.morgan.com>
  8. Sender: news@Sybase.COM
  9. Lines: 70
  10.  
  11. In article <1993Jan6.101709@is.morgan.com>, shafla@is.morgan.com (Sharon Flanagan) writes:
  12. |> 
  13.  
  14. |> 
  15. |> I'm working with a Sybase open server based on the "utility" sample program.
  16. |> I've written an RPC which allowes various clients to send and recieve
  17. |> information.  When a client registers for information, it sends the name of
  18. |> the RPC, a paramater that indicates it is a register message, its transaction
  19. |> type, and some parameters to hold the information it wants.  
  20.  
  21. Sound good so far
  22.  
  23. |> The function
  24. |> allocates space for a new srvproc, uses srv_bmove() to copy the srvproc and
  25. |> this new srvproc is then added to a linked list which is indexed by
  26. |> transaction type.  When a client notifies the open server that it has
  27. |> information, it sends the name of the RPC, a parameter that indicates that
  28. |> it is a notify message, its transaction type, and parameters which hold its
  29. |> information. The code goes through the linked list - if it finds a matching
  30. |> transaction type, it puts information from the current srvproc to a copy of the srvproc from the linked list.
  31.  
  32. It seems a little dangerous going about copying srvprocs and then trying
  33. to use them in Open Server calls.  If you are going to set up a linked
  34. list of srvprocs, why not just use the pointers rather than copying the
  35. entire structure?  
  36.  
  37. |> 
  38. |> PROBLEM:
  39. |> The forementioned program works with the first notify.  I use the
  40. |> srv_senddone() with the SRV_DONE_FINAL flag set when I return the information
  41. |> to the registering client.  However, when another client notifies that it
  42. |> has information, my program gets a SEGV error when it tries to find the number
  43. |> of parameters in the linked list srvproc.  The srv_senddone() function
  44. |> seems to clear out the parameters from the srvproc in the linked list -
  45. |> I've used a srv_rpcparams() call after the srv_senddone() and its result is
  46. |> -1 (perhaps no current RPC).  I've used srv_bmove to copy the srvproc from
  47. |> the linked list into another area of memory - but it didn't help.
  48. |> 
  49. |> How can I send information back to the clients multiple times over the open
  50. |> server - client connection?  Is there a way to circumvent the "flush" which
  51. |> happens with a srv_senddone?  If I use the SRV_DONE_MORE flag, the client
  52. |> doesn't get data.
  53. |> I've tested the open server using functions which login to it and then
  54. |> send information via the dbproc (dprpcparam(), dbrpcsend()).
  55. |> 
  56.  
  57. It's hard to get clear what's going on here, as is usually the case
  58. when you're trying to describe an application in 100 words or less...
  59.  
  60. You might want to look into using notifications to notify clients, 
  61. rather than sending rows to notify them.  Clients can register interest
  62. in particular Open Server RPCs, and then they will get notified whenever 
  63. that RPC is invoked in the Open Server.  Take a look at the 4.6/2.0
  64. docs for more information...
  65.  
  66. |> Any ideas?????
  67. |> 
  68. |>  
  69. |> Thanks in advance for any assistance.
  70. |> 
  71. |> Sharon Flanagan
  72. |> shafla@is.morgan.com
  73.  
  74. Hope this helps,
  75.  
  76. David
  77. -- 
  78. davidvc@sybase.com | {pacbell,lll-tis,pyramid,sun}!sybase!davidvc
  79. David Van Couvering Sybase 1650 65th Street Emeryville, CA  94608
  80. - Opinions expressed here are mine and not necessarily those of Sybase -
  81.