1 INFO-VAX	Tue, 07 Nov 2006	Volume 2006 : Issue 612       Contents:' Alphaserver DS10 617Mhz EV67 - in stock 8 Re: An increasingly-rare island of corporate inspiration8 Re: An increasingly-rare island of corporate inspiration Re: CIFS questions Re: CIFS questions Re: CIFS questions) DECW$MAIL bug: crashes for large messages ( FA: Vintage Alpha/AXP t-shirt and others3 Re: Itanium model numbers {re F$getsyi("HW_MODEL")} 3 Re: Itanium model numbers {re F$getsyi("HW_MODEL")} 3 Re: Itanium model numbers {re F$getsyi("HW_MODEL")} 3 Re: Itanium model numbers {re F$getsyi("HW_MODEL")}  OpenVMS Hobbyist Integrity Re: OpenVMS Hobbyist Integrity Re: OpenVMS Hobbyist Integrity Re: PID of a batch job RE: Time change questions !   F ----------------------------------------------------------------------  $ Date: Mon, 6 Nov 2006 14:30:34 -0500> From: "Island Computers, D B Turner" <dturner-at-islandco.com>0 Subject: Alphaserver DS10 617Mhz EV67 - in stock0 Message-ID: <12kv3aqm7gbr953@news.supernews.com>  3 We have a quantity of these on sale for November 06   ) Base system without license is only $2000   - Call or email with configuration requirements    Thanks y'all !   --   Island Computers US Corp 2700 Gregory St  Savannah GA 31404  Tel: 912 447 6622 x201# Mail: dturner-atnospam-islandco-com % (You know what to do with the dashes)    ------------------------------  % Date: Mon, 06 Nov 2006 20:21:33 -0600 3 From: David J Dachtera <djesys.no@spam.comcast.net> A Subject: Re: An increasingly-rare island of corporate inspiration 0 Message-ID: <454FEDAD.76A6AEF7@spam.comcast.net>   Paul Sture wrote:  > I > In article <GaqdnT4xhojsjdHYnZ2dnUVZ_vSdnZ2d@metrocastcablevision.com>, , >  Bill Todd <billtodd@metrocast.net> wrote: >  > >>G > > I suspect not, nor anyone else.  *Already owning* VMS and having at D > > least what support structure is left of it in place and ready toI > > revitalize is one thing, picking up the pieces and trying to put them F > > back together in a totally different environment is quite another. > >  > J > Judging by a few postings here about the build procedure used by OpenVMSI > Engineering and my own experience of inheriting (much smaller) projects H > done by others, it can be a real nightmare reproducing the environment > for a correct build.  O I don't think any environments were reproduced during the last two transitions. 8 Not sure why a future transition would be any different.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Mon, 06 Nov 2006 20:36:44 -0600 3 From: David J Dachtera <djesys.no@spam.comcast.net> A Subject: Re: An increasingly-rare island of corporate inspiration 0 Message-ID: <454FF13C.F27693F4@spam.comcast.net>   davidc@montagar.com wrote: >  > David J Dachtera wrote: R > > I tend to think that if Sun owned OpenVMS, we'd not only see an x86 port, we'dT > > see x86-64 as well. Probably even see a published spec. that freeware developersR > > could use to develop OPenVMS-x86 drivers for some of the odd chipsets, adapter& > > cards, etc. out there in x86-land. > G > Thing is, there are specs for writing drivers for OpenVMS.  There are D > people that have published source to various drivers, too.  ForestI > Kenney, for example, has lately provided many examples of communicating H > with various USB devices (had fun looking at some of them in Atlanta -G > working on Integrity).  The IDSM is available that kinds all kinds of G > goodies about how OpenVMS works.  As much as many Unix distributions,  > OpenVMS is pretty... Open.  M Well, the issue, as has been mentioned in previous discussions, is the widely O varied chispets on x86 server mobo.'s out there now. This is often cited as one P of the "knock out" factors for not doing the x86 port. These bits are bit closer8 to the kernel than, for example, a device (type) driver.  G > The next question, is there a market for some of the odd chipsets out 1 > there.  Maybe for some, probably not for most.    O True. However, thanx to Compaq, and later HP, Proliants have propagated in vast I numbers, some of which are only now being shrunk back by products such as J WMware. So, the actual scope of the variations in chipsets that would needK support just to make it worthwhile is probably very small, even considering " other server vendors such as Dell.   > Okay, the USB Hamster > > is pretty funny, but not something you're likely to see in aG > datacenter.  Well, maybe that itself is the problem - there should be H > more humor in the datacenter, and a hamster on every Superdome showingF > the activity of each partition may be as useful as any other graphic
 > display.  1 Real-time, visual performance / activity display!   I > Since you've brought the question up, what chipset(s) would you like to H > have drivers for on OpenVMS?  Are you a developer that could assist inC > this task?  Even in the freeware world, it starts with one person H > saying "I think there should be support for this chip, so I'll step upE > to the plate".  Hardware is getting cheaper, and a Hobbyist license ( > would certainly qualify for this task.  O To make that a viable pursuit, we'd need the Emerald code to be released to the M hobbyist community, even if under NDA. Or, if anyone knows exactly which bits F are held back from Source Listings discs, some way to work around thatO limitation and build a workable development environment. Then, VMS-x86 could be J like Linux: originate "in the wild", and find its way (back) into the dataL center as M$ viri, worms, trojans, etc. continue to proliferate unabated andL Corporate America continues to seek alternatives to cut downtimes and reduce costs.  M ...and before anyone raises the "business case" question further, let me turn O the tables on you and ask you: Linux is big business. What is the business case K for Linux? When you have YOUR answer, simply apply that to VMS-x86, and the  question now answers itself.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Mon, 06 Nov 2006 14:43:07 -0500 - From: bradhamilton <bradhamilton@comcast.net>  Subject: Re: CIFS questions ( Message-ID: <454F904B.30102@comcast.net>   Thanks for the tips, John.  G I increased the debug level (using PDBEDIT), and saw messages relating  F to process quota exhaustion.  I then looked at the SAMBA$SMBD process G quotas, and noticed that they were set like a typical DEFAULT user.  I  G jacked up the quotas through the roof, and at least got faster process  ; creation/tear-down!  Still no luck with WORKGROUP, however.   I Not to argue with you, but the CIFS FAQ states that CIFS on Integrity is  I supported as a base-level product, but CIFS on Alpha requires a separate  B support contract; therefore, it will not be "supported" for Alpha L hobbyists (the only kind, at this point in time).  Hence, my questions here.  C The debug levels reveal a lot of warning/error messages related to  G varying C modules; I get the impression that this particular RC is not  6 ready for prime-time.  Back to SAMBA 2.2.8, I think...  H BTW - what is the e-mail address for CIFS questions?  Perhaps I can get 6 responses, even though I'm not paying for support.	:-)   ------------------------------  % Date: Mon, 06 Nov 2006 15:07:58 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network>  Subject: Re: CIFS questions ; Message-ID: <xMudncJATbS5C9LYnZ2dnUVZ_t-dnZ2d@adelphia.com>    bradhamilton wrote:  >  > Thanks for the tips, John. > I > I increased the debug level (using PDBEDIT), and saw messages relating  H > to process quota exhaustion.  I then looked at the SAMBA$SMBD process I > quotas, and noticed that they were set like a typical DEFAULT user.  I  I > jacked up the quotas through the roof, and at least got faster process  = > creation/tear-down!  Still no luck with WORKGROUP, however.  > K > Not to argue with you, but the CIFS FAQ states that CIFS on Integrity is  K > supported as a base-level product, but CIFS on Alpha requires a separate  D > support contract; therefore, it will not be "supported" for Alpha I > hobbyists (the only kind, at this point in time).  Hence, my questions   > here.   I That applies to the production release.  AFAIK, it does not apply to the  H evaluation release.  The evaluation release is intended to get feedback  to the engineering team.  H There is no formal support available for the evaluation releases at all C except through the e-mail address or the web-form which just sends   e-mail to the same address.   E > The debug levels reveal a lot of warning/error messages related to  I > varying C modules; I get the impression that this particular RC is not  8 > ready for prime-time.  Back to SAMBA 2.2.8, I think...  H At this point the messages at a higher debug level on OpenVMS should be B equivalent to the same messages from a SAMBA 3.x on a UNIX system.  J > BTW - what is the e-mail address for CIFS questions?  Perhaps I can get ; > responses, even though I'm not paying for support.    :-)   , The e-mail address is OpenVMSCIFS(at)hp.com.   -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------   Date: 6 Nov 2006 12:05:07 -0800 ) From: "DaveG" <david.gudewicz@abbott.com>  Subject: Re: CIFS questions B Message-ID: <1162843507.365683.66340@k70g2000cwa.googlegroups.com>   bradhamilton wrote:  > Thanks for the tips, John. > H > I increased the debug level (using PDBEDIT), and saw messages relatingG > to process quota exhaustion.  I then looked at the SAMBA$SMBD process H > quotas, and noticed that they were set like a typical DEFAULT user.  IH > jacked up the quotas through the roof, and at least got faster process= > creation/tear-down!  Still no luck with WORKGROUP, however.  > J > Not to argue with you, but the CIFS FAQ states that CIFS on Integrity isJ > supported as a base-level product, but CIFS on Alpha requires a separateC > support contract; therefore, it will not be "supported" for Alpha N > hobbyists (the only kind, at this point in time).  Hence, my questions here. > D > The debug levels reveal a lot of warning/error messages related toH > varying C modules; I get the impression that this particular RC is not8 > ready for prime-time.  Back to SAMBA 2.2.8, I think... > I > BTW - what is the e-mail address for CIFS questions?  Perhaps I can get 8 > responses, even though I'm not paying for support.	:-)  , Here's a feedback link for the CIFS product:  ( http://h71000.www7.hp.com/perl/email1.pl   Dave...    ------------------------------  % Date: Mon, 06 Nov 2006 19:27:24 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: DECW$MAIL bug: crashes for large messages8 Message-ID: <c7303$454fd2ef$cef8887a$20128@TEKSAVVY.COM>  L In decwindows MAIL, Alpha VMS 8.3, if you try to open/read a large message, * the application simply crashes immediatly.   $ mc decw$mail& X Toolkit Error: Cannot perform malloc  5 Fatal error detected, image exiting -- final message: % %DWT-F-NOMSG, Message number 03AB8204      The messge in question: < 48032 records, external message id MAIL$E230EABE000500A5.MAI Attributes: New message   I If you try to open a large message that it cannot open, I would assume a  G dialogue would pop up stating that the message is too big to be opened   instead of DECW$MAIL crashing.  L On VAX VMS 7.3, trying to open the very same message with DECW$MAIL takes a F long time of huffing and puffing and eventually does open the message.  I Since the bulk of the memory allocation is for the message data in 8 bit  I bytes, it seems to me that the 32 vs 64 bit differences shouldn't matter.    ------------------------------  # Date: Tue, 07 Nov 2006 04:18:54 GMT  From: vmsguy <vmsguy@telus.net> 1 Subject: FA: Vintage Alpha/AXP t-shirt and others , Message-ID: <OOT3h.95956$E67.16291@clgrps13>  3 I have up for auction some golden oldies including:   % - 1992 Alpha/AXP logo digital t-shirt   > http://cgi.ebay.ca/ws/eBayISAPI.dll?ViewItem&item=130045106993   Others:   < - A very rare Hitchhiker's Guide to VMS t-shirt (never worn)2 - Process Software Land's End sweater (never worn)F - A classic TGV tie dye glow in the dark t-shirt (excellent condition)  I not sure where I got the last one - might have been at that TGV chocolate ) themed party in San Francisco one year...    ------------------------------  % Date: Mon, 06 Nov 2006 14:17:00 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>< Subject: Re: Itanium model numbers {re F$getsyi("HW_MODEL")}) Message-ID: <eio1na$1d5s$1@pyrite.mv.net>    JF Mezei wrote:   C > Seriously, have there really been instances of existing products  9 > changing name in mid-life ? (in the firm ware that is).   F    You are aware of a basic premise here, that simply having a "knob" G that would allow making a particular change will then tend to indicate  F that somebody somewhere sometime somehow is going to eventually twist H that knob?  And often when you least expect it.  (This is also known as : the "What's this [botton/knob/lever/switch] do?" theorem.)  H    As for the direct answer, yes, product names have been changed.  The I "Sable" box -- now known as the AlphaServer 2100 series -- is an example  G of a name change.  The box was initially named and shipped as the "DEC  H 2100 Model A600MP Server" series, or some such variation.  The VAX 8800 H series became variously known as the VAX 8820N series.  There have been  other cases.  I    Now as to whether or not this sort of name change can or will happen,  H that's another discussion, and fodder for HP to answer.  I (personally) G would not rule it out, given the basic premise of the inevitability of   knob-twisting.   ------------------------------  % Date: Mon, 06 Nov 2006 17:46:09 -0500 ' From: Dave Froble <davef@tsoft-inc.com> < Subject: Re: Itanium model numbers {re F$getsyi("HW_MODEL")}9 Message-ID: <n-udnUVQy43yJtLYnZ2dnUVZ_qWdnZ2d@libcom.com>     VAXman- @SendSpamHere.ORG wrote:f > In article <eio13r$1d0c$1@pyrite.mv.net>, Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes: >># >> VAXman- @SendSpamHere.ORG wrote:  >>K >>> Both yours and Hoff's information are great but really haven't answered M >>> by question; that bein, will these HW Model names remain consistent?  If, K >>> for example, I update the Itanium's F/W, what are the chances of seeing ( >>> a different product naming scheme?  J >>   No idea.  Sorry.  I don't know of a case where a product name change L >> has happened, but it would not surprise me to learn that it might happen K >> should something get re-badged or re-named or "varianted" into some new  E >> and different packaging somewhere along the line.  (eg: zx6000 vs  K >> rx2600.  IIRC, there is a name change here, though the box is the same.  E >>  Not exactly the situation you are seeking to discuss, obviously.)  >>G >>   It's certainly fodder for the HP server firmware folks to discuss.  >>H >>   I don't recall seeing anything indicating the string would even be E >> unique, nor have any particular mapping.  It's really just a name.  >>E >>   What might you be up to here?  What attribute, detail, hardware  O >> configuration or software or hardware are you looking to differentiate here?  > J > For licensing purposes to track the machine that a particular product isJ > licensed to.  I have found organizations with multiple machines and onlyJ > a license for a single machine in that organization.  It would really beJ > nice if a machine serial number -- accessible to software too -- was in-J > troduced again. Barring that, at least knowing that the software is on aJ > machine of a particular type helps to keep the customer somewhat honest. >  >    Can't resist!  :-)  B Brian and billy boy, on the same page, with the same problem.  :-)  I Are these organizations in China?  Seems that's billy boy's big problem,  + how to get the Chinese to pay for software.   ; You've got a serious problem, one without any easy answers.   G If you use anything on or in the machine, then when there are hardware  G problems, and pieces are swapped out, your ID may then change, and the  H software will claim there is a problem, even if the software is running  on only one system.   E I've had some ideas on potential solutions.  If you're interested in   hearing them, let me know.   --  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: Tue, 07 Nov 2006 01:26:05 GMT " From:   VAXman-  @SendSpamHere.ORG< Subject: Re: Itanium model numbers {re F$getsyi("HW_MODEL")}0 Message-ID: <00A5E56A.3FD2C43B@SendSpamHere.ORG>  c In article <n-udnUVQy43yJtLYnZ2dnUVZ_qWdnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  >  > ! >VAXman- @SendSpamHere.ORG wrote: g >> In article <eio13r$1d0c$1@pyrite.mv.net>, Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes:  >>> $ >>> VAXman- @SendSpamHere.ORG wrote: >>> L >>>> Both yours and Hoff's information are great but really haven't answeredN >>>> by question; that bein, will these HW Model names remain consistent?  If,L >>>> for example, I update the Itanium's F/W, what are the chances of seeing) >>>> a different product naming scheme?   K >>>   No idea.  Sorry.  I don't know of a case where a product name change  M >>> has happened, but it would not surprise me to learn that it might happen  L >>> should something get re-badged or re-named or "varianted" into some new F >>> and different packaging somewhere along the line.  (eg: zx6000 vs L >>> rx2600.  IIRC, there is a name change here, though the box is the same. F >>>  Not exactly the situation you are seeking to discuss, obviously.) >>> H >>>   It's certainly fodder for the HP server firmware folks to discuss. >>> I >>>   I don't recall seeing anything indicating the string would even be  F >>> unique, nor have any particular mapping.  It's really just a name. >>> F >>>   What might you be up to here?  What attribute, detail, hardware P >>> configuration or software or hardware are you looking to differentiate here? >>  K >> For licensing purposes to track the machine that a particular product is K >> licensed to.  I have found organizations with multiple machines and only K >> a license for a single machine in that organization.  It would really be K >> nice if a machine serial number -- accessible to software too -- was in- K >> troduced again. Barring that, at least knowing that the software is on a K >> machine of a particular type helps to keep the customer somewhat honest.  >>   >>   >  >Can't resist!  :-)  > C >Brian and billy boy, on the same page, with the same problem.  :-)  > J >Are these organizations in China?  Seems that's billy boy's big problem, , >how to get the Chinese to pay for software. > < >You've got a serious problem, one without any easy answers. > H >If you use anything on or in the machine, then when there are hardware H >problems, and pieces are swapped out, your ID may then change, and the I >software will claim there is a problem, even if the software is running   >on only one system. > F >I've had some ideas on potential solutions.  If you're interested in  >hearing them, let me know.   K Not me directly... remember, I'm just the piano player; I'm not writing the  music.   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Mon, 06 Nov 2006 22:31:11 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>< Subject: Re: Itanium model numbers {re F$getsyi("HW_MODEL")}) Message-ID: <eiouls$1lhu$1@pyrite.mv.net>     VAXman- @SendSpamHere.ORG wrote:  J > For licensing purposes to track the machine that a particular product isJ > licensed to.  I have found organizations with multiple machines and onlyJ > a license for a single machine in that organization.  It would really beJ > nice if a machine serial number -- accessible to software too -- was in-J > troduced again. Barring that, at least knowing that the software is on aJ > machine of a particular type helps to keep the customer somewhat honest.  H    Short of a USB dongle or such, I'm not aware of a way to assign that G sort of a serial number.  The usual approach is to collect up a series  D of configuration-specific details such as the system and disk model F information, the Ethernet NIC MAC address(es), the system disk GUIDs, H and otherwise, and use that together to determine the uniqueness of the  host.   I    [Would you be interested in a product that would provide this sort of   thing?]    ------------------------------   Date: 6 Nov 2006 14:23:25 -0800  From: davidc@montagar.com # Subject: OpenVMS Hobbyist Integrity C Message-ID: <1162851805.016486.188580@m73g2000cwd.googlegroups.com>     Okay, I think it's finally here!  F With much help from Hoff, the OpenVMS Hobbyist Program can now provideF licenses for the IA64 Integrity platforms.  Currently, the offering isB licenses only - there are no Integrity Hobbyist Kits at this time.  F I've tested as much as I can (finally have in rz2620 to test with), soD if there are any problems, please let me know.  I'll address them as fast as I can.  F Note that the licenses use checksum method 2, so you no longer have to= enter in both the Termination Date and Release Date, just the E termination date.  If you want the Layered Products, you must request A the IA64 Layered Products - the VAX/Alpha LP PAK's will not work.   E I got my rx2620 at the Atlanta Integrity Porting Workshop - this is a E sweet deal.   If you have any plans, even if it's a year or two away, * to port to IA64 - this is a MUST GO event.   ------------------------------  * Date: Mon, 6 Nov 2006 23:23:03 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)' Subject: Re: OpenVMS Hobbyist Integrity $ Message-ID: <eiog4n$ahv$1@online.de>  C In article <1162851805.016486.188580@m73g2000cwd.googlegroups.com>,  davidc@montagar.com writes:   H > Note that the licenses use checksum method 2, so you no longer have to? > enter in both the Termination Date and Release Date, just the  > termination date.     7 Why are these two dates the same for hobbyist licenses?    ------------------------------  % Date: Mon, 06 Nov 2006 23:04:35 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>' Subject: Re: OpenVMS Hobbyist Integrity ) Message-ID: <eip0kg$1m2q$1@pyrite.mv.net>   / Phillip Helbig---remove CLOTHES to reply wrote: E > In article <1162851805.016486.188580@m73g2000cwd.googlegroups.com>,  > davidc@montagar.com writes:  > I >> Note that the licenses use checksum method 2, so you no longer have to @ >> enter in both the Termination Date and Release Date, just the >> termination date.   > 9 > Why are these two dates the same for hobbyist licenses?   I    That would define the last software release that can be used with the  0 PAK, and the last date that the PAK can be used.  @    The release date is analogous to the version of the software.  H    Software can contain an embedded software release date and a version E number, and the software can be used until the release date is newer  C than the value on the license PAK, or newer than the version limit   encoded on the PAK.   G    The termination date test is triggered when the current system date  B exceeds the termination date on the license PAK.  The PAK remains & functional up to the termination date.  F    The release date is typically associated with the software release E release, though various products have used the same release date for  F eons.  Embedding the same release date for multiple software releases 0 obviously effectively disables the release date.  G    The release date can be used for the warranty period, for instance,  F and transparently allows software upgrade(s) to any software releases I within that date range.  Like the version number, it puts an upper limit  A on the version -- but unlike the software version string and the  F associated upper version limit mechanism, the use of the release date D means you don't have to track the particular product version number 	 anywhere.   C    The termination date can be used for the loan of products.  The  0 hobbyist licenses use this mechanism, obviously.   ------------------------------   Date: 6 Nov 2006 15:30:48 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: PID of a batch job 3 Message-ID: <bwksbMIGW53W@eisner.encompasserve.org>   q In article <NDIFgprZcP2x@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: f > In article <1162776972.640071.254080@m73g2000cwd.googlegroups.com>, apogeusistemas@gmail.com writes:I >> How can I get process ID from a batch job , using a lexical function ? A >> I need get PID from a specified batch job to issue a stop/id .  > J >    That depends. What do you know about the batch job that you can start
 >    from?  / But using STOP/ID on a batch job is a bad idea.   ? It is much better to use the queue manager to stop a batch job.  --  N ==============================================================================0 DoD Instruction 8500.2 field test sites wanted -- 	http://www.LJK.com/LJK/8500_2_fieldtest.html N ==============================================================================   ------------------------------  $ Date: Tue, 7 Nov 2006 08:23:47 +11006 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>$ Subject: RE: Time change questions !X Message-ID: <0A7046B0A95F2B41B3712F0C5FD1CDC303BBE5@ex-tg2-pr.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C701EA.72FE2A27 . Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printable          -----Original Message-----B From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org] Sent: Tue 11/7/2006 12:59 AM To: Info-VAX@Mvb.Saic.Com $ Subject: Re: Time change questions ! =20 L In article <eihufu$8qk_001@s961.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv@aol.= com writes:  >=20? > If it were in DATE, it should have been easy to fix.  I don't ? > understand the reply to the SPR.  We knew how to ship FORTRAN 6 > patches and it was even politcally correct to do so.  G    Yes, it should have been easy to fix. I just don't recall seeing the     fix.   G    The DATE routine itself had to be "fixed" for Y2K.  The ANSI Fortran B    standard said in part that it returned the two digit year sinceE    1900, which was impossible to keep.  DATE now returns the last two 5    digits of the year and a new routine returns more.   A    Recently porting an app with DATE in it from VAX to Alpha, the E    compiler issued an informational message when it saw DATE, but the @    output of 06 was just what the original programmer would have6    expected (fortunately just to time stamp a report).    
 **********  L My solution to this was to write my own variants of DATE and IDATE using th=L e DATE_AND_TIME intrinsic: label all occurrences as EXTERNAL, ensure the ch=L aracter variable for DATE was *11 instead of *9 and fix any formatting acco= rdingly.   Regards, Paddy    G *********************************************************************** ; Please consider the environment before printing this email.   C "This electronic message and any attachments may contain privileged @ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advise D the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.   C If you have received the email in error, please notify TransGrid=20 C immediately.  Any views expressed in this email are those of the=20 ? individual sender except where the sender expressly and with=20 C authority states them to be the views of TransGrid.  TransGrid uses > virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************     ' ------_=_NextPart_001_01C701EA.72FE2A27 - Content-Type: text/html; charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printable   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> L <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7233.69">* <TITLE>RE: Time change questions !</TITLE> </HEAD>  <BODY>) <!-- Converted from text/plain format -->  <BR> <BR> <BR>  0 <P><FONT SIZE=3D2>-----Original Message-----<BR>L From: Bob Koehler [<A HREF=3D"mailto:koehler@eisner.nospam.encompasserve.or=: g">mailto:koehler@eisner.nospam.encompasserve.org</A>]<BR>  Sent: Tue 11/7/2006 12:59 AM<BR> To: Info-VAX@Mvb.Saic.Com<BR> ( Subject: Re: Time change questions !<BR> <BR>L In article &lt;eihufu$8qk_001@s961.apx1.sbo.ma.dialup.rcn.com&gt;, jmfbahci= v@aol.com writes:<BR>  &gt;<BR>K &gt; If it were in DATE, it should have been easy to fix.&nbsp; I don't<BR> K &gt; understand the reply to the SPR.&nbsp; We knew how to ship FORTRAN<BR> = &gt; patches and it was even politcally correct to do so.<BR>  <BR>L &nbsp;&nbsp; Yes, it should have been easy to fix. I just don't recall seei=
 ng the<BR> &nbsp;&nbsp; fix.<BR>  <BR>L &nbsp;&nbsp; The DATE routine itself had to be &quot;fixed&quot; for Y2K.&n= bsp; The ANSI Fortran<BR> L &nbsp;&nbsp; standard said in part that it returned the two digit year sinc= e<BR> L &nbsp;&nbsp; 1900, which was impossible to keep.&nbsp; DATE now returns the=
  last two<BR> C &nbsp;&nbsp; digits of the year and a new routine returns more.<BR>  <BR>L &nbsp;&nbsp; Recently porting an app with DATE in it from VAX to Alpha, the= <BR>L &nbsp;&nbsp; compiler issued an informational message when it saw DATE, but=  the<BR>L &nbsp;&nbsp; output of 06 was just what the original programmer would have<= BR> D &nbsp;&nbsp; expected (fortunately just to time stamp a report).<BR> <BR> <BR> **********<BR> <BR>L My solution to this was to write my own variants of DATE and IDATE using th=L e DATE_AND_TIME intrinsic: label all occurrences as EXTERNAL, ensure the ch=L aracter variable for DATE was *11 instead of *9 and fix any formatting acco= rdingly.<BR> <BR> Regards, Paddy<BR> </FONT>  </P>   <FONT SIZE=3D3><BR>  <BR>K ***********************************************************************<BR> ? Please consider the environment before printing this email.<BR>  <BR>G "This electronic message and any attachments may contain privileged<BR> B and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR> F the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>  <BR>E If you have received the email in error, please notify TransGrid <BR> E immediately.  Any views expressed in this email are those of the <BR> A individual sender except where the sender expressly and with <BR> G authority states them to be the views of TransGrid.  TransGrid uses<BR> B virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>  </FONT>  </BODY>  </HTML> ) ------_=_NextPart_001_01C701EA.72FE2A27--    ------------------------------   End of INFO-VAX 2006.612 ************************