API tools faq
paste
Advertisement
Guest User

Untitled

a guest
Apr 19th, 2017
1,032
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 9.18 KB | None | 0 0
raw download clone embed print report
  1. From: IJSAPL::KUPPENS "Do I have a complete working knowledge of virtually everything ?....." 8-SEP-1996 12:50:06.09
  2. To: STAR::EVERHART
  3. CC: KUPPENS
  4. Subj: U: SCSI Philips Medical SEPT 3 1996 minutes and actions
  5.  
  6. Glenn,
  7.  
  8. Question from Philips:
  9.  
  10.  
  11. "Is it possible to make a user-callable call which does a SCSI-RESET ?",
  12.  
  13.  
  14. as they have major problems in the hospitals when they sometimes need
  15. a SCSI-RESET and now can only do a SCSI-RESET by a total system reboot,
  16. which takes *too* long....
  17.  
  18. Please advise?,
  19.  
  20. ThanXs!,
  21. Robbert.
  22.  
  23.  
  24.  
  25. To all,
  26.  
  27.  
  28.  
  29. Minutes and actionlist of the conference call of Tuesday September 3 at
  30. Nashua: 9.00 am
  31. Moscow: 5.00 pm
  32. Netherlands: 3.00 pm
  33.  
  34.  
  35.  
  36. AGENDA:
  37. =======
  38.  
  39.  
  40. - Introduced involved people and responsiblities
  41.  
  42. Johan van Oosterhout (Philips) software specialist
  43. Lex van Gijssel (Philips) project leader
  44. Wim Mosterman (Philips) software specialist
  45.  
  46. Glenn Everhart (Digital Nashua) SCSI architect OpenVMS
  47.  
  48. Sergei Osipov (Digital Moscow) project manager
  49. Igor Abramov (Digital Moscow) software specialist
  50. Vadim Model (Digital Moscow) software specialist
  51. Gleb Rajko (Digital Moscow) software specialist
  52. Jur van den Burg (Digital Utrecht) MCS software specialist
  53. Arie de Groot (Digital Utrecht) account manager (not present
  54. at conf. call.)
  55.  
  56.  
  58.  
  59. SCSI DRIVER(s):
  60. ---------------
  61.  
  62.  
  63. SCSI driver to support host/target functionality:
  64. - Understanding requirements Philips Medical SCSI driver
  65. Digital MSC (Moscow Software Center) people understand the current
  66. requirement but requested missing hardware spec + required
  67. hardware components.
  68.  
  69. - Understanding re-using existing SCSI driver (Glenn)
  70. Glenn Everhart is available for questions regarding the re-use of
  71. existing SCSI drivers, Glenn will mail the sources to Moscow.
  72.  
  73. - Understanding timeline/milestones of delivery
  74. It is understood by all parties that latest delivery of operational
  75. drivers must be no later than November 29, 1996.
  76. Digital MSC has made a preliminary qualification and has proposed
  77. to deliver the OpenVMS driver in 2 months. Windows NT drivers
  78. development is under investigation but depends on availability of
  79. Windows NT SCSI sources. Costs for development have been qualified
  80. and has been communicated to Philips Medical. Final agreement how
  81. costs will be X-charged is to be finalized latest september 27, 1996.
  82. Michel van der Togt (manager OEM group Digital) has agreed with
  83. Robert Boers (manager Digital MSC) that development of the drivers
  84. can start directly (as costs will be pre-paid by Digital Netherlands).
  85.  
  86. - Understanding communication/support channels
  87. Communication will take place through Email and telephone, below
  88. you will find all information:
  89.  
  90.  
  91.  
  92. DIGITAL:
  93. ========
  94.  
  95. Digital MSC office post address is:
  96. Digital Equipment Corporation
  97. 129223 Russia Moscow
  98. Prospect Mira AO VVC
  99. Business Center JV "Technopark"
  100. Building 6
  101. Attn. Sergei Osipov
  102.  
  103. The preferred e-mail/tel/fax coordinates of Digital MSC persons
  104. are the following:
  105.  
  106. Igor (CECMOW::) Abramov abramov@cecmow.enet.dec.com
  107. Gleb (CECMOW::) Rajko rajko@cecmow.enet.dec.com
  108. Vadim (CECMOW::) Model model@cecmow.enet.dec.com
  109. Sergei (MSCDEV::) Osipov osipov@cecmow.enet.dec.com
  110. tel. +7 502 223 2601/2602
  111. +7 095 974 7610/7612
  112. fax +7 502 223 2600
  113. +7 095 188 4557
  114. DTN 892 2601
  115.  
  116.  
  117. Glenn C. (STAR::) Everhart everhart@star.enet.dec.com
  118. tel. +1 603 881 1497
  119.  
  120.  
  121. Jur van den Burg vdburg@utrtsc.enet.dec.com
  122. tel. +31 30 2833973
  123.  
  124. Arie de Groot groot_ar@utrop1.enet.dec.com
  125. tel. +31 30 2833166
  126. fax. +31 30 2832161
  127.  
  128.  
  129.  
  130.  
  131.  
  132. PHILIPS MEDICAL SYSTEMS MR DIVISION:
  133. ====================================
  134.  
  135.  
  136. Postaddress:
  137.  
  138. Philips Medical Systems MR
  139. Attent. of Lex van Gijsel
  140. Veenpluis 2-10
  141. Best
  142. The Netherlands
  143.  
  144. telephone fax
  145. Johan van Oosterhout +31-40-2762203 +31-40-2765644
  146. ohout@best.ms.philips.com
  147. Wim Mosterman +31-40-2763407 +31-40-2765644
  148. mosterman@best.ms.philips.com
  149. Lex van Gijsel +31-40-2763583 +31-40-2765644
  150. avgijsel@best.ms.philips.com
  151.  
  152.  
  153.  
  154. - Understanding how to deliver driver to comply with requirements
  155. and how to be included in OpenVMS codestream V7.?
  156. Glenn Everhart will email SCSI sourcecode and together with
  157. Jur van der Burg (debugging/testing support max. 1 day/week)
  158. will ensure that driver(s) to be delivered will be qualified
  159. for inclusion in OpenVMS codestream.
  160.  
  161. - Understanding testing and qualification delivery procedure
  162. Philips Medical MR will send all hardware and available
  163. tools and documentation and will document latest September 27,
  164. 1996 how drivers will be tested and how acceptance-tests will
  165. be undertaken.
  166. Philips Medical must at least send the following to Digital
  167. MSC latest September 9, 1996:
  168. - 2x PCI-ARI board
  169. - source code initial test program ARI
  170. - Hardware specification(s)
  171. - 2x KZPSA PCI-SCSI board
  172.  
  173. - Plan follow-on meeting(s), Email/telephone
  174. See also above for Email and telephone interfaces.
  175. Direct communication will take place between Digital MSC and
  176. Philips Medical, as soon as Digital MSC has preliminary working
  177. drivers Jur van der Burg must be notified to be able to test
  178. and debug the driver(s) together with Philips Medical (Johan
  179. van Oosterhout).
  180.  
  181.  
  183.  
  184. ARI DRIVER(s):
  185. --------------
  186.  
  187.  
  188.  
  189. ARI driver to support PCI-ARI board as developed by Philips Medical:
  190. - Understanding requirements Philips Medical ARI driver
  191. Digital MSC (Moscow Software Center) people understand the current
  192. requirements.
  193.  
  194. - Understanding re-using existing PCI driver
  195. Glenn Everhart will ask VMS engineers which existing OpenVMS PCI
  196. drivers already do PCI-DMA (as example driver), possible PCI-FDDI
  197. driver (DEFPA?)
  198.  
  199. - Understanding timeline/milestones of delivery
  200. It is understood by all parties that latest delivery of operational
  201. drivers must be no later than November 29, 1996.
  202. Digital MSC has made a preliminary qualification and has proposed
  203. to deliver the OpenVMS driver in 2 months. Windows NT drivers
  204. development is under investigation but depends on availability of
  205. Windows NT sources. Costs for development have been qualified
  206. and has been communicated to Philips Medical. Final agreement how
  207. costs will be X-charged is to be finalized latest september 27, 1996.
  208. Michel van der Togt (manager OEM group Digital) has agreed with
  209. Robert Boers (manager Digital MSC) that development of the drivers
  210. can start directly (as costs will be pre-paid by Digital Netherlands).
  211.  
  212. - Understanding communication/support channels
  213. See above.
  214.  
  215. - Understanding how to deliver driver to comply with requirements
  216. and how to be delivered to Philips Medical for their own support?
  217.  
  218. - Understanding testing and qualification delivery procedure
  219. Philips Medical MR will send all hardware and available
  220. tools and documentation and will document latest September 27,
  221. 1996 how drivers will be tested and how acceptance-tests will
  222. be undertaken.
  223. Philips Medical must at least send the following to Digital
  224. MSC latest September 9, 1996:
  225. - 2x PCI-ARI board
  226. - source code initial test program ARI
  227. - Hardware specification(s)
  228. - 2x KZPSA PCI-SCSI board
  229.  
  230. - Plan follow-on meeting(s), Email/telephone
  231. See also above for Email and telephone interfaces.
  232. Direct communication will take place between Digital MSC and
  233. Philips Medical.
  234.  
  235.  
  237.  
  238. Questions and remarks for Digital MSC people (from Philips):
  239.  
  240.  
  241. - Drivers must be VMS and WNT release independent
  242. - Drivers must be platform independent
  243. - Drivers must be PCI compliant
  244.  
  245.  
  246. 1. It is not clear to me which SCSI-drivers will be changed in order
  247. to get target functionality.
  248. At this moment we are using the GKdriver (class-driver) and the
  249. PKSdriver (portdriver for KZPSA)
  250. Will both drivers be changed?
  251. It must be possible to talk to the BDAS (data-acquisition system)
  252. via the SCSI interface the way we do it now.
  253. Will this be possible after the changes?
  254.  
  255. 2. There is an error in Req. Spec SCSI-driver (XJS-155-4626).
  256. In section 4, it says:
  257. 'It must be possible to define the Host as SCSI-initiator ...
  258. .....
  259. As such, a function should be available to define initiator or target
  260. behaviour on a SCSI channel basis.'
  261.  
  262. This should NOT be on channel basis but on SCSI-ID basis.
  263. In other words, a SCSI-device (represented by its SCSI-ID)
  264. must be defined as initiator or target.
  265. All SCSI-channels representing this device should have
  266. target or initiator behaviour.
  267. The problem however is that for the QIO function a 'channel'
  268. is defined as the combination of a SCSI-ID and a SCSI-LUN.
  269. With the 'open' function defined in XJS-155-4626 it is, in theory,
  270. possible to define 'target' for channel 600 and initiator
  271. for channel 601.
  272.  
  273. I suggest to add a function that defines target or initiator
  274. on a SCSI_ID basis and to leave-out the 'open_flag'
  275. parameter in the open function.
  276. If this can be agreed, I will update XJS-155-4626.
  277.  
  278. Johan van Oosterhout.
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Thanks and regards,
  285.  
  286. Arie and Robbert.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!