1 INFO-VAX	Thu, 07 Sep 2006	Volume 2006 : Issue 490       Contents:# Re: All is not well at the HP board # Re: All is not well at the HP board # Re: All is not well at the HP board  Re: Announcment from Bruden  Re: Authoring Tool for OpenVMS Re: Authoring Tool for OpenVMS/ Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode ( Re: Changes to OpenVMS Patch Kit Formats3 Re: Confusing behaviour of local and global symbols 3 Re: Confusing behaviour of local and global symbols 3 Re: Confusing behaviour of local and global symbols 3 Re: Confusing behaviour of local and global symbols 3 Re: Confusing behaviour of local and global symbols 3 Re: Confusing behaviour of local and global symbols  Creating a HDLC CRC?A Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL A Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL A Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL ' Re: Heads Up:  Intel to axe 20,000 jobs C Re: Please Loot the Inforamtion/Mainframe Material  at "MFRESOURCE" 4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC. VMS MAIL:  Will it ever join the 21st century?2 Re: VMS MAIL:  Will it ever join the 21st century?2 Re: VMS MAIL:  Will it ever join the 21st century?1 Re: Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX) 1 Re: Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX)  RE: What is PSDC Re: [VMS V7.3-2] ECO date  Re: [VMS V7.3-2] ECO date  Re: [VMS V7.3-2] ECO date  Re: [VMS V7.3-2] ECO date  Re: [VMS V7.3-2] ECO date   F ----------------------------------------------------------------------  % Date: Wed, 06 Sep 2006 18:51:49 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> , Subject: Re: All is not well at the HP board, Message-ID: <44FF50F3.D7B3141E@teksavvy.com>   More news today on this issue:  o http://news.com.com/SEC+filing+acknowledges+pretexting+in+HP+board+probe/2100-1014_3-6112710.html?tag=nefd.lede   G I won't comment in order to prevent personal attacks hijack this topic.    ------------------------------  % Date: Wed, 06 Sep 2006 19:53:07 -0400 ( From: Bill Todd <billtodd@metrocast.net>, Subject: Re: All is not well at the HP boardG Message-ID: <VrKdnXItFOz-wmLZnZ2dnUVZ_qGdnZ2d@metrocastcablevision.com>    JF Mezei wrote:   > More news today on this issue: > q > http://news.com.com/SEC+filing+acknowledges+pretexting+in+HP+board+probe/2100-1014_3-6112710.html?tag=nefd.lede  > I > I won't comment in order to prevent personal attacks hijack this topic.   F Funny - the entirely justified comments I made earlier didn't seem to H have hijacked the topic at all.  In fact, people chose to respond to my F own post rather than to your original post, and didn't take any issue : with the comments I made about your personal deficiencies.  F As for the new material that you just presented (perhaps just as well G without comment, given that you don't appear to have incorporated your  G earlier gaffes into your psyche), Perkins' substantiating post-meeting  E documents plus the new weasel-worded HP SEC filing suggest that it's  D time for some serious shit to hit the BoD (and I hope that it does).   - bill   ------------------------------  % Date: Thu, 07 Sep 2006 00:29:08 -0400 ' From: Dave Froble <davef@tsoft-inc.com> , Subject: Re: All is not well at the HP board9 Message-ID: <_4ydnR5-aqCkA2LZnZ2dnUVZ_qOdnZ2d@libcom.com>    David Mathog wrote:  > Michael D. Ober wrote: > > >> In addition, if the State of California discovers that the J >> investigator who obtained the phone records violated the law, Pat Dunn I >> should be charged as well (at least as an accessory) since she is the  % >> person who hired the investigator.  > E > According to one article I read the phone records were obtained by  E > "pretexting" == pretending to be somebody else.  The person who did D > this provided the last 4 digits of the director's social security B > number.  Since HP pays the directors it must be in possession of? > these magic SS digits.  If the "pretexter" obtained them from @ > HP all hell is going to break loose and one or more people are9 > going to jail. Deservedly so.  This also would give the * > outed director grounds for a civil suit. > B > The world being what it is though the "pretexter" may have just B > purchased this information from Choicepoint or one of the other G > companies that traffic in personal information.  If so, he/she better  > have saved the receipt.   H Don't know anything about Choicepoint and other similar companies, (and B maybe I should be rectifying that lack of knowledge), but if such G personal data is so easily obtained, then me thinks there is some much   needed new privacy legislation.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 06 Sep 2006 10:02:26 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>$ Subject: Re: Announcment from Bruden* Message-ID: <44fed4e3@usenet01.boi.hp.com>   JF Mezei wrote:  > Sue wrote:I >> BRUDEN Corporation announces a name change.  Starting on 9/5/06 BRUDEN D >> Corporation will be operating as BRUDEN-OSSG, the BRUDEN On-Shore >> Systems Group.  ... 0 > I take it the name change is a PR exercise ...  C    There is some humor buried within the announcement and the name.   C    As for the intent, you'll want to direct that to the principals.    ------------------------------   Date: 6 Sep 2006 21:52:36 GMT  From: healyzh@aracnet.com ' Subject: Re: Authoring Tool for OpenVMS , Message-ID: <ednfv401ih9@enews2.newsguy.com>  - Hoff Hoffman <hoff-remove-this@hp.com> wrote: E >    The tool running on another of the various HP platforms that the D > writing group uses, and the tool the group is using is not (AFAIK) > operating on OpenVMS.   K I should have rather guessed this was the case, but was hoping differently.   K >    As for SGML, few folks actually want to work with SGML, as it's rather L > too gonzo for most mere mortals.  Most folks work with a subset of it (eg: > XHTML), or a variant (SDML).  J >    I'd look at a docbook port or such, if you want a tool running native >    on OpenVMS.  K Without a doubt, docbook is *exactly* what I want.  However, to the best of K my knowledge, docbook hasn't been ported, and I've been keeping my eyes out  for a port.   H >    I don't know of anything other than Touch DOCUMENT and RUNOFF (DSR,J > DSR-Plus) that include converters that can generate the OpenVMS-specificL > file formats, for those constructs like the help libraries.  (DSR-Plus wasL > on a Freeware a distro or two back, IIRC, and RUNOFF (DSR) is still latent > in OpenVMS.)  C I'm looking for a solution that will output to plain Text, HTML, or F Postscript.  It needs to be like SDML/SGML/HTML/TeX in that the sourceG document is plain text, so that a script can easily generate the source  docment.  L RUNOFF doesn't appear to be the right choice, and DSR-Plus appears to be VAXJ only.  Touch DOCUMENT would be a very good choice if I had faith about itsL continued existance, but since I haven't seen any sign of it being ported to! Itanium, I don't have much faith.   L I might end up just end up writting my own abstraction layer that outputs toE SDML, TeX, or HTML.  My needs are pretty basic, and this might be the  easiest solution.    		Zane   ------------------------------  # Date: Wed, 06 Sep 2006 22:28:07 GMT 7 From: John Malmberg <malmberg@dskwld.zko.hp.compaq.dec> ' Subject: Re: Authoring Tool for OpenVMS . Message-ID: <XXHLg.54$3n5.37@news.cpqcorp.net>   healyzh@aracnet.com wrote: > M > Without a doubt, docbook is *exactly* what I want.  However, to the best of M > my knowledge, docbook hasn't been ported, and I've been keeping my eyes out 
 > for a port.   D  From a brief look at docbook, it appears to mainly a collection of B templates and scripts that invoke the programs that do the actual  document formatting.  C I recall seeing older ports to OpenVMS of several of the supported  G document formatters, such as TEX and LATEX, and I am not sure how much   they have changed since then.    http://www.docbook.org9 http://en.tldp.org/HOWTO/mini/DocBook-Install/using.html.    -John ! malmberg@dskwld.zko.hp.compaq.dec  Personal Opinion Only    ------------------------------  $ Date: Thu, 7 Sep 2006 07:06:29 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 8 Subject: Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode1 Message-ID: <ednk3q$ar5$1@news-02.connect.com.au>    Hi,   J FYI, If you forget to terminate the itemlist to $audit_event you can crash' your system. Several times actually :-(   I My Tier3 code has nsa$_chain codes to addition lists depending on whether I the client transport was Decnet or TCP/IP but as I'm cobbling together an K authentication server that a couple of people have asked for, I dropped the E transport lists but forgot to terminate the original list with a zero 	 longword.   I I can't tell you if it let's an unpriviliged user do this 'cos the server H image is installed with oodles of privileges and I've wasted enough timeJ tracking it down already. Hopefully it checks to see if you have some type/ of privilege (Audit?) before crashing your box.   G And these people have the nerve to even look me in the face? Disbelief!    Regards Richard Maher    ------------------------------   Date: 6 Sep 2006 23:06:18 -0200 6 From: eplan@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)1 Subject: Re: Changes to OpenVMS Patch Kit Formats , Message-ID: <44ff546a$1@news.langstoeger.at>   In article <1157562348.113817.67600@m79g2000cwm.googlegroups.com>, "george.pagliarulo@hp.com" <george.pagliarulo@hp.com> writes:E >To reiterate,  the only VMS patch kits that will be digitally signed F >are V8.3 and later kits.  Kits for versions prior to V8.3 will not beH >signed.  The reason for shipping PCSI$COMPRESSED kits for those earlierF >versions is so that we can standardize on one packaging format across >all supported versions.   ...except OpenVAX   B (until a newer PCSI utility/ECO comes out for OpenVMS VAX V7.3 andC OpenVMS VAX V7.3 ECOs are then in PCSI instead of VMSINSTAL format)    SCNR   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 6 Sep 2006 11:05:46 -0700 - From: "Doug Phillips" <dphill46@netscape.net> < Subject: Re: Confusing behaviour of local and global symbolsC Message-ID: <1157565946.551713.230340@b28g2000cwb.googlegroups.com>    hanblo {at} netscape.net wrote:  > Hello,I > I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour " > when it comes to symbolhandling.   Something does seem wrong.   $HELP SHOW SYMBOL EXAMPLE says:    ##" "... The command interpreter first> searches the local symbol table for the current command level,: then local symbol tables for preceding command levels, and& finally the global symbol table.  ..." ##   > Two commandprocdures:  >  > CP_1:  > $  DBA = " > $  @CP_2 "" -uusername	 > $  exit  >  > CP_2: ) > $  DBA == F$edit(P2, "TRIM, LOWERCASE")  > $  show symbol DBA*   F This displays the Global value "-uusername", but it should display the! preceding level local, "1_L_SYMB"    > $  show symbol/global DBA* > $!4 > $! Next command says undefined symbol, check...... > $! > $  show symbol/local DBA*  > $! > $! Next command gives me "1_"  > $!    E The first time I run this, it returns "" (null), then subsequent runs  return "1_"     / > $  write sys$output "''F$extract(0, 2, DBA)'"  > $! > $! and of course this is true  > $!H > $  if F$extract(0, 2, DBA) .nes. "-u" then write sys$output "No match"	 > $  exit  >  > Question: H > Shouldn't show symbol/local and F$extract work against the same symbolD > table (or actually do the same search through the local and global > symboltables)? >   8 The /LOCAL limits the search to the current level local.  E Maybe you mean "Shouldn't SHOW SYMBOL and F$EXTRACT, along with other D unqualified symbol translations, search the same way and in the same0 order?" That seems like a resonable expectation.   ------------------------------   Date: 6 Sep 2006 13:54:41 -0500  From: briggs@encompasserve.org< Subject: Re: Confusing behaviour of local and global symbols3 Message-ID: <YJG2siJ4bu+I@eisner.encompasserve.org>   s In article <1157565946.551713.230340@b28g2000cwb.googlegroups.com>, "Doug Phillips" <dphill46@netscape.net> writes: ! > hanblo {at} netscape.net wrote: 	 >> Hello, J >> I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour# >> when it comes to symbolhandling.  >  > Something does seem wrong. > ! > $HELP SHOW SYMBOL EXAMPLE says:  >  > ##$ > "... The command interpreter first@ > searches the local symbol table for the current command level,< > then local symbol tables for preceding command levels, and( > finally the global symbol table.  ..." > ## >  >> Two commandprocdures: >> >> CP_1:
 >> $  DBA = "  >> $  @CP_2 "" -uusername 
 >> $  exit >> >> CP_2:* >> $  DBA == F$edit(P2, "TRIM, LOWERCASE") >> $  show symbol DBA* > H > This displays the Global value "-uusername", but it should display the# > preceding level local, "1_L_SYMB"   = You are absolutely right.  And my previous posting was wrong.   A When used with a wildcard, SHOW SYMBOL appears to search only the - innermost local and the global symbol tables.   @ When used without a wildcard, SHOW SYMBOL searches all tables as documented.      Demonstration...  
 $! cp0.com $ xx = "level 0" $ @cp1 $ exit  
 $! cp1.com $ xx = "level 1" $ @cp2 $ exit  
 $! cp2.com $ E $ ! no local definition, no global definition, no answer for wildcard  $ show sym xx* $ E $ ! no local definition, no global definition, innermost answer shown 
 $ show sym xx  $ D $ ! no local definition, no global definition, innermost answer used $ write sys$output "xx is ", xx  $ K $ ! local definition, no global definition, local answer shown for wildcard  $ xx = "level 2" $ show sym xx* $ > $ ! local definition, no global definition, local answer shown
 $ show sym xx  $ = $ ! local definition, no global definition, local answer used  $ write sys$output "xx is ", xx  $ 6 $ ! no local, global, global answer shown for wildcard $ delete /symbol xx  $ xx == "global" $ show sym xx* $ , $ ! no local, global, innermost answer shown
 $ show sym xx  $ 6 $ ! no local, global definition, innermost answer used $ write sys$output "xx is ", xx  $ : $ ! both local and global, both answers shown for wildcard $ xx = "level 2" $ show sym xx* $ - $ ! both local and global, local answer shown 
 $ show sym xx  $ , $ ! both local and global, local answer used $ write sys$output "xx is ", xx  $  $ delete /symbol /global xx  $ exit  D I suggest running this with $ SET VERIFY to confirm that the answersG are as indicated in the comments.  Don't trust me -- I've already blown  it once on this thread.   @ Without the wildcard, SHOW SYMBOL matches the default DCL symbol lookup search order properly.    ------------------------------  % Date: Wed, 06 Sep 2006 21:35:57 +0200 ' From: Hans Blom <hans.y.blom@telia.com> < Subject: Re: Confusing behaviour of local and global symbols9 Message-ID: <44ff2218$0$19260$88260bb3@news.teranews.com>    Hans Blom wrote:! > hanblo {at} netscape.net wrote: 	 >> Hello, J >> I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour# >> when it comes to symbolhandling.  >> Two commandprocdures: >> >> CP_1: >> $  DBA = "1_L_SYMB" >> $  @CP_2 "" -uusername 
 >> $  exit >> >> CP_2:* >> $  DBA == F$edit(P2, "TRIM, LOWERCASE") >> $  show symbol DBA* >> $  show symbol/global DBA*  >> $! 5 >> $! Next command says undefined symbol, check......  >> $!  >> $  show symbol/local DBA* >> $!   >> $! Next command gives me "1_" >> $! 0 >> $  write sys$output "''F$extract(0, 2, DBA)'" >> $!   >> $! and of course this is true >> $! I >> $  if F$extract(0, 2, DBA) .nes. "-u" then write sys$output "No match" 
 >> $  exit >> >> Question:I >> Shouldn't show symbol/local and F$extract work against the same symbol E >> table (or actually do the same search through the local and global  >> symboltables)?  >>
 >> Regards >> Hans Blom >> > Hello all,' > grand forum, thanks for your answers. C > But Ok, let's boil it down to what was in the application script. D > All those "show symbols" were entered by me in an effort to debug. >  > CP_1:  > $  DBA = "1_L_SYMB"  > $  @CP_2 "" -uusername	 > $  exit  >  > CP_2: & > $  DBA == F$edit(P2, "TRIM, UPCASE"). > $  if F$extract(0, 2, DBA) .nes. "-u" then -$ > 			write sys$output "No match????"	 > $  exit  > ' > Still strange? Or am I lost as usual? 	 > Regards  > Hans Holy Macarel!!D UPCASE should be read as LOWERCASE, just trying to fool the phishers   Hans   ------------------------------  % Date: Wed, 06 Sep 2006 21:33:32 +0200 ' From: Hans Blom <hans.y.blom@telia.com> < Subject: Re: Confusing behaviour of local and global symbols9 Message-ID: <44ff2187$0$19260$88260bb3@news.teranews.com>    hanblo {at} netscape.net wrote:  > Hello,I > I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour " > when it comes to symbolhandling. > Two commandprocdures:  >  > CP_1:  > $  DBA = "1_L_SYMB"  > $  @CP_2 "" -uusername	 > $  exit  >  > CP_2: ) > $  DBA == F$edit(P2, "TRIM, LOWERCASE")  > $  show symbol DBA*  > $  show symbol/global DBA* > $!4 > $! Next command says undefined symbol, check...... > $! > $  show symbol/local DBA*  > $! > $! Next command gives me "1_"  > $!/ > $  write sys$output "''F$extract(0, 2, DBA)'"  > $! > $! and of course this is true  > $!H > $  if F$extract(0, 2, DBA) .nes. "-u" then write sys$output "No match"	 > $  exit  >  > Question: H > Shouldn't show symbol/local and F$extract work against the same symbolD > table (or actually do the same search through the local and global > symboltables)? > 	 > Regards  > Hans Blom  > 
 Hello all,% grand forum, thanks for your answers. A But Ok, let's boil it down to what was in the application script. B All those "show symbols" were entered by me in an effort to debug.   CP_1:  $  DBA = "1_L_SYMB"  $  @CP_2 "" -uusername $  exit    CP_2: $ $  DBA == F$edit(P2, "TRIM, UPCASE"), $  if F$extract(0, 2, DBA) .nes. "-u" then -" 			write sys$output "No match????" $  exit   % Still strange? Or am I lost as usual?  Regards  Hans   ------------------------------   Date: 6 Sep 2006 13:05:45 -0700 - From: "Doug Phillips" <dphill46@netscape.net> < Subject: Re: Confusing behaviour of local and global symbolsB Message-ID: <1157573145.553930.85290@m73g2000cwd.googlegroups.com>   briggs@encompasserve.org wrote: u > In article <1157565946.551713.230340@b28g2000cwb.googlegroups.com>, "Doug Phillips" <dphill46@netscape.net> writes: # > > hanblo {at} netscape.net wrote:  > >> Hello, L > >> I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour% > >> when it comes to symbolhandling.  > >  > > Something does seem wrong. > > # > > $HELP SHOW SYMBOL EXAMPLE says:  > >  > > ##& > > "... The command interpreter firstB > > searches the local symbol table for the current command level,> > > then local symbol tables for preceding command levels, and* > > finally the global symbol table.  ..." > > ## > >  > >> Two commandprocdures: > >>
 > >> CP_1: > >> $  DBA = "  > >> $  @CP_2 "" -uusername  > >> $  exit > >>
 > >> CP_2:, > >> $  DBA == F$edit(P2, "TRIM, LOWERCASE") > >> $  show symbol DBA* > > J > > This displays the Global value "-uusername", but it should display the% > > preceding level local, "1_L_SYMB"  > ? > You are absolutely right.  And my previous posting was wrong.  > C > When used with a wildcard, SHOW SYMBOL appears to search only the / > innermost local and the global symbol tables.  > B > When used without a wildcard, SHOW SYMBOL searches all tables as
 > documented.  >   E Odd. My first test was with v7.3-2 but I've gone back to VAX v6.2 and  it works that way there, too.    >  > Demonstration...  C <snip demostration showing difference between show symbol searches>     B > Without the wildcard, SHOW SYMBOL matches the default DCL symbol > lookup search order properly.   D Again, odd. Is this someplace in the doc's that I haven't found? TheB question comes to mind: Presuming this is the way it's intended to$ work, why would it be done this way?   I also quoted & commented:! > > $! Next command gives me "1_"  > > $! > G > The first time I run this, it returns "" (null), then subsequent runs 
 > return "1_"  > 1 > > $  write sys$output "''F$extract(0, 2, DBA)'"   E but now can't reproduce that; I get "1_" every time. Must have bumped B against one of those extradimensional p-brane distortion thingies.   ------------------------------   Date: 6 Sep 2006 18:29:36 -0700 $ From: "AEF" <spamsink2001@yahoo.com>< Subject: Re: Confusing behaviour of local and global symbolsB Message-ID: <1157592575.976707.42270@h48g2000cwc.googlegroups.com>   Doug Phillips wrote:! > briggs@encompasserve.org wrote: w > > In article <1157565946.551713.230340@b28g2000cwb.googlegroups.com>, "Doug Phillips" <dphill46@netscape.net> writes: % > > > hanblo {at} netscape.net wrote: 
 > > >> Hello, N > > >> I run OpenVMS 7.3-2 with ECO's and have, what I think a funny behaviour' > > >> when it comes to symbolhandling.  > > >   > > > Something does seem wrong. > > > % > > > $HELP SHOW SYMBOL EXAMPLE says:  > > >  > > > ##( > > > "... The command interpreter firstD > > > searches the local symbol table for the current command level,@ > > > then local symbol tables for preceding command levels, and, > > > finally the global symbol table.  ..." > > > ## > > >  > > >> Two commandprocdures: > > >> > > >> CP_1: > > >> $  DBA = "  > > >> $  @CP_2 "" -uusername  > > >> $  exit > > >> > > >> CP_2:. > > >> $  DBA == F$edit(P2, "TRIM, LOWERCASE") > > >> $  show symbol DBA* > > > L > > > This displays the Global value "-uusername", but it should display the' > > > preceding level local, "1_L_SYMB"  > > A > > You are absolutely right.  And my previous posting was wrong.  > > E > > When used with a wildcard, SHOW SYMBOL appears to search only the 1 > > innermost local and the global symbol tables.  > > D > > When used without a wildcard, SHOW SYMBOL searches all tables as > > documented.  > >  > G > Odd. My first test was with v7.3-2 but I've gone back to VAX v6.2 and  > it works that way there, too.  >  > >  > > Demonstration... > E > <snip demostration showing difference between show symbol searches>  >  > D > > Without the wildcard, SHOW SYMBOL matches the default DCL symbol! > > lookup search order properly.  > F > Again, odd. Is this someplace in the doc's that I haven't found? TheD > question comes to mind: Presuming this is the way it's intended to& > work, why would it be done this way? >  > I also quoted & commented:# > > > $! Next command gives me "1_"  > > > $! > > I > > The first time I run this, it returns "" (null), then subsequent runs  > > return "1_"  > > 3 > > > $  write sys$output "''F$extract(0, 2, DBA)'"  > G > but now can't reproduce that; I get "1_" every time. Must have bumped D > against one of those extradimensional p-brane distortion thingies.  5 [LOL, well a little.] String theory proven right! &-)   $ Next time, blame it on space aliens!   Yow!    1 It's always something.  -- Roseanne Roseannadanna    AEF    ------------------------------  % Date: Thu, 07 Sep 2006 01:12:16 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com> Subject: Creating a HDLC CRC? ; Message-ID: <44FF71F0.12048.1A49196@squayle.insight.rr.com>   9 The VMS FAQ section 10.29 has code for using lib$crc and  2 lib$crc_table to compute an AUTODIN-II 32-bit CRC.  > I found a helpful page that lists all sort of CRC polynomials:   http://users.physik.tu- 8 muenchen.de/gammel/matpack/html/LibDoc/Crypto/MpCRC.html  E I need to do the same for the 16-bit HDLC CRC.  The page lists magic  
 values of:       AUTODIN-II		0x04C11DB7     HDLC			0x1021   C Now, the code in the FAQ has a value of 0xEDB88320.  I was able to  @ notice that this is the bit pattern of 0x04C11DB7, just exactly 
 backwards.  B So, I'm planning on using 0x04204000 to compute the HDLC CRC, and E leave the rest of the FAQ's program unchanged.  Anyone see a problem  
 with that?  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------  % Date: Wed, 06 Sep 2006 10:08:02 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>J Subject: Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL* Message-ID: <44fed635@usenet01.boi.hp.com>   JF Mezei wrote:   - > 	added "lib$signal("SS$_DEBUG") in the code  > 	CC/DEBUG/etc # > 	LINK/DEBUG/NOTRACEBACK/SHARE etc   I    Hopefully what was posted was a form of pseudo-code, and not what was  J actually in the C code.  There's an example of the debugger signal in the N OpenVMS FAQ.  And if you're seeing the signal, the debugger output appears to O not be aimed at the correct and intended display, or something else caught the  F signal before the debugger.  Check your logical name definitions, and 3 specifically check the context for the definitions.    ------------------------------  % Date: Wed, 06 Sep 2006 10:09:42 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>J Subject: Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL* Message-ID: <44fed698@usenet01.boi.hp.com>   JF Mezei wrote:   J > Am I missing something ?  (defined dbg$input and dbg$output to the FTAx:4 > device, and DBG$DECW$DISPLAY to the WSAx: device.)  N    ps: I'd pick one or the other, and not both.  DBG$DECW$DISPLAY to "  ", or N get rid of the DBG$* definitions and use the WS device and its target and the  DECwindows debugger.   ------------------------------  % Date: Wed, 06 Sep 2006 16:18:29 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> J Subject: Re: Debugging image invoked by SYMBIONT via LIB$FIND_IMAGE_SYMBOL, Message-ID: <44FF2D0E.9D7B3CB1@teksavvy.com>   Hoff Hoffman wrote: J >    Hopefully what was posted was a form of pseudo-code, and not what wasK > actually in the C code.  There's an example of the debugger signal in the  > OpenVMS FAQ.      D OK Thanks. Didn't realise one had to supply the debugger commands as) part of the lib$signal system service !.  E And very interesting that that argument is apssed as a counted string 3 instead of a descriptor ! Any history behind that ?   = BTW, the faq can be accessed at http:://www.hp.com/go/vms/faq    ------------------------------  % Date: Wed, 06 Sep 2006 15:50:01 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Heads Up:  Intel to axe 20,000 jobs, Message-ID: <44FF2663.7BF19380@teksavvy.com>   Neil Rieck wrote: N > I'm afraid there is nothing proving it either. The only thing that will shutJ > down IA64 is if a "Curly type" is pushed into a decision making position& > then shoots his company in the foot.  G If Intel is losing money on IA64 (which one Intel exec already admitted H to), the only way they can afford to continue the programme is either toF scale it down to barebones, or to ask HP to subsidize it so that Intel doesn't lose money.   E If HP must subsidize that IA64 thing, and the 8086 ends up performing G better/faster, then HP would be stupid to stick to IA64 that brings now F technological advantage to its products and will be/is seen as lagging# behind others , including the 8086.   B Consider that while IA64's product cycle has lenghtened due to the@ delays and postponing features to the next generation,  Intel isH quickening the 8086 product cycle to get new generations every couple of" years. The writing is on the wall.  L > I am surprised that anybody even listens to analysts anymore. These peopleE > have the worst track record and I'm convinced the 1996-2006 decade    D Corporations *have* to listen to what analysts have to say. AnalystsE work for companies who own a lot of stock in Intel, so if an analysts # says "X", then intel has to listen.   L > Like Alpha and PA-RISC, most people have never heard of IA64 or Itanium or > Integrity.  G Which is why I found it significant to start seeing  financial analysts G start to mention IA64 as hindering Intel's corporate performance.  This / wasn't just wired or the inquirer.net anymore.        A And for HP, this requires some really serious long term strategic G thinking. IIf it feels that neither HP-UX nor VMS have long term growth H potential, then they may just as well leave them on that IA64 thing evenE if the later only gets speed bumps and no major new developments. For D Tandem, it doesn't matter because customers are so captive that theyG would stick on any CPU architecture as long as it runs and is supported  even if it runs slowly.   G Look at it this way: for HP, which is more profitable: selling hardware B with Linux on it and then selling support contracts, or paying forC development of HP-UX and VMS, selling licences at low cost and then  selling support contracts ?   F Looks to me that on paper, Linuix may end up being more profitable forH vendors since they don't have to pay for its development. In the end, itE is history rewritten when you look at companies like Data General who D abandonned their own proprietary OS to go to Unix because it was not3 only more "standard", but also more cost efficient.   F This is why I feel strongly that the VMS community needs to drive homeF to HP the message that we need VMS ported to the 8086 ASAP so that VMSF can legerage its potential for growth and give HP a technological edge that Dell can't have.    ------------------------------  % Date: Wed, 06 Sep 2006 23:58:50 -0400 ' From: CBFalconer <cbfalconer@yahoo.com> L Subject: Re: Please Loot the Inforamtion/Mainframe Material  at "MFRESOURCE") Message-ID: <44FF98FA.3BFF3EE2@yahoo.com>   
 Sri wrote: > 7 > MFRESOURCE:  Mainframe Resources Group: (YAHOO GROUP)  >  ... snip ... > > > So MEMBERS should post only to specific to mainframe realted > inforamtion. > 0 > Other postings in this Group is not permitted. >  > Thanks & Regards,  > Group Moderator.  @ Posting this spam to comp.programming is not permitted.  I doubt@ that it is permitted to any of the crossposted newsgroups. F'ups set.   --  ) Chuck F (cbfalconer at maineline dot net) ;    Available for consulting/temporary embedded and systems. #    <http://cbfalconer.home.att.net>    ------------------------------  % Date: Wed, 06 Sep 2006 16:00:12 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC , Message-ID: <44FF28C5.41F0BE69@teksavvy.com>   Robert Deininger wrote: A > No, with respect to TCPIP you are a decade or more out of date.   G Current version fo VAX-VMS still require a UCX licence to run the TCPIP - stack. And that software is not 10 years old.   F Point is that since about 1990, it was obvious that TCPIP would becomeE the standard for networking.  DEC should have made TCPIP part of VMS  H back then. Perhaps just a "NETWORKING" PAK to enable both TCPIP ServicesQ and DECNET. Or just get the networking software to check for a valid VMS licence.   G If it was finally done on IA64, it is way too late and should have been  done a long long time ago.    I > functionality.  While the OS PAK was separate, the whole collection was ) > commonly bundled with new system sales.   H But this still requires the customer to individually manage those PAKs. G I think that NAS packages did come close to teh "NETWORKING" philosophy G with a single PAX enabling a slew of products. But there were different 1 levels of NAS packages which complicated matters.     " >  I'm not aware of any common VMSE > sales model in over a decade that would have included, required, or  > suggested an actual UCX PAK.  H Existing long time customers didn't magically get a UCX PAK in the mail.0 Only new customers would get a "bundle" of PAKs.   ------------------------------  % Date: Wed, 06 Sep 2006 16:04:53 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC , Message-ID: <44FF29DF.F4353ACD@teksavvy.com>   "Main, Kerry" wrote:H > From a technical perspective, locking down monstrous numbers of remoteH > home desktops, PDA's, crackberries, laptops etc is a huge and daunting > task.   . And also an impossible task to get 100% right.  E You still need to consider that ANY data that comes from outside your G physical plant is potentially infected or downright malicious and still F need to firtewall everything that comes from the outside. In fact, youG shoudl also firewall anything that comes from a Windows box even inside  your company.   < And you should have a policy that your core mission criticalH applications should not run on the same OS as that used on desktops thatB have "free" access to the internet/email. This way, an attack thatB penetrates your company via those desktops cannot infect your core- systems because they run on an differennt OS.    ------------------------------  % Date: Thu, 07 Sep 2006 00:43:09 -0400 ' From: Dave Froble <davef@tsoft-inc.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC 9 Message-ID: <lsCdnfszw94ePGLZnZ2dnUVZ_smdnZ2d@libcom.com>    JF Mezei wrote:  > "Main, Kerry" wrote:I >> From a technical perspective, locking down monstrous numbers of remote I >> home desktops, PDA's, crackberries, laptops etc is a huge and daunting  >> task. > 0 > And also an impossible task to get 100% right. > G > You still need to consider that ANY data that comes from outside your I > physical plant is potentially infected or downright malicious and still H > need to firtewall everything that comes from the outside. In fact, youI > shoudl also firewall anything that comes from a Windows box even inside  > your company.  > > > And you should have a policy that your core mission criticalJ > applications should not run on the same OS as that used on desktops thatD > have "free" access to the internet/email. This way, an attack thatD > penetrates your company via those desktops cannot infect your core/ > systems because they run on an differennt OS.   I Now that's a good marketing idea.  Doesn't hurt that it's also true.  Of  1 course, VMS isn't the only alternative to windoz.   G I've still got a customer who doesn't give a damn.  Regardless of what  I they're told, they'll continue to run windoz servers.  My best option is  + to continue to take their money regardless.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 06 Sep 2006 22:24:08 -0400 ) From: Stephen Eickhoff <operagost@og.com> 7 Subject: VMS MAIL:  Will it ever join the 21st century? 5 Message-ID: <44ff82c7$0$3578$815e3792@news.qwest.net>   O What exactly are HP's plans for VMS Mail?  They began including an IMAP server  O back in 5.3 and have enhanced SMTP's performance and added anti-SPAM features.  O    But it's all still riding on a message store that hasn't seen a significant  K enhancement in some time (I'm guessing... 1988).  The greatest flaw is the  H failure to store message size within the indexed file.  This negatively O impacts performance of POP3 and IMAP to a large degree... exponentially in the  M case of IMAP, which may have have to dig through thousands of entries in the  O file system index simply to obtain the file size information.  HP/Compaq could  I have at least mitigated this issue by storing larger messages within the  L indexed file, resulting in fewer files in the mail directory and thus fewer O hits on the file index.  Or, they could even better by reworking the MAIL file  M format to include file size information.  Instead, nothing has been done.  I  M had some hope for 8.3 as I'd read on the HP OpenVMS 8.3 home page that there  G were "Mail enhancements" but it turns out that they were actually SMTP  
 enhancements.   K If HP intends their customers to actually use these messaging protocols, I  G recommend some enhancements in the next OpenVMS version.  Otherwise, I  M recommend that POP3 and IMAP be removed entirely so that OpenVMS engineering  2 can dedicate their resources to more useful tasks.   Yes, I know about PMDF.    ------------------------------  % Date: Wed, 06 Sep 2006 23:30:56 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>; Subject: Re: VMS MAIL:  Will it ever join the 21st century? , Message-ID: <44FF924C.147A0AD5@teksavvy.com>   Stephen Eickhoff wrote:  > , > What exactly are HP's plans for VMS Mail?     B Consider Hoff's recent suggestiosn we start using Mozilla or otherB clients instead of VMS based clients. Consider that user interfaceF issues don't seem to make to to the VMS roadmaps. Most applications weH use on VMS haven't been updated since the last century. And some we use,H like the DHCP GUI management application can't be maintained because the, company that made it doesn't exist anymore.   E Hey, I'm all with you on this. MAIL needs a major makeover to make it A internet compatible. Lots of changes needed, such as allowing the G setting of the message time stamp (right now, all messages are dated on F date of reception on that node, and not on date it was actually sent).   ------------------------------   Date: 6 Sep 2006 23:12:17 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ; Subject: Re: VMS MAIL:  Will it ever join the 21st century? 3 Message-ID: <gDCXlSmJpP2r@eisner.encompasserve.org>   a In article <44ff82c7$0$3578$815e3792@news.qwest.net>, Stephen Eickhoff <operagost@og.com> writes:   N > But it's all still riding on a message store that hasn't seen a significant M > enhancement in some time (I'm guessing... 1988).  The greatest flaw is the  J > failure to store message size within the indexed file.  This negatively 8 > impacts performance of POP3 and IMAP to a large degree  9 But VMS users read their mail without using POP3 or IMAP.   G If you want to use a VMS machine to serve mail files to other operating D systems, there are several third party products to do exactly that -" one released within the past year.  D If you, with a goal off the design-center, are unwilling to buy from? third party vendors, there will soon be no third party vendors.    Larry Kilgallen ) third party vendor not in the email space    ------------------------------   Date: 6 Sep 2006 10:58:54 -0700 / From: "Volker Halle" <volker_halle@hotmail.com> : Subject: Re: Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX)B Message-ID: <1157565534.083845.36890@p79g2000cwp.googlegroups.com>   Luke,   E the brand new VMS83A_ADDENDUM-V0100 (and VMS83I_ADDENDUM-V0100) patch B make a reference to this bugcheck and provide a solution for V8.3:   5.2.7  FREWSLX System Crash    5.2.7.1  Problem Description:   <                The system can crash with a FRESWLX bugcheck.                  Images Affected: %                 -  [SYSLIB]SPISHR.EXE   >                5.2.7.2  CLDs, and QARs reporting this problem:  %                     5.2.7.2.1  CLD(s)                      None.   %                     5.2.7.2.2  QAR(s)                      75-109-1694   )                5.2.7.3  Problem Analysis:   E                As of V8.2, MONITOR uses a mechanism known as "keep in D                working set" to lock data into the working set.  ThisF                mechanism is intended for locking very small numbers ofB                pages in the working set for short periods of time.D                However, the data monitor locked into the working setC                could be very large (based on MAXPROCESSCNT).  Under D                these conditions, it is possible that if a page faultF                occurs, there will not be any available dynamic working?                set entries to remove from the working set.  The E                operating system does not expect a case where there is  noD                room in the working set, resulting in the FREWSLX bug                check.   D                5.2.7.4  Release Version of OpenVMS that will contain$                         this change:7                Next release of OpenVMS Alpha after V8.3   %                5.2.7.5  Work-arounds:                 None.   --- , Volker Halle, Invenate GmbH, OpenVMS Support  # An OpenVMS crashdump analysis a day $ makes the Windows headaches go away.   ------------------------------   Date: 6 Sep 2006 18:51:55 -0700 A From: "luke.shipway@googlemail.com" <luke.shipway@googlemail.com> : Subject: Re: Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX)C Message-ID: <1157593915.019527.169620@b28g2000cwb.googlegroups.com>    Volker Halle wrote:    > Luke,  > G > the brand new VMS83A_ADDENDUM-V0100 (and VMS83I_ADDENDUM-V0100) patch D > make a reference to this bugcheck and provide a solution for V8.3: >   D Thank you very much for the pointer and all your help with this (and other) issues.  D It truely is much appreciated.  I think I should have some time next week to look at our VMS migration.   E We're currently moving offices (superb timing, or not) so things have 
 been crazy around here.   ------------------------------  $ Date: Wed, 6 Sep 2006 14:52:58 -0400' From: "Main, Kerry" <Kerry.Main@hp.com>  Subject: RE: What is PSDC T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A11959@tayexc19.americas.cpqcorp.net>   > -----Original Message-----B > From: Peter 'EPLAN' LANGSTOEGER [mailto:peter@langstoeger.at]=20! > Sent: September 6, 2006 4:10 PM  > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: What is PSDC  >=20 > In article=20 < > <1157543328.216309.98350@m79g2000cwm.googlegroups.com>,=20% > "alok" <alok.net@gmail.com> writes:  > >I want to know about PSDC .! > >Plz give me some info on this.  >=20B > In DEC world this means the Polycenter Solutions/Software (?)=20 > Data Collector. G > It was a data analysis tool for VMS, worked with the PSPA Performance @ > Advisor (and IIRC as a hotfile database for the defragger),=20 > and got sold@ > (like almost all Polycenter Products) to CAI (where most of=20 > them got underB > the UNICENTER umbrella or renamed and naturally more expensive). >=20E > You could forget about it (as it is no longer "natural" for VMS ;-) : > If you need to keep in touch with PSDC, check CAI for=20 > UNICENTER Performance = > Solutions for OpenVMS at http://supportconnectw.ca.com I=20  > think, this is it. >=20@ > Nowadays, VMS has ECP, TDC for free and PERFDAT from HP for=20
 > such tasks.  >=20 > --=20  > Peter "EPLAN" LANGSTOEGER ' > Network and OpenVMS system specialist  > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist >=20  8 Peter - Some additional links for CA / OpenVMS products:  1 http://www.cai.com/openvms (Main CA OpenVMS page)   A http://www3.ca.com/solutions/Product.aspx?ID=3D1174 (CA / OpenVMS  performance products)    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: 6 Sep 2006 23:01:51 -0200 6 From: eplan@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)" Subject: Re: [VMS V7.3-2] ECO date, Message-ID: <44ff535f$1@news.langstoeger.at>   In article <1157561705.514212.163610@m73g2000cwd.googlegroups.com>, "george.pagliarulo@hp.com" <george.pagliarulo@hp.com> writes: G >  Where is this date coming from?  Is this the date that is listed for B >the kit on the ITRC site or is it the date on the kit after it is >downloaded to your system?   M It's the date of the kit after unpacking the DCX container file I downloaded. L I thought, that it is the original date of the kitfile (before DCX packing).  L Try yourself, download the DCX file from ITRC FTPserver and RUN (unpack) it.) What date does the kit get on your side ?    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 6 Sep 2006 18:17:43 -0700 $ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: [VMS V7.3-2] ECO dateC Message-ID: <1157591863.143132.306740@m73g2000cwd.googlegroups.com>     Peter 'EPLAN' LANGSTOEGER wrote:v > In article <1157563582.813836.57510@d34g2000cwd.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes: > >$ dir .pcsi/dat > > - > >Directory DSA64:<OPENVMS_PATCHES.ALPHA.LP>  > > * > >DEC-AXPVMS-DNVOSIECO03-V0703-2-4.PCSI;2/ > >                      4-OCT-2006 23:49:25.33  > >  > > D > >The data is clearly wrong ! I would guess, that the .33 after theG > >seconds may just be some local time value, if the date stored in the F > >self-compressing image did not include the full OpenVMS time value. > E > Thanks for responding and also thanks for your (IMNSHO very useful) K > explanation of the hundreths seconds value. Now I have yet another reason / > why DCX is worse than others (namely ZIPSFX).  > O > For me it seems, that the system where packaging was done, was not NTPsynced\   ; NTP? It's a month into the future! Talk about time drift!!!   E I don't think NTP is really relevant here. Someone mistakenly set the D system something like a month into the future. I don't think lack of& NTP is going to do that, even on a PC!   AEF    >  > -- > Peter "EPLAN" LANGSTOEGER ' > Network and OpenVMS system specialist  > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  $ Date: Wed, 6 Sep 2006 22:01:29 -0400/ From: "William Webb" <william.w.webb@gmail.com> " Subject: Re: [VMS V7.3-2] ECO dateI Message-ID: <8660a3a10609061901g1bbfd2baqe76b1d7f3c16c6da@mail.gmail.com>   A On 6 Sep 2006 18:17:43 -0700, AEF <spamsink2001@yahoo.com> wrote:  > " > Peter 'EPLAN' LANGSTOEGER wrote:x > > In article <1157563582.813836.57510@d34g2000cwd.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes: > > >$ dir .pcsi/dat > > > / > > >Directory DSA64:<OPENVMS_PATCHES.ALPHA.LP>  > > > , > > >DEC-AXPVMS-DNVOSIECO03-V0703-2-4.PCSI;21 > > >                      4-OCT-2006 23:49:25.33  > > >  > > > F > > >The data is clearly wrong ! I would guess, that the .33 after theI > > >seconds may just be some local time value, if the date stored in the H > > >self-compressing image did not include the full OpenVMS time value. > > G > > Thanks for responding and also thanks for your (IMNSHO very useful) M > > explanation of the hundreths seconds value. Now I have yet another reason 1 > > why DCX is worse than others (namely ZIPSFX).  > > Q > > For me it seems, that the system where packaging was done, was not NTPsynced\  > = > NTP? It's a month into the future! Talk about time drift!!!  > G > I don't think NTP is really relevant here. Someone mistakenly set the F > system something like a month into the future. I don't think lack of( > NTP is going to do that, even on a PC! >  > AEF  >  > >  > > -- > > Peter "EPLAN" LANGSTOEGER ) > > Network and OpenVMS system specialist   > > E-mail  peter@langstoeger.atJ > > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist >  >    Simple explanation:    Extreme overclocking.   K Probably one of those fanatics whose system is cooled with liquid nitrogen.    : - )    WWWebb   --  ! I'm no longer job-hunting, folks.   F Thanks to all those who expressed concern and sent me possibilities to investigate.   ------------------------------  % Date: Wed, 06 Sep 2006 14:45:42 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>" Subject: Re: [VMS V7.3-2] ECO date* Message-ID: <44ff1749@usenet01.boi.hp.com>   Volker Halle wrote:   E > The dat[e] is clearly wrong ! I would guess, that the .33 after the F > seconds may just be some local time value, if the date stored in theE > self-compressing image did not include the full OpenVMS time value.   O    I'd not immediately tend to assume zip includes the hundredths -- there are  O various ways to get drift in the lowest bits of the quadword, not the least of   which is via DECnet FAL.  K    zip (and unzip) may well be using a Unix-format date value -- yep, just  O looked, it's converting into and out of the epoch.  And the Unix epoch doesn't  O have particular precision.  I have NOT confirmed it is the conversion at fault  O here, nor at whether or not the FDL approach ("-V") avoids this path; this has   not been confirmed.   L    Short of a change to (at least) unzip/unzipsfx (and assuming FDL isn't a P work-around) (and pending confirmation), this will likely be the behaviour seen 4 at least for the near-term, for better or for worse.     	--   Q    I've commented before around the whole ECO process, and blogged on it once or  M twice -- but I don't see the current processing sequence and the environment   changing particularly soon.    ------------------------------  % Date: Thu, 07 Sep 2006 00:22:16 -0400 ' From: Dave Froble <davef@tsoft-inc.com> " Subject: Re: [VMS V7.3-2] ECO date9 Message-ID: <_4ydnR9-aqAAAWLZnZ2dnUVZ_qOdnZ2d@libcom.com>     Peter 'EPLAN' LANGSTOEGER wrote:v > In article <1157563582.813836.57510@d34g2000cwd.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes: >> $ dir .pcsi/dat >>- >> Directory DSA64:<OPENVMS_PATCHES.ALPHA.LP>  >>* >> DEC-AXPVMS-DNVOSIECO03-V0703-2-4.PCSI;2. >>                      4-OCT-2006 23:49:25.33 >> >>D >> The data is clearly wrong ! I would guess, that the .33 after theG >> seconds may just be some local time value, if the date stored in the F >> self-compressing image did not include the full OpenVMS time value. > E > Thanks for responding and also thanks for your (IMNSHO very useful) K > explanation of the hundreths seconds value. Now I have yet another reason / > why DCX is worse than others (namely ZIPSFX).  > N > For me it seems, that the system where packaging was done, was not NTPsynced >   G No, it just took them a while to produce the patch, and then they sent  + it back in time to when it was needed.  :-)    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   End of INFO-VAX 2006.490 ************************