1 INFO-VAX	Sat, 22 Oct 2005	Volume 2005 : Issue 589       Contents:2 Re: "Jumbo Packets" and TCPIP Services for OpenVMS2 Re: "Jumbo Packets" and TCPIP Services for OpenVMS0 Re: Delete/Entry=### fails to stop job execution LIB$WAIT & COBOL/VMS problem) Re: OT: Is your HP printer spying on you? ) Re: OT: Is your HP printer spying on you? < Porting VAX/VMS to 8086 (Was: Re: Porting VMS back to VAX ?) Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ? A RE: UCX performance on VMS 6.2 - Unexpected rise in CPU usage.... A Re: UCX performance on VMS 6.2 - Unexpected rise in CPU usage.... , Re: updated VMS Information (sent yesterday)= Re: Where are text strings in SHOW.EXE? (Technical Question!) = Re: Where are text strings in SHOW.EXE? (Technical Question!)   F ----------------------------------------------------------------------  # Date: Fri, 21 Oct 2005 18:47:05 GMT / From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com> ; Subject: Re: "Jumbo Packets" and TCPIP Services for OpenVMS 8 Message-ID: <JIa6f.90387$7b6.62213@twister.nyroc.rr.com>  3 "Rick Jones" <rick.jones2@hp.com> wrote in message  . news:wES5f.15037$WK5.12044@news.cpqcorp.net...0 > Jeff Goodwin <jgoodwin@maine.rrr-r.com> wrote:F >> Q4. If I turn on jumbo frames, is OpenVMS smart enough to negotiateB >> a smaller frame size when communicating to a peer that does not >> support jumbo frames?   Rick,   L Thanks for the great response.  Since Maximum Segment Size is IP only, does J anyone know if SCS/LAVC negotiates a common frame size when communicating 6 between a Jumbo Frame peer and a non-Jumbo Frame peer?   -Jeff     F > A comment not specific to VMS, but about Jumbo Frames and TCP/UDP in
 > general....  > E > When the two TCP's exchange MSS options, if the other system is not E > using Jumbo Frames, the "typical" MSS will be send and that is what G > the TCP on the Jumbo Frames-enabled system will use.  That is, if the E > other side doesn't also support Jumbo Frames, they will not be used  > and there will be no benefit.  > A > If you are using UDP, there is no exchange and so both ends and : > everything in the middle _MUST_ understand Jumbo Frames. > F > There is another feature of some GbE NICs (no idea if VMS TCP stacksC > support it or not) called "large send" or "TSO" (TCP Segmentation E > Offload).  This can be thought of as "poor man's" Jumbo Frames - in H > this case, TCP is told it can have a virtual MSS up to 64KB or so, andE > it is the NIC that further segments the TCP segment into a suitable F > size.  The frames on the network then look just like they would withG > the standard MTU, and neither the intermediate devices nor the remote F > end system have to have support.  This drops CPU util on the sender,$ > but does nothing for the reciever. > . > Generally, it is not used for UDP, only TCP. >  > rick jones > --  I > oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates H > these opinions are mine, all mine; HP might not want them anyway... :)G > feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...     ------------------------------  # Date: Fri, 21 Oct 2005 22:37:14 GMT % From: Rick Jones <rick.jones2@hp.com> ; Subject: Re: "Jumbo Packets" and TCPIP Services for OpenVMS 4 Message-ID: <u4e6f.15142$sp6.10738@news.cpqcorp.net>  . Jeff Goodwin <jgoodwin@maine.rrr-r.com> wrote: > Rick, ! > Thanks for the great response.     My pleasure.  ' > Since Maximum Segment Size is IP only   F It would be more accurate to say that Maximum Segment Size is TCP only> since the option appears in a TCP header and not an IP header.  B > does anyone know if SCS/LAVC negotiates a common frame size whenF > communicating between a Jumbo Frame peer and a non-Jumbo Frame peer?  F I don't know, but tcpdump might :) Still, with JumboFrame, the generalF expectation is that _everything_ in the same broadcast domain supportsF it, or it should not be enabled (Lest one climb the stairs into a dark@ room and get eaten by a Grue).  That the TCP MSS exchange coversC folks' backsides of in this regard is purely a matter of fortuitous 
 happenstance.   
 rick jones --  H Wisdom Teeth are impacted, people are affected by the effects of events.F these opinions are mine, all mine; HP might not want them anyway... :)D feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   ------------------------------  % Date: Fri, 21 Oct 2005 17:48:05 -0400  From: norm.raphael@metso.com9 Subject: Re: Delete/Entry=### fails to stop job execution Q Message-ID: <OF442BBDC8.4D16B773-ON852570A1.00774648-852570A1.0077D010@metso.com>   + This is a multipart message in MIME format. " --=_alternative 0077D00C852570A1_=, Content-Type: text/plain; charset="US-ASCII"  ? "AEF" <spamsink2001@yahoo.com> wrote on 10/20/2005 11:02:43 AM:    >  > Michael Moroney wrote:$ > > briggs@encompasserve.org writes: > > I > > >I no longer have a VMS system to play around to test this in detail, B > > >but I believe that a queue manager abort is implemented as a 
 SYS$FORCEXC > > >delivered as a user mode AST to the target process with a exit  > > >status of JBC-F-JOBABORT. > > D > > >The effect of this is to run down any currently executing image: > > >so that it terminates with the JBC-F-JOBABORT status. > > E > > >Now, as you have helpfully shown above, this fatal (-F-) status   appears E > > >to be superseded by the DCL-W-SKPDAT code.  So, where DCL would   normallyG > > >have done the default ON ERROR THEN EXIT handling and run down the H > > >current command procedure, the DCL-W-SKPDAT is quietly ignored and  the  > > >procedure continues.  > > I > > >My recollection is that the queue manager gives FORCEX a few seconds I > > >to percolate and then whips out the $DCLPRC hammer to hit the target H > > >batch job with.  If the batch job can complete normally within thatB > > >few second grace period, this would fit the symptoms you see. > > E > > I vaguely remember reading that the queue manager first issues a   $FORCEX,C > > then issues what amounts to a $FORCEX in supervisor mode after   waiting,D > > then again in exec mode before the actual $DELPRC (not $DCLPRC). > > G > > The first will run down an image, but DCL will continue on if there I > > is a $ SET NOON or something (and that forcex will have no effect if   the J > > batch job is in a DCL only loop), the second may behave similarly due  toG > > the way DCL is implemented (except no immunity from being in a DCL   onlyI > > loop), the third is effectively almost as big of a hammer as $DELPRC.  > > J > > >I also recall (albeit less reliably) that if the batch job is runningE > > >purely at DCL level (in Supervisor mode) and not activating any   imagesF > > >then the user mode $FORCEX will be completely ineffective and theJ > > >first thing that impacts the batch job is the $DCLPRC hammer falling. > > F > > No effect to DCL by a user mode $FORCEX, correct.  Not sure if my  memoryH > > is correct that there are more attempts after the first $FORCEX and  the  > > $DELPRC or not.  > : > I was able to reproduce the problem on a VMS 6.2 system: >  > $ TYPE ABORT.COM > $   SET VERIFY > $   SET NOON. > $   DIR/FULL SYS$SYSDEVICE:[*...]/OUTPUT=NL: > IMAGE LINE > IMAGE LINE 2 > $   SHOW SYMBOL $STATUS 
 > $   EXIT >  > $ TYPE ABORT.LOG > $ SET NOVERIFY0 > Running SYLOGIN.COM at 20-OCT-2005 10:56:45.04 > $   SET NOON. > $   DIR/FULL SYS$SYSDEVICE:[*...]/OUTPUT=NL:/ > %JBC-F-JOBABORT, job aborted during execution D > %DCL-W-SKPDAT, image data (records not beginning with "$") ignored > $   SHOW SYMBOL $STATUS  >   $STATUS == "%X00048084" 
 > $   EXIT > ' > Notice that the severity is 4, not 0.  > C > >From the 6.2 release notes (don't know if this has been modified 	 > since):  > * > 4.1.1.1 Terminating Executing Batch Jobs > V6.29 >   Under the following conditions, the DELETE/ENTRY com- 3 >   mand might fail to stop an executing batch job:  >  >  >   . 3 >         The batch job is a DCL command procedure.  >   . 7 >         There is an ON ERROR CONTINUE command (or SET 5 >         NOON command) within the command procedure.  >  > 5 >   The DELETE/ENTRY command causes the job to termi- A >   nate in phases. A delete_process AST routine is given in user ; >   mode, supervisor mode, and then executive mode. Because B >   there is a small delay between each mode, it is possible that,= >   in a batch job, a user-mode image might terminate and the 9 >   command procedure might continue to execute until the ; >   supervisor-mode delete_process AST routine is executed.  >  > 7 >   The return status of the SYNCHRONIZE command is as- ? >   sumed to contain the termination status of the target batch < >   job. In addition, command procedures would normally exe-2 >   cute a command such as $ON ERROR THEN CONTINUE4 >   or $SET NOON before issuing the SYNCHRONIZE com-4 >   mand. If a DELETE/ENTRY command is issued to the4 >   job executing the SYNCHRONIZE command, the JBC$_; >   JOBABORT is interpreted as being the termination status > >   of the target batch job rather than a return status of the3 >   SYNCHRONIZE command. The command procedure then C >   continues to execute for a short period with this incorrect as- < >   sumption and performs an operation such as requeuing theE >   target batch job or incorrectly reporting a failure of the target  >   batch job. >  > 8 >   This problem has been fixed for the SYNCHRONIZE com-; >   mand by detecting this situation and waiting in an exit : >   handler for longer than the delay between the user and& >   supervisor mode termination delay. >  > @ >   Any other images that would report the job completion status6 >   obtained by the SJC$_SYNCHRONIZE_JOB function code= >   of the $SNDJBC system service as the return status of the < >   program should implement logic similar to the following: >  >  >   1. Declare an exit handler: >   2. In the exit handler, implement the following logic:+ >         IF (exit status is JBC$_JOBABORT)  >         THEN >               Wait 10 seconds  >         ENDIF  >  ==> This all seems on the mark, but I wonder what would happen if , the DCL were properly coded with $DECK/$EOD:  ' > 4GL report writer that requires this:  > eg:  $ SET DEFAULT JOBSPACE 	 >      $! 
 >      $ Quiz 
        $ DECK  >        exe PDRM1401_01 >        exe PDRM1401_02        $ EOD	 >      $! . >      $ PRINT PDR1401PRT.LIS /QUEUE=SYSQUEUE1 >      . >      . >      .E > When the Delete/Entry=456 command was entered while the PDRM1401_01 G > module was executing, the following messages were placed into the log / > file and the job continued executing with the  > print statement:   That should eliminate the B %DCL-W-SKPDAT, image data (records not beginning with "$") ignoredH message, but obviously SET ON, etc. is indeed needed to fix the problem." --=_alternative 0077D00C852570A1_=+ Content-Type: text/html; charset="US-ASCII"      <br>I <br><font size=2><tt>&quot;AEF&quot; &lt;spamsink2001@yahoo.com&gt; wrote  on 10/20/2005 11:02:43 AM:<br> <br>	 &gt; <br>  &gt; Michael Moroney wrote:<br> . &gt; &gt; briggs@encompasserve.org writes:<br>
 &gt; &gt;<br> G &gt; &gt; &gt;I no longer have a VMS system to play around to test this  in detail,<br>H &gt; &gt; &gt;but I believe that a queue manager abort is implemented as a SYS$FORCEX<br>G &gt; &gt; &gt;delivered as a user mode AST to the target process with a  exit<br>+ &gt; &gt; &gt;status of JBC-F-JOBABORT.<br> 
 &gt; &gt;<br> G &gt; &gt; &gt;The effect of this is to run down any currently executing 	 image<br> G &gt; &gt; &gt;so that it terminates with the JBC-F-JOBABORT status.<br> 
 &gt; &gt;<br> F &gt; &gt; &gt;Now, as you have helpfully shown above, this fatal (-F-) status appears<br>H &gt; &gt; &gt;to be superseded by the DCL-W-SKPDAT code. &nbsp;So, where DCL would normally<br>G &gt; &gt; &gt;have done the default ON ERROR THEN EXIT handling and run  down the<br>L &gt; &gt; &gt;current command procedure, the DCL-W-SKPDAT is quietly ignored and the<br> & &gt; &gt; &gt;procedure continues.<br>
 &gt; &gt;<br> F &gt; &gt; &gt;My recollection is that the queue manager gives FORCEX a few seconds<br> G &gt; &gt; &gt;to percolate and then whips out the $DCLPRC hammer to hit  the target<br>J &gt; &gt; &gt;batch job with. &nbsp;If the batch job can complete normally within that<br> F &gt; &gt; &gt;few second grace period, this would fit the symptoms you see.<br>
 &gt; &gt;<br> H &gt; &gt; I vaguely remember reading that the queue manager first issues a $FORCEX,<br>H &gt; &gt; then issues what amounts to a $FORCEX in supervisor mode after waiting,<br>N &gt; &gt; then again in exec mode before the actual $DELPRC (not $DCLPRC).<br>
 &gt; &gt;<br> G &gt; &gt; The first will run down an image, but DCL will continue on if 	 there<br> K &gt; &gt; is a $ SET NOON or something (and that forcex will have no effect 
 if the<br>K &gt; &gt; batch job is in a DCL only loop), the second may behave similarly 
 due to<br>F &gt; &gt; the way DCL is implemented (except no immunity from being in a DCL only<br>F &gt; &gt; loop), the third is effectively almost as big of a hammer as $DELPRC.<br>
 &gt; &gt;<br> H &gt; &gt; &gt;I also recall (albeit less reliably) that if the batch job is running<br>I &gt; &gt; &gt;purely at DCL level (in Supervisor mode) and not activating  any images<br>G &gt; &gt; &gt;then the user mode $FORCEX will be completely ineffective  and the<br> J &gt; &gt; &gt;first thing that impacts the batch job is the $DCLPRC hammer falling.<br>
 &gt; &gt;<br> J &gt; &gt; No effect to DCL by a user mode $FORCEX, correct. &nbsp;Not sure if my memory<br>I &gt; &gt; is correct that there are more attempts after the first $FORCEX  and the<br>  &gt; &gt; $DELPRC or not.<br> 	 &gt; <br> A &gt; I was able to reproduce the problem on a VMS 6.2 system:<br> 	 &gt; <br>  &gt; $ TYPE ABORT.COM<br>  &gt; $ &nbsp; SET VERIFY<br> &gt; $ &nbsp; SET NOON<br>: &gt; $ &nbsp; DIR/FULL SYS$SYSDEVICE:[*...]/OUTPUT=NL:<br> &gt; IMAGE LINE<br>  &gt; IMAGE LINE 2<br> % &gt; $ &nbsp; SHOW SYMBOL $STATUS<br>  &gt; $ &nbsp; EXIT<br>	 &gt; <br>  &gt; $ TYPE ABORT.LOG<br>  &gt; $ SET NOVERIFY<br> 7 &gt; Running SYLOGIN.COM at 20-OCT-2005 10:56:45.04<br>  &gt; $ &nbsp; SET NOON<br>: &gt; $ &nbsp; DIR/FULL SYS$SYSDEVICE:[*...]/OUTPUT=NL:<br>6 &gt; %JBC-F-JOBABORT, job aborted during execution<br>I &gt; %DCL-W-SKPDAT, image data (records not beginning with &quot;$&quot;)  ignored<br> % &gt; $ &nbsp; SHOW SYMBOL $STATUS<br> 1 &gt; &nbsp; $STATUS == &quot;%X00048084&quot;<br>  &gt; $ &nbsp; EXIT<br>	 &gt; <br> . &gt; Notice that the severity is 4, not 0.<br>	 &gt; <br> M &gt; &gt;From the 6.2 release notes (don't know if this has been modified<br>  &gt; since):<br>	 &gt; <br> 1 &gt; 4.1.1.1 Terminating Executing Batch Jobs<br> 
 &gt; V6.2<br> E &gt; &nbsp; Under the following conditions, the DELETE/ENTRY com-<br> ? &gt; &nbsp; mand might fail to stop an executing batch job:<br> 	 &gt; <br> 	 &gt; <br>  &gt; &nbsp; .<br> N &gt; &nbsp; &nbsp; &nbsp; &nbsp; The batch job is a DCL command procedure.<br> &gt; &nbsp; .<br> F &gt; &nbsp; &nbsp; &nbsp; &nbsp; There is an ON ERROR CONTINUE command (or SET<br> P &gt; &nbsp; &nbsp; &nbsp; &nbsp; NOON command) within the command procedure.<br>	 &gt; <br> 	 &gt; <br> A &gt; &nbsp; The DELETE/ENTRY command causes the job to termi-<br> M &gt; &nbsp; nate in phases. A delete_process AST routine is given in user<br> G &gt; &nbsp; mode, supervisor mode, and then executive mode. Because<br> N &gt; &nbsp; there is a small delay between each mode, it is possible that,<br>I &gt; &nbsp; in a batch job, a user-mode image might terminate and the<br> E &gt; &nbsp; command procedure might continue to execute until the<br> G &gt; &nbsp; supervisor-mode delete_process AST routine is executed.<br> 	 &gt; <br> 	 &gt; <br> C &gt; &nbsp; The return status of the SYNCHRONIZE command is as-<br> K &gt; &nbsp; sumed to contain the termination status of the target batch<br> H &gt; &nbsp; job. In addition, command procedures would normally exe-<br>> &gt; &nbsp; cute a command such as $ON ERROR THEN CONTINUE<br>@ &gt; &nbsp; or $SET NOON before issuing the SYNCHRONIZE com-<br>@ &gt; &nbsp; mand. If a DELETE/ENTRY command is issued to the<br>@ &gt; &nbsp; job executing the SYNCHRONIZE command, the JBC$_<br>G &gt; &nbsp; JOBABORT is interpreted as being the termination status<br> J &gt; &nbsp; of the target batch job rather than a return status of the<br>? &gt; &nbsp; SYNCHRONIZE command. The command procedure then<br> G &gt; &nbsp; continues to execute for a short period with this incorrect  as-<br> H &gt; &nbsp; sumption and performs an operation such as requeuing the<br>F &gt; &nbsp; target batch job or incorrectly reporting a failure of the
 target<br> &gt; &nbsp; batch job.<br>	 &gt; <br> 	 &gt; <br> D &gt; &nbsp; This problem has been fixed for the SYNCHRONIZE com-<br>G &gt; &nbsp; mand by detecting this situation and waiting in an exit<br> F &gt; &nbsp; handler for longer than the delay between the user and<br>2 &gt; &nbsp; supervisor mode termination delay.<br>	 &gt; <br> 	 &gt; <br> L &gt; &nbsp; Any other images that would report the job completion status<br>B &gt; &nbsp; obtained by the SJC$_SYNCHRONIZE_JOB function code<br>I &gt; &nbsp; of the $SNDJBC system service as the return status of the<br> H &gt; &nbsp; program should implement logic similar to the following:<br>	 &gt; <br> 	 &gt; <br> * &gt; &nbsp; 1. Declare an exit handler<br>F &gt; &nbsp; 2. In the exit handler, implement the following logic:<br>F &gt; &nbsp; &nbsp; &nbsp; &nbsp; IF (exit status is JBC$_JOBABORT)<br>) &gt; &nbsp; &nbsp; &nbsp; &nbsp; THEN<br> I &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Wait 10 seconds<br> * &gt; &nbsp; &nbsp; &nbsp; &nbsp; ENDIF<br>	 &gt; <br>  ==</tt></font>H <br><font size=2><tt>This all seems on the mark, but I wonder what would happen if </tt></font>M <br><font size=2><tt>the DCL were properly coded with $DECK/$EOD:</tt></font>  <br>C <br><font size=2><tt>&gt; 4GL report writer that requires this:<br> ) &gt; eg: &nbsp;$ SET DEFAULT JOBSPACE<br>  &gt; &nbsp; &nbsp; &nbsp;$!<br> + &gt; &nbsp; &nbsp; &nbsp;$ Quiz</tt></font> : <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp;$ DECK<br>3 &gt; &nbsp; &nbsp; &nbsp; &nbsp;exe PDRM1401_01<br> ; &gt; &nbsp; &nbsp; &nbsp; &nbsp;exe PDRM1401_02</tt></font> 9 <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp;$ EOD<br>  &gt; &nbsp; &nbsp; &nbsp;$!<br> D &gt; &nbsp; &nbsp; &nbsp;$ PRINT PDR1401PRT.LIS /QUEUE=SYSQUEUE1<br> &gt; &nbsp; &nbsp; &nbsp;.<br> &gt; &nbsp; &nbsp; &nbsp;.<br> &gt; &nbsp; &nbsp; &nbsp;.<br>L &gt; When the Delete/Entry=456 command was entered while the PDRM1401_01<br>F &gt; module was executing, the following messages were placed into the log<br> 6 &gt; file and the job continued executing with the<br>! &gt; print statement:</tt></font>  <br>; <br><font size=2><tt>That should eliminate the </tt></font> J <br><font size=2><tt>%DCL-W-SKPDAT, image data (records not beginning with" &quot;$&quot;) ignored</tt></font>I <br><font size=2><tt>message, but obviously SET ON, etc. is indeed needed  to fix the problem.</tt></font> $ --=_alternative 0077D00C852570A1_=--   ------------------------------  # Date: Sat, 22 Oct 2005 04:08:56 GMT * From: AlexB <BartonekDragRacing@yahoo.com>% Subject: LIB$WAIT & COBOL/VMS problem 6 Message-ID: <pan.2005.10.22.04.19.22.226327@yahoo.com>  9 May or may not be the proper forum but its worth a shot..   H Currently in my COBOL program I am using the lib$wait routine. Its being= called in block of code that is being run via a perform loop.   I For testing purposes I set the initial wait time to 10 seconds. The first J time the perform loop runs through and hits the LIB$WAIT call it waits forF 10 seconds. If there is no work to do it calls lib$wait but completelyJ skips the 10 second count from then on as if it had met the 10 second wait	 criteria.    Here is my call:B CALL "LIB$WAIT" USING BY REFERENCE duration, libnowake, float-type   duration is set to 10 H libnowake is set to 0 or 1, but I've also substituted 'OMITTED' in place5 of libnowake..none of these values fixed the problem.   E Current versions of software pertinent to this problem: OVMS = 7.3-2,  roll-up patch 4 	 COBOL 2.8  RDB 7.1-411    I thank you'all in advance!    -Alex    ------------------------------  % Date: Sat, 22 Oct 2005 13:15:12 +1300 $ From: "Lurker" <nowhere@nothing.com>2 Subject: Re: OT: Is your HP printer spying on you?3 Message-ID: <Ktf6f.1844$S24.130330@news.xtra.co.nz>   4 "Dave Froble" <davef@tsoft-inc.com> wrote in message* news:11ldj3eh9ao6l2d@corp.supernews.com...  C > I'm also thinking about some of the court decisions RIAA has been 
 > getting.  < You know, it's a bit curious how posters from the US presume< that all the rest of the world knows what the acronims mean.  > Sure, I can Google it and probably find what the heck that one> means but you (and others) seem to use it like a houshold term< which is (by default) known to everyone and everywhere else. Well, sorry mate, it's not.    ------------------------------  % Date: Fri, 21 Oct 2005 21:21:49 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: OT: Is your HP printer spying on you?, Message-ID: <43599422.CD16785B@teksavvy.com>  
 Lurker wrote: > > You know, it's a bit curious how posters from the US presume> > that all the rest of the world knows what the acronims mean.    F RIAA is the Recording Industry Association of America. It includes theF big bad record labels and some of the artists. Its role is to find andG sue individuals who listen to their music on the internet, find ways to D make CDs unusable on a PC to prevent their being listened to and anyG other possible plan that will protect the high price of CDs in stores.      G The RIAA is sinking the same way as Digital: they are refusing to lower : the price of CDs to compete against their new competition.   ------------------------------  % Date: Sat, 22 Oct 2005 10:11:29 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> E Subject: Porting VAX/VMS to 8086 (Was: Re: Porting VMS back to VAX ?) 1 Message-ID: <djc77d$ap3$1@news-02.connect.com.au>    Hi JF,  K Given your passion for native VMS on 8086 are we not missing an opportunity L to think outside the box (rubber-room :-) on this one? Are you not migrating in the wrong direction?   K Given the near 1:1 instuction set match between the 8086 and VAX assemblers I (I have no idea how close they really are but to the casual observer they I both quack-like-a-duck.  Anyway, that's what John Reagan's for), would it J not be better (cheaper and easier!) to port *VAX*/VMS to 8086 and then addJ the 64-bit VLM extensions? The new features that made it to Alpha and then> I64 could subsequently be rolled-out, once more, with a provenL upgrade/modification path, at engineering's leisure. (The OPCODE translationI tables must readily exists for all these emulators to function as well as 	 they do!)   J The *best* thing would be that we get rid of all that crap C code that hasF been shoe-horned into the lovely VMS development environment all theseE years!!! No more EPIC "re-compile all the time", "more memory", "more G instructions", "over-engineered pipelining, out-of-sequence", "socially L inept" compilers! Stop trying to think up more ways to stick more valves andL more engineering into that 2.0 litre dynamo, just go for the 6.0 litre grunt- of that super-charged V8 and be done with it!   L Yes JF, what they're all wispering about in corridors *is* a covert project!C And that project name is "Exodus". (Well you can only has sooo many F "Genusussss" :-) Get your free copy of Bliss-86 now and start porting!   Regards Richard Maher.  K PS. I drive a 1.8 litre ford that let's me go as fast as the Nanny-State of K WA will let me. And my next Hi-Octane move will be to the Toyota Tarago (or C Crysler Grand-Voyager) but I do admire those who find beauty in the K simplicity of the Holden Monaro (and who doesn't think the (FJ) efijy would . sell like hot-cakes if they mass-produced it?)    : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:435171A8.66340643@teksavvy.com...F > Ok, putting all management and business issues aside for a moment... > G > Much has been said about VMS having gotten a good cleanup when ported J > from Alpha to IA64 and making possible common code bases across multiple
 platforms. > F > Much has been said about VAX not having the same code base as Alpha. >  > G > How difficult would it be to "port" VMS back to VAX and have it share H > the same code base as Alpha/IA64 ?  They could re-use the VAX specificF > code and integrate it into the source code management system right ? > H > How much of the VMS code is 64 bit specific that would require lots ofI > changes to run on a 32 bit entity such as VAX ? Or is a large amount of F > code written in such a way that it can easily be compiled for 32 bit > architecture (aka VAX) ? > C > For instance, would ODS5 compile easily for VAX, or would it be a G > nighmare because there are so many assumptions that it will run in 64  > bit environment ?    ------------------------------  % Date: Fri, 21 Oct 2005 18:39:52 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> & Subject: Re: Porting VMS back to VAX ?: Message-ID: <A6e6f.22176$GH1.585895@news20.bellglobal.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:43585FE4.623CF304@teksavvy.com... > Neil Rieck wrote: H >> Simplifying CPU design allowed for the development of some other coolG >> features like out-of-order execution, speculative execution, etc. A   >> Motorola C >> engineer told be that RISC didn't mean "Reduced Instruction Set  
 >> Computing" 6 >> it meant "Relegate Important Stuff to the Compiler" >  > G > You described some complexity in CISC that made RISC better. However, F > were those unique to VAX or were they truly widespread in other CISCE > architectures ? Seems most other CISC were *much* simpler than VAX.  >   I The real complicated instructions were more common in VAX (you never saw  J instructions like that on PDP). But both VAX and PDP had some complicated E addressing modes (PDP-11 had a total of 7 addressing modes if memory  H serves). To do certain CISC style addressing in Alpha requires multiple L instructions but at least the processor can be more easily interrupted etc. M Alpha really is running micro-code out of RAM when seen from a CISC point of  > view and the much larger image size is proof of that argument.   > D > When you look at the fact that Intel implemented many stolen AlphaF > features into its pentium 3 (and now does it freely), it seems to meG > that many RISC tricks are also applicable to some CISC architectures.  > E > And since the 8086 has matured into a very respectable chip that is G > right up there in terms of performance, isn't that a proof that it is . > possible to make CISC compete against RISC ? >   L The question here should be "is P4 still a RISC machine"? Intel doubled the K clock requirement when moving from P3 so that a P4 running a 1.5 GHz clock  M was required in order to do the same amount of work as a P3 running 750 MHz.  H And what about all those MMX instructions? Intel called it SIMD (single L instruction multiple data) but that sounds suspiciously similar to the POLY I instruction found inside VAX. Nope, the P4 is only a RISC machine if you  I decide not to use the CISC instructions. It's all in the marketecture :-)    > G > Was it just VAX that was just so complex that it couldn't get all the  > performance tricks ? >   L IMHO the chip heads just had to go to a reduced (simple) instruction set to K be able to do all the other cool things like Speculative Execution, Out Of  K Order Execution etc. As I said in a previous post, I wasn't a RISC convert  F at the time but I've seen the light and don't want to go back to CISC.    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Fri, 21 Oct 2005 18:52:04 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> & Subject: Re: Porting VMS back to VAX ?: Message-ID: <%he6f.22180$GH1.586498@news20.bellglobal.com>  6 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message % news:3rs7mtFl3t78U1@individual.net... . > In article <43585FE4.623CF304@teksavvy.com>,1 > JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>H >> Was it just VAX that was just so complex that it couldn't get all the >> performance tricks ?  > H > What RISC "performance tricks" do you think the VAX needed?  Just likeF > the Alpha is still holding it's own against EPIC so too, the VAX wasG > holding it's own agains RISC until serious development on the VAX was G > stopped.  There is no real reason to believe that if it had continued G > til today that the VAX wouldn't still be a performance leader in it's 9 > genre. (Which does not include laptops, in my opinion.)  > I I've seen some interesting optimizations in the Alpha language compilers  H which, if applied to VAX, would have made the VAX machines run somewhat L faster. But there were other DEC benchmarks which proved that Alpha was one K (or more) orders of magnitude faster than VAX. Whenever someone offers you  M an "order of magnitude" increase in speed and has also dropped you've got to  
 go for it.  C http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html#vax_vs_alpha     
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Fri, 21 Oct 2005 14:58:46 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> J Subject: RE: UCX performance on VMS 6.2 - Unexpected rise in CPU usage....R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB70C64A@tayexc19.americas.cpqcorp.net>   > -----Original Message-----2 > From: Lawrie [mailto:stroker_ace@hotmail.com]=20  > Sent: October 21, 2005 4:00 AM > To: Info-VAX@Mvb.Saic.Com A > Subject: Re: UCX performance on VMS 6.2 - Unexpected rise in=20  > CPU usage....  >=20H > The overhead is not necessarily a problem, I am just a little suprisedE > by the rise in CPU, from 1%-5% cpu using blocking QIO writes over a = > 19.2K asynch serial link to 4%-10% CPU using multiplexed=20  > TCP/IP sockets > and 10 Meg ethernet. >=20H > At some point in the future we will be upgrading our version of VMS toG > 7.2 and running on a much faster machine so this is unlikely to be an  > issue. >=20	 > Regards  >=20 > Lawrie >=20   Laurie,   ? Did you mean to say you were planning to upgrade to VMS v7.3-2?   = V7.2 is about 5 years old and there has been many performance  enhancements since that time.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  # Date: Sat, 22 Oct 2005 00:04:30 GMT # From: Beach Runner <bob@nospam.com> J Subject: Re: UCX performance on VMS 6.2 - Unexpected rise in CPU usage....< Message-ID: <imf6f.163890$xl6.46763@tornado.tampabay.rr.com>  I 6.2 is  around 1995.  However there is a DEC THREAD ECO you should check   if it's installed.   Main, Kerry wrote: >>-----Original Message-----0 >>From: Lawrie [mailto:stroker_ace@hotmail.com]   >>Sent: October 21, 2005 4:00 AM >>To: Info-VAX@Mvb.Saic.Com ? >>Subject: Re: UCX performance on VMS 6.2 - Unexpected rise in   >>CPU usage....  >>H >>The overhead is not necessarily a problem, I am just a little suprisedE >>by the rise in CPU, from 1%-5% cpu using blocking QIO writes over a ; >>19.2K asynch serial link to 4%-10% CPU using multiplexed   >>TCP/IP sockets >>and 10 Meg ethernet. >>H >>At some point in the future we will be upgrading our version of VMS toG >>7.2 and running on a much faster machine so this is unlikely to be an  >>issue. >>	 >>Regards  >> >>Lawrie >> >  > 	 > Laurie,  > A > Did you mean to say you were planning to upgrade to VMS v7.3-2?  > ? > V7.2 is about 5 years old and there has been many performance  > enhancements since that time.  > 	 > Regards  >  > Kerry Main > Senior Consultant  > HP Services Canada > Voice: 613-592-4660  > Fax: 613-591-4477  > kerryDOTmainAThpDOTcom > (remove the DOT's and AT)  > 6 > OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Sat, 22 Oct 2005 11:59:51 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 5 Subject: Re: updated VMS Information (sent yesterday) 1 Message-ID: <djcdij$j0g$1@news-02.connect.com.au>    Hi,   F > HP has announced availability of Web Service Integration Toolkit for > OpenVMS (WSIT) version 1.0  I First is was ONC/RPC, then DCE/RPC then COM then Bridgeworks and now it's C WSIT - Just how many "Tools for porting our legacy COBOL, BASIC etc C customers to newer technologies" are you blokes gonna come up with?   F Where is Kerry Main??? Presumably Kerry, the necessity to produce realJ customer requirements before HP project funding is approved does not applyJ to those in charge of the Crystal Ball. But obviously we're all riding theI crest of technological innovation and the money that's been squandered on G these many disasters is just a natural progression on someone's path to  enlightenment?  J C'mon Kerry, how much has been spent on WSIT and for what return? Will youJ now continue to pour money into the Bridgeworks sewer and has that projectD manager had their arsed kick out of HP? How many customers are using9 Bridgeworks/ (After how many years and how many dollars?)   & Aaargh, if you didn't laugh you'd cry.   Regards Richard Maher   . <susan_skonetski@hotmail.com> wrote in message= news:1129770161.487022.235110@z14g2000cwz.googlegroups.com...  >  > Dear distribution lists, > F > As you can tell I am back in my office after a wonderful three weeksD > doing the European OpenVMS Technical Update Days.  This message ofG > updated VMS information is long and please keep in mind that urls can D > and do wrap to the next line, they all work I have tried them all. > G > Sorry about this size of this, but its better than sending individual  > email messages.  > H > Reminder where the jobs are concerned I have nothing to do with hiring	 > anyone.  >  > Warm Regards as always,  > Sue  >  >  >  > Table of Contents  > , > Asia Pacific OpenVMS Technical Update days > ANNOUNCEMENTS C > The HP DECset V12.7 product release is now shipping to customers! 1 > availability of Web Service Integration Toolkik  > Reminders  > VMS MENTIONS IN THE PRESS G > NOW AVAILABLE for the French and Italian VMS readers in our community  > COOL WEB SITES - my favorites  > EVENTS  > New Feature - "It is Personal"! > Jobs - there is a bunch of them  >  > K ___________________________________________________________________________ D > Asia Pacific OpenVMS Technical Update Days still to come - see you > there 3 > Sydney Nov 3-4 http://www.hp.com.au/ovmstechdays/ 7 > Melbourne Nov 8-9, http://www.hp.com.au/ovmstechdays/  > Singapore Nov 14-15 7 > http://h50055.www5.hp.com/edm/sg/SG543010/default.htm  > Taiwan Nov 17-18B > http://218.32.200.131/enterprise/activity/051117_VMs/default.asp >  > L ____________________________________________________________________________ ___  > ANNOUNCEMENTS  >  > C > The HP DECset V12.7 product release is now shipping to customers!  > I > HP DECset version 12.7 for OpenVMS on HP Integrity servers, AlphaServer H > systems, and VAX systems is now available. HP DECset is a powerful setC > of command-line oriented development tools to be used with the HP @ > OpenVMS compilers to aid developers in editing, compiling, andA > debugging their code. HP DECset supports multiple languages and G > improves software development productivity. Language Sensitive Editor 9 > (LSE) support for JAVA and HTML is new in DECset V12.7.  > ' > For more information on DECset visit: ? > http://h71000.www7.hp.com/commercial/decset/decset_index.html 4 > http://h18000.www1.hp.com/info/SP4229/SP4229PF.PDF4 > http://h18000.www1.hp.com/info/SP2707/SP2707PF.PDF@ > -------------------------------------------------------------- > F > HP has announced availability of Web Service Integration Toolkit forE > OpenVMS (WSIT) version 1.0 for HP Integrity servers and AlphaServer G > systems.  WSIT is a collection of easy-to-use integration tools which D > are highly extensible, based on standards and built on open sourceC > technology.  The toolkit can be used to call OpenVMS applications H > written in 3GL languages, such as C, BASIC, COBOL, and ACMS from newerE > technologies and languages such as Java, Microsoft .NET, Java -RMI, E > JMS, and web services.  To learn more or to download, please visit: @ > http://h71000.www7.hp.com/openvms/products/ips/wsit/index.html >  >  > = > ___________________________________________________________  > Reminders  > 9 > Articles for the Technical Journal are due November 15.  > I > If you have anyone that would like to sign up for the VMS interest list  > just have them send me email > / > New HP-Interex Belux web server in production  > "http://www.hp-interex.be" > , > Here is the latest issue of Customer Times > L "http://www.hp.com/products1/evolution/customertimes/index.html?jumpid=em_CT	 jun05_hm"  > __________________________ >  > VMS MENTIONS IN THE PRESS  > % > HP expands virtualization offerings  > L "http://searchopensource.techtarget.com/originalContent/0,289142,sid39_gci11 25028,00.html" > ' > Computerworld Article from Tech Forum  > L "http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,105503,0 0.html"  > F > Stop Arguing About Cars and Start Managing Fleets (this one compares > VMS to being just like UNIX)6 > "http://www.itjungle.com/tfh/tfh101705-story04.html" > F > IBM User Group President Warns Of IT Personnel Shortage (I like this > one) > L "http://www.informationweek.com/story/showArticle.jhtml?articleID=171204068" > F > its an interview with the Samba team lead and he does mention VMS as > one of the > target platforms > L "http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1127 053,00.html" >  > L ****************************************************************************
 ********** > G > NOW AVAILABLE for the French and Italian VMS readers in our community  > 2 > Italian OpenVMS.Org site - http://it.openvms.org1 > French OpenVMS.Org site - http://fr.OpenVMS.Org  >  > L **************************************************************************** ***********  >  > COOL WEB SITES - my favorites  >  > OpenVMS ebusiness information 5 > http://h71000.www7.hp.com/ebusiness/technology.html  > 8 > THIS IS VERY COOL LOOK AT THIS - Molecular expressionsA > http://microscopy.fsu.edu/wallpaper/macpaper/chipshots/dec.html  > ! > _______________________________  > EVENTS > H > OpenVMS Technical Update Days, Sydney Nov 3-4 and Melbourne Nov - 8-9,$ > http://www.hp.com.au/ovmstechdays/* > Montreal Canada Technical Seminar Oct 27- > http://www.encompasscanada.com/seminars.htm * > Edmonton Canada Technical Seminar Oct 31- > http://www.encompasscanada.com/seminars.htm  > + > _________________________________________  >  > F > New Feature - Each week I am going to add something personal about aD > VMS user/customer/engineer as long as I get the information. It is% > Personal -----Original Message----- 9 > From: Colin Butcher [mailto:colin.butcher@xdelta.co.uk] ) > Sent: Tuesday, October 04, 2005 5:33 PM  > To: Colin Butcher - > Subject: My brother's golf course and range  >  > G > I know that I've told some of you about this and that you'd asked for E > more information if you were over this way. If it's not of interest  > then please ignore it. > G > If you're in the Edinburgh area and are interested in golf (I'm not!) G > then you might find this of use: http://www.kings-acregolf.com/2.html E > Apparently they'll also put together "day packages" for conferences ! > etc. if you'd find that of use.  > C > Claude Harmon is Butch Harmon's son (Butch is the coach for Tiger H > Woods). Ian knows him well and persuaded him to join him at Kings Acre > working with Alan. > " > It's supposed to be pretty good. >    ------------------------------    Date: 21 Oct 2005 10:57:01 -0700$ From: "AEF" <spamsink2001@yahoo.com>F Subject: Re: Where are text strings in SHOW.EXE? (Technical Question!)C Message-ID: <1129917421.823836.110660@g44g2000cwa.googlegroups.com>    Hoff Hoffman wrote: l > In article <1129818989.302315.301510@g47g2000cwa.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes:C > :So what changed from 6.1 to 6.2? Where does SHOW.EXE in v6.2 get ) > :strings like "Bad Pages" and the like?  >  >   From the message file.     Thanks!      >   What are you up to?     $ Curiosity and a little practicality.   Here's the motivation:  > I manage 35 VAX systems. Every morning I do a morning check. IB submit/remote a command procedure on each node that collects vitalB statistics like SHOW DEV D, SHOW MEMORY, SHOW SYSTEM, etc. Then myG local command procedure collects all the resultant log files and copies D them together into one big file called ALL.OUT. I search ALL.OUT for@ various things to make a quick "health check" of my systems. ForF example, I search for "Uptime" to see if anything has rebooted withoutD warning and to check that the system times are reasonably in sync. IE search for "mou" to check disk space. I search for RW,FP,BAD to check G for RWxxx states, FPx states, and bad pages. And I do other searches of A ALL.OUT to check various other things. I also run READ-ALL.COM to D gather SHOW ERROR outputs and DIFF them so I can see what new errorsD have popped up. Usually there is nothing important that comes up for that.   G Now, I remember that long, long ago at a different job with another VAX D system I saw SHOW MEMORY produce a "Bad Pages" display, but I didn'tD remember whether it said "bad pages" or "invalid pages" or somethingD else. Now this doesn't normally show up in SHOW MEMORY output unlessD one actualy HAS bad pages. And since I don't have any bad pages, andD don't know how to make some test bad pages, I endeavored to find outG what the heading for "bad pages" is for VMS 6.1 and 6.2. I searched the F archives of comp.os.vms and found a post with "BAD PAGES" in it and itB was v6.2, which I am running on some of the systems. Hurray! So, ID thought: Why not search SHOW.EXE and see if "Bad Pages" is there. OnD 6.1 systems it was and on 6.2 systems it wasn't. So, I then thought:G How does the 6.2 SHOW.EXE get this string? Is it in another file? Is it * encoded or compressed somehow? So I asked.  B Suggestions for improving my morning check are welcome. NOTE: I amF constrained by management so I can't spend a very large amount of time or money on improving this.    > L >   (Parsing the text output of commands is not considered supported, FWIW.)   Understood.    ------------------------------  # Date: Fri, 21 Oct 2005 18:56:56 GMT # From: hoff@hp.nospam (Hoff Hoffman) F Subject: Re: Where are text strings in SHOW.EXE? (Technical Question!)3 Message-ID: <YRa6f.15130$In6.9209@news.cpqcorp.net>   j In article <1129917421.823836.110660@g44g2000cwa.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes: ..  E   You can pick off many of the target values using lexical functions, F   such as f$getsyi("BOOTTIME").  Stuff -- like some of the error count7   values -- can be slightly tougher to locate directly.   E   But if you're happy with what you've got, and you don't mind having D   to find and fix it occasionally; as displays are changed around...  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------   End of INFO-VAX 2005.589 ************************