INFO-VAX Fri, 21 Sep 2007 Volume 2007 : Issue 516 Contents: Re: Command fails in batch, seems to work at-ed interactively Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: Hypervisor Re: Hypervisor Re: Hypervisor Selling: DL145 Dual Core Opteron Selling: DL145 Dual Core Opteron Re: tz88 - green-brick for BA350 shelf Re: Xyplex Terminal Server with VMS ---------------------------------------------------------------------- Date: Fri, 21 Sep 2007 10:35:56 -0400 From: norm.raphael@metso.com Subject: Re: Command fails in batch, seems to work at-ed interactively Message-ID: This is a multipart message in MIME format. --=_alternative 005031AF8525735D_= Content-Type: text/plain; charset="US-ASCII" AEF wrote on 09/20/2007 08:40:26 PM: > On Sep 20, 9:39 am, norm.raph...@metso.com wrote: > > AEF wrote on 09/19/2007 08:23:02 PM: > > > > > > > > > On Sep 19, 8:19 pm, David J Dachtera > > > wrote: > > > > AEF wrote: > > > > > > > On Sep 17, 9:33 pm, Doug Phillips wrote: > > > > > > On Sep 17, 8:26 pm, David J Dachtera > > > > > > wrote: > > > > > > > > > Doug Phillips wrote: > > > > > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote: > > > > > > > > > This code checks for an empty or blanked PostalZip field. > > > > > > > > > When run inside the batch, is seems to give a > > different,incorrect > > > > > > > > > result then when the code is extracted to another procedure > > file > > > > > > > > > and run against the renamed data file. > > > > > > > > > In this case there is a match and Sever is "1". > > > > > > > > > In the nomatch case Sever is "3". > > > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a > > wrong > > > > > > > > > result as there should have been a match. > > > > > > > > > Why would the same code fail to work and later work on the > > renamed > > > > > > > > > file. (The diff command is to eliminate the trailing > > > spaces first.) > > > > > > > > > [OpenVMS Alpha V7.3-1] > > > > > > > > > === Actual log excerpt: > > > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384 > > bytes. > > > > > > > > > QUIT > > > > > > > > > <221 > > > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA] > > > FRONTIER_ATO.XML;1;" > > > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1" > > > > > > > > > $ > > > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR. > > > XML_*;",,,,"SYNTAX_ONLY"),3) > > > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA] > > > FRONTIER_ATO.XML;1;" > > > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA] > > > FRONTIER_ATO.XML;1; nl: > > > > > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1;) a > > > posting typo > > > > > > > > or is it really in your command? > > > > > > > > > Interesting thought; however, ... > > > > > > > > > DJAS02::DDACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl: > > > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of > > > special characters > > > > > > > \;NL\ > > > > > > > DJAS02::DDACHTERA$ sh sym $status > > > > > > > $STATUS == "%X00038110" > > > > > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.) > > > > > > > > > Gives a different message/status. > > > > > > > > Yes it does. It pipes the error to the next command, but it > > doesn't > > > > > > display it. The $status is from the last command in the pipe, no? > > > > > > > Apparently so! See below. > > > > > > > Try > > > > > > piping it your example. Here's mine: > > > > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe > > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > > > > characters > > > > > > \;NL\ > > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search > > sys$pipe > > > > > > "whatever" > > > > > > %SEARCH-I-NOMATCHES, no strings matched > > > > > > > Yes, this extra semicolon appears to be the cause of the problem: > > > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET > > > > > %SEARCH-I-NOMATCHES, no strings matched > > > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET > > > > > 2 $ set noon > > > > > 7 $ set terminal/inquire/noeightbit/INSERT/FORM > > > > > $ > > > > > > > Apparently, errors in the first steps aren't reported to SYS$ERROR > > or > > > > > SYS$ERROR isn't the screen until the last command is run (deja vu: > > why > > > > > is this only a warning?!): > > > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > > > characters > > > > > $ > > > > > > > This looks like a good reason _not_ to use PIPE in a command > > > > > procedure. In this case it saves you from working with temporary > > files > > > > > and their cleanup but makes troubleshooting more difficult. Friendly > > > > > comments welcome on this. > > > > > > I wouldn't go quite that far. Yes it complicates debugging; however > > see: > > > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE > > > > > > ...for an example of TEE.COM that you can insert into the pipeline and > > see > > > > what's actually being PIPEd into SEARCH, in this case. > > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET > > > > > > Probably only works on-line. In batch, send the TEE output to a disk > > file. > > > > > > -- > > > > David J Dachtera > > > > dba DJE Systemshttp://www.djesys.com/ > > > > > > Unofficial OpenVMS Marketing Home > > > > Pagehttp://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/ > > > > > OK, thanks. > > > > > AEF > > > > Points taken, but in this case (I covered myself with the "seems" in the > > subject) > > the debugging problem was "old eyes" as I failed to see the typo-induced > > extra > > ";" from the calling procedure, so none of these issues would have helped > > bring > > to light the problem in a "test" scenerio; the real problem, not being > > understood, > > was not presented to the testing. > > But what about this: > > Here's the relevant log snippet: > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML; > 1;" > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl: > /nonumb | - > sear sys$pipe ""/window=(0,6)/mat=or/exact/nonumb | > - > sear sys$pipe "" /exact/nonumb | - > sear sys$pipe "> ","><"/exact/out=nl: > %SEARCH-I-NOMATCHES, no strings matched > > Now, suppose instead of using PIPE you did this: > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML; > 1;" > $ diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl: > /nonumb > > > The error message from the DIFF would tell you right away what the > problem was, no? Yes, but the sequence is 1) test with a filename without substitution 2) Call the procedure from a higher-level procedure with a filename without substitution. 3) Call the procedure from a higher-level procedure with a substituted filename. and the error was a typo in the calling procedure which did not - as you have pointed out clearly - display because pipe hides it from sys$error and sys$output, but the pipe command had already been tested. So again, the problem was really "old eyes." > > AEF > --=_alternative 005031AF8525735D_= Content-Type: text/html; charset="US-ASCII"



