1 INFO-VAX	Sat, 19 Feb 2005	Volume 2005 : Issue 100       Contents:A Re: Announcing the latest issue of the OpenVMS Technical Journal. A Re: Announcing the latest issue of the OpenVMS Technical Journal. # Re: HP financials: Alpha sales down # Re: HP financials: Alpha sales down # Re: HP financials: Alpha sales down 1 Re: Looking for suggestions for bootcamp sessions 1 Re: Looking for suggestions for bootcamp sessions 1 Re: Looking for suggestions for bootcamp sessions 1 Re: Looking for suggestions for bootcamp sessions = Re: Micro$oft warns of undetectable spyware security risk ... ! Re: Mounting disks during STARTUP ! Re: Mounting disks during STARTUP ! Re: Mounting disks during STARTUP  RE: Need performance help " Re: OpenVMS Small Partner Strategy" Re: OpenVMS Small Partner Strategy" Re: OpenVMS Small Partner Strategy& Re: Port Print facility Update for I64  Re: VMS 8.2 Itanium Distribution  Re: VMS 8.2 Itanium Distribution  Re: VMS 8.2 Itanium Distribution  Re: VMS 8.2 Itanium Distribution  F ----------------------------------------------------------------------  + Date: Sat, 19 Feb 2005 08:36:17 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> J Subject: Re: Announcing the latest issue of the OpenVMS Technical Journal.0 Message-ID: <cv6tps$g8t$1@sparta.btinternet.com>   Hi Sue,   D Please thank everyone who finds the extra time to contribute to thisI journal. Keep'em coming! With VMS being the beast that it is, there's not L always gonna be something in any given journal for everyone, but it's alwaysL worth a read. I found this issue's "Porting the Macro-32 Compiler to OpenVMSC I64" informative. (And the editor did not submit to the pressure to H "balance" up the refreshingly blatant VMS-only bias in this issue with aH bollocks "C & C++ - a tale of two compilers"  or "Is vi really as bad as# everyone says?" article. Hoorah!!!)   H The one problem I had is not being able to get at the PDF version. Is it just me?  I Anyway, I now have HIGH-HOPES for the portability of my MACRO-32 code! If L anyone has the time to run the following command file on IA64 and tell me if+ it falls over anywhere that would be great!    Cheers Richard.   / PS. Good to hear John Gillings is still around.   J PPS. Obviously replace the "&"s with " "s (Hopefully it doesn't wrap much)   $!+ 4 $!&(c)&Copyright&Richard&Maher.&All&rights&reserved. $!-& $&on&warning&then&exit: $&if&.not.&f$privilege("cmkrnl,sysprv")&&then&goto&no_priv9 $&if&f$getsyi("arch_name")&.nes.&"Alpha"&then&goto&no_vax  $! $&create&dir_watch_exec.mar  ;++  ; 4 ;&(c)&Copyright&Tier3&Software.&All&rights&reserved. ;&A ;&&&&&Ownership&of&this&software&and&all&associated&intellectual& @ ;&&&&&property&rights&remain&vested&in&Tier3&Software&Ltd.&&ThisA ;&&&&&software&&or&any&other&copies&thereof&&may&not&be&provided& 6 ;&&&&&or&otherwise&made&available&to&any&other&person. ; * ;&&&&&Do&not&remove&this&copyright&notice. ;  ;&&&&&Author:&Richard&Maher  ;  ;-- E &&&&&&&&.macro&define_service,name,narg=0,flags=0,mode=exec,?endmacro  & 3 &&&&&&&&'mode'_routine_count='mode'_routine_count+1  & 1 &&&&&&&&.call_entry&&&&&home_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&quad_args=true,&&&&&&&&&- " &&&&&&&&&&&&&&&&&&&&&&&&label=name & # &&&&&&&&.save_psect&&&&&local_block  & # &&&&&&&&.psect&&&&&&&&&&'mode'_list  &  &&&&&&&&.address&&&&&&&&name & $ &&&&&&&&.psect&&&&&&&&&&'mode'_flags &  &&&&&&&&.long&&&&&&&&&&&flags  &  &&&&&&&&.restore_psect &  &&&&&&&&.if&not_equal&narg   &&&&&&&&&cmpb&&&&(ap),#narg  &&&&&&&&&bgeq&&&&endmacro   &&&&&&&&&movzwl&&#ss$_insfarg,r0 &&&&&&&&&ret  	 endmacro:   
 &&&&&&&&.endc 
 &&&&&&&&.endm   3 &&&&&&&&.title&&DIR_WATCH&-&Wait&for&file&creation&  &&&&&&&&.ident&&"V1.2" & & &&&&&&&&.library&"sys$library:lib.mlb"   &&&&&&&&$psldef  &&&&&&&&$lckdef  &&&&&&&&$iosbdef &&&&&&&&$plvdef  &&&&&&&&$lksbdef &&&&&&&&$fibdef   ! &&&&&&&&.irpc&arg_idx,<123456789>   &&&&&&&&arg'arg_idx'='arg_idx'*4
 &&&&&&&&.endr    &&&&&&&&volume_name_size=12  &&&&&&&&devlocknam_size=16 &&&&&&&&dataseq=4   8 &&&&&&&&promote_flags=<lck$m_nodlckwt!lck$m_nodlckblk!&-2 &&&&&&&&&&&&&&&&&&&&&&&lck$m_valblk!lck$m_convert>   &&&&&&&&kernel_routine_count=0 &&&&&&&&exec_routine_count=0 & A &&&&&&&&.psect&&exec_list,pic,con,rel,lcl,shr,noexe,rd,nowrt,long  exec_table:  & B &&&&&&&&.psect&&exec_flags,pic,con,rel,lcl,shr,noexe,rd,nowrt,long exec_flags:  & C &&&&&&&&.psect&&kernel_list,pic,con,rel,lcl,shr,noexe,rd,nowrt,long 
 kernel_table:  & D &&&&&&&&.psect&&kernel_flags,pic,con,rel,lcl,shr,noexe,rd,nowrt,long
 kernel_flags:  & F &&&&&&&&.psect&&t3$wff_rw_data,pic,con,rel,lcl,noshr,noexe,rd,wrt,quad  A parse_fab:&&&&&&&&&&&&&&$fab&&&&&&&&&&&&nam=<parse_nam>,&&&&&&&&- 8 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&fna=in_file_name  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quadA parse_nam:&&&&&&&&&&&&&&$nam&&&&&&&&&&&&nop=<noconceal>,&&&&&&&&- A &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&esa=<expanded_file>,&&&&- : &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&ess=<nam$c_maxrss>  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad4 expanded_file:&&&&&&&&&&.blkb&&&&&&&&&&&nam$c_maxrss  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad4 in_file_name:&&&&&&&&&&&.blkb&&&&&&&&&&&nam$c_maxrss  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&long; child_null_args:&&&&&&&&.long&&&&&&&&&&&12,&0,&lck$k_nlmode 1 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&user_lksb I &&&&&&&&&&&&&&&&&&&&&&&&.long&&&&&&&&&&&<lck$m_noqueue!lck$m_system!&&&&- I &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&lck$m_nodlckblk!lck$m_nodlckwt!&- 7 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&lck$m_expedite> 9 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&child_resnam_desc ; parent_id:&&&&&&&&&&&&&&.long&&&&&&&&&&&0,&0,&0,&0,&0,&0,&0   ) child_id:&&&&&&&&&&&&&&&.long&&&&&&&&&&&0   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad0 parent_resnam:&&&&&&&&&&.ascii&&&&&&&&&&"F11B$v"8 parent_volnam:&&&&&&&&&&.blkb&&&&&&&&&&&volume_name_size( parent_resnam_len&&&&&&&=.-parent_resnam  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad0 child_resnam:&&&&&&&&&&&.ascii&&&&&&&&&&"F11B$s") child_did_num:&&&&&&&&&&.blkw&&&&&&&&&&&1 ) &&&&&&&&&&&&&&&&&&&&&&&&.byte&&&&&&&&&&&0 ) child_did_rvn:&&&&&&&&&&.blkb&&&&&&&&&&&1 ' child_resnam_len&&&&&&&&=.-child_resnam   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) devnam_desc:&&&&&&&&&&&&.long&&&&&&&&&&&0 = &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&parse_nam+nam$t_dvi+1 ) disk_chan:&&&&&&&&&&&&&&.word&&&&&&&&&&&0   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) devlocknam:&&&&&&&&&&&&&.blkb&&&&&&&&&&&1 8 volume_name:&&&&&&&&&&&&.blkb&&&&&&&&&&&volume_name_size) &&&&&&&&&&&&&&&&&&&&&&&&.blkb&&&&&&&&&&&3   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) dev_class:&&&&&&&&&&&&&&.long&&&&&&&&&&&0 3 dvi_iosb:&&&&&&&&&&&&&&&.blkb&&&&&&&&&&&iosb$s_iosb   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad3 find_fib:&&&&&&&&&&&&&&&.blkb&&&&&&&&&&&fib$w_exctl   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) fib_file_len:&&&&&&&&&&&.long&&&&&&&&&&&0 ) fib_file_addr:&&&&&&&&&&.long&&&&&&&&&&&0   3 iosb:&&&&&&&&&&&&&&&&&&&.blkb&&&&&&&&&&&iosb$s_iosb 5 krnl_lksb:&&&&&&&&&&&&&&.blkb&&&&&&&&&&&lksb$b_valblk   4 result_file:&&&&&&&&&&&&.blkb&&&&&&&&&&&nam$c_maxrss  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) result_file_len:&&&&&&&&.blkw&&&&&&&&&&&1   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad) door_bell:&&&&&&&&&&&&&&.long&&&&&&&&&&&0 ) user_iosb_addr:&&&&&&&&&.blkl&&&&&&&&&&&1 ) astadr:&&&&&&&&&&&&&&&&&.blkl&&&&&&&&&&&1 ) astprm:&&&&&&&&&&&&&&&&&.blkl&&&&&&&&&&&1 ) user_ast_adr:&&&&&&&&&&&.blkl&&&&&&&&&&&1  & F &&&&&&&&.psect&&t3$wff_ro_data,pic,con,rel,lcl,shr,noexe,rd,nowrt,quad  ; parent_enq_args:&&&&&&&&.long&&&&&&&&&&&12,&0,&lck$k_nlmode 1 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&user_lksb I &&&&&&&&&&&&&&&&&&&&&&&&.long&&&&&&&&&&&<lck$m_noqueue!lck$m_system!&&&&- I &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&lck$m_nodlckblk!lck$m_nodlckwt!&- 7 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&lck$m_expedite> : &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&parent_resnam_desc; &&&&&&&&&&&&&&&&&&&&&&&&.long&&&&&&&&&&&0,&0,&0,&0,&0,&0,&0   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad9 parent_resnam_desc:&&&&&.long&&&&&&&&&&&parent_resnam_len 5 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&parent_resnam 8 child_resnam_desc:&&&&&&.long&&&&&&&&&&&child_resnam_len4 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&child_resnam  1 null_did:&&&&&&&&&&&&&&&.repeat&&&&&&&&&nam$s_did ) &&&&&&&&&&&&&&&&&&&&&&&&.byte&&&&&&&&&&&0  &&&&&&&&&&&&&&&&&&&&&&&&.endr   , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quadG dvi_list:&&&&&&&&&&&&&&&.word&&&&&&&&&&&devlocknam_size,dvi$_devlocknam 2 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&devlocknam) &&&&&&&&&&&&&&&&&&&&&&&&.long&&&&&&&&&&&0   7 &&&&&&&&&&&&&&&&&&&&&&&&.word&&&&&&&&&&&4,dvi$_devclass 1 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&dev_class , &&&&&&&&&&&&&&&&&&&&&&&&.long&&&&&&&&&&&0,&0  , &&&&&&&&&&&&&&&&&&&&&&&&.align&&&&&&&&&&quad3 fib_desc:&&&&&&&&&&&&&&&.long&&&&&&&&&&&fib$w_exctl 0 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&find_fib  4 result_file_desc:&&&&&&&.long&&&&&&&&&&&nam$c_maxrss3 &&&&&&&&&&&&&&&&&&&&&&&&.address&&&&&&&&result_file   E &&&&&&&&.psect&&t3$wff_common,pic,ovr,rel,gbl,noshr,noexe,rd,wrt,quad   ) synch_ef:&&&&&&&&&&&&&&&.blkl&&&&&&&&&&&1 ) last_seq:&&&&&&&&&&&&&&&.long&&&&&&&&&&&0 3 user_lksb:&&&&&&&&&&&&&&.blkb&&&&&&&&&&&lksb$s_lksb   A &&&&&&&&.psect&&t3$wff_code,pic,con,rel,lcl,shr,exe,rd,nowrt,quad   . &&&&&&&&define_service&&t3$$waitfr_file_init,7  ! 10$:&&&&tstl&&&&&&&&&&&&parent_id  &&&&&&&&bnequ&&&&&&&&&&&97$     &&&&&&&&clrl&&&&&&&&&&&&last_seq  $ &&&&&&&&$clref_s&&&&&&&&efn=arg1(ap) &&&&&&&&blbs&&&&&&&&&&&&r0,20$ &&&&&&&&ret   * 20$:&&&&movl&&&&&&&&&&&&arg1(ap),door_bell  # &&&&&&&&movl&&&&&&&&&&&&arg2(ap),r6 - &&&&&&&&ifnord&&&&&&&&&&#dsc$k_z_bln,(r6),99$ 6 &&&&&&&&cmpw&&&&&&&&&&&&#nam$c_maxrss,dsc$w_length(r6) &&&&&&&&blssu&&&&&&&&&&&98$   ? &&&&&&&&ifnord&&&&&&&&&&dsc$w_length(r6),@dsc$a_pointer(r6),99$   1 &&&&&&&&movc5&&&&&&&&&&&dsc$w_length(r6),&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&@dsc$a_pointer(r6),&&&&&- 9 &&&&&&&&&&&&&&&&&&&&&&&&#^a"&",#nam$c_maxrss,in_file_name < &&&&&&&&movb&&&&&&&&&&&&dsc$w_length(r6),parse_fab+fab$b_fns  # &&&&&&&&movl&&&&&&&&&&&&arg3(ap),r7 - &&&&&&&&ifnord&&&&&&&&&&#dsc$k_z_bln,(r7),99$ > &&&&&&&&ifnowrt&&&&&&&&&dsc$w_length(r7),dsc$a_pointer(r7),99$  # &&&&&&&&movl&&&&&&&&&&&&arg4(ap),r8  &&&&&&&&beql&&&&&&&&&&&&30$   - &&&&&&&&ifnowrt&&&&&&&&&#iosb$s_iosb,(r8),99$  &&&&&&&&clrl&&&&&&&&&&&&(r8) &&&&&&&&clrl&&&&&&&&&&&&4(r8)   ) 30$:&&&&movl&&&&&&&&&&&&r8,user_iosb_addr ' &&&&&&&&movl&&&&&&&&&&&&arg5(ap),astadr ' &&&&&&&&movl&&&&&&&&&&&&arg6(ap),astprm - &&&&&&&&movl&&&&&&&&&&&&arg7(ap),user_ast_adr    &&&&&&&&brb&&&&&&&&&&&&&100$  % 97$:&&&&movzwl&&&&&&&&&&#ss$_abort,r0  &&&&&&&&ret   ( 98$:&&&&movzwl&&&&&&&&&&#ss$_badparam,r0 &&&&&&&&ret   & 99$:&&&&movzwl&&&&&&&&&&#ss$_accvio,r0 &&&&&&&&ret   % 100$:&&&$parse&&&&&&&&&&fab=parse_fab  &&&&&&&&blbs&&&&&&&&&&&&r0,120$    &&&&&&&&tstl&&&&&&&&&&&&r8 &&&&&&&&beql&&&&&&&&&&&&110$= &&&&&&&&movl&&&&&&&&&&&&parse_fab+fab$l_stv,iosb$w_status(r8)    110$:&&&ret   . 120$:&&&movzbl&&&&&&&&&&parse_nam+nam$b_esl,r69 &&&&&&&&movc5&&&&&&&&&&&r6,expanded_file,&&&&&&&&&&&&&&&- 9 &&&&&&&&&&&&&&&&&&&&&&&&#^a"&",dsc$w_length(r7),&&&&&&&&- * &&&&&&&&&&&&&&&&&&&&&&&&@dsc$a_pointer(r7)  I &&&&&&&&bitl&&&&&&&&&&&&#<nam$m_node!nam$m_wildcard!nam$m_search_list>,&- + &&&&&&&&&&&&&&&&&&&&&&&&parse_nam+nam$l_fnb  &&&&&&&&bnequ&&&&&&&&&&&98$   ? &&&&&&&&cmpc&&&&&&&&&&&&#nam$s_did,parse_nam+nam$w_did,null_did  &&&&&&&&bnequ&&&&&&&&&&&130$+ &&&&&&&&movzwl&&&&&&&&&&#ss$_unsupported,r0  &&&&&&&&ret   9 130$:&&&movc3&&&&&&&&&&&#fib$s_did,parse_nam+nam$w_did,&- * &&&&&&&&&&&&&&&&&&&&&&&&find_fib+fib$w_did  : &&&&&&&&movl&&&&&&&&&&&&parse_nam+nam$l_name,fib_file_addr7 &&&&&&&&subl3&&&&&&&&&&&#expanded_file,fib_file_addr,r7 . &&&&&&&&movzbl&&&&&&&&&&parse_nam+nam$b_esl,r6* &&&&&&&&subl3&&&&&&&&&&&r7,r6,fib_file_len  7 &&&&&&&&movzbl&&&&&&&&&&parse_nam+nam$t_dvi,devnam_desc   1 &&&&&&&&$assign_s&&&&&&&devnam=devnam_desc,&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&chan=disk_chan,&&&&&&&&&- * &&&&&&&&&&&&&&&&&&&&&&&&acmode=#psl$c_exec &&&&&&&&blbs&&&&&&&&&&&&r0,140$  &&&&&&&&ret   1 140$:&&&$getdviw_s&&&&&&chan=disk_chan,&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&itmlst=dvi_list,&&&&&&&&- % &&&&&&&&&&&&&&&&&&&&&&&&iosb=dvi_iosb  &&&&&&&&blbc&&&&&&&&&&&&r0,900$ # &&&&&&&&movl&&&&&&&&&&&&dvi_iosb,r0  &&&&&&&&blbc&&&&&&&&&&&&r0,900$   + &&&&&&&&cmpl&&&&&&&&&&&&dev_class,#dc$_disk  &&&&&&&&beqlu&&&&&&&&&&&150$+ &&&&&&&&movzwl&&&&&&&&&&#ss$_unsupported,r0  &&&&&&&&ret   8 150$:&&&movc3&&&&&&&&&&&#volume_name_size,volume_name,&-% &&&&&&&&&&&&&&&&&&&&&&&&parent_volnam   1 &&&&&&&&$cmkrnl_s&&&&&&&routin=g^sys$enqw,&&&&&&- . &&&&&&&&&&&&&&&&&&&&&&&&arglst=parent_enq_args &&&&&&&&blbc&&&&&&&&&&&&r0,900$ 2 &&&&&&&&movzwl&&&&&&&&&&user_lksb+lksb$w_status,r0 &&&&&&&&blbc&&&&&&&&&&&&r0,900$   7 &&&&&&&&movl&&&&&&&&&&&&user_lksb+lksb$l_lkid,parent_id   = &&&&&&&&movw&&&&&&&&&&&&parse_nam+nam$w_did_num,child_did_num = &&&&&&&&movb&&&&&&&&&&&&parse_nam+nam$b_did_nmx,child_did_rvn   1 &&&&&&&&$cmkrnl_s&&&&&&&routin=g^sys$enqw,&&&&&&- . &&&&&&&&&&&&&&&&&&&&&&&&arglst=child_null_args &&&&&&&&blbc&&&&&&&&&&&&r0,900$ 2 &&&&&&&&movzwl&&&&&&&&&&user_lksb+lksb$w_status,r0 &&&&&&&&blbc&&&&&&&&&&&&r0,900$   6 &&&&&&&&movl&&&&&&&&&&&&user_lksb+lksb$l_lkid,child_id    &&&&&&&&pushal&&&&&&&&&&synch_ef' &&&&&&&&calls&&&&&&&&&&&#1,g^lib$get_ef  &&&&&&&&blbc&&&&&&&&&&&&r0,900$   & &&&&&&&&movzwl&&&&&&&&&&#ss$_normal,r0   900$:&&&ret    ;+% ;&Promote&the&lock&with&blocking&AST.  ; < ;&Drop&back&to&USER&mode&for&$SYNCHing.&It&would&be&churlish" ;&to&dawdle&around&at&KERNEL&mode. ;-8 &&&&&&&&define_service&&t3$$waitfr_file_promote,,,kernel    10$:&&&&tstl&&&&&&&&&&&&child_id &&&&&&&&bnequ&&&&&&&&&&&20$  &&&&&&&&clrl&&&&&&&&&&&&r0 &&&&&&&&ret   6 20$:&&&&movl&&&&&&&&&&&&child_id,user_lksb+lksb$l_lkid  1 &&&&&&&&$enq_s&&&&&&&&&&efn=synch_ef,&&&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&lkmode=#lck$k_prmode,&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&lksb=user_lksb,&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&flags=#promote_flags,&&&- 4 &&&&&&&&&&&&&&&&&&&&&&&&blkast=g^t3$$wff_krnlblk_ast &&&&&&&&blbc&&&&&&&&&&&&r0,900$    900$:&&&ret    ;+ ;&Kernel&mode&blocking&AST ;-1 &&&&&&&&.call_entry&&&&&quad_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&home_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&label=t3$$wff_krnlblk_ast     10$:&&&&tstl&&&&&&&&&&&&child_id &&&&&&&&beql&&&&&&&&&&&&900$  6 &&&&&&&&movl&&&&&&&&&&&&child_id,krnl_lksb+lksb$l_lkid  1 &&&&&&&&$enqw_s&&&&&&&&&lkmode=#lck$k_nlmode,&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&lksb=krnl_lksb,&&&&&&&&&- , &&&&&&&&&&&&&&&&&&&&&&&&flags=#lck$m_convert   &&&&&&&&blbc&&&&&&&&&&&&r0,900$ 2 &&&&&&&&movzwl&&&&&&&&&&krnl_lksb+lksb$w_status,r0 &&&&&&&&blbc&&&&&&&&&&&&r0,900$   # &&&&&&&&pushl&&&&&&&&&&&#psl$c_user  &&&&&&&&pushl&&&&&&&&&&&#0$ &&&&&&&&pushl&&&&&&&&&&&user_ast_adr' &&&&&&&&calls&&&&&&&&&&&#3,g^sys$dclast  &&&&&&&&blbc&&&&&&&&&&&&r0,900$    900$:&&&ret    ;++ ;&Check&to&see&if&*our*&file's&been&created  ;-, &&&&&&&&define_service&&t3$$waitfr_file_find  @ &&&&&&&&movl&&&&&&&&&&&&user_lksb+lksb$b_valblk+dataseq,last_seq  1 &&&&&&&&$qiow_s&&&&&&&&&chan=disk_chan,&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&func=#io$_access,&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&iosb=iosb,&&&&&&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&p1=fib_desc,&&&&&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&p2=#fib_file_len,&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&p3=#result_file_len,&&&&- , &&&&&&&&&&&&&&&&&&&&&&&&p4=#result_file_desc   &&&&&&&&blbc&&&&&&&&&&&&r0,900$ - &&&&&&&&movzwl&&&&&&&&&&iosb+iosb$w_status,r0  &&&&&&&&blbc&&&&&&&&&&&&r0,900$    900$:&&&ret    ;+9 ;&Reset&the&Last&Data&sequence&number&to&force&file&check  ;-/ &&&&&&&&define_service&&t3$$waitfr_file_zap_seq     &&&&&&&&clrl&&&&&&&&&&&&last_seq& &&&&&&&&movzwl&&&&&&&&&&#ss$_normal,r0   900$:&&&ret    ;+ ;&Common&reset&routine ;-8 &&&&&&&&define_service&&t3$$waitfr_file_cancel,1,,kernel    &&&&&&&&tstl&&&&&&&&&&&&child_id &&&&&&&&beql&&&&&&&&&&&&10$   % &&&&&&&&$deq_s&&&&&&&&&&lkid=child_id   &&&&&&&&clrl&&&&&&&&&&&&child_id  ! 10$:&&&&tstl&&&&&&&&&&&&parent_id  &&&&&&&&beql&&&&&&&&&&&&20$   & &&&&&&&&$deq_s&&&&&&&&&&lkid=parent_id! &&&&&&&&clrl&&&&&&&&&&&&parent_id   ! 20$:&&&&tstw&&&&&&&&&&&&disk_chan  &&&&&&&&beql&&&&&&&&&&&&30$ & &&&&&&&&$dassgn_s&&&&&&&chan=disk_chan! &&&&&&&&clrw&&&&&&&&&&&&disk_chan     30$:&&&&tstl&&&&&&&&&&&&synch_ef &&&&&&&&beql&&&&&&&&&&&&40$   &&&&&&&&pushal&&&&&&&&&&synch_ef( &&&&&&&&calls&&&&&&&&&&&#1,g^lib$free_ef  &&&&&&&&clrl&&&&&&&&&&&&synch_ef  & 40$:&&&&tstl&&&&&&&&&&&&user_iosb_addr &&&&&&&&beql&&&&&&&&&&&&50$ ) &&&&&&&&movl&&&&&&&&&&&&user_iosb_addr,r5 2 &&&&&&&&movzwl&&&&&&&&&&arg1(ap),iosb$w_status(r5)  % 50$:&&&&$setef_s&&&&&&&&efn=door_bell ! &&&&&&&&clrl&&&&&&&&&&&&door_bell    &&&&&&&&tstl&&&&&&&&&&&&astadr &&&&&&&&beql&&&&&&&&&&&&900$  # &&&&&&&&pushl&&&&&&&&&&&#psl$c_user  &&&&&&&&pushl&&&&&&&&&&&astprm &&&&&&&&pushl&&&&&&&&&&&astadr' &&&&&&&&calls&&&&&&&&&&&#3,g^sys$dclast    &&&&&&&&clrl&&&&&&&&&&&&astadr &&&&&&&&clrl&&&&&&&&&&&&astprm  & 900$:&&&movzwl&&&&&&&&&&#ss$_normal,r0 &&&&&&&&ret   
 krnl_rundown:  &&& A &&&&&&&&.jsb_entry&&&&&&&&&&&&&&&&&&&&&&;&Entry&point&for&Kernel& 9 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&;&rundown&handler     &&&&&&&&tstl&&&&&&&&&&&&child_id &&&&&&&&beql&&&&&&&&&&&&10$   % &&&&&&&&$deq_s&&&&&&&&&&lkid=child_id   ! 10$:&&&&tstl&&&&&&&&&&&&parent_id  &&&&&&&&beql&&&&&&&&&&&&99$   & &&&&&&&&$deq_s&&&&&&&&&&lkid=parent_id   99$:&&&&rsb   
 exec_rundown:  &&& D &&&&&&&&.jsb_entry&&&&&&&&&&&&&&&&&&&&&&;&Entry&point&for&Executive&9 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&;&rundown&handler   ! &&&&&&&&tstw&&&&&&&&&&&&disk_chan  &&&&&&&&beql&&&&&&&&&&&&10$ & &&&&&&&&$dassgn_s&&&&&&&chan=disk_chan   10$:&&&&rsb   
 &&&&&&&&.PAGE ) &&&&&&&&.SBTTL&&Privileged&Library&Vector  &  ;+B ;&Any&psect&with&the&VEC&attribute&will&be&automatically&moved&to& ;&the&start&of&the&image.  ;-6 &&&&&&&&.psect&&dickie$services,page,vec,pic,nowrt,exe & A &&&&&&&&.long&&&&plv$c_typ_cmod&&&&&&&&&&;&Set&type&of&vector&to& A &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&;&change&mode&dispatcher 3 &&&&&&&&.long&&&&0&&&&&&&&&&&&&&&&&&&&&&&;&Reserved D &&&&&&&&.long&&&&kernel_routine_count&&&&;&#&of&Kernel&mode&routinesG &&&&&&&&.long&&&&exec_routine_count&&&&&&;&#&of&Executive&mode&routines > &&&&&&&&.address&kernel_table&&&&&&&&&&&&;&Kernel&routine&list< &&&&&&&&.address&exec_table&&&&&&&&&&&&&&;&Exec&routine&listA &&&&&&&&.address&krnl_rundown&&&&&&&&&&&&;&Kernel&rundown&handler A &&&&&&&&.address&exec_rundown&&&&&&&&&&&&;&Exec&&&rundown&handler 9 &&&&&&&&.long&&&&0&&&&&&&&&&&&&&&&&&&&&&&;&RMS&Dispatcher ? &&&&&&&&.address&kernel_flags&&&&&&&&&&&&;&Kernel&routine&flags ? &&&&&&&&.address&exec_flags&&&&&&&&&&&&&&;&Exec&&&routine&flags  &  &&&&&&&&.end&&&&&&&&&&&& $!L $&macro/list/enable=quad/preserve=(granularity,atomicity)&dir_watch_exec.mar $!& ! $&link&&/share=dir_watch_exec&&&- ! &&&&&&&&/sysexe&&&&&&&&&&&&&&&&&- ! &&&&&&&&/map&&&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/cross&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/full&&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/notrace&&&&&&&&&&&&&&&&- ! &&&&&&&&/section_binding&&&&&&&&- ! &&&&&&&&dir_watch_exec.obj,&&&&&-  &&&&&&&&sys$input:/options   gsmatch=lequal,1,2  9 symbol_vector&=&(t3$$waitfr_file_init=procedure,&&&&&&&&- 9 &&&&&&&&&&&&&&&&&t3$$waitfr_file_promote=procedure,&&&&&- 9 &&&&&&&&&&&&&&&&&t3$$waitfr_file_find=procedure,&&&&&&&&- 9 &&&&&&&&&&&&&&&&&t3$$waitfr_file_cancel=procedure,&&&&&&- 9 &&&&&&&&&&&&&&&&&t3$$waitfr_file_zap_seq=procedure,&&&&&- % &&&&&&&&&&&&&&&&&t3$wff_common=psect)    protect=yes  collect=safe,&&&&&&&&&&&-  &&&&&&&&t3$wff_common,&&-  &&&&&&&&t3$wff_rw_data   $!0 $copy/log&dir_watch_exec.exe&sys$common:[syslib] $! $install:==$install/command = $if&f$file_attributes("sys$share:dir_watch_exec.exe","KNOWN")  $then 4 $&&&&&&&install&replace&sys$share:dir_watch_exec.exe $else K $&&&&&&&install&add&sys$share:dir_watch_exec.exe&/open/header/share/protect  $!C $!&If&you&have&your&GH_RSRVPGCNT&SYSGEN&parameter&geared&up&for&it, 9 $!&you&can&install&dir_watch_exec.exe&as&/RESIDENT&as&in:  $!G $!&&&&&&install&add&sys$share:dir_watch_exec.exe&/open/protect/resident  $endif $!$ $purge&sys$share:dir_watch_exec.exe&8 $set&file/protection=(w:e)&sys$share:dir_watch_exec.exe& $! $&create&dir_watch_user.mar    &&&&&&&&$psldef  &&&&&&&&$lksbdef   &&&&&&&&dataseq=4   ! &&&&&&&&.irpc&arg_idx,<123456789>   &&&&&&&&arg'arg_idx'='arg_idx'*4
 &&&&&&&&.endr   J &&&&&&&&.title&&DIR_WATCH_USER&-&User&mode&RTL&for&Wait&for&file&creation& &&&&&&&&.ident&&"V1.2"  E &&&&&&&&.psect&&t3$wff_common,pic,ovr,rel,gbl,noshr,noexe,rd,wrt,quad   ) synch_ef:&&&&&&&&&&&&&&&.blkl&&&&&&&&&&&1 ) last_seq:&&&&&&&&&&&&&&&.blkl&&&&&&&&&&&1 3 user_lksb:&&&&&&&&&&&&&&.blkb&&&&&&&&&&&lksb$s_lksb   A &&&&&&&&.psect&&t3$wff_code,pic,con,rel,lcl,shr,exe,rd,nowrt,quad   1 &&&&&&&&.call_entry&&&&&quad_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&home_args=false,&&&&&&&&- - &&&&&&&&&&&&&&&&&&&&&&&&label=sys$waitfr_file    &&&&&&&&cmpb&&&&&&&&&&&&(ap),#6  &&&&&&&&bgeq&&&&&&&&&&&&10$ ' &&&&&&&&movzwl&&&&&&&&&&#ss$_insfarg,r0  &&&&&&&&ret   - 10$:&&&&pushab&&&&&&&&&&g^t3$$wff_userblk_ast   &&&&&&&&pushl&&&&&&&&&&&arg6(ap)  &&&&&&&&pushl&&&&&&&&&&&arg5(ap)  &&&&&&&&pushl&&&&&&&&&&&arg4(ap)  &&&&&&&&pushl&&&&&&&&&&&arg3(ap)  &&&&&&&&pushl&&&&&&&&&&&arg2(ap)  &&&&&&&&pushl&&&&&&&&&&&arg1(ap)1 &&&&&&&&calls&&&&&&&&&&&#7,g^t3$$waitfr_file_init    &&&&&&&&blbc&&&&&&&&&&&&r0,900$   7 &&&&&&&&$dclast_s&&&&&&&astadr=g^t3$$wff_userblk_ast,&- * &&&&&&&&&&&&&&&&&&&&&&&&acmode=#psl$c_user &&&&&&&&blbc&&&&&&&&&&&&r0,900$   & &&&&&&&&movzwl&&&&&&&&&&#ss$_normal,r0   900$:&&&ret    ;+ ;&Cancel&Service ;-1 &&&&&&&&.call_entry&&&&&quad_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&home_args=false,&&&&&&&&- 4 &&&&&&&&&&&&&&&&&&&&&&&&label=sys$waitfr_file_cancel  # 10$:&&&&pushl&&&&&&&&&&&#ss$_cancel 1 &&&&&&&&calls&&&&&&&&&&&#1,t3$$waitfr_file_cancel  &&&&&&&&blbc&&&&&&&&&&&&r0,900$   & &&&&&&&&movzwl&&&&&&&&&&#ss$_normal,r0   900$:&&&ret    ;+ ;&User&mode&blocking&AST ;-1 &&&&&&&&.call_entry&&&&&quad_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&home_args=false,&&&&&&&&- 1 &&&&&&&&&&&&&&&&&&&&&&&&label=t3$$wff_userblk_ast   4 &&&&&&&&calls&&&&&&&&&&&#0,g^t3$$waitfr_file_promote &&&&&&&&tstl&&&&&&&&&&&&r0 &&&&&&&&bnequ&&&&&&&&&&&10$  &&&&&&&&ret    10$:&&&&blbc&&&&&&&&&&&&r0,900$   ' &&&&&&&&$synch_s&&&&&&&&efn=synch_ef,&- & &&&&&&&&&&&&&&&&&&&&&&&&iosb=user_lksb   &&&&&&&&blbc&&&&&&&&&&&&r0,900$ 2 &&&&&&&&movzwl&&&&&&&&&&user_lksb+lksb$w_status,r0% &&&&&&&&cmpl&&&&&&&&&&&&r0,#ss$_abort  &&&&&&&&bneq&&&&&&&&&&&&20$  &&&&&&&&ret   + 20$:&&&&cmpl&&&&&&&&&&&&r0,#ss$_valnotvalid  &&&&&&&&bneq&&&&&&&&&&&&50$   4 &&&&&&&&calls&&&&&&&&&&&#0,g^t3$$waitfr_file_zap_seq &&&&&&&& 50$:&&&&blbc&&&&&&&&&&&&r0,900$   @ &&&&&&&&cmpl&&&&&&&&&&&&user_lksb+lksb$b_valblk+dataseq,last_seq &&&&&&&&bneq&&&&&&&&&&&&100$ &&&&&&&&ret   1 100$:&&&calls&&&&&&&&&&&#0,g^t3$$waitfr_file_find * &&&&&&&&cmpl&&&&&&&&&&&&r0,#ss$_nosuchfile &&&&&&&&bnequ&&&&&&&&&&&900$ &&&&&&&&ret  &&&&&&&& 900$:&&&pushl&&&&&&&&&&&r03 &&&&&&&&calls&&&&&&&&&&&#1,g^t3$$waitfr_file_cancel  &&&&&&&&ret    &&&&&&&&.end&&&&&&&&&&&& $!& L $&macro/list/enable=quad/preserve=(granularity,atomicity)&dir_watch_user.mar $!& ! $&link&&/share=dir_watch_user&&&- ! &&&&&&&&/map&&&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/cross&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/full&&&&&&&&&&&&&&&&&&&- ! &&&&&&&&/notrace&&&&&&&&&&&&&&&&- ! &&&&&&&&/section_binding&&&&&&&&- ! &&&&&&&&dir_watch_user.obj,&&&&&-  &&&&&&&&sys$input:/options   gsmatch=lequal,1,2  - symbol_vector&=&(sys$waitfr_file=procedure,&- 2 &&&&&&&&&&&&&&&&&sys$waitfr_file_cancel=procedure)  $ sys$library:dir_watch_exec.exe/share   $!0 $copy/log&dir_watch_user.exe&sys$common:[syslib]9 $set&file/protection=(w:re)&sys$share:dir_watch_user.exe&  $! $install:==$install/command = $if&f$file_attributes("sys$share:dir_watch_user.exe","KNOWN")  $then 4 $&&&&&&&install&replace&sys$share:dir_watch_user.exe $else C $&&&&&&&install&add&sys$share:dir_watch_user.exe&/open/header/share  $endif $!$ $purge&sys$share:dir_watch_user.exe& $! $create&test_dir.cob identification&division.* program-id.&&&&test_dir&with&ident&"V1.2". author.&&&&&&&&Richard&Maher.  *  data&division. working-storage&section.E 01&&timer_ast&&&&&&&pic&9(9)&&&&&&&&comp&&&&value&external&timer_ast. D 01&&comp_ast&&&&&&&&pic&9(9)&&&&&&&&comp&&&&value&external&comp_ast.F 01&&ss$_cancel&&&&&&pic&9(9)&&&&&&&&comp&&&&value&external&ss$_cancel.F 01&&ss$_normal&&&&&&pic&9(9)&&&&&&&&comp&&&&value&external&ss$_normal.) 01&&sys_status&&&&&&pic&9(9)&&&&&&&&comp.  * 6 01&&user_exit&&&&&&&pic&x(1)&&&&&&&&&&&&&&&&value&"N". 01&&in_file&&&&&&&&&pic&x(60). 01&&out_file&&&&&&&&pic&x(255). ) 01&&out_len&&&&&&&&&pic&9(4)&&&&&&&&comp. 	 01&&iosb. ) &&&&03&&iosb_status&pic&9(9)&&&&&&&&comp.  &&&&03&&&&&&&&&&&&&&pic&x(4). E 01&&some_stuff&&&&&&pic&x(16)&&&&&&&&&&&&&&&value&"Just&to&show&how". 7 01&&two_mins&&&&&&&&pic&s9(11)v9(7)&comp&&&&value&-120. ) 01&&wff_flag&&&&&&&&pic&9(9)&&&&&&&&comp.  *  procedure&division.  kick_off&section.  00. 7 &&&&call&"lib$get_ef"&using&wff_flag&giving&sys_status. # &&&&if&sys_status&not&=&ss$_normal& 2 &&&&&&&&call&"lib$stop"&using&by&value&sys_status.  9 &&&&display&"Enter&filename:&"&erase&screen&no&advancing. H &&&&accept&in_file&protected&reversed&bold&at&end&move&"Y"&to&user_exit.  . &&&&perform&loop_around&until&user_exit&=&"Y".  
 &&&&stop&run.  *  loop_around&section. 00.  &&&&call&"sys$waitfr_file"( &&&&&&&&using&&&by&value&&&&&&&&wff_flag1 &&&&&&&&&&&&&&&&by&descriptor&&&in_file,&out_file $ &&&&&&&&&&&&&&&&by&reference&&&&iosb( &&&&&&&&&&&&&&&&by&value&&&&&&&&comp_ast* &&&&&&&&&&&&&&&&by&reference&&&&some_stuff &&&&&&&&giving&&sys_status. # &&&&if&sys_status&not&=&ss$_normal& 2 &&&&&&&&call&"lib$stop"&using&by&value&sys_status.   &&&&call&"str$trim"&2 &&&&&&&&using&&&by&descriptor&&&out_file,&out_file' &&&&&&&&&&&&&&&&by&reference&&&&out_len  &&&&&&&&giving&&sys_status. # &&&&if&sys_status&not&=&ss$_normal& 2 &&&&&&&&call&"lib$stop"&using&by&value&sys_status.  4 &&&&display&"Expanded&File&=&",&out_file(1:out_len).   &&&&call&"sys$setimr" ! &&&&&&&&using&&&by&value&&&&&&&&0 ( &&&&&&&&&&&&&&&&by&reference&&&&two_mins) &&&&&&&&&&&&&&&&by&value&&&&&&&&timer_ast ( &&&&&&&&&&&&&&&&by&reference&&&&out_file! &&&&&&&&&&&&&&&&by&value&&&&&&&&0  &&&&&&&&giving&&sys_status. # &&&&if&sys_status&not&=&ss$_normal& 2 &&&&&&&&call&"lib$stop"&using&by&value&sys_status.  ) &&&&display&"Waiting&for&file&to&arrive".    &&&&call&"sys$synch"( &&&&&&&&using&&&by&value&&&&&&&&wff_flag$ &&&&&&&&&&&&&&&&by&reference&&&&iosb &&&&&&&&giving&&sys_status. > &&&&if&sys_status&=&ss$_normal&move&iosb_status&to&sys_status.   &&&&evaluate&&&&sys_status8 &&&&&&&&when&&&&ss$_cancel&display&"Got&fed-up&waiting!": &&&&&&&&when&&&&ss$_normal&display&"Your&file&has&arrived"C &&&&&&&&&&&&&&&&&&&&&&&&&&&call&"sys$cantim"&using&out_file&omitted D &&&&&&&&when&&&&other&&&&&&call&"lib$stop"&using&by&value&sys_status &&&&end-evaluate.  *  fini. , &&&&display&"Enter&filename:&"&no&advancing.H &&&&accept&in_file&protected&reversed&bold&at&end&move&"Y"&to&user_exit. *  end&program&test_dir.  identification&division.* program-id.&&&&comp_ast&with&ident&"V1.2". *  data&division. linkage&section. 01&&some_stuff&&&&&&pic&x(16). * $ procedure&division&using&some_stuff. kick_off&section.  00. 1 &&&&display&"Here's&my&parameter&-&",&some_stuff.  &&&&exit&program.  *  end&program&comp_ast.  identification&division.+ program-id.&&&&timer_ast&with&ident&"V1.2".  *  data&division. working-storage&section.F 01&&ss$_normal&&&&&&pic&9(9)&&&&&&&&comp&&&&value&external&ss$_normal.) 01&&sys_status&&&&&&pic&9(9)&&&&&&&&comp.  *  procedure&division.  kick_off&section.  00. 4 &&&&call&"sys$waitfr_file_cancel"&giving&sys_status.# &&&&if&sys_status&not&=&ss$_normal& 2 &&&&&&&&call&"lib$stop"&using&by&value&sys_status.   &&&&exit&program.  *  end&program&timer_ast. $! $cobol/lis&test_dir.cob 1 $link/exe=test_dir.exe&test_dir.obj,sys$input/opt   $ sys$library:dir_watch_user.exe/share   $! $exit  $!	 $no_priv: K $&&&&&&&write&sys$output&"Insufficient&privilege.&You&need&(CMKRNL,SYSPRV)"  $&&&&&&&exit&44  $no_vax:8 $&&&&&&&write&sys$output&"This&code&only&works&on&alpha" $&&&&&&&exit&44  $!   + L ---------------------------------------------------------------------------- ---- WAITFR_FILE   J                 Monitor an on-disk directory until the user-specified file has D                 been created. This service completes asynchronously.  K                 For additional information about system service completion, 9                 refer to the Synchronize ($SYNCH) service   L ---------------------------------------------------------------------------- ----C FORMAT          SYS$WAITFR_FILE [efn] ,filespec ,resultant-filespec ;                                 [,iosb] [,astadr] [,astprm]   L ---------------------------------------------------------------------------- ---- ARGUMENTS       efn )                 OpenVMS usage:  ef_number 3                 type:           longword (unsigned) )                 access:         read only (                 mechanism:      by value  K                 Event flag that SYS$WAITFR_FILE is to set once this service J                 detects that the user-specified file has been created. The efn I                 argument is a longword value containing the number of the  event L                 flag; however, SYS$WAITFR_FILE uses only the low-order byte. If<                 you do not specify efn, event flag 0 is set.  D                 When SYS$WAITFR_FILE begins execution, it clears the	 specified D                 event flag or event flag 0 if efn was not specified.                   filespec+                 VMS usage:      char_string 4                 type:           character-coded text)                 access:         read only B                 mechanism:      by descriptor--fixed length string
 descriptor  I                 File specification, which may not contain wildcards, that H                 SYS$WAITFR_FILE uses to search for the desired file. TheL                 filespec argument is the address of a descriptor pointing toF                 the file specification. The maximum length of the file+                 specification is 255 bytes.   F                 Additionally, the file specification may not contain a searchH                 list logical name, a node specification or a device name that<                 refers to a device other than a disk device.  K                 SYS$WAITFR_FILE uses RMS to parse the filespec argument. If  RMS >                 is unable to parse the file specification then SYS$WAITFR_FILE H                 will place the secondary RMS error status (STV) into the first .                 longword of the iosb argument.                       + "                 resultant-filespec  +                 OpenVMS usage:  char_string 0                 type:           character string&                 access:         modifyB                 mechanism:      by descriptor--fixed length string
 descriptor  I                 Resultant file specification that SYS$WAITFR_FILE returns  whenL                 it has successfully parsed the specification in the filespecD                 argument. All concealed logical names will have been
 translated4                 in this expanded file specification.                   iosb  /                 OpenVMS usage:  io_status_block 3                 type:           quadword (unsigned) *                 access:         write only3                 mechanism:      by 32-bit reference   H                 I/O status block that is to receive the final completion status. K                 The iosb argument is the 32-bit address of the quadword I/O                  status block.   C                 SYS$WAITFR_FILE sets the quadword to 0 upon request  initiation. I                 Upon request completion, a condition value is returned to  the J                 first longword; the second longword is reserved for future use.  K                 Though this argument is optional, TIER3 strongly recommends  that:                 you specify it, for the following reasons:  L                 . If you are using an event flag to signal the completion of the J                 service, you can test the I/O status block for a condition value L                 to be sure that the event flag was not set by an event other(                 than service completion.  D                 . If you are using the $SYNCH service to synchronize
 completionK                 of the service, the I/O status block is a required argument  forn                 $SYNCH.t  L                 . The condition value returned in R0 and the condition valueJ                 returned in the I/O status block provide information aboutD                 different aspects of the call to the SYS$WAITFR_FILE service.H                 The condition value returned in R0 gives you information about F                 the success or failure of the service call itself; the	 conditionuL                 value returned in the I/O status block gives you informationF                 about the success or failure of the service operation.I                 Therefore, to accurately assess the success or failure ofe thenL                 call to SYS$WAITFR_FILE, you must check the condition values=                 returned in both R0 and the I/O status block.M                                                                                             +-                 astadr  -                 OpenVMS usage:  ast_procedure /                 type:           procedure values<                 access:         call without stack unwinding3                 mechanism:      by 32-bit reference8  G                 AST service routine to be executed when SYS$WAITFR_FILEhL                 completes. The astadr argument is the 32-bit address of this                 routine.  L                 If you specify astadr, the AST routine executes at user modeK                 regardless of the access mode of the caller of the service.e                   astprm  (                 OpenVMS usage:  user_arg3                 type:           longword (unsigned)b)                 access:         read only (                 mechanism:      by value  E                 AST parameter to be passed to the AST service routinea	 specifiediK                 by the astadr argument. The astprm argument is the longword-                 parameter.  L ---------------------------------------------------------------------------- ---- DESCRIPTIONfE                 Control returns to your program immediately followingS
 successfulH                 completion of this service. Once SYS$WAITFR_FILE detects thatE                 the file specified by filespec has been created, thisr servicehL                 will inform your program by setting the event flag specified by:                 efn and, if specified, delivering the AST.  K                 For each VMS Process, there can only be one SYS$WAITFR_FILEhG                 service 'active' at any given time. Therefore it is notaB                 currently possible to implement OR type waits withH                 SYS$WAITFR_FILE. That is, you can not choose to wait for this"                 file OR that file.  #                 Required Privilegeso  L                 You must have read access to the disk and directory that you are                  monitoring.n                    Related Services  &                 SYS$WAITFR_FILE_CANCEL                                                                                                 +&L ---------------------------------------------------------------------------- ----K CONDITION       SS$_NORMAL              The service completed successfully.  The&K VALUES                                  directory watch has been initiated.&C RETURNED        SS$_INSFARG             Insufficient call arguments&
 specified.L                                         Although astadr and astprm arguments aresC                                         optional they must still bee specified as-                                         zero. L                 SS$_ABORT               A call to SYS$WAITFR_FILE is alreadyE                                         active. Only one call to this& service H                                         per process, is permitted at any given_L                                         time. Review your code or cancel theH                                         outstanding directory watch with?                                         SYS$WAITFR_FILE_CANCEL. I                 SS$_ACCVIO              Filespec could not be read by thep callerK                                         or either the resultant-filespec orp iosbL                                         arguments could not be written to by thet/                                         caller.lD                 SS$_BADPARAM            One or more of the following
 conditions2                                         is true: -E                                         . filespec is longer than 255&
 charactersL                                         . filespec contained a wildcard * or %nH                                         . filespec contained a node nameI                                         . filespec contained a searchlist&H                 SS$_UNSUPPORTED         No FID could be obtained for theF                                         directory specification or the	 specified D                                         device is not a disk device.  ?                 Any errors returned by the following services:-&1                                         SYS$PARSE&2                                         SYS$ASSIGN3                                         SYS$GETDVIWe/                                         SYS$ENQn2                                         LIB$GET_EF  L ---------------------------------------------------------------------------- ----K CONDITION       SS$_NORMAL              The file that you have been waiting& for&9 VALUES                                  has been created.&K RETURNED        SS$_CANCEL              The wait was cancelled by a call to&> IN THE I/O                              SYS$WAITFR_FILE_CANCELH STATUS          fab$l_stv               Secondary RMS error status. This willL BLOCK                                   only occur if SYS$WAITFR_FILE failedK                                         while attempting to call SYS$PARSE.:  L ---------------------------------------------------------------------------- ----       +&L ---------------------------------------------------------------------------- ---- WAITFR_FILE_CANCEL  H                 The cancel wait for file service will abort a file watch thatJ                 was previously set in motion by a call to SYS$WAITFR_FILE.  L ---------------------------------------------------------------------------- ----& FORMAT          SYS$WAITFR_FILE_CANCEL  L ---------------------------------------------------------------------------- ----	 ARGUMENTSa                 None._  L ---------------------------------------------------------------------------- ----C DESCRIPTION     The cancel file wait service is used to prematurely& terminate ak1                 previous call to SYS$WAITFR_FILE.&  H                 SYS$WAITFR_FILE_CANCEL relinquishes all system resourcesK                 obtained by SYS$WAITFR_FILE, sets the specified event flag,o andiC                 delivers the AST to the calling process, if one wast
 requested.  I                 In order to identify the abnormal termination of the wait& for K                 file service SYS$WAITFR_FILE_CANCEL sets the IOSB status to&                 SS$_CANCEL.&  L                 It is not a requirement of SYS$WAITFR_FILE that this routine beJ                 called. The equivalent processing, except for AST delivery anda<                 event flag setting is implied at image exit.  #                 Required Privileges,                   None.a                    Related Services                   SYS$WAITFR_FILE&  L ---------------------------------------------------------------------------- ----K CONDITION       SS$_NORMAL              The service completed successfully.c VALUES RETURNED   ------------------------------  % Date: Sat, 19 Feb 2005 11:20:22 +0100&& From: Paul Sture <paul.sture@decus.ch>J Subject: Re: Announcing the latest issue of the OpenVMS Technical Journal., Message-ID: <37oi73F5a2tabU1@individual.net>   Richard Maher wrote:  	 > Hi Sue,r > F > Please thank everyone who finds the extra time to contribute to thisK > journal. Keep'em coming! With VMS being the beast that it is, there's notdN > always gonna be something in any given journal for everyone, but it's alwaysN > worth a read. I found this issue's "Porting the Macro-32 Compiler to OpenVMSE > I64" informative. (And the editor did not submit to the pressure torJ > "balance" up the refreshingly blatant VMS-only bias in this issue with aJ > bollocks "C & C++ - a tale of two compilers"  or "Is vi really as bad as% > everyone says?" article. Hoorah!!!)d > J > The one problem I had is not being able to get at the PDF version. Is it
 > just me? > . Just tried downloading it and no problem here.   ------------------------------  % Date: Sat, 19 Feb 2005 07:37:05 -0500&) From: "Neil Rieck" <n.rieck@sympatico.ca>e, Subject: Re: HP financials: Alpha sales down9 Message-ID: <OpGRd.19394$dZ.809447@news20.bellglobal.com>   . "Tom Linden" <tom@kednos.com> wrote in message" news:opsmd87aa5zgicya@hyrrokkin...G > On Thu, 17 Feb 2005 22:33:35 -0500, Neil Rieck <n.rieck@sympatico.ca>& > wrote: >:K >> In December-2004 my employer purchased two used AS-DS20e machines from a,K >> used equipment vendor and we quickly realized we were in the middle of a_E >> bidding war. The vendor told us that used Alpha sales were up 150%7 >> (whateverE >> that means) since September 2004 with no end in sight coming. This&
 >> startedD >> us to speculate: "Did this have anything to do with the announcedI >> End-of-Life of Alpha?". Were others thinking things like "Gee, Itaniumz >> boxesI >> are coming out now but I'd like to wait for the technology to mature a& >> bitJ >> so I'll by myself some time by purchasing used Alphas?" If any of theseG >> speculations are even partly true, it makes you wonder why Compaq/HP&	 >> didn'tpG >> do the IBM thing and be a little more secretive when it comes to EOLn >> statements etc. >&% > Which computer systems did IBM EOL?f >   F None and others in this thread (see later posts) have missed my point.  F First off, IBM very rarely (if ever) admits to making technological orJ marketing mistakes (I know this from first-hand experience with them). TheL attitude they project to most non-technical customers is almost hypnotic and8 the decision makers at most companies are totally duped.  F They are quite loud when introducing new products and very quiet aboutJ announcing the end of others. They almost always sell a product until thatG market is almost sucked dry, and usually won't kill a product until the J replacement product is ready and all affected customers have been notified through the sales channel.  H When Compaq publicly announced the EOL of Alpha way back when, they wereE being very honest as well as very stupid. They don't have to time new&G product introductions like IBM does, but they could have emulated their8H previous success in going from VAX to Alpha: they should have gone aheadK with Itanium development, production and sales but shouldn't have announced&4 Alpha's EOL until Itanium was eclipsing Alpha sales.  F (ps. I know that Compaq was bleeding money and that this is one of theI reasons they decided to EOL Alpha; likewise IBM has also had its share of I financial problems (the 1980s) but seemed to transform itself back into anK financial and technological juggernaut without shooting itself in the foot.&  L I believe that some potential customers buying stop-gap Alphas from the usedJ equipment market accounts for "some" of the currently bad sales figures atI HP; and that this was caused by Compaq's premature Alpha-EOL announcementp way back when)      
 Neil Rieck Kitchener/Waterloo/Cambridge,a Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  # Date: Sat, 19 Feb 2005 15:24:36 GMTd5 From: rdeininger@mindspringdot.com (Robert Deininger)h, Subject: Re: HP financials: Alpha sales downL Message-ID: <rdeininger-1902051024350001@user-uinj4l7.dialup.mindspring.com>  J In article <6bSdnZXZ595Y3IvfRVn-jg@igs.net>, "John Smith" <a@nonymous.com> wrote:   >Keith Parris wrote: >> JF Mezei wrote:I >>> VMS is on its way there too, with only 660 customer left that matter.& >>B >> I don't know where you pulled that number from, but it's low by  >> multiple orders of magnitude. >& >&M >The 660 came from Gorham/Marcello in a published interview - as key accounts& >that HP talks to.  D But those are key, large accounts that get special attention from HPI bigwigs.  They get special attention from bigwigs because they spend vastn, sums of money.  That's what bigwigs are for.  I Not "only 660 customer [sic] left that matter", as that JF thing spun the0! quote in his usual twisted way.  l  J You're arguing about the difference between JF's and Keith's definition ofI customers that matter.  Now you'll change the subject slightly and createvB your own definitions to convince yourself that the sky is falling.  J Please feel free to take out of context anything I've written, mix it withE stuff from other folks who post about VMS, come up with more creative0G theories, and post them as obvious facts.  Someone else will come along&J and insult anyone who doesn't buy your line of nonsense.  I can't think ofB a better strategy to build up goodwill in the VMS community.  GiveB yourself a big pat on the back for doing your part to improve VMS.   ------------------------------  % Date: Sat, 19 Feb 2005 11:39:23 -0500r# From: "John Smith" <a@nonymous.com>i, Subject: Re: HP financials: Alpha sales down, Message-ID: <DdidnX7hiski9orfRVn-2w@igs.net>   Robert Deininger wrote:&; > In article <6bSdnZXZ595Y3IvfRVn-jg@igs.net>, "John Smith"h > <a@nonymous.com> wrote:d >  >> Keith Parris wrote: >>> JF Mezei wrote:&B >>>> VMS is on its way there too, with only 660 customer left that >>>> matter. >>>uC >>> I don't know where you pulled that number from, but it's low by&! >>> multiple orders of magnitude.g >> >>F >> The 660 came from Gorham/Marcello in a published interview - as key >> accounts that HP talks to.& >&F > But those are key, large accounts that get special attention from HPF > bigwigs.  They get special attention from bigwigs because they spend3 > vast sums of money.  That's what bigwigs are for.l >&G > Not "only 660 customer [sic] left that matter", as that JF thing spun % > the quote in his usual twisted way.l >e> > You're arguing about the difference between JF's and Keith'sE > definition of customers that matter.  Now you'll change the subject9D > slightly and create your own definitions to convince yourself that > the sky is falling.  >&G > Please feel free to take out of context anything I've written, mix ithC > with stuff from other folks who post about VMS, come up with more&G > creative theories, and post them as obvious facts.  Someone else willoE > come along and insult anyone who doesn't buy your line of nonsense.iD > I can't think of a better strategy to build up goodwill in the VMSE > community.  Give yourself a big pat on the back for doing your part& > to improve VMS.c      I JF said that only 660 accounts existed. I corrected that falsehood as you&F would characterize it. JF clearly knows the fact that the 660 is *key*K accounts, and I am willing to give him the benefit of the doubt in the heat&  of flying fingers on a keyboard.  K All I was commenting on was the veracity of the legendary 411,000 installedtL VMS systems - a number that has remained unchanged in public statements fromK VMS's various owners for nearly 6 years despite claims of single and double$H digit sales increases and claims of new customers, and offering a way toL look at the numbers factoring in the 'key' accounts that the suits talk withI to get an anecdotal sense of how much, if any, smoke is being blown about& the 411,000 systems.    K Unfortunately many large companies don't listen to their employees and have&H better hearing when it comes to customer beefs. I know that you'd preferI that this were  the case as it would 'tone down' the 'noise' you complain& about.  L But seeing as it is the case, as to my actions vs. your actions in improvingI VMS's situation in the market, I suggest that you continue to do what you&L do - work on improving and enhancing VMS; and I'll continue to do what I andJ others are doing - pushing at HP to market the fruits of your labor, whichI will in the end benefit you, your co-workers, my business, HP's business,&. and results for all of us who own HP's shares.  H We both want the same end result - we simply have differing views on how that result will be achieved.&   Have a nice weekend.   --- OpenVMS - The classics never go out of style.&   ------------------------------  # Date: Sat, 19 Feb 2005 10:08:34 GMT&! From: Nigel Barker <nigel@hp.com>&: Subject: Re: Looking for suggestions for bootcamp sessions8 Message-ID: <3a2e11p5gos9geplaf1vrdiefjudqp21vm@4ax.com>  F On Fri, 18 Feb 2005 20:24:09 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:  P >:However it is still possible to do the equivalent of >>> b dka0 it's just that0 >:you have to type in a few more characters e.g. >:% >:shell>  fs0:\efi\vms\vms_loader.efie >&A >  That's the fixed-disk path to the OpenVMS EFI bootstrap script& >  in the first FAT partition.  K It is the equivalent of >>> b dka0 which is also specific to one disk. SomesL knowledge of which disk you are booting from is necessary just as it is with Alpha.   -- Nigel Barker Live from the sunny Cote d'Azur&   ------------------------------  % Date: Sat, 19 Feb 2005 05:55:01 -0800&# From: "Tom Linden" <tom@kednos.com>n: Subject: Re: Looking for suggestions for bootcamp sessions( Message-ID: <opsmf59zu4zgicya@hyrrokkin>  D On Sat, 19 Feb 2005 10:08:34 GMT, Nigel Barker <nigel@hp.com> wrote:  H > On Fri, 18 Feb 2005 20:24:09 GMT, hoff@hp.nospam (Hoff Hoffman) wrote: > J >> :However it is still possible to do the equivalent of >>> b dka0 it's   >> just that2 >> :you have to type in a few more characters e.g. >> :' >> :shell>  fs0:\efi\vms\vms_loader.efie >>B >>  That's the fixed-disk path to the OpenVMS EFI bootstrap script >>  in the first FAT partition.o >&J > It is the equivalent of >>> b dka0 which is also specific to one disk.   > SomeK > knowledge of which disk you are booting from is necessary just as it is  t > with > Alpha.I Can you partition the disk at the shell> prompt?  If so, can you boot VMSu  from different partitions?d >& > -- > Nigel Barker! > Live from the sunny Cote d'AzurD       --  C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/&   ------------------------------  # Date: Sat, 19 Feb 2005 15:48:02 GMT&5 From: rdeininger@mindspringdot.com (Robert Deininger)=: Subject: Re: Looking for suggestions for bootcamp sessionsL Message-ID: <rdeininger-1902051048020001@user-uinj4l7.dialup.mindspring.com>  M In article <opsmf59zu4zgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> wrote:&  E >On Sat, 19 Feb 2005 10:08:34 GMT, Nigel Barker <nigel@hp.com> wrote:& >&I >> On Fri, 18 Feb 2005 20:24:09 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:c >>K >>> :However it is still possible to do the equivalent of >>> b dka0 it's  &
 >>> just thatw3 >>> :you have to type in a few more characters e.g.& >>> :i( >>> :shell>  fs0:\efi\vms\vms_loader.efi >>>&C >>>  That's the fixed-disk path to the OpenVMS EFI bootstrap scriptw  >>>  in the first FAT partition. >>K >> It is the equivalent of >>> b dka0 which is also specific to one disk.  & >> Some&L >> knowledge of which disk you are booting from is necessary just as it is   >> withc	 >> Alpha.iJ >Can you partition the disk at the shell> prompt?  If so, can you boot VMS > from different partitions?    I I don't know if you can partition a disk from the shell.  It seems likelyl= there's a tool somewhere to do it, but it isn't done for VMS.   J So far, VMS a system disk only has one EFI partition containing a VMS bootI utility.  I don't think that's a fundamental requirement, that's just the& way VMS does it.  I You could try copying VMS_LOADER and IPB into the maintenance partition. hG I expect they would boot VMS just as they do in the standard partition.    ------------------------------  # Date: Sat, 19 Feb 2005 17:25:45 GMT&! From: Nigel Barker <nigel@hp.com>_: Subject: Re: Looking for suggestions for bootcamp sessions8 Message-ID: <8sre115u6dvjoffi5jbcvju1aiemiufgqr@4ax.com>  H On Sat, 19 Feb 2005 05:55:01 -0800, "Tom Linden" <tom@kednos.com> wrote:  E >On Sat, 19 Feb 2005 10:08:34 GMT, Nigel Barker <nigel@hp.com> wrote:& >bI >> On Fri, 18 Feb 2005 20:24:09 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:& >>K >>> :However it is still possible to do the equivalent of >>> b dka0 it's  ,
 >>> just thatn3 >>> :you have to type in a few more characters e.g., >>> :&( >>> :shell>  fs0:\efi\vms\vms_loader.efi >>>&C >>>  That's the fixed-disk path to the OpenVMS EFI bootstrap scriptb  >>>  in the first FAT partition. >>K >> It is the equivalent of >>> b dka0 which is also specific to one disk.  & >> Some&L >> knowledge of which disk you are booting from is necessary just as it is   >> with&	 >> Alpha. J >Can you partition the disk at the shell> prompt?  If so, can you boot VMS > from different partitions?  N The disk _is_ partitioned at the EFI shell> prompt but VMS knows nothing aboutK disk partitions so it is not possible. The EFI & Diagnostic partitions justfN appear as container files from the VMS point of view. HP-UX doesn't know aboutN partitioned disks either but Linux & Windows do so it is possible to set up anN rx2600 & use its 3 internal disks & choose between 4 operating systems at boot time.&   -- Nigel Barker Live from the sunny Cote d'Azur&   ------------------------------  % Date: Sat, 19 Feb 2005 13:27:09 +0100 + From: Karsten Nyblad <nospam@nospam.nospam>cF Subject: Re: Micro$oft warns of undetectable spyware security risk ...- Message-ID: <cv7bc5$17lo$1@news.cybercity.dk>l   Michael D. Ober wrote:I   > If this becomes a common problem, I suspect it will spell the end of = free OS& > downloads (Linux). >  > Mike Ober. > ( > <bob@instantwhip.com> wrote in message> > news:1108733310.343931.80970@g14g2000cwa.googlegroups.com... > < >>so you think everything can be patched in windoze land ... >>+ >>http://www.theinquirer.net/?article=21326   I The real problem i operating systems where it is normal to browse on the  ? internet while while having system administrators rights.  Any &F reasonebly designed OS would not allow normal users to install kernel G mode patches, and you need to do that to install that kind of spyware.  H Read:  The descibed problem is a problem on Windows, but not on OpenVMS  or *nix.   ------------------------------  + Date: Sat, 19 Feb 2005 08:23:15 +0000 (UTC)sP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)* Subject: Re: Mounting disks during STARTUP$ Message-ID: <cv6t1j$haf$2@online.de>  < In article <4216AB92.B95547F1@comcast.net>, David J Dachtera$ <djesys.nospam@comcast.net> writes:    > Bart Zorn wrote: > > J > > There is one example which demonstrates that it works: when you have aJ > > shadowed system disk with more than one member, the second (and third)B > > member get automatically added to the shadow set at boot time. > & > That's how it SUPPOSED to work, yes. > J > When my system boots, I see messages about shadow-set inconsistency, and@ > then the boot disk is reMOUNTed as a single-member shadow-set.  H I have never seen that.  Even if the system suffers a hard shutdown via H a power failure, both members of the system-disk shadow set are mounted 
 at boot time./  J > First guess time would be because the primary swap/page files are on the@ > system disk, and it can be DISMOUNTed cleanly during OPCCRASH.  F I have the primary page/swap files on the system disk.  Not a problem.   ------------------------------  + Date: Sat, 19 Feb 2005 08:21:35 +0000 (UTC)rP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)* Subject: Re: Mounting disks during STARTUP$ Message-ID: <cv6suf$haf$1@online.de>  9 In article <cv5mht$uep$1@news01.intel.com>, Ken Fairfielda! <my.full.name@intel.com> writes: o  B >      While I was at SLAC, all of our shadow set mounts were doneA > via a subroutine that did the following (after various checks):m > 4 >          $ Mount/System/NoRebuild/Include/NoCopy -2 >               DSAxxx /Shadow=(<one-mbr>) <label> > @ > The subroutine was called with the obvious parameters: the DSA@ > device name, a comma-separated list of the shadow members, and > the volume label.& >  > NOTES:5 > 	1) On each call, the routine would check the first&5 > 	   member in the list to see that it EXISTs and isa5 > 	   AVL.  If not, it went on to try the next member)1 > 	   in the list.  (This was important when youru5 > 	   storage was RA90's on HSC's...following a power9: >             outage, there were always three or four that" >             wouldn't spin up...) > 1 > 	2) The /Include automatically mounts all validf( >             members of the shadow set. > 2 > 	3) The /NoCopy prevents starting a shadow copy,5 > 	   therefore protecting your data in the case thata? >             an out-of-date member was first in the list, say,o= >             because it had previously been dismounted for ai? >             backup, and another member is actually the "good"0= >             member.  The "bad" member gets mounted, but you&@ >             don't destroy the data on the "good", not mounted, >             member.e  E Why would you want to mount (and presumably write to) the bad member?fI This means that the good member becomes stale.  How do you reconcile the &G new data on the bad member and the data on the non-mounted good member?a  3 > 	4) By not listing all (potential) members in thee6 > 	   /Shadow=(...) list, you are always (well, nearly> >             always :-) able to mount the shadow set.  If all; >             members are listed, conditions like (1) wouldi> >             prevent the mount from succeeding, and (3) would" >             result in lost data.  I Without /INCLUDE but listing all members, the shadow set will mount with & all available disks.  1 I still don't see what advantage /INCLUDE brings.&   ------------------------------  % Date: Sat, 19 Feb 2005 08:01:54 -0500s+ From: Ken Robinson <kenrbnsn1@patmedia.net>v* Subject: Re: Mounting disks during STARTUPA Message-ID: <6.2.1.2.2.20050219075528.04144f20@mail.patmedia.net>e  8 At 09:59 PM 2/18/2005, David J Dachtera wrote (in part):  % >That's how it SUPPOSED to work, yes.u >&I >When my system boots, I see messages about shadow-set inconsistency, and&? >then the boot disk is reMOUNTed as a single-member shadow-set.h   Which version on VMS?"  K There was a problem in version 7.3-2 after shadowing to dissimilar devices fK was introduced that showed similar characteristics. The system would allow tG shadowing of the system disk to dissimilar devices, but when trying to dJ boot, the system would either crash or issue that message. I believe that  problem has been patched.t  K I discovered it while trying to move a system disk from HSG storage to EVA  < storage. A 9 Gb HSG disk is not the same as a 9 Gb EVA disk.   Ken    ------------------------------  % Date: Sat, 19 Feb 2005 10:05:58 -0500a' From: "Main, Kerry" <kerry.main@hp.com> " Subject: RE: Need performance helpR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB53F62C@tayexc19.americas.cpqcorp.net>   > -----Original Message-----> > From: David J Dachtera [mailto:djesys.nospam@comcast.net]=20" > Sent: February 18, 2005 10:08 PM > To: Info-VAX@Mvb.Saic.Com $ > Subject: Re: Need performance help >=20	 [snip...]&  3 > > Also, have not used this myself, but check out:f4 > > http://h71000.www7.hp.com/openvms/products/dcpi/ >=20A > Looked at that today. I was hoping it could be a replacement=20_ > for SPM orF > PSPA, but it seems much more engineering-oriented, and assumes a farD > more intimate knowledge of the software than the average CTO, data; > center manager, etc. is likely to possess when seeking=20( > performance data > from the system. >=20 > Still hoping...u >=20 > --=20& > David J Dachtera > dba DJE Systems  > http://www.djesys.com/ >=20  	 [snip ..]-   David,  = Not the same as SPM, but did you also consider the following: 9 http://h71000.www7.hp.com/openvms/products/ecp/index.htmli  E [ECP V5.4D for VMS V7.3-2 and below; V5.5 required for VMS V8.2 Alphau$ systems. See VMS V8.2 release notes]   Regardsn  
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660e Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Sat, 19 Feb 2005 03:22:39 -0500a' From: Dave Froble <davef@tsoft-inc.com>-+ Subject: Re: OpenVMS Small Partner Strategy-0 Message-ID: <111dt9gte7j5o04@corp.supernews.com>   David J Dachtera wrote:  > Dave Froble wrote:   >>Another idea shot in the ass.  >  > . > Geez, Dave, can you be any more pessimistic?  	 Probably.   H The story that started this is pretty much the same as my story, except 2 I was even smaller and didn't even survive Palmer.  H I've got one customer that, when I questioned their firm desire to move H VMS based applications to windows, replied "We no longer trust Compaq". C   There is no counter to such.  If they lack trust, then that's it.   D It gets pretty bad when someone will prefer to trust Microsoft, you ; know, the people who said "Your problem is you trusted us".f  I If HP started selling VMS systems at PC prices, I'd still have a problem  ' selling them due to the last 5-6 years.   
 Want more?   ------------------------------  # Date: Sat, 19 Feb 2005 15:37:02 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) + Subject: Re: OpenVMS Small Partner StrategytL Message-ID: <rdeininger-1902051037010001@user-uinj4l7.dialup.mindspring.com>  B In article <1108744009.975338.57300@g14g2000cwa.googlegroups.com>, jordan@ccs4vms.com wrote:    ...   G >I don't see HP even bothering to pay attention to any such suggestion. C >They are just flat NOT INTERESTED in selling VMS into small/medium F >business, and so have no interest in vendors that specialized in that >area. i  D Does HP treat VMS differently than other enterprise products in thisF situation?  (They clearly do have different policies for PCs and other consumer stuff.)  H I'm curious whether this is part of the Great Anti-VMS Conspiracy insideI HP, or just another stupid-seeming policy that is hindering HP's businessf in many areas.  G (I write stupid-seeming, because a sufficiently incompetent bureaucracySH might actually generate enough overhead expenses to make $1 million/yearH in sales the break-even point for HP.  There's a chance that this policyI actually improves HP's bottom line.  Fixing the bureaucracy would be event' better, but maybe they don't know how.)i   ------------------------------  % Date: Sat, 19 Feb 2005 11:24:05 -0500c# From: "John Smith" <a@nonymous.com>i+ Subject: Re: OpenVMS Small Partner Strategy , Message-ID: <QOWdnblFKP209YrfRVn-vA@igs.net>   Robert Deininger wrote:hD > In article <1108744009.975338.57300@g14g2000cwa.googlegroups.com>, > jordan@ccs4vms.com wrote:  >  > ...n >i= >> I don't see HP even bothering to pay attention to any such D >> suggestion. They are just flat NOT INTERESTED in selling VMS intoA >> small/medium business, and so have no interest in vendors thatn >> specialized in that area. > F > Does HP treat VMS differently than other enterprise products in thisH > situation?  (They clearly do have different policies for PCs and other > consumer stuff.) >tC > I'm curious whether this is part of the Great Anti-VMS ConspiracyYD > inside HP, or just another stupid-seeming policy that is hindering > HP's business in many areas. >,= > (I write stupid-seeming, because a sufficiently incompetent F > bureaucracy might actually generate enough overhead expenses to makeB > $1 million/year in sales the break-even point for HP.  There's aE > chance that this policy actually improves HP's bottom line.  Fixing G > the bureaucracy would be even better, but maybe they don't know how.)     H Can't comment on that specifically, but I have seen situations where theK bureaucracy at another organization was 'top heavy' and paper-pushing. WhateL was done in that case was the creation of a small team that basically did an, end-run around the traditional channel maze.  K This was about 3 years ago - they setup a group of about 5 people to managedH all the smaller companies that wanted to push their products, authorizedB virtually anybody who was a real business selling to end-users andJ conversant with the industry at the 'technical' level they needed to be atH in order to successfully sell, offered them prices almost as low (only aJ couple percent different) as the company's biggest distribution customers,I and ran interference for them within the company to break down obstacles.uJ Unit sales increased by about 20% (against a fully-costed expense of aboutH $500,000 p.a. for the 'SWAT' team) as a result because these 'resellers'J were hitting into markets that the vendor wasn't even looking at. ProductsL were equally complicated in their own way as VMS and HW configuration issues	 you have.   H Sorry I can't tell you who they are - I found this out during some other0 work were were doing for this company under NDA.   --- OpenVMS - The classics never go out of style.    ------------------------------  % Date: Sat, 19 Feb 2005 08:40:10 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network> / Subject: Re: Port Print facility Update for I64 1 Message-ID: <r9ydndssp5Eh3IrfRVn-uA@adelphia.com>    David J Dachtera wrote:  > "John E. Malmberg" wrote:R >  >>David J Dachtera wrote:e >> >>J >>>I could use some help trying AEST WRQ's ALPHALK2.EXE (the Alpha-versionE >>>of VAXLINK2). I got an image, but it ACCVIOs when I try to run it.o >>E >>Why not simply compile it?  WRQ does not provide it in binary, theyiF >>provide it in source code, which they download to the host, and then >>they compile it. > C > If you know where to find the source code, please provide a link.d  F Have you tried contacting WRQ support?  They have always been helpful 3 for me.  They need to update their scripts for I64.c  I At my former site, the VAXLINK stuff fell out of use once the PC LAN was nD installed.  The WRQ terminal emulators also include a graphical FTP 6 client as a separate and optionally installed program.   -John  wb8tyw@qsl.network Personal Opinion Onlyg   ------------------------------  % Date: Sat, 19 Feb 2005 11:18:05 -0000s6 From: "Alex Daniels" <AlexNoSpamDaniels@themail.co.uk>) Subject: Re: VMS 8.2 Itanium Distribution 5 Message-ID: <4217206f$0$8745$db0fefd9@news.zen.co.uk>o  ? "David J Dachtera" <djesys.nospam@comcast.net> wrote in message $ news:4216ACBB.56A896E@comcast.net...I > Anyone know if the hobbyist folks have recovered and have done any workT > on a hobbyist kit for I64? >   @ HP answered that question in one of the recent webcast sessions.  * March/April this year was the answer IIRC.   Alex   ------------------------------  # Date: Sat, 19 Feb 2005 15:56:31 GMTs5 From: rdeininger@mindspringdot.com (Robert Deininger) ) Subject: Re: VMS 8.2 Itanium Distribution L Message-ID: <rdeininger-1902051056300001@user-uinj4l7.dialup.mindspring.com>  E In article <1108743749.8025c9a5c7b2d36a5aaf6f3b13db15a0@teranews>, JF$+ Mezei <jfmezei.spamnot@teksavvy.com> wrote:    >Nigel Barker wrote: > G >> It's on DVD for the very good reason that it doesn't fit on a CD. In- fact AFAICR-! >> it wouldn't even fit on 2 CDs.  >-B >I can understand executables bloating from VAX to Alpha since allE >pointers/adresses double in size from 32 to 64 bits, and if you havecD >instructions containing 2 adddresses, that makes things even worse. >eH >But from Alpha to IA64, since both are 64 bits, how come there would be> >so much difference in size between 600meg and over 1200 meg ? > A >Is the bloat due to truly bigger .exe files ? Or are there extra 1 >components bundled into the OS installtion CDs ?   E The Alpha CD is very full.  It takes more effort with each release to H squeeze the essentials onto the disk.  Since DVD is the standard on I64,H there was no good reason to even try to fit on a CD.   Once the line wasG crossed, there was no reason to spend effort trimming down the kit.  Soa@ some of the reason I64 is bigger is just delayed-onset bloating.  I I64 executables are bigger than alpha, but I haven't payed much attentionC@ to the exact ratio.  Since disks are growing so much faster than( executables, it seems to be a non-issue.   ------------------------------  # Date: Sat, 19 Feb 2005 16:01:34 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger)w) Subject: Re: VMS 8.2 Itanium Distribution L Message-ID: <rdeininger-1902051101340001@user-uinj4l7.dialup.mindspring.com>  G In article <cv5uqh01u9k@enews3.newsguy.com>, healyzh@aracnet.com wrote:u  ( >John Reagan <john.reagan@hp.com> wrote:K >> In general images run 2-3 times larger.  A combination of the ELF/DWARF  L >> formats not being as tightly compact and a larger number of instructions K >> (many of which are 'nop's to fill bundles).  In general, you can ZIP an  : >> .EXE file more than you can the source that created it. >_E >> I also think there are other components as well, but I'm not sure.  > H >How does this effect the Memory footprint?  Does this mean you need 2-35 >times as much RAM on Itanium as you did on an Alpha?.  I Dunno the exact ratio.  Since VMS runs on a 64-MB Alpha, and the smallest G HP I64 system available has 512 MB, fitting OS code in memory is not an  interesting problem on I64.   B Code size can still be a performance issue due to memory bandwidthG limitiations.  Memory bandwidth hasn't grown as fast as memory size.  I_I expect there are more importance considerations for performance than code- size.    ------------------------------  % Date: Sat, 19 Feb 2005 09:47:48 -0800a# From: "Tom Linden" <tom@kednos.com> ) Subject: Re: VMS 8.2 Itanium DistributionD( Message-ID: <opsmgg1yuozgicya@hyrrokkin>  4 On Sat, 19 Feb 2005 15:56:31 GMT, Robert Deininger  % <rdeininger@mindspringdot.com> wrote:T  G > The Alpha CD is very full.  It takes more effort with each release to J > squeeze the essentials onto the disk.  Since DVD is the standard on I64,J > there was no good reason to even try to fit on a CD.   Once the line wasI > crossed, there was no reason to spend effort trimming down the kit.  So-B > some of the reason I64 is bigger is just delayed-onset bloating.K > I64 executables are bigger than alpha, but I haven't payed much attention B > to the exact ratio.  Since disks are growing so much faster than* > executables, it seems to be a non-issue.  9 Any chance that we will need DVD HW for Alphas in future?-   -- -C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/R   ------------------------------   End of INFO-VAX 2005.100 ************************