1 INFO-VAX	Tue, 22 Nov 2005	Volume 2005 : Issue 652       Contents:! Re: $GETDVI suggestions requested ! Re: $GETDVI suggestions requested ! Re: $GETDVI suggestions requested ! Re: $GETDVI suggestions requested ! Re: $GETDVI suggestions requested & Re: ??==MacOSX burned VMS CD <CR><LF>.& Re: ??==MacOSX burned VMS CD <CR><LF>.& Re: ??==MacOSX burned VMS CD <CR><LF>.& Re: ??==MacOSX burned VMS CD <CR><LF>.& Re: ??==MacOSX burned VMS CD <CR><LF>.& Re: Alpha uArchitecture in the news...& Re: Alpha uArchitecture in the news...& Re: Alpha uArchitecture in the news...& Re: Alpha uArchitecture in the news...& Re: Alpha uArchitecture in the news... Re: Configure tips! Re: Debugger and FORTRAN INCLUDES - DECpark (Reading, UK) to close after 25 years  HP Component Excess For Sale RE: Need help with C program RE: Need help with C program" Upgrade a 5300A controller via CD?& Re: Upgrade a 5300A controller via CD? Uptimes Project (which one?) Re: VMS memory management  Re: VMS memory management M Re: Weird screen color ... greenish screens likely card-video incompatibility   F ----------------------------------------------------------------------  % Date: Tue, 22 Nov 2005 14:05:43 +0200 7 From: "Guy Peleg" <guy.peleg@remove_this_header@hp.com> * Subject: Re: $GETDVI suggestions requested, Message-ID: <4383099a$1@usenet01.boi.hp.com>  4 "Ken Robinson" <kenrbnsn@gmail.com> wrote in message< news:1132630528.822606.43750@z14g2000cwz.googlegroups.com... > Rob Brooks wrote: @ > > Note: This is a long message; anyone who quotes it fully (or substantially so) 9 > > in suggesting an new item code will be ignored by me.  > > -----------------  > > G > > Once again, I am soliciting suggestions for new $GETDVI item codes.  These L > > new item codes (as all others) will also be available via LIB$GETDVI and3 > > F$GETDVI.  They will be for Alpha and I64 only.  > G > Not a suggestion for a new item (or maybe it is). It would be nice to I > get values like freeblocks in bytes like we now can in DCL. Perhaps you ( > can honor the value of SET PROC/UNITS.  C V8.3 will add a new lexical function - F$CUNITS to converts various I units, currently it can only handle converting blocks to bytes, using the  new 	 function:   5 IPL31> write sys$output f$getdvi("dsa0","freeblocks")  26431038> IPL31> write sys$output f$cunit(f$getdvi("dsa0","freeblocks")) 12.60GB  IPL31>     > D > A new item that would be nice would be percent_free (space left on= > volume), so we wouldn't have to fake decimal math with DCL.  > I > One more "nice" thing to have -- a way to get a comma seperated list of H > settings that are represented by a returned HEX number for things like > DEVCHAR, DEVCHAR2, etc.  >  > Ken Robinson > VMS System Engineer  > eSpeed >    ------------------------------  % Date: Tue, 22 Nov 2005 08:59:31 -0500 * From: "Syltrem" <syltremzulu@videotron.ca>* Subject: Re: $GETDVI suggestions requested/ Message-ID: <11o691qgj7tr46@corp.supernews.com>   C "Guy Peleg" <guy.peleg@remove_this_header@hp.com> wrote in message  & news:4383099a$1@usenet01.boi.hp.com...  E > V8.3 will add a new lexical function - F$CUNITS to converts various K > units, currently it can only handle converting blocks to bytes, using the  > new  > function:  > 7 > IPL31> write sys$output f$getdvi("dsa0","freeblocks") 
 > 26431038@ > IPL31> write sys$output f$cunit(f$getdvi("dsa0","freeblocks"))	 > 12.60GB  > IPL31> >    Guy,  J Why f$cunits, and not f$CVunits when we already have f$CVtime, f$CVsi and  f$CVui? @ All other Conversion lexicals start with CV... easy to remember.  G BTW this is most useful ! Doing it in DCL with integers only, has some  K limitations.. although there's supposed to be a f$math or something coming   soon (you talked about this).    Thanks!  Syltrem    ------------------------------    Date: 22 Nov 2005 10:07:48 -0600. From: brooks@cuebid.zko.hp.nospam (Rob Brooks)* Subject: Re: $GETDVI suggestions requested, Message-ID: <jDnvdx6mF40s@cuebid.zko.hp.com>  + "Ken Robinson" <kenrbnsn@gmail.com> writes:   I > One more "nice" thing to have -- a way to get a comma seperated list of H > settings that are represented by a returned HEX number for things like > DEVCHAR, DEVCHAR2, etc.   M The supported way to get that information is to use each individual item code O that corresponds to the bit of interest in the various status bytes, words, and 
 longwords.   --    L Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.hp.com   ------------------------------    Date: 22 Nov 2005 07:56:00 -0800! From: kenneth.randell@verizon.net * Subject: Re: $GETDVI suggestions requestedC Message-ID: <1132674960.128444.244850@o13g2000cwo.googlegroups.com>   " Well, for mounted disks, how about   VCB$L_WINDOW
 VCB$L_SPL_CNT 
 VCB$L_PENDERR   = There are also pointers to new 'interesting' values, such as:    VCB$L_READS  VCB$L_WRITES VCB$L_SPLIT_IO  C but using SDA shows these values are not being updated, or at least 0 remain at 0 on my systems running 8.2 and 8.2-1.   ------------------------------    Date: 22 Nov 2005 11:35:18 -0600. From: brooks@cuebid.zko.hp.nospam (Rob Brooks)* Subject: Re: $GETDVI suggestions requested, Message-ID: <e$dN0bPM6t0w@cuebid.zko.hp.com>  g In article <1132674960.128444.244850@o13g2000cwo.googlegroups.com>, kenneth.randell@verizon.net writes: $ > Well, for mounted disks, how about >  > VCB$L_WINDOW > VCB$L_SPL_CNT  > VCB$L_PENDERR    	Yup, sure, I'll add those.   ? > There are also pointers to new 'interesting' values, such as:  > 
 > VCB$L_READS  > VCB$L_WRITES > VCB$L_SPLIT_IO > E > but using SDA shows these values are not being updated, or at least 2 > remain at 0 on my systems running 8.2 and 8.2-1.  H Right; I don't know for what purpose they were added.  Unless I can findJ out more about why they were added, I'll won't create item codes for them.     --    L Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.hp.com   ------------------------------  % Date: Tue, 22 Nov 2005 08:04:18 +0100 + From: Karsten Nyblad <nospam@nospam.nospam> / Subject: Re: ??==MacOSX burned VMS CD <CR><LF>. = Message-ID: <4382c2e3$0$67262$157c6196@dreader2.cybercity.dk>    Hans M. Aus wrote:K > How do I burn a VMS CD with text files so that the CR and LF are handled   > correctly? > I > I have tried to burn CDs with Disk Utility and Toast but the CR and LF  K > are subsequently not handled correctly in the VMS Editor. The text lines  J > contain <CR><LF> and the line runs off the screen. The remainder of the  > text seems to be fine. > D > How to I make an exact copy of the CD with OSX including the file 
 > attributes?   G VMS has a number of record formats.  Normally text files are stored as  I records each containing one line.  Each record starts with the length of  G the line stored in two bytes followed by the characters each stored in  E one byte.  If the length of the line is not even, then the record is  I patted with a zero byte because some of the first disk controllers could  E only read and write starting on even byte boundaries.  Then the next   record follows, etc.  F However, VMS also has two record formats called stream and stream_lf, H where records are terminated by <CR><LF> and <LF>, respectively.  These I two formats are similar to how files are stored on Windows and Unix (Mac  G OS X), respectively.  You may want to make sure that your files are in   one of these formats.   I You can convert an ordinary VMS text file to one of these formats by the  F convert/FDL utility.  The FDL file you will need is easiest to create I with edit/fdl.  All you need to do is making and FDL file that has a the  ! record format set as stream(_lf).   F VMS knows the record format from some bits stored separately from the < file in the file system.  You can set these bits by the SET F FILE/ATTRIBUTES, and then VMS will interpret the bytes of the file as C told by the new bits.  Be sure to have a backup of the file before   playing with this utility.  I Further, there is a utility called exchange/network, that can be used to  G change the lay out of the file, but you will most likely not need that.    ------------------------------    Date: 22 Nov 2005 07:06:57 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: ??==MacOSX burned VMS CD <CR><LF>. 3 Message-ID: <tPDB$szpf1a8@eisner.encompasserve.org>   \ In article <cIrgf.32740$6e1.9217@newssvr14.news.prodigy.com>, "Jim" <j.n@nospam.com> writes:  K > Don't Unix systems assume that all text files are delimited by CR and LF?   B    No, the convention on UNIX is lines of text are separated by LF#    alone.  Windows uses CRLF pairs.   L > Anyway, the normal file on VMS is VFC.  The editor may have a way to read  > files with CR-LF attributes.I > You probably should use the Convert utility to change the files to VFC.   E    The editor is perfectly happy to read files with CR-LF attributes, F    since it uses RMS.  The problem is there is no RMS attribute to sayH    so.  MOUNT/UNDEFINED_FAT=STREAM tells RMS to assume CR-LF attributes.F    CONVERT probably also would need to know what RMS attributes it was9    converting from.  The OP needs a capability similar to A    SET FILE/ATTRIBUTES; for a CD that's what /UNDEFINED_FAT does.    ------------------------------    Date: 22 Nov 2005 07:13:10 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: ??==MacOSX burned VMS CD <CR><LF>. 3 Message-ID: <68tM50Xbmt8J@eisner.encompasserve.org>   k In article <4382c2e3$0$67262$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > H > However, VMS also has two record formats called stream and stream_lf, J > where records are terminated by <CR><LF> and <LF>, respectively.  These K > two formats are similar to how files are stored on Windows and Unix (Mac  I > OS X), respectively.  You may want to make sure that your files are in   > one of these formats.   G    Because of it's pre-OS X history, Macs store text files in a variety D    of formats, and utilities which run on Macs will deal with all ofE    them.  For example, when I edit files on Mac I use an editor which B    will allow me to choose LF, CRLF, or CR record separators.  TheB    consequences of that choice are my problem, but it allows me to6    interface to whatever the next application expects.   ------------------------------    Date: 22 Nov 2005 06:41:29 -0800, From: "rcyoung" <rcyoung@aliconsultants.com>/ Subject: Re: ??==MacOSX burned VMS CD <CR><LF>. C Message-ID: <1132670489.257618.144090@f14g2000cwb.googlegroups.com>   B You see a similar problem when you FTP text files to a VMS system.F There are many discussions on OpenVMS/FTP on how to "fix" the problem.+ I think something similar would assist you.    ------------------------------  + Date: Tue, 22 Nov 2005 11:44:37 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)/ Subject: Re: ??==MacOSX burned VMS CD <CR><LF>. 2 Message-ID: <05112211443727_2038971B@antinode.org>  , From: "rcyoung" <rcyoung@aliconsultants.com>  D > You see a similar problem when you FTP text files to a VMS system.  6    Not if you use ASCII mode instead of binary in FTP.  H > There are many discussions on OpenVMS/FTP on how to "fix" the problem.- > I think something similar would assist you.   3    Not if the goal is to work directly from the CD.   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------    Date: 22 Nov 2005 09:25:11 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)/ Subject: Re: Alpha uArchitecture in the news... , Message-ID: <4382e3f7$1@news.langstoeger.at>  d In article <Nprgf.978$e43.129242@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:G >For anyone who is interested, the Nov-2005 issue of COMPUTER (an IEEE  J >publication) contains an article comparing some characteristics of Alpha L >EV3, EV4, EV5, EV6, and EV8. (I'm not sure why this last entry isn't EV7). , >It is co-written by an author from HP LABS.  @ Strange. Where did EV3 live ? Not in real/sold products I think.   --   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: 22 Nov 2005 01:27:49 -0800+ From: "Lee Morgan" <leemorgan@ntlworld.com> / Subject: Re: Alpha uArchitecture in the news... C Message-ID: <1132651669.108660.231520@z14g2000cwz.googlegroups.com>    Hi  ! Is this article available online?   > I am in the UK and am unable to source a copy of the magazine.   Thanks.    ------------------------------  % Date: Tue, 22 Nov 2005 07:52:02 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> / Subject: Re: Alpha uArchitecture in the news... : Message-ID: <MvEgf.11454$gK4.341804@news20.bellglobal.com>  7 "Lee Morgan" <leemorgan@ntlworld.com> wrote in message  = news:1132651669.108660.231520@z14g2000cwz.googlegroups.com...  > Hi > # > Is this article available online?  > @ > I am in the UK and am unable to source a copy of the magazine. > 	 > Thanks.  > L Here is the URL for the online portion of the magazine but I think you need + to be an IEEE member to view most articles.   4 http://www.computer.org/portal/site/ieeecs/index.jsp  > The title of the article I referred to is "Heterogeneous Chip  Multiprocessors"  K p.s. Ii isn't so much an article about Alpha as it is an article about why  J larger chip areas is less rewarding than going to multicores. Having said H this, let me add my own 2 cents worth: I don't see that much difference L between multicores and multi-CPUs (SMP). There might not be any good reason F to continue with the development and production of EV8, but there was J probably no need to kill off EV7. Probably something like the AlphaServer L GS-1280 is where the industry wants to end up, but HP is already there with  a finished product.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  + Date: Tue, 22 Nov 2005 16:38:22 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) / Subject: Re: Alpha uArchitecture in the news... ( Message-ID: <dlvhhu$qh3$1@pcls4.std.com>  8 peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:  e >In article <Nprgf.978$e43.129242@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: H >>For anyone who is interested, the Nov-2005 issue of COMPUTER (an IEEE K >>publication) contains an article comparing some characteristics of Alpha  M >>EV3, EV4, EV5, EV6, and EV8. (I'm not sure why this last entry isn't EV7).    A >Strange. Where did EV3 live ? Not in real/sold products I think.   F If I recall, it was a prototype only, used for Alpha code development.H It had no floating point instructions, but other than that I don't know  anything about it.   ------------------------------  % Date: Tue, 22 Nov 2005 13:09:58 -0500 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: Alpha uArchitecture in the news... 0 Message-ID: <11o6nmm7grcin99@corp.supernews.com>    Peter 'EPLAN' LANGSTOEGER wrote:f > In article <Nprgf.978$e43.129242@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: > H >>For anyone who is interested, the Nov-2005 issue of COMPUTER (an IEEE K >>publication) contains an article comparing some characteristics of Alpha  M >>EV3, EV4, EV5, EV6, and EV8. (I'm not sure why this last entry isn't EV7).  - >>It is co-written by an author from HP LABS.  >  > B > Strange. Where did EV3 live ? Not in real/sold products I think. >   H No, but the hardware engineers would have known of it.  The progression E from EV3 to EV4 and production would be of interest to CPU designers.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 22 Nov 2005 11:19:21 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network>  Subject: Re: Configure tips ; Message-ID: <1NqdnWRFI6uR2B7enZ2dnUVZ_tydnZ2d@adelphia.com>    Martin Borgman wrote: 
 > Hi John, > J > you're missing one of the most important options in "UNIX" porting. The H > CRTL feature switches. With these feature switches you can change the 1 > CRTL's behavior to a more "UNIX" like behavior.   D I was focusing mainly on what it takes to get through or around the K Configure step.  To discuss every possible thing would be a very long post.   J > And since you mention getopt, yes you can change getopts behavior to be : > case sensitive. The way "UNIX" programs expect it to be.  I Actually the reason that I would have to use the GNU getopts behavior is  ( to get the long parameter name handling.  C > Just look at the GNV sources and particularly at vms_crtl_init.c.   B I am very familiar with some of the GNV sources, and have several C changes in the queue to be tested and integrated by the current HP  / internal group that is responsible for the kit.   E > For a short introduction of how this works, please read the porting 6 > guide at <http://www.oooovms.dyndns.org/reference/>.  D For: http://www.oooovms.dyndns.org/reference/guide_19-jul-2005.pdf :   Page 30, discussion on fork().  I If a program has a MS-DOS/Microsoft Windows variant, instead of fork, it  A will use run-time library calls of spawnXX() with the "XX" being  D replaced with characters that indicate how the arguments are passed.  E I have not tested this, but it appears that this might be able to be  H implemented with either a static procedure or a macro using vfork() and H the corresponding execXX() functions, which means less modifications to  the original source.  B For Page 35, the example of M4.  According to my build notes, the C current version of M4 is 1.4.3 and it has a good enough version of  B config.guess so that the --build option is not needed.  I did use:  ' bash$ export GNV_DISABLE_DCL_FALLBACK=1 2 bash$ ./configure --prefix=/usr --exec-prefix=/usr  G I also set up SYS$POSIX root as a search list so that I could even run   the install step.   : $! Hack so make install will work for non privileged users; $!--------------------------------------------------------- @ $define new_gnu DSKWLD$DKA100:[project_root.gnu.]/job/trans=conc/ $save_gnu = f$trnlnm("GNU","LNM$SYSTEM_TABLE"); ) $define old_gnu 'save_gnu'/job/trans=conc ! $define gnu new_gnu:,old_gnu:/job % $create/dir new_gnu:[bin]/prot=o:rwed ) $create/dir new_gnu:[usr.bin]/prot=o:rwed - $create/dir new_gnu:[usr.include]/prot=o:rwed ) $create/dir new_gnu:[usr.lib]/prot=o:rwed + $create/dir new_gnu:[usr.local]/prot=o:rwed + $create/dir new_gnu:[usr.share]/prot=o:rwed * $define sys$posix_root new_gnu,old_gnu/job    G This was before I modified the [.wrapper]cc.c file to be a little more  @ friendly to both VMS and UNIX scripts.  I am testing a GNV_CC_* G environment to auto-magically select a first include file based on the   module name.  " $ type lcl_root:setup_m4_build.com; $cc :== CC/FIRST_INCLUDE=PRJ_ROOT:[M4-1^.4^.3]M4_VMS_1INC.H $ $define DECC$ACL_ACCESS_CHECK ENABLE+ $define DECC$ALLOW_REMOVE_OPEN_FILES ENABLE 
 [end-of-file]   ) $ type lcl_root:[m4-1^.4^.3]M4_VMS_1INC.H ! /* missing include in getopt.c */  #include <string.h>    /* Hide DECC getopt */ #include <unistd.h>  #define getopt gnu_getopt  #define optarg gnu_optarg  #define optopt gnu_optopt  #define optind gnu_optind  #define opterr gnu_opterr   . /* Missing include of stdlib.h in obstack.c */2 /* If we include stdlib.h, it breaks configure  */2 /* because the temporary c files created by     */2 /* configure have prototypes that conflict with */2 /* the built in ANSI prototyped headers         */ void abort(void); 
 [end-of-file]   F The write locked source is on src_root: and the build directory is on I lcl_root: with prj_root being a search list of lcl_root:,src_root:.  And  ; I set my default to be prj_root:[m4-1^.4^.3] for the build.   F I did not link in a lib$initialize program on the build that I did, I , was depending on the DECC$ feature logicals.  I With the version of the CC wrapper that I am currently testing, I should  G be able to add a suitable lib$initialize section in with out modifying   the build scripts.    1 For http://www.oooovms.dyndns.org/reference/ht/ :   I I expect item #2 to no longer be needed with a future release of the GNV   kit.  I Item #3 means that the project now has an out of date config.guess file,  G and it is time for the maintainers of the mainstream of the project to  D get a newer one, which is needed for both OpenVMS support and other 
 platforms.     -John  wb8tyw@qsl.network! malmberg@dskwld.zko.hp.compaq.dec  Personal Opinion Only    ------------------------------    Date: 22 Nov 2005 07:01:28 -0800* From: "Steve Kulpa" <stevekulpa@yahoo.com>* Subject: Re: Debugger and FORTRAN INCLUDESC Message-ID: <1132671688.711995.282720@g44g2000cwa.googlegroups.com>   G Agreed, as that's how I used to do it back at the old job.  I suggested A that we use libraries and such when I first started, but that was E poo-pooed and now that I've been here for 6 months and understand the F system better, I see why.  Problem is, this software system gets movedC from Development, to Marketing Testing, then from there to QA, then D from there to Production, and the 'mover' utility moves source code,C and then recompiles and links on the new system, but can not handle C libraries when it links (don't ask me, I didn't write it).  to make F matters worse, it works fine that way and it's a critical system, so I0 doubt I would win any fight to change the mover.   -sigh  steve    ------------------------------  % Date: Tue, 22 Nov 2005 13:20:50 +0000  From: Roy Omond <Roy@Omond.net> 6 Subject: DECpark (Reading, UK) to close after 25 years4 Message-ID: <dlv5vi$c92$1$8302bc10@news.demon.co.uk>  8 I have just heard that it will soon be announced that HP8 is to close the DECpark (Worton Grange, Reading) site as' part of its headquarters consolidation.    Sad.   ------------------------------    Date: 22 Nov 2005 07:12:27 -0800 From: markv@advantageic.com % Subject: HP Component Excess For Sale C Message-ID: <1132672347.195341.287580@g14g2000cwa.googlegroups.com>   A We have the below HP components available for purchase at a great 5 price. These items are fully tested and we need bids.           & 16 HP A783869001 73GB SCSI HARD DRIVES   16 HP A683460001 1024MB RAM   ! 8  HP A778460501 16BIT SOUND CARD    8 HP A723166450 PCI BACKPLANE   * 8 COMPAQ 313287001 FIRE GLX1 GRAPHICS CARD  $ 16 HP A966662010 1.3GHZ ITANIUM CPUS  # 8 HP A723166510 ZX6000 SYSTEM BOARD    8 HP A723166550 STATUS BOARD   8 HP A723162012 SLIM DVDROM    8 HP 09504119 650W POWER SUPPLY            Mark Vaudreuil
 Senior Trader  Advantage Components, Inc. Acton, MA 01720  Email: Markv@Advantageic.com Phone: (978) 264-0700 EXT 802  Fax: (978) 266-1411    ------------------------------  % Date: Tue, 22 Nov 2005 08:33:08 -0500 # From: "Dan Allen" <dallen@nist.gov> % Subject: RE: Need help with C program : Message-ID: <JFEPKAPBPMDFDBOIANGDMEMNHAAA.dallen@nist.gov>  C > I was just going to let it go, but this is the kind of thing that C > really gets me.  People bitch about all the bad C code out there. A > Well, there's your reason.  Code written by someone who doesn't D > know the language and has no intention to learn anything about it.E > And then when some program crashes and destroys all their important C > data or some hacker gets in using a buffer overflow or some other 2 > well now exploit, C gets the blame!!  Go figure. >   I Come on Bill that could never happen here - he's using VMS descriptors...    Sorry, couldn't help myself ;-)    Dan    > bill >  > --  L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |C > Scranton, Pennsylvania   |         #include <std.disclaimer.h>     >    ------------------------------    Date: 22 Nov 2005 08:47:36 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) % Subject: RE: Need help with C program 3 Message-ID: <NC72yuT$MA+w@eisner.encompasserve.org>   ` In article <JFEPKAPBPMDFDBOIANGDMEMNHAAA.dallen@nist.gov>, "Dan Allen" <dallen@nist.gov> writes:D >> I was just going to let it go, but this is the kind of thing thatD >> really gets me.  People bitch about all the bad C code out there.B >> Well, there's your reason.  Code written by someone who doesn'tE >> know the language and has no intention to learn anything about it. F >> And then when some program crashes and destroys all their importantD >> data or some hacker gets in using a buffer overflow or some other3 >> well now exploit, C gets the blame!!  Go figure.  >>   > K > Come on Bill that could never happen here - he's using VMS descriptors...   E Unlike superior languages, C requires that descriptors be constructed 1 by hand, for instance with the macro $DESCRIPTOR.    ------------------------------  + Date: Tue, 22 Nov 2005 16:23:09 +0000 (UTC) < From: gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann)+ Subject: Upgrade a 5300A controller via CD? ) Message-ID: <dlvgld$nq4$1@news.BelWue.DE>    Hello,  L in my DS25 there is a raid controller 5300a. I downloaded a new firmware forN this controller. Unfortunately the DS25 has no floppy. According to the manualO an upgrade via the CD/DVD should be possible as well. The question is: how do I M do that? I burned an ISO CD on a PC and put the unzipped firmware file on it. N But it was not recognized. Thus, what else is necessary to create a proper CD?   Regards,    Christoph Gartmann    --  E  Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452   ImmunbiologieI  Postfach 1169                 Internet: gartmann@immunbio dot mpg dot de   D-79011  Freiburg, Germany 9                http://www.immunbio.mpg.de/home/menue.html    ------------------------------  + Date: Tue, 22 Nov 2005 11:29:49 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)/ Subject: Re: Upgrade a 5300A controller via CD? 2 Message-ID: <05112211294945_2038971B@antinode.org>  < From: gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann)  N > in my DS25 there is a raid controller 5300a. I downloaded a new firmware forP > this controller. Unfortunately the DS25 has no floppy. According to the manualQ > an upgrade via the CD/DVD should be possible as well. The question is: how do I O > do that? I burned an ISO CD on a PC and put the unzipped firmware file on it. P > But it was not recognized. Thus, what else is necessary to create a proper CD?  *    What does "it was not recognized" mean?  B    If you disclosed what you did on the PC, and with what, someone? (else) might be able to say what went wrong there, if anything.   D    I'd expect VMS of the version you're using (which is what, by theD way?) to "recognize" a real ISO 9660 CD just fine.  It's hard to sayE "what else is necessary" when given so few clues to what you actually  did.    ?    Your first step would be to provide a useful problem report,  including facts like:   G    1. What you did.  (Hint: "Something on a PC, something on a DS25" is !       not sufficiently detailed.)   H    2. What you did it with.  (Hint: "A PC (running comething) and a DS254       (running VMS?)" is not sufficiently detailed.)  A    3. What happened.  (Hint: "It didn't work" is not sufficiently        detailed.)  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------    Date: 22 Nov 2005 12:11:46 -06004 From: kuhrt.nospammy@encompasserve.org (Marty Kuhrt)% Subject: Uptimes Project (which one?) 3 Message-ID: <5unv8CCcwNiA@eisner.encompasserve.org>   7 Anyone know what is happening with the Uptimes Project?   7 A while back it was migrated off of hostingwired.com to A lp-musix.net which meant that the client had to be updated.  Then A around the third of November there was a message on lp-musix that : said hostingwired demanded it back, and they were going to4 continue on with the project at uptimes-project.org.  = There seem to be active VMS clients on all three.  None of my ? accounts work on hostingwired or lp-musix.   Which host are the A cov bicker bunch using most?  Should we (the coven) start our own  uptime project host?   ------------------------------  # Date: Tue, 22 Nov 2005 15:06:44 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) " Subject: Re: VMS memory management- Message-ID: <8uGgf.32$oH2.5@news.cpqcorp.net>   - In article <437b4f90$1@news.langstoeger.at>,  8 peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes: .. >Better contact the ISV ...  ..    This is an excellent suggestion.> It is very likely they know more about the application and its2 memory needs/problems than general OpenVMS people.   --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 22 Nov 2005 07:15:43 -0800* From: "Steve Kulpa" <stevekulpa@yahoo.com>" Subject: Re: VMS memory managementB Message-ID: <1132672543.831119.93480@o13g2000cwo.googlegroups.com>  G I had an application that did pretty much the same thing. turned out to G be a routine that was using dynamic memory to work a stack, and was not C 'putting it back' properly.  After a couple of days, it would be so E hacked up that the program just sat there thrashing while it tried to F manipulate the stack.  Once the fix was made to properly return popped" stack entries, all was well again.   steve    ------------------------------    Date: 22 Nov 2005 06:33:15 -0800( From: "pbritto" <britto.paulo@gmail.com>V Subject: Re: Weird screen color ... greenish screens likely card-video incompatibilityC Message-ID: <1132669995.794575.116080@f14g2000cwb.googlegroups.com>   E It's a HD15 at the monitor end, I don't have a Philips here but if it 3 works with a Philips it should work with this HP!!! G Do you set anything in STARTUP_VMS to get it to work with your Philips? E did you ever change anything regard to color setting or card settings  in the STARTUP_VMS ?   Rich Jordan wrote:G > The ZLXp-E series cards had an issue where teh ground for the 'green' H > signal was floating on the card; DEC monitor cables of the appropriateD > type grounded the green signal.  When using the card with a peeceeE > monitor and cable, you'd get fringing and ringing and other display G > artifacts.  I don't know if the -L series had the same feature, and I G > don't recall anyone getting just dark green; that makes it sound like 8 > one or more of the color feeds is not getting through. > H > In the -E cards' case the solution was to tie the green ground line onF > the card to one or both of the other color signal grounds.  Again, II > have no idea if the -L cards have the problem or would benefit from the  > 'fix'. > G > Is the monitor using BNC connectors or HD15 (at the monitor end)?  If C > BNC, then you need to make sure you have enabled SYNC ON GREEN at E > console level on the Alpha (no references handy for the environment A > variable, sorry).  You could also try swapping the red and blue H > connections to see if you get a color shift, but not the green (you'll
 > lose sync).  > E > If the monitor is HD15 then it should get the separate sync signals  > from the cable.  > F > No other ideas, sorry.  my -L1 card worked very well with a standard- > Philips SVGA monitor, and with a DEC VRC21.    ------------------------------   End of INFO-VAX 2005.652 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                