AEF <spamsink2001@yahoo.com> wrote on 09/20/2007 08:40:26 PM:

> On Sep 20, 9:39 am, norm.raph...@metso.com wrote:
> > AEF <spamsink2...@yahoo.com> wrote on 09/19/2007 08:23:02 PM:
> >
> >
> >
> > > On Sep 19, 8:19 pm, David J Dachtera <djesys...@spam.comcast.net>
> > > wrote:
> > > > AEF wrote:
> >
> > > > > On Sep 17, 9:33 pm, Doug Phillips <dphil...@netscape.net> wrote:
> > > > > > On Sep 17, 8:26 pm, David J Dachtera <djesys...@spam.comcast.net>
> > > > > > wrote:
> >
> > > > > > > Doug Phillips wrote:
> >
> > > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote:
> > > > > > > > > This code checks for an empty or blanked PostalZip field.
> > > > > > > > > When run inside the batch, is seems to give a
> > different,incorrect
> > > > > > > > > result then when the code is extracted to another procedure
> > file
> > > > > > > > > and run against the renamed data file.
> > > > > > > > > In this case there is a match and Sever is "1".
> > > > > > > > > In the nomatch case Sever is "3".
> > > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a
> > wrong
> > > > > > > > > result as there should have been a match.
> > > > > > > > > Why would the same code fail to work and later work on the
> > renamed
> > > > > > > > > file.  (The diff command is to eliminate the trailing
> > > spaces first.)
> > > > > > > > > [OpenVMS Alpha V7.3-1]
> > > > > > > > > === Actual log excerpt:
> > > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384
> > bytes.
> > > > > > > > > QUIT
> > > > > > > > > <221
> > > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA]
> > > FRONTIER_ATO.XML;1;"
> > > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1"
> > > > > > > > > $
> > > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR.
> > > XML_*;",,,,"SYNTAX_ONLY"),3)
> > > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]
> > > FRONTIER_ATO.XML;1;"
> > > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]
> > > FRONTIER_ATO.XML;1;  nl:
> >
> > > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1;) a
> > > posting typo
> > > > > > > > or is it really in your command?
> >
> > > > > > > Interesting thought; however, ...
> >
> > > > > > > DJAS02::DDACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl:
> > > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of
> > > special characters
> > > > > > >  \;NL\
> > > > > > > DJAS02::DDACHTERA$ sh sym $status
> > > > > > >   $STATUS == "%X00038110"
> >
> > > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.)
> >
> > > > > > > Gives a different message/status.
> >
> > > > > > Yes it does. It pipes the error to the next command, but it
> > doesn't
> > > > > > display it. The $status is from the last command in the pipe, no?
> >
> > > > > Apparently so! See below.
> >
> > > > >  Try
> > > > > > piping it your example. Here's mine:
> >
> > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe
> > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
> > > > > > characters
> > > > > >  \;NL\
> > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search
> > sys$pipe
> > > > > > "whatever"
> > > > > > %SEARCH-I-NOMATCHES, no strings matched
> >
> > > > > Yes, this extra semicolon appears to be the cause of the problem:
> >
> > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET
> > > > > %SEARCH-I-NOMATCHES, no strings matched
> > > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET
> > > > >     2   $ set noon
> > > > >     7   $ set terminal/inquire/noeightbit/INSERT/FORM
> > > > > $
> >
> > > > > Apparently, errors in the first steps aren't reported to SYS$ERROR
> > or
> > > > > SYS$ERROR isn't the screen until the last command is run (deja vu:
> > why
> > > > > is this only a warning?!):
> >
> > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid
> > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
> > > > > characters
> > > > > $
> >
> > > > > This looks like a good reason _not_ to use PIPE in a command
> > > > > procedure. In this case it saves you from working with temporary
> > files
> > > > > and their cleanup but makes troubleshooting more difficult. Friendly
> > > > > comments welcome on this.
> >
> > > > I wouldn't go quite that far. Yes it complicates debugging; however
> > see:
> > > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE
> >
> > > > ...for an example of TEE.COM that you can insert into the pipeline and
> > see
> > > > what's actually being PIPEd into SEARCH, in this case.
> >
> > > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET
> >
> > > > Probably only works on-line. In batch, send the TEE output to a disk
> > file.
> >
> > > > --
> > > > David J Dachtera
> > > > dba DJE Systemshttp://www.djesys.com/
> >
> > > > Unofficial OpenVMS Marketing Home
> >
> > Pagehttp://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/
> >
> > > OK, thanks.
> >
> > > AEF
> >
> > Points taken, but in this case (I covered myself with the "seems" in the
> > subject)
> > the debugging problem was "old eyes" as I failed to see the typo-induced
> > extra
> > ";" from the calling procedure, so none of these issues would have helped
> > bring
> > to light the problem in a "test" scenerio; the real problem, not being
> > understood,
> > was not presented to the testing.
>
> But what about this:
>
> Here's the relevant log snippet:
>
>  $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;
> 1;"
> $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1;  nl:
> /nonumb | -
>        sear sys$pipe "<Consignee>"/window=(0,6)/mat=or/exact/nonumb |
> -
>         sear sys$pipe "<PostalZip>" /exact/nonumb | -
>          sear sys$pipe "> ","><"/exact/out=nl:
> %SEARCH-I-NOMATCHES, no strings matched
>
> Now, suppose instead of using PIPE you did this:
>
>  $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;
> 1;"
> $ diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1;  nl:
> /nonumb
> <add search commands here>
>
> The error message from the DIFF would tell you right away what the
> problem was, no?

Yes, but the sequence is
1) test with a filename without substitution
2) Call the procedure from a higher-level procedure with a
   filename without substitution.
3) Call the procedure from a higher-level procedure with a
   substituted filename.

and the error was a typo in the calling procedure which did not -
as you have pointed out clearly - display because pipe hides it
from sys$error and sys$output, but the pipe command had already
been tested.  So again, the problem was really "old eyes."

>
> AEF
>
--=_alternative 005031AF8525735D_=-- ------------------------------ Date: Fri, 21 Sep 2007 13:18:43 +0200 From: "P. Sture" Subject: Re: despair Message-ID: In article , m.kraemer@gsi.de (Michael Kraemer) wrote: > And the advantage of languages supporting e.g. bounds checking, > PL/I for example (sorry Tom), is not that large. For that, you need descriptor > areas, and these can be overwritten or trashed as well. > Which is rather easy since arguments are passed by reference (IIRC) > and not by value, as in C. Moreover, in the old times when I still > coded PL/I, the recommendation was to enable bounds checking only > for testing, but to disable for production, for performance reasons. > Unfortunately the most nasty errors occur at production time, > not at testing time. Wrong pointers can't be checked easily anyway. Going back a few years to a very large COBOL application, I found that compiling with bounds checking added an insignificant amount of overhead (the application was I/O intensive), so included it in production executables. This paid off handsomely, as all the customer had to do was send us an error printout, and we could often ship a tape containing the fix by return post. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: 21 Sep 2007 07:43:48 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: despair Message-ID: In article , JF Mezei writes: > > But that means that you can do things in C that other languages don't > let you do. Although I can write bad code in about any language, writing good code in Macro-32 is trivial, and writing bad code in C is trivial. So what do you think you can do in C that can't be done in Macro-32 on any VMS system? ------------------------------ Date: 21 Sep 2007 07:46:13 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: despair Message-ID: <5xxxcXBnjeHr@eisner.encompasserve.org> In article , m.kraemer@gsi.de (Michael Kraemer) writes: > > The things you can do wrong in C/C++ are incorrect in any > other language as well. It has been one of the first lessons > in my programming courses (Fortran) that you should not write > to locations you do not own. Back then the pitfalls were mostly array indices, > with more modern languages these would be pointers. With the C library a simple I/O call can write to locations you don't own and the programmer must work hard to prevent that. Just try overflowing an input buffer using Fortran I/O. I've been asking for an example for years. ------------------------------ Date: 21 Sep 2007 13:04:23 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: despair Message-ID: <5lhtqnF88ai5U1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , JF Mezei writes: >> >> But that means that you can do things in C that other languages don't >> let you do. > > Although I can write bad code in about any language, writing good > code in Macro-32 is trivial, and writing bad code in C is trivial. Writing bad code in any language is trivial. I watch students do it every day. I have seen them write bad code in Pascal, BASIC, Java, C, C++, COBOL, PHP, Perl, Javascript and, yes, Ada too. > > So what do you think you can do in C that can't be done in Macro-32 > on any VMS system? Write code that is portable to other systems. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Fri, 21 Sep 2007 08:35:55 -0500 From: Ron Johnson Subject: Re: despair Message-ID: <0NPIi.48584$hP1.15273@newsfe13.lga> On 09/21/07 08:04, Bill Gunshannon wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article , JF Mezei writes: >>> But that means that you can do things in C that other languages don't >>> let you do. >> Although I can write bad code in about any language, writing good >> code in Macro-32 is trivial, and writing bad code in C is trivial. > > Writing bad code in any language is trivial. I watch students do it > every day. I have seen them write bad code in Pascal, BASIC, Java, C, > C++, COBOL, PHP, Perl, Javascript and, yes, Ada too. > >> So what do you think you can do in C that can't be done in Macro-32 >> on any VMS system? > > Write code that is portable to other systems. :-) Now write a *large*, portable system that doesn't contain a lot of IFDEFs in it, or a modern version of All The World's A VAX syndrome that makes/made it very hard to convert to 64-bit. OpenOffice.org (then written mostly in C++) suffered from that disease for quite a while. (Of course, this is becoming more and more irrelevant as Linux conquers the non-Windows world and Solaris and FreeBSD get Linux-compatibility modules.) -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Fri, 21 Sep 2007 09:59:03 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F3CE27.9010508@comcast.net> Bob Koehler wrote: > In article , JF Mezei writes: > >>But that means that you can do things in C that other languages don't >>let you do. > > > Although I can write bad code in about any language, writing good > code in Macro-32 is trivial, and writing bad code in C is trivial. > > So what do you think you can do in C that can't be done in Macro-32 > on any VMS system? > Write a portable program! ------------------------------ Date: Fri, 21 Sep 2007 10:01:09 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F3CEA5.5080703@comcast.net> Bob Koehler wrote: > In article , m.kraemer@gsi.de (Michael Kraemer) writes: > >>The things you can do wrong in C/C++ are incorrect in any >>other language as well. It has been one of the first lessons >>in my programming courses (Fortran) that you should not write >>to locations you do not own. Back then the pitfalls were mostly array indices, >>with more modern languages these would be pointers. > > > With the C library a simple I/O call can write to locations you > don't own and the programmer must work hard to prevent that. > > Just try overflowing an input buffer using Fortran I/O. I've been > asking for an example for years. > With greater control goes greater responsibility! Besides, buffer overflows provide interesting opportunities! :-) ------------------------------ Date: 21 Sep 2007 09:30:19 -0500 From: briggs@encompasserve.org Subject: Re: despair Message-ID: <5bhehJluhFBg@eisner.encompasserve.org> In article <5xxxcXBnjeHr@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , m.kraemer@gsi.de (Michael Kraemer) writes: >> >> The things you can do wrong in C/C++ are incorrect in any >> other language as well. It has been one of the first lessons >> in my programming courses (Fortran) that you should not write >> to locations you do not own. Back then the pitfalls were mostly array indices, >> with more modern languages these would be pointers. > > With the C library a simple I/O call can write to locations you > don't own and the programmer must work hard to prevent that. > > Just try overflowing an input buffer using Fortran I/O. I've been > asking for an example for years. > options /extend_source implicit none character *80 garbage character *80 buffer integer *4 length read ( 5, '(q,a)' ) length, buffer(1:length) type *, garbage end ------------------------------ Date: Fri, 21 Sep 2007 07:33:16 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Fri, 21 Sep 2007 06:35:55 -0700, Ron Johnson wrote: > On 09/21/07 08:04, Bill Gunshannon wrote: >> In article , >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>> In article , JF Mezei writes: >>>> But that means that you can do things in C that other languages don't >>>> let you do. >>> Although I can write bad code in about any language, writing good >>> code in Macro-32 is trivial, and writing bad code in C is trivial. >> >> Writing bad code in any language is trivial. I watch students do it >> every day. I have seen them write bad code in Pascal, BASIC, Java, C, >> C++, COBOL, PHP, Perl, Javascript and, yes, Ada too. >> >>> So what do you think you can do in C that can't be done in Macro-32 >>> on any VMS system? >> >> Write code that is portable to other systems. :-) > > Now write a *large*, portable system that doesn't contain a lot of > IFDEFs in it, or a modern version of All The World's A VAX syndrome > that makes/made it very hard to convert to 64-bit. > > OpenOffice.org (then written mostly in C++) suffered from that > disease for quite a while. > > (Of course, this is becoming more and more irrelevant as Linux > conquers the non-Windows world and Solaris and FreeBSD get > Linux-compatibility modules.) > http://www.informationweek.com/blog/main/archives/2007/09/sparks_fly_as_l.html -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 21 Sep 2007 12:30:30 -0400 From: JF Mezei Subject: Re: despair Message-ID: Bob Koehler wrote: > So what do you think you can do in C that can't be done in Macro-32 > on any VMS system? Since all languages eventually get translated into machine code, obviously there is nothing that can be done in a higher level language that cannot be done in Macro. I really do not understand why some people go out of their way to criticise C. C gives you the flexibility of assembler while giving you higher level language tools. So you can write applications with much greater efficiency than with some assembly language. And you know, I've never really had problems with lack of bounds checking. Especially with dynamically allocated structures, you still need to keep track of how many items you have used and how many have been pre-allocated. And C has become quite pedantic with regards to type checks, so when you want to cheat and take 4 bytes from a string and load then into an integer, you need to be specific about it so the compiler won't bother you. But you can do it. C is not for kids. You need good programming skills and experience to write good C code that has proper architecture to prevent problems and/or detect them. A weenie might just define some array with 10 items in it and assume it will work. A more experienced programmer will define a symbol to "10" and then preallocate that array with that symbol and then use that symbol in tests later in the program to ensure a variable is within bounds. ------------------------------ Date: Fri, 21 Sep 2007 12:39:50 -0400 From: JF Mezei Subject: Re: despair Message-ID: <3c20a$46f3f3d9$cef8887a$30849@TEKSAVVY.COM> Bob Koehler wrote: > With the C library a simple I/O call can write to locations you > don't own and the programmer must work hard to prevent that. If you make a "read" call to SYS$QIO in COBOL or other languages, and give the address of a 20 character string and then specify a length of 512, will the COBOL run time detect that QIO is being told to write way beyond the bounds of the integer ? Yes, the scanf and fscanf functions in C are dangerous, but gets and fgets provide for a "maxchar" limit, and you can specify "sizeof(variable)" for the "maxchar" argument which means that it will not write beyond the variable's boundary. I really do not understand why some people are so keen to bash C when many of their arguments are not an issue for good programmers. ------------------------------ Date: Fri, 21 Sep 2007 12:21:39 -0500 From: Ron Johnson Subject: Re: despair Message-ID: On 09/21/07 09:33, Tom Linden wrote: > On Fri, 21 Sep 2007 06:35:55 -0700, Ron Johnson > wrote: [snip] >> >> Now write a *large*, portable system that doesn't contain a lot of >> IFDEFs in it, or a modern version of All The World's A VAX syndrome >> that makes/made it very hard to convert to 64-bit. >> >> OpenOffice.org (then written mostly in C++) suffered from that >> disease for quite a while. >> >> (Of course, this is becoming more and more irrelevant as Linux >> conquers the non-Windows world and Solaris and FreeBSD get >> Linux-compatibility modules.) >> > http://www.informationweek.com/blog/main/archives/2007/09/sparks_fly_as_l.html My mistake for not specifying "non-Windows *server and middleware* world". Linux won't conquer the desktop (and I'm writing this from a Linux desktop) because: (a) MSFT has locked up important protocols like what Exchange uses, (b) Windows has a ~95% desktop footprint, and so (c) most desktop developers develop for that 95%. Linux *will*, I think, chip away in narrow-functionality vertical markets, like kiosks, call centers, anywhere that there's still a 3270, etc. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 21 Sep 2007 12:28:45 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: despair Message-ID: In article , briggs@encompasserve.org writes: > > What they actually told you to do was: > > . ./scriptname > > The dot tells your shell to execute the given script in the current > shell context rather than in a subshell context. Kind of like an > 'include' -- it works pretty much as if you'd pasted the script > contents as input to the running shell. Of course, you're assuming which shell the fellow was using. ------------------------------ Date: 21 Sep 2007 12:33:39 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: despair Message-ID: In article <5lhtqnF88ai5U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > Write code that is portable to other systems. :-) I've ported it from VAX-11 to NVAX to CVAX to EV4 and EV5. Someday maybe I'll port it to Itanium. That meets all my needs. 8-) ------------------------------ Date: 21 Sep 2007 12:37:44 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: despair Message-ID: <2uDVG9NCr5$+@eisner.encompasserve.org> In article <3c20a$46f3f3d9$cef8887a$30849@TEKSAVVY.COM>, JF Mezei writes: > Bob Koehler wrote: >> With the C library a simple I/O call can write to locations you >> don't own and the programmer must work hard to prevent that. > > If you make a "read" call to SYS$QIO in COBOL or other languages, and > give the address of a 20 character string and then specify a length of > 512, will the COBOL run time detect that QIO is being told to write way > beyond the bounds of the integer ? No. But $QIO is not in the standard COBOL library. Someone finally posted an example of how to overflow a buffer using Fortran I/O, proving that if you work hard enough it can be done. How about an example in COBOL? Maybe that will help prove that errors which take work to avoid in C take work to create in better languages. Then Ada. I really want to see it in Ada. ------------------------------ Date: Fri, 21 Sep 2007 13:34:34 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F400AA.6080106@comcast.net> JF Mezei wrote: > Bob Koehler wrote: > >> So what do you think you can do in C that can't be done in Macro-32 >> on any VMS system? > > > > Since all languages eventually get translated into machine code, > obviously there is nothing that can be done in a higher level language > that cannot be done in Macro. > > > I really do not understand why some people go out of their way to > criticise C. C gives you the flexibility of assembler while giving you > higher level language tools. So you can write applications with much > greater efficiency than with some assembly language. > > And you know, I've never really had problems with lack of bounds > checking. Especially with dynamically allocated structures, you still > need to keep track of how many items you have used and how many have > been pre-allocated. > > And C has become quite pedantic with regards to type checks, so when you > want to cheat and take 4 bytes from a string and load then into an > integer, you need to be specific about it so the compiler won't bother > you. But you can do it. > > > C is not for kids. You need good programming skills and experience to > write good C code that has proper architecture to prevent problems > and/or detect them. > > A weenie might just define some array with 10 items in it and assume it > will work. A more experienced programmer will define a symbol to "10" > and then preallocate that array with that symbol and then use that > symbol in tests later in the program to ensure a variable is within bounds. I believe that a good programmer will do that no matter what language he is coding in. I recall doing something of the sort in IBM Fortran IV back in the 1970s. You could say DEFINE N=123 (or was it PARAMETER N=123?) or something like that and then DIMENSION X(N). . . . I'd use N for the upper limit of the array everywhere in the program. If the world changed a little and we needed to handle 273 widgets instead of 123, I just changed the value of N and recompiled. C adds the convenience of dynamic memory allocation so you don't NEED to recompile. OTOH, C is really structured to use pointers rather than subscripts. . . . Most of what I wrote in Fortran, I would not attempt in C and vice versa. The two languages are good at very different things. . . . ------------------------------ Date: Fri, 21 Sep 2007 12:43:23 -0500 From: Ron Johnson Subject: Re: despair Message-ID: <%oTIi.108943$lZ7.63980@newsfe20.lga> On 09/21/07 11:30, JF Mezei wrote: > Bob Koehler wrote: >> So what do you think you can do in C that can't be done in Macro-32 >> on any VMS system? > > > Since all languages eventually get translated into machine code, > obviously there is nothing that can be done in a higher level language > that cannot be done in Macro. > > > I really do not understand why some people go out of their way to > criticise C. C gives you the flexibility of assembler while giving you > higher level language tools. So you can write applications with much > greater efficiency than with some assembly language. > > And you know, I've never really had problems with lack of bounds > checking. Especially with dynamically allocated structures, you still > need to keep track of how many items you have used and how many have > been pre-allocated. > > And C has become quite pedantic with regards to type checks, so when you > want to cheat and take 4 bytes from a string and load then into an > integer, you need to be specific about it so the compiler won't bother > you. But you can do it. > > > C is not for kids. You need good programming skills and experience to > write good C code that has proper architecture to prevent problems > and/or detect them. But not everyone on your team will have good programming skills, and neither will the all of the maintainers who come after you. IMNSHO, there are languages which are just *better* for writing large apps in specific "spaces". Why use a language designed to fit a time-sharing OS and text-processing apps onto a PDP-11 to write: (a) a large DP system (instead of COBOL-85 or PL/I), (b) a large numeric analysis system (instead of FORTRAN-90 or PL/I), (c) a life-critical system like a health-, medical- or aviation- monitoring system (instead of Ada), (d) a GUI (instead of Pascal, BASIC or PL/I with assistance from scripting languages like Python), (e) "regular" desktop apps (instead of Pascal, BASIC, PL/I or scripting languages) (f) "high-performance" desktop apps (instead of Pascal, BASIC or PL/I)? > A weenie might just define some array with 10 items in it and assume it > will work. A more experienced programmer will define a symbol to "10" > and then preallocate that array with that symbol and then use that > symbol in tests later in the program to ensure a variable is within bounds. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Fri, 21 Sep 2007 12:48:23 -0500 From: Ron Johnson Subject: Re: despair Message-ID: On 09/21/07 11:39, JF Mezei wrote: > Bob Koehler wrote: >> With the C library a simple I/O call can write to locations you >> don't own and the programmer must work hard to prevent that. > > If you make a "read" call to SYS$QIO in COBOL or other languages, and > give the address of a 20 character string and then specify a length of > 512, will the COBOL run time detect that QIO is being told to write way > beyond the bounds of the integer ? > > > Yes, the scanf and fscanf functions in C are dangerous, but gets and > fgets provide for a "maxchar" limit, and you can specify > "sizeof(variable)" for the "maxchar" argument which means that it will > not write beyond the variable's boundary. That "makes messy" the inherent structure of the code. > I really do not understand why some people are so keen to bash C when > many of their arguments are not an issue for good programmers. Because the time and effort that the good programmer spends on handling all that low-level crap can be more profitably spent on high-level stuff that actually is "mission-focused". -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 21 Sep 2007 12:49:56 -0500 From: briggs@encompasserve.org Subject: Re: despair Message-ID: In article <3c20a$46f3f3d9$cef8887a$30849@TEKSAVVY.COM>, JF Mezei writes: > Bob Koehler wrote: >> With the C library a simple I/O call can write to locations you >> don't own and the programmer must work hard to prevent that. > > If you make a "read" call to SYS$QIO in COBOL or other languages, and > give the address of a 20 character string and then specify a length of > 512, will the COBOL run time detect that QIO is being told to write way > beyond the bounds of the integer ? With Cobol (or Ada, Fortran, PL/I or BASIC) you have a choice. You don't need to call an I/O routing passing address and length as separate parameters. You have a language-integrated I/O system with language-integrated bounds checking available. With C you have no choice. There is no language-integrated I/O system. You need to call run time library routines. And you need to call them with address and length specified separately since there's no language-defined syntax for call by descriptor. I'm not an anti-C bigot. I understand that it's perfectly possible for a programmer or a programming team to exert the requisite self-discipline to produce reliable overrun-free code even without the crutch of automatic bounds checking to rely upon. (In the embedded systems world, you need static assurance that array bounds are not overrun. Blowing up the application with a stack dump on a bounds violation detected at run time will usually do more harm than good). > Yes, the scanf and fscanf functions in C are dangerous, but gets and > fgets provide for a "maxchar" limit, and you can specify > "sizeof(variable)" for the "maxchar" argument which means that it will > not write beyond the variable's boundary. $ help cc run gets CC Run-time_functions gets Reads a line from the standard input (stdin). Syntax: #include char *gets(char *string); Nope. No maxchar there. # man gets Standard C Library Functions gets(3C) NAME gets, fgets - get a string from a stream SYNOPSIS #include char *gets(char *s); char *fgets(char *s, int n, FILE *stream); Nope. No maxchar for gets. Just for fgets. Not sure why. ------------------------------ Date: Fri, 21 Sep 2007 13:22:10 +0200 From: "P. Sture" Subject: Re: Hypervisor Message-ID: In article , Jan-Erik Söderholm wrote: > P. Sture wrote: > > In article <85e5$46f29734$cef8887a$25894@TEKSAVVY.COM>, > > JF Mezei wrote: > > > >>> Virtual Management System. > >>> Virtual Machine System > >> > >> Or Virtual Machine Supervisor > > > > I like that. > > > >> Or Virtual Machine Service > > > > Or Virtual Machine Services? > > > > "VMS Management System" ? > > On an Rdb meeting many years ago, someone asked what > "SQL" stands for and the speeker said it ment > "SQL Query Language"... > Right up there with "PIN Number" :-) -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Fri, 21 Sep 2007 13:25:39 +0200 From: "P. Sture" Subject: Re: Hypervisor Message-ID: In article , m.kraemer@gsi.de (Michael Kraemer) wrote: > In article , "P. Sture" > > > > Virtual Management System. > > as opposed to "Real management system" ? > That is, a VMS is sth with really no management ? Point taken. Virtual Machine Supervisor gets my vote. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: 21 Sep 2007 12:42:52 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Hypervisor Message-ID: In article , "P. Sture" writes: > > Or Virtual Machine Services? Very Many, Simplified ------------------------------ Date: Fri, 21 Sep 2007 08:46:52 -0400 From: "David Turner, Island Computers" Subject: Selling: DL145 Dual Core Opteron Message-ID: <13f7f9gf3roeodb@news.supernews.com> We have a couple of NEW Opteron systems here 2.6Ghz Dual Core 64 Bit(2 x Dual Core capable) 2GB Memory DVD/CDRW, 2 x 80GB SATA disks Built in Graphics Dual Gigabit Rackmount Kit Only $1199 Great for a Charon system ! -- David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404 T: 877-6364332 x201 Intl: 001 912 447 6622 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com ------------------------------ Date: Fri, 21 Sep 2007 08:46:57 -0400 From: "David Turner, Island Computers" Subject: Selling: DL145 Dual Core Opteron Message-ID: <13f7f9ktdi6gsde@news.supernews.com> We have a couple of NEW Opteron systems here 2.6Ghz Dual Core 64 Bit(2 x Dual Core capable) 2GB Memory DVD/CDRW, 2 x 80GB SATA disks Built in Graphics Dual Gigabit Rackmount Kit Only $1199 Great for a Charon system ! -- David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404 T: 877-6364332 x201 Intl: 001 912 447 6622 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com ------------------------------ Date: Fri, 21 Sep 2007 16:23:18 GMT From: Michael Austin Subject: Re: tz88 - green-brick for BA350 shelf Message-ID: Richard B. Gilbert wrote: > Michael Austin wrote: >> Richard B. Gilbert wrote: >> >>> Michael Austin wrote: >>> >>>> Does any one have one of these old devices they want to get rid of - >>>> cheaply? I have one that flashes all lights on the front after a >>>> power glitch. I had 2 in this shelf - and luckily only one of them >>>> got hit. I have tried re-seating and following the instructions to >>>> clear the error, but it looks like it is toast. >>>> >>>> Or if you just have the drive - I am sure my former DEC FS skills >>>> can take care of placing it into the canister. >>>> >>> >> You Said: >> >>> You don't NEED a new drive. All you need to do is replace the >>> "Leader". Note that this is a job normally done by field service. >>> If you don't know what you're doing, pay someone who does! >>> >> >> "Or if you just have the drive - I am sure my former DEC FS skills can >> take care of placing it into the canister. " >> >> I pioneered replacing the leader tape instead of the drive in the >> Dallas office back in the mid-80's working on TK50's. I got these for >> free and looks like I now know why. The ribbon cable in the back of >> this one was crimped/broken. Hopefully that is all that is wrong with >> it... I will take some time later to pull the other drive and replace >> it with this one to see if it is indeed just the cable. My guess is >> that the controller got fried- replaced a few of those in my time as >> well... >> >> Man - these parts dealers are not cheap - the ribbon cable goes from >> $145-$200. I hate putting money into something I got for free. >> > > You could try buying the two connectors, a length of cable, and making > your own. ISTR that a bench vise can substitute for a crimping tool. > Actually this is a very specialized ribbon cable as it goes from 50 pins to 8-10 pins with some surface-mount stuff on it... Michael. ------------------------------ Date: Fri, 21 Sep 2007 12:06:14 +0100 From: Jonathan Casiot Subject: Re: Xyplex Terminal Server with VMS Message-ID: <13f79dap8gb3re2@corp.supernews.com> Tom Linden wrote: > Any of you using one of these? The unit I got doesn't have the card > with the > Nbase software. It can also be boot loaded from Alpha or VAX VMS. Any > of you doing > that? > I have done this in the past, though am currently loading my MaxServer 1640 from a Linux machine. You'll need the relevant boot image for your Xyplex terminal server as well. -- Jonathan [take out the TRASH to reply by e-mail] ------------------------------ End of INFO-VAX 2007.516 ************************