INFO-VAX Wed, 13 Feb 2008 Volume 2008 : Issue 87 Contents: Re: DIBOL to Re: DIBOL to RE: DIBOL to Re: DIBOL to Re: Dilbert Does Virtualization Escape sequences redux Re: Iffy DCL IF Re: Iffy DCL IF Re: Iffy DCL IF Re: Iffy DCL IF Re: Iffy DCL IF Re: Iffy DCL IF Multiple system disks and SAN Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: SPAM detection for freeware MX 4.2 Re: Testing new rewired "cable adapters" for lights-out console use Thank you Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Xerox 7760 on DCPS? ---------------------------------------------------------------------- Date: Tue, 12 Feb 2008 18:38:48 -0500 From: John Reagan Subject: Re: DIBOL to Message-ID: Bob Gezelter wrote: > For porting, it depends on the style of code. If you want integrated > (non-custom) support for access to indexed and other files, you are > probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly > difficult to access keyed files from C/C++, but it will be in the > nature of a non-integrated add-in (or in the case of C++, probably a > class). Not to divert the topic, but Pascal has just as good support for indexed and relative files as the langauges listed above. Well, you can't CREATE a file with segmented keys from Pascal without resorting to a USERACTION routine, but you can open an existing file and even use FINDK to lookup a record. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Wed, 13 Feb 2008 00:33:39 GMT From: Tad Winters Subject: Re: DIBOL to Message-ID: John Reagan wrote in news:fotat3$tf1$1@usenet01.boi.hp.com: > Bob Gezelter wrote: > >> For porting, it depends on the style of code. If you want >> integrated (non-custom) support for access to indexed and other >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is >> not inherantly difficult to access keyed files from C/C++, but it >> will be in the nature of a non-integrated add-in (or in the case of >> C++, probably a class). > > Not to divert the topic, but Pascal has just as good support for > indexed and relative files as the langauges listed above. Well, you > can't CREATE a file with segmented keys from Pascal without > resorting to a USERACTION routine, but you can open an existing file > and even use FINDK to lookup a record. > It seems like DIBOL was quite a good language. Why did Digital drop it with the move to Alpha? ------------------------------ Date: Tue, 12 Feb 2008 20:31:16 -0500 From: "Hank Vander Waal" Subject: RE: DIBOL to Message-ID: <012101c86de0$213a9b50$6500a8c0@dellxp30> It IS a great language. They did not drop it - they farmed it out to some one who was still developing it. One less thing for them to worry about It is now DBL and runs on all kinds of platforms. -----Original Message----- From: Tad Winters [mailto:stafford.no.spam.winters2@verizon.net] Sent: Tuesday, February 12, 2008 7:34 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: DIBOL to John Reagan wrote in news:fotat3$tf1$1@usenet01.boi.hp.com: > Bob Gezelter wrote: > >> For porting, it depends on the style of code. If you want >> integrated (non-custom) support for access to indexed and other >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is >> not inherantly difficult to access keyed files from C/C++, but it >> will be in the nature of a non-integrated add-in (or in the case of >> C++, probably a class). > > Not to divert the topic, but Pascal has just as good support for > indexed and relative files as the langauges listed above. Well, you > can't CREATE a file with segmented keys from Pascal without > resorting to a USERACTION routine, but you can open an existing file > and even use FINDK to lookup a record. > It seems like DIBOL was quite a good language. Why did Digital drop it with the move to Alpha? ------------------------------ Date: 12 Feb 2008 22:46:46 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: DIBOL to Message-ID: In article , John Reagan writes: > Bob Gezelter wrote: > >> For porting, it depends on the style of code. If you want integrated >> (non-custom) support for access to indexed and other files, you are >> probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly >> difficult to access keyed files from C/C++, but it will be in the >> nature of a non-integrated add-in (or in the case of C++, probably a >> class). > > Not to divert the topic, but Pascal has just as good support for indexed > and relative files as the langauges listed above. Well, you can't > CREATE a file with segmented keys from Pascal without resorting to a > USERACTION routine, but you can open an existing file and even use FINDK > to lookup a record. DEC/Compaq/HP Ada forces one to specify a FDL string to do that, but after getting accustomed to it that is not such a bad approach if your rate of file creation is sufficiently low that overhead from parsing the FDL string is not an issue. ------------------------------ Date: Tue, 12 Feb 2008 21:34:36 -0700 From: "Michael D. Ober" Subject: Re: Dilbert Does Virtualization Message-ID: <13r4sr0n8ot1p35@corp.supernews.com> "Larry Kilgallen" wrote in message news:mlyp9tgAhjjF@eisner.encompasserve.org... > http://www.dilbert.com/comics/dilbert/archive/images/dilbert20183362080212.gif > So, So true. Mike. ------------------------------ Date: Tue, 12 Feb 2008 14:44:14 -0500 From: Dave Cantor Subject: Escape sequences redux Message-ID: There was a discussion a while ago about control- and escape sequences for various DEC terminals. While I don't have a copy anymore (having surrendered it when I left the employ of DEC), I do have the name of the appropriate document. Perhaps someone here can find a copy of DEC STD 138-0, Registry of Control Functions for Character Imaging Devices -- Dave C. Groton, CT ------------------------------ Date: Tue, 12 Feb 2008 14:42:03 -0500 From: Dave Cantor Subject: Re: Iffy DCL IF Message-ID: In article <26d0968f-7da1-40ff-b1c1-1e6baa4532f6 @l1g2000hsa.googlegroups.com> and many following articles, spamsink2001 @yahoo.com and many others have been writing about a DCL command file with a line like $ IF somecondition .OR. someothercondition dosomething here $ some other command without a continuation mark (hyphen) at the end of the first line of the IF. This yields skipping the line that does not begin with a dollar sign. It's not a bug; it's a FEATURE. Say you have a command file like. $ RUN SOMEPROGRAM.EXE Data line 1 Data line 2 Data line 3 ... Last data line $ DIR FOO It is not known when SOMEPROGRAM.EXE will exit. It might have read all the data lines; it might have read 1 or 2 of them; it might have read none of them. It is necessary for DCL to find the next line beginning with the $ to find its next command. All those data lines are SYS$INPUT for SOMEPROGRAM.EXE. So, is it possible that an IF can have a SYS$INPUT? Maybe, but I'm sure it wouldn't be used. It would have to be skipped however. What if the IF statement were $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP Data line 1 Date line 2 $ DIR X.TMP If FOO is different from BAR, then those data lines need to be skipped. This is all, of course, just my arrogant opinion, after writing DCL code for 20 or so years, both in and out of DEC. -- Dave C. Groton, CT ------------------------------ Date: Tue, 12 Feb 2008 15:22:39 -0500 From: norm.raphael@metso.com Subject: Re: Iffy DCL IF Message-ID: This is a multipart message in MIME format. --=_alternative 006FF1EA852573ED_= Content-Type: text/plain; charset="US-ASCII" Dave Cantor wrote on 02/12/2008 02:42:03 PM: > In article <26d0968f-7da1-40ff-b1c1-1e6baa4532f6 > @l1g2000hsa.googlegroups.com> and many following articles, spamsink2001 > @yahoo.com and many others have been writing about a DCL command file > with a line like > > $ IF somecondition .OR. someothercondition > dosomething here > $ some other command > > without a continuation mark (hyphen) at the end of the first line of the > IF. This yields skipping the line that does not begin with a dollar > sign. > > It's not a bug; it's a FEATURE. > > Say you have a command file like. > > $ RUN SOMEPROGRAM.EXE > Data line 1 > Data line 2 > Data line 3 > ... > Last data line > $ DIR FOO > > It is not known when SOMEPROGRAM.EXE will exit. It might have read all > the data lines; it might have read 1 or 2 of them; it might have read > none of them. > > It is necessary for DCL to find the next line beginning with the $ to > find its next command. > > All those data lines are SYS$INPUT for SOMEPROGRAM.EXE. > > So, is it possible that an IF can have a SYS$INPUT? Maybe, but I'm sure > it wouldn't be used. It would have to be skipped however. > > What if the IF statement were > > $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP > Data line 1 > Date line 2 > $ DIR X.TMP > > If FOO is different from BAR, then those data lines need to be skipped. 1) You need a THEN or it doesn't work as you describe. 2) If you make the VALUE of FOO different from the VALUE of BAR then and add the THEN, you get a -W- on each of the next two lines, because the conditional COPY statement does not get executed, so DCL does not try to read or skip the next two lines. In this case, even $DECK/$EOD does not help; this is just wrong syntax. > > This is all, of course, just my arrogant opinion, after writing DCL code > for 20 or so years, both in and out of DEC. See, arrogance without testing will leave you embarrassed, if you can be. > > -- > Dave C. > Groton, CT --=_alternative 006FF1EA852573ED_= Content-Type: text/html; charset="US-ASCII"
Dave Cantor <Dave@Cantor.mv.com> wrote on 02/12/2008 02:42:03 PM:

> In article <26d0968f-7da1-40ff-b1c1-1e6baa4532f6
> @l1g2000hsa.googlegroups.com> and many following articles, spamsink2001
> @yahoo.com and many others have been writing about a DCL command file
> with a line like
>
> $ IF somecondition .OR. someothercondition
>   dosomething here
> $ some other command
>
> without a continuation mark (hyphen) at the end of the first line of the
> IF.   This yields skipping the line that does not begin with a dollar
> sign.
>
> It's not a bug; it's a FEATURE.
>
> Say you have a command file like.
>
> $ RUN SOMEPROGRAM.EXE
> Data line 1
> Data line 2
> Data line 3
> ...
> Last data line
> $ DIR FOO
>
> It is not known when SOMEPROGRAM.EXE will exit.   It might have read all
> the data lines; it might have read 1 or 2 of them; it might have read
> none of them.
>
> It is necessary for DCL to find the next line beginning with the $ to
> find its next command.  
>
> All those data lines are SYS$INPUT for SOMEPROGRAM.EXE.
>
> So, is it possible that an IF can have a SYS$INPUT?  Maybe, but I'm sure
> it wouldn't be used.  It would have to be skipped however.
>
> What if the IF statement were
>
>   $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP
>    Data line 1
>    Date line 2
>   $ DIR X.TMP
>
> If FOO is different from BAR, then those data lines need to be skipped.


1) You need a THEN or it doesn't work as you describe.
2) If you make the VALUE of FOO different from the VALUE of BAR then
and add the THEN, you get a -W- on each of the next two lines, because
the conditional COPY statement does not get executed, so DCL does not
try to read or skip the next two lines.  In this case, even $DECK/$EOD
does not help; this is just wrong syntax.

>
> This is all, of course, just my arrogant opinion, after writing DCL code
> for 20 or so years, both in and out of DEC.

See, arrogance without testing will leave you embarrassed, if you can be.

>
> --
> Dave C.
> Groton, CT
--=_alternative 006FF1EA852573ED_=-- ------------------------------ Date: Tue, 12 Feb 2008 21:58:07 GMT From: Rob Brown Subject: Re: Iffy DCL IF Message-ID: On Tue, 12 Feb 2008, norm.raphael@metso.com wrote: > Dave Cantor wrote on 02/12/2008 02:42:03 PM: > >> $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP >> Data line 1 >> Date line 2 >> $ DIR X.TMP >> >> If FOO is different from BAR, then those data lines need to be skipped. > > 1) You need a THEN or it doesn't work as you describe. > 2) If you make the VALUE of FOO different from the VALUE of BAR then > and add the THEN, you get a -W- on each of the next two lines, because > the conditional COPY statement does not get executed, so DCL does not > try to read or skip the next two lines. In this case, even $DECK/$EOD > does not help; this is just wrong syntax. I could vote for this being a DCL bug. -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Tue, 12 Feb 2008 17:28:47 -0500 From: norm.raphael@metso.com Subject: Re: Iffy DCL IF Message-ID: This is a multipart message in MIME format. --=_alternative 007B7E10852573ED_= Content-Type: text/plain; charset="US-ASCII" Rob Brown wrote on 02/12/2008 04:58:07 PM: > On Tue, 12 Feb 2008, norm.raphael@metso.com wrote: > > > Dave Cantor wrote on 02/12/2008 02:42:03 PM: > > > >> $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP > >> Data line 1 > >> Date line 2 > >> $ DIR X.TMP > >> > >> If FOO is different from BAR, then those data lines need to be skipped. > > > > 1) You need a THEN or it doesn't work as you describe. > > 2) If you make the VALUE of FOO different from the VALUE of BAR then > > and add the THEN, you get a -W- on each of the next two lines, because > > the conditional COPY statement does not get executed, so DCL does not > > try to read or skip the next two lines. In this case, even $DECK/$EOD > > does not help; this is just wrong syntax. > > I could vote for this being a DCL bug. > Well, no. The original example is a bug. This one gets warnings as it should. > > -- > > Rob Brown b r o w n a t g m c l d o t c o m > G. Michaels Consulting Ltd. (780)438-9343 (voice) > Edmonton (780)437-3367 (FAX) > http://gmcl.com/ > --=_alternative 007B7E10852573ED_= Content-Type: text/html; charset="US-ASCII"



Rob Brown <mylastname@gmcl.com> wrote on 02/12/2008 04:58:07 PM:

> On Tue, 12 Feb 2008, norm.raphael@metso.com wrote:
>
> > Dave Cantor <Dave@Cantor.mv.com> wrote on 02/12/2008 02:42:03 PM:
> >
> >>   $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP
> >>    Data line 1
> >>    Date line 2
> >>   $ DIR X.TMP
> >>
> >> If FOO is different from BAR, then those data lines need to be skipped.
> >
> > 1) You need a THEN or it doesn't work as you describe.
> > 2) If you make the VALUE of FOO different from the VALUE of BAR then
> > and add the THEN, you get a -W- on each of the next two lines, because
> > the conditional COPY statement does not get executed, so DCL does not
> > try to read or skip the next two lines.  In this case, even $DECK/$EOD
> > does not help; this is just wrong syntax.
>
> I could vote for this being a DCL bug.
>


Well, no.  The original example is a bug.  This one gets warnings as it
should.

>
> --
>
> Rob Brown                        b r o w n a t g m c l d o t c o m
> G. Michaels Consulting Ltd.      (780)438-9343 (voice)
> Edmonton                         (780)437-3367 (FAX)
>                                   http://gmcl.com/
>
--=_alternative 007B7E10852573ED_=-- ------------------------------ Date: Tue, 12 Feb 2008 17:59:42 -0800 (PST) From: AEF Subject: Re: Iffy DCL IF Message-ID: <09d081ea-63a1-4b46-8fba-9c326db945fb@q77g2000hsh.googlegroups.com> On Feb 12, 4:22 pm, norm.raph...@metso.com wrote: > Dave Cantor wrote on 02/12/2008 02:42:03 PM: > > > > > In article <26d0968f-7da1-40ff-b1c1-1e6baa4532f6 > > @l1g2000hsa.googlegroups.com> and many following articles, spamsink2001 > > @yahoo.com and many others have been writing about a DCL command file > > with a line like > > > $ IF somecondition .OR. someothercondition > > dosomething here > > $ some other command > > > without a continuation mark (hyphen) at the end of the first line of the > > IF. This yields skipping the line that does not begin with a dollar > > sign. > > > It's not a bug; it's a FEATURE. > > > Say you have a command file like. > > > $ RUN SOMEPROGRAM.EXE > > Data line 1 > > Data line 2 > > Data line 3 > > ... > > Last data line > > $ DIR FOO > > > It is not known when SOMEPROGRAM.EXE will exit. It might have read all > > the data lines; it might have read 1 or 2 of them; it might have read > > none of them. > > > It is necessary for DCL to find the next line beginning with the $ to > > find its next command. > > > All those data lines are SYS$INPUT for SOMEPROGRAM.EXE. But why would you write it that way? The data lines are hard-coded, so a sensible way would be to use a special keyword to signal the end, or just do something you know that the SOMEPROGRAM expects. OK, maybe this could be the variable output of another DCL command procedure. Even then, don't you want to know that some of the lines are skipped? And this is what you get when FOO doesn't equal BAR: DCL> @HUH $ IF FOO .EQS. BAR THEN COPY SYS$INPUT X.TMP Data line 1 %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \DATA\ Date line 2 %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \DATE\ $ DIR X.TMP %DIRECT-W-NOFILES, no files found > > So, is it possible that an IF can have a SYS$INPUT? Maybe, but I'm sure > > it wouldn't be used. It would have to be skipped however. > > > What if the IF statement were > > > $ IF FOO .EQS. BAR COPY SYS$INPUT X.TMP > > Data line 1 > > Date line 2 > > $ DIR X.TMP > > > If FOO is different from BAR, then those data lines need to be skipped. > > 1) You need a THEN or it doesn't work as you describe. > 2) If you make the VALUE of FOO different from the VALUE of BAR then > and add the THEN, you get a -W- on each of the next two lines, because > the conditional COPY statement does not get executed, so DCL does not > try to read or skip the next two lines. In this case, even $DECK/$EOD > does not help; this is just wrong syntax. Not only that, why would you write it this way? Why not use something like this?: DCL> TYPE HUH.COM $ IF FOO .EQS. BAR $ THEN $ COPY SYS$INPUT X.TMP Data line 1 Date line 2 $ DIR X.TMP $ ENDIF DCL> DCL> SH SYM FOO FOO = "BLAH" DCL> SH SYM BAR BAR = "BLAH" DCL> @HUH $ IF FOO .EQS. BAR $ THEN $ COPY SYS$INPUT X.TMP Data line 1 Date line 2 %COPY-S-COPIED, SYS$INPUT: copied to DISK$DATA1: [FELDMAN.DCL.PLAY]X.TMP;1 (2 records) $ DIR X.TMP Directory DISK$DATA1:[FELDMAN.DCL.PLAY] X.TMP;1 1/4 13-FEB-2008 01:51:47.68 Total of 1 file, 1/4 blocks. $ ENDIF DCL> FOO = "BLAHSKI" DCL> @HUH $ IF FOO .EQS. BAR $ ENDIF DCL> > OK, there wasn't always the IF THEN ELSE ENDIF construct. Well, at least you can do it since what, V5? Perhaps one could use a subroutine instead. Anyway, I'm out of time for now. ... Later! [...] AEF ------------------------------ Date: Tue, 12 Feb 2008 21:36:59 -0500 From: Dave Cantor Subject: Re: Iffy DCL IF Message-ID: In article , norm.raphael@metso.com wrote... > See, arrogance without testing will leave you embarrassed, if you can be. You are so right. I seem to have forgotten what I always used to say: "If you're going to be arrogant, at least have the class to be right." I wasn't. You're right. The IF needs a THEN, of course. I constructed this file X.COM: $ A = 1 $ B = 2 $ IF A .EQ. B THEN READ SYS$INPUT X FOO BAR $ EXIT Then, @X.COM produces %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \FOO\ %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \BAR\ Then, I changed the IF line to use .NE. rather than .EQ., reran @X.COM and got only %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \BAR\ indicating that the READ statement had eaten the line containing FOO. So, what would you have DCL do? Just pass by the data lines without comment? I still think it's a feature, not a bug, but there probably should be an option not to display -W- messages. You could do $ SET MESSAGE /NOFACI /NOIDEN /NOSEVE /NOTEXT to suppress the messages if you really want to. Humbled a little, but still arrogant. (And now, I'll probably be getting errors when writing IF ... THEN in Windows .BAT files!) -- Dave C. Groton, CT ------------------------------ Date: Wed, 13 Feb 2008 09:28:22 +1300 From: Malcolm Smeaton Subject: Multiple system disks and SAN Message-ID: <7015937@MVB.SAIC.COM> We have Alpha and Integrity servers sharing the same cluster but using different system disks. However they share the same authorization files e.g. =20 $ define/system/exec sysuaf dsa100:[vms$common.sysexe]sysuaf.dat $ define/system/exec rightslist dsa100:[vms$common.sysexe]rightslist.dat $ define/system/exec qman$master dsa100:[vms$common.sysexe] $ define/system/exec vmsmail_profile dsa100:[vms$common.sysexe]vmsmail_profile.data $ define/system/exec netproxy dsa100:[vms$common.sysexe]netproxy.dat $ define/system/exec net$proxy dsa100:[vms$common.sysexe]net$proxy.dat $ define/system/exec vms$objects dsa100:[vms$common.sysexe]vms$objects.dat $ define/system/exec vms$audit_server dsa100:[vms$common.sysmgr]vms$audit_server.dat $ define/system/exec vms$password_history dsa100:[vms$common.sysexe]vms$password_history.data =20 Integrity is running on VMS 8.3 and Alpha is running on VMS 7.3-2. =20 I want to upgrade Integrity to VMS 8.3-1H1 first and then Alpha to VMS 8.3. I can't quite upgrade the Alpha systems yet because of some legacy applications which we are in the process of decommissioning. =20 The shared cluster files are currently on the Alpha system disk, dsa100: which is on a RAID 7000 StorageWorks disk array. =20 At the moment the integrity system disk is locally attached to a rx3600 server, $10$dka0: We have since purchased a rx2660 itanium server so I want to copy the integrity system disk to a disk called $1$DGA12 on our EVA5000 SAN and then upgrade the new system disk to VMS 8.3-1H1. During this period I want to keep the Alpha systems running because we have important 24x7 applications on it. =20 QUESTION 1: =20 The VMS 8.3-1H1 Upgrade and Installation Manual Section 4.5.5 tells me I need to move the authorization files to the new system disk before I do the upgrade and then move them back to their original location after the upgrade. I have some problems with this. =20 1. These files, particularly sysuaf.dat, rightslist.dat, vmsmail_profile.data are changing all the time due to password changes and because we use VMS for our usercode management system accounts come and go. 2. I do not feel comfortable about copying live files which are open for update 3. By the time I copy the files back some of the information will be out of date =20 Do I have to copy these files back again? As far as I am aware the upgrade does not modify any of these files. When I originally installed OpenVMS 8.3 on Integrity I did it as a standalone installation on the rx3600 and then joined the rx3600 to the Alpha cluster at a later date. So the integrity system disk still has the original authorization files on the integrity system disk that were built at the time of the standalone installation. Why can't I just use those for the upgrade and go back to the authorization files on the Alpha system disk again after the upgrade? =20 QUESTION 2: =20 After the upgrade is complete and the rx3600 systems disk is $1$DGA12 on the EVA5000 I want to add the rx2660 to the SAN. To do this the Upgrade and Installation Manual recommends I boot from the installation DVD, select the DCL prompt and type: =20 $$$ @SYS$MANAGER:BOOT_OPTIONS=20 =20 This has an option to configure the SAN disk $1$DGA12: as a Boot Options device. What the Installation Guide doesn't mention is that you are required to mount the device $1$DGA12 as part of the configuration. This means a standalone node running off the installation DVD has mounted the same disk as the rx3600 VMS cluster node server. That seems very risky to me, although I notice the BOOT_OPTIONS.COM utility does mount the desk read-only. Can I assume it is safe to do this? I know I could configure the rx2660 to add $1$DGA12: before using it as a system disk but I still want to ask the question.=20 =20 --=20 Regards Malcolm =20 Malcolm Smeaton, Server Group Leader Information and Communication Technology Services University of Canterbury Te Whare Wananga o Waitaha Private Bag 4800, Christchurch 8140, New Zealand ------------------------------ Date: Wed, 13 Feb 2008 06:21:03 GMT From: "John E. Malmberg" Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: Steven M. Schweda wrote: > A long, rambling complaint about the C compiler, the librarian, and > MMS follows. MMK works with ODS-5 volumes and lowercase extensions now. I have been told that an update to MMS/DECSET to support ODS-5 will be coming out. I do not know the status. I have been compiling things with /NAMES=(AS-IS,SHORTENED) because too much stuff has names longer than 31 characters that are the same for the first 31 characters with other names. For the shared images, I have been putting aliases in for uppercase, exact case, (manually truncated/mangled if needed), and also uppercase crc shortened, and exact case crc shortened. That way it can be used with the maximum number of compiler settings. I have not seen an issue with the librarian, but I did modify the AR utility in GNV to fix an issue with case sensitivity of the modules. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Tue, 12 Feb 2008 21:30:27 -0800 From: Vance Haemmerle Subject: Re: SPAM detection for freeware MX 4.2 Message-ID: Martin Vorlaender wrote: > Vance Haemmerle wrote: > >>Joseph Huber wrote: >> >>>MX 6 is now open source, see >>> http://www.openvms.org/stories.php?story=08/02/05/9642981 >>>and >>>http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1190006 > > ... > >>At least I was using my changes for the last 7 months. >>My SMTP server is on a VAX and I don't think MX 6 supports VAX. > > > It could be well worth a look. In the 00README.TXT file, Matt writes: > "I have removed the kitting for VAX systems, although the source code > still contains VAX support." > > cu, > Martin That's good. The release notes for V5.4 said the next version would not suppport VAX. -- Vance ------------------------------ Date: Wed, 13 Feb 2008 06:13:38 GMT From: "John E. Malmberg" Subject: Re: Testing new rewired "cable adapters" for lights-out console use Message-ID: AEF wrote: > Maybe this is a dumb question, but at least it's on topic!!! > > We're moving our servers and such to a new data center in a new > building. My "manager" wants to go "lights-out" so I need a better > terminal server. The old terminal server (a MOXA CN 2100) has the > problem that power-ups and power-downs cause it to emit break signals, > so I never leave cables plugged into any VAX systems when I'm done > with console sessions. But with the lights-out scneario, I need > something better. I used to just turn off the halt on break for the consoles. The only times I have needed to halt one of my systems was when I needed to do on site maintenance. > So I have a new terminal server lined up: a Cisco 2610. The Cisco > doesn't have the power-cycle/break problem, but the cables need to be > wired differently! (Why doesn't everyone use the same wiring scheme?) > So a member of the network group was kind enough to wire up some cable > adapters (MMJ to RJ45) (I now owe hum lunch!). I tested them by > logging in on the console port, running MONITOR SYSTEM, and running > the STAR TREK and TWILIGHT ZONE animations. All these things work. Is > there anything else I need to do to be sure the new pin-out > arrangement (or wiring scheme or whatever it's called) of these "cable > adapters" is correct? You have to do continuity tests. A common wiring error is to not put in one of the signal returns on MMJ to what ever adapters. The MMJ signal has two signal returns, one for outgoing signals and one for incoming based on RS-423 signaling standards. If you make the MMJ/RJ45 to 25 pin or 9 pin D adapters with out jumpering the two signal returns of the MMJ/RJ45 to the single signal return of the D connectors, on NULL cable connections, there actually is no signal return at all. If you just have one of those adapters on one end, and plug the MMJ/RJ45 into the other end, it only works reliably if the signal commons are jumpered internally to the device. For RS-232, this is the case. For RS-423 it is not. Of course some RJ45 connections that are RS-232, there is only one signal common. On the MMJ there are always 2. Note that quite a number of internet reference sites are wrong about proper wiring of serial ports. Usually one or more of the signal returns are missing, yet things still work because there is another usually non-optimal common DC ground. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Tue, 12 Feb 2008 16:11:29 -0800 (PST) From: Sue Subject: Thank you Message-ID: Dear Newsgroup, I just wanted to say "Thank you". I really appreciate that you are vocal, loyal and always willing to give me an answer to my questions and feedback to my requests. I know that if you are on my email list that sometimes I send a lot of email and you don't seem to mind. Please remember that you are valued. I have my own TLA (three letter acronym) which in the UK has a completely different meaning. But it is GBH, great big hug. GBH, Sue ------------------------------ Date: Tue, 12 Feb 2008 13:33:59 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: <64cc746c-465d-43d4-81aa-0949c9ccb4cc@h11g2000prf.googlegroups.com> On Feb 12, 1:36=A0pm, Hein RMS van den Heuvel wrote: > Btw... how did you even find it. x0333 is 'odd' and most proper > application will ignore it, being a succes code. The first test of R0 shows SS$_NORMAL, then the application looks at the IOSB and anything other than SS$_NORMAL gets reported (and the application is aborted at that point). None of the other expected status value from the IOSB would be recoverable, so if it's not SS $_NORMAL then out we go. > This is most certain to be semi-random data hitting the IOSB. > Any AST work in the application at all? It's looking more and more like that is the case. As I said, the R0 value returned by the $QIOW is SS$_NORMAL. The remainder of the IOSB values are also invalid, which indicates a buffer overrun someplace. Since there is absolutely nothing between the $QIOW and the test of the status values, that suggests the error is either in $QIOW or the parameters being passed. It works 100% of the time in the development environment and naturally fails only in production. (And, of course, I'm getting the flak about "didn't you test it?". Of course I f#$%^&* tested it.) The only other difference in mailbox handling between this version and the one it replaces is the $QIOW now uses EFN$C_ENF instead of the default event flag (0). Shouldn't be a factor unless there was a patch related to EFN$C_ENF. More research. If I could get it to fail in the development environment that would be really nice. And no, no other AST routines that I'm aware of. Certainly none under my control. ------------------------------ Date: Tue, 12 Feb 2008 17:00:46 -0500 From: "Richard B. Gilbert" Subject: Re: Unusual mailbox status value Message-ID: <47B2170E.1020009@comcast.net> FrankS wrote: > On Feb 12, 1:36 pm, Hein RMS van den Heuvel > wrote: > >>Btw... how did you even find it. x0333 is 'odd' and most proper >>application will ignore it, being a succes code. > > > The first test of R0 shows SS$_NORMAL, then the application looks at > the IOSB and anything other than SS$_NORMAL gets reported (and the > application is aborted at that point). None of the other expected > status value from the IOSB would be recoverable, so if it's not SS > $_NORMAL then out we go. > > >>This is most certain to be semi-random data hitting the IOSB. >>Any AST work in the application at all? > > > It's looking more and more like that is the case. As I said, the R0 > value returned by the $QIOW is SS$_NORMAL. The remainder of the IOSB > values are also invalid, which indicates a buffer overrun someplace. > > Since there is absolutely nothing between the $QIOW and the test of > the status values, that suggests the error is either in $QIOW or the > parameters being passed. It works 100% of the time in the development > environment and naturally fails only in production. (And, of course, > I'm getting the flak about "didn't you test it?". Of course I f#$%^&* > tested it.) > > The only other difference in mailbox handling between this version and > the one it replaces is the $QIOW now uses EFN$C_ENF instead of the > default event flag (0). Shouldn't be a factor unless there was a > patch related to EFN$C_ENF. > > More research. If I could get it to fail in the development > environment that would be really nice. > > And no, no other AST routines that I'm aware of. Certainly none under > my control. Can you trim your code down to the absolute minimum reproducer? If you can't figure it out from there, you could post it! And if the minimum fails to reproduce, replace the missing pieces one by one until it does fail. ------------------------------ Date: Tue, 12 Feb 2008 14:19:23 -0800 (PST) From: Bob Gezelter Subject: Re: Unusual mailbox status value Message-ID: On Feb 12, 4:33 pm, FrankS wrote: > On Feb 12, 1:36 pm, Hein RMS van den Heuvel > > wrote: > > Btw... how did you even find it. x0333 is 'odd' and most proper > > application will ignore it, being a succes code. > > The first test of R0 shows SS$_NORMAL, then the application looks at > the IOSB and anything other than SS$_NORMAL gets reported (and the > application is aborted at that point). None of the other expected > status value from the IOSB would be recoverable, so if it's not SS > $_NORMAL then out we go. > > > This is most certain to be semi-random data hitting the IOSB. > > Any AST work in the application at all? > > It's looking more and more like that is the case. As I said, the R0 > value returned by the $QIOW is SS$_NORMAL. The remainder of the IOSB > values are also invalid, which indicates a buffer overrun someplace. > > Since there is absolutely nothing between the $QIOW and the test of > the status values, that suggests the error is either in $QIOW or the > parameters being passed. It works 100% of the time in the development > environment and naturally fails only in production. (And, of course, > I'm getting the flak about "didn't you test it?". Of course I f#$%^&* > tested it.) > > The only other difference in mailbox handling between this version and > the one it replaces is the $QIOW now uses EFN$C_ENF instead of the > default event flag (0). Shouldn't be a factor unless there was a > patch related to EFN$C_ENF. > > More research. If I could get it to fail in the development > environment that would be really nice. > > And no, no other AST routines that I'm aware of. Certainly none under > my control. Frank, I would agree with the opinion that something is stomping on the storage. Debugging suggestions without the sources are always dicey, but there are two possibilities: - the problem is a mis-specified buffer or - the problem is in the code If the problem is in the code, using SET WATCH may very well identify the problem (this is particularly true if the IOSB structure is a static variable). If it is allocated on the stack, it is a bit more laborious to localize. Another possibility is an error in indirection. More context is always helpful. - Bob Gezelter,http://www.rlgsc.com ------------------------------ Date: Tue, 12 Feb 2008 14:50:51 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Unusual mailbox status value Message-ID: <0da09e1f-4ae0-4750-8f76-55d04a757f8e@y5g2000hsf.googlegroups.com> On Feb 12, 4:33=A0pm, FrankS wrote: > On Feb 12, 1:36=A0pm, Hein RMS van den Heuvel > > wrote: > > Btw... how did you even find it. x0333 is 'odd' and most proper > > application will ignore it, being a succes code. > > The first test of R0 shows SS$_NORMAL, then the application looks at > the IOSB and anything other than SS$_NORMAL gets reported Ok. Pretty standard, allthough I'd prefer a low bit test myself. >=A0The remainder of the IOSB > values are also invalid, which indicates a buffer overrun someplace. That's why I suggest to create a formatted print of the memory around the IOSB. You might just recognize the data when there is a little more of it. > Since there is absolutely nothing between the $QIOW and the test of > the status values, that suggests the error is either in $QIOW or the > parameters being passed. The receive buffer specifically of course. >=A0It works 100% of the time in the development > environment and naturally fails only in production. That's the fun part. So debugger watch points are unlikely to trap this huh? > I'm getting the flak about "didn't you test it?". =A0Of course I f#$%^&* > tested it.) :^) > The only other difference in mailbox handling between this version and > the one it replaces is the $QIOW now uses EFN$C_ENF instead of the > default event flag (0). =A0Shouldn't be a factor unless there was a > patch related to EFN$C_ENF. But in using the EFN$C_ENF the IOSB because even more important. It plays a critical role in the underlying $SYNCH action. The EFN 0 usage may have influenced the timing. And the IOSB is on the stack as a properly allocated local variable? Is it part of a (larger) malloced (LIB$GET_VM) structure? It is not passed in by address and stale by the it is used is it? Does making the IOSB a static variable in low memory make the problem hide? > More research. =A0If I could get it to fail in the development > environment that would be really nice. That would be too easy :-) Good luck! Hein. ------------------------------ Date: Tue, 12 Feb 2008 16:20:50 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: On Feb 12, 5:50=A0pm, Hein RMS van den Heuvel wrote: > > The only other difference in mailbox handling between this version and > > the one it replaces is the $QIOW now uses EFN$C_ENF instead of the > > default event flag (0). =A0Shouldn't be a factor unless there was a > > patch related to EFN$C_ENF. > > But in using the EFN$C_ENF the IOSB because even more important. > It plays a critical role in the underlying $SYNCH action. > The EFN 0 usage may have influenced the timing. Can you expand on why using EFN$C_ENF would affect the behavior? I can't get Courier font on this news writer, so pardon the spacing that follows. The relevant section of code (written in BASIC) is ... %include "$IOSBDEF" %from %library %include "STARLET" %from %library map (NCR$IOSB) iosb io_status map (NCR$IOSB) basic$quadword io_quadword l$_return_status =3D SYS$QIOW( EFN$C_ENF ! EFN & , w$_mailbox_channel ! Chan & , IO$_READVBLK ! Func & , io_quadword ! IOSB & , ! ARTN & , ! APRM & , msg::s$_buffer ! P1 & , c$_max_message ! P2 & , ! P3 & , ! P4 & , ! P5 & , ) ! P6 if (l$_return_status <> SS$_NORMAL) then print TIME$(0%); " (ERROR) Failed to read mailbox message (CALL)!" call PRINT_STATUS_MESSAGE (l$_return_status) else l$_return_status =3D io_status::IOSB$W_STATUS if (l$_return_status <> SS$_NORMAL) then print TIME$(0%); " (ERROR) Failed to read mailbox message (IOSB)!" call PRINT_STATUS_MESSAGE (l$_return_status) end if end if As you see, the IOSB is declared on a MAP (static common block). The MSG data structure is declared as a local variable. This code is executed at the main program level, so there should be no issues with stale or invalid addresses. The C$_MAX_MESSAGE value is declared as a longword constant =3D 504, and MSG::S$_BUFFER is a fixed length string declared using the same C$_MAX_MESSAGE constant. There shouldn't be any question that the buffer area is sufficient to hold the largest message. According to the linker map, the MSG data structure is allocated in a psect which occurs well before the IOSB. So a (very large) overwrite of the MSG buffer would be needed to clobber the IOSB. By looking at the log from the mailbox writer process the largest message being written to the mailbox is around 160 bytes. I still need to verify that the writer is not writing a message larger than the mailbox maximum message size. However, I would expect an error from the $QIOW on the writer process if that were happening, and an SS $_BUFFEROVF on the reader side. The program is failing at the test of the IOSB status value, with the message about "failed to read ... (IOSB)" getting printed. As you can see, nothing occurs between the $QIOW completion and the test of the IOSB. I have to guess that the $QIOW is clobbering the status block. > That's why I suggest to create a formatted print of the memory around > the IOSB. You might just recognize the data when there is a little more o= f it. Did that, and yes it's very recognizable if I were looking at the mailbox writer, not the reader. That is, the data that's clobbering the IOSB appears to only exist in the writer process. A completely independent process from the reader where the invalid value is occurring. Very bizarre. Again suggesting that either the writer is dumping too large a message into the mailbox, or that the mailbox driver is getting quite confused, or both. ------------------------------ Date: Wed, 13 Feb 2008 02:31:14 GMT From: John Santos Subject: Re: Unusual mailbox status value Message-ID: FrankS wrote: > On Feb 12, 5:50 pm, Hein RMS van den Heuvel > wrote: > >>>The only other difference in mailbox handling between this version and >>>the one it replaces is the $QIOW now uses EFN$C_ENF instead of the >>>default event flag (0). Shouldn't be a factor unless there was a >>>patch related to EFN$C_ENF. >> >>But in using the EFN$C_ENF the IOSB because even more important. >>It plays a critical role in the underlying $SYNCH action. >>The EFN 0 usage may have influenced the timing. > > > Can you expand on why using EFN$C_ENF would affect the behavior? It *might* be changing the sequence of events. If EFN=0, it might fill in the buffer and then the IOSB, before setting the event flag (and triggering the completion AST), but if EFN=EFN$C_EFN, it *might* do this in the other order. If the i/o buffer is extending past the IOSB, you could see exactly this symptom. See below. > > I can't get Courier font on this news writer, so pardon the spacing > that follows. The relevant section of code (written in BASIC) is ... > > %include "$IOSBDEF" %from %library > %include "STARLET" %from %library > > map (NCR$IOSB) iosb io_status > map (NCR$IOSB) basic$quadword io_quadword > > l$_return_status = SYS$QIOW( EFN$C_ENF ! > EFN & > , w$_mailbox_channel ! > Chan & > , IO$_READVBLK ! > Func & > , io_quadword ! > IOSB & > , ! > ARTN & > , ! > APRM & > , msg::s$_buffer ! > P1 & > , c$_max_message ! > P2 & > , ! > P3 & > , ! > P4 & > , ! > P5 & > , ) ! P6 > > if (l$_return_status <> SS$_NORMAL) then > print TIME$(0%); " (ERROR) Failed to read mailbox message > (CALL)!" > call PRINT_STATUS_MESSAGE (l$_return_status) > else > l$_return_status = io_status::IOSB$W_STATUS > > if (l$_return_status <> SS$_NORMAL) then > print TIME$(0%); " (ERROR) Failed to read mailbox > message (IOSB)!" > call PRINT_STATUS_MESSAGE (l$_return_status) > end if > end if > > As you see, the IOSB is declared on a MAP (static common block). > > The MSG data structure is declared as a local variable. This code is > executed at the main program level, so there should be no issues with > stale or invalid addresses. The C$_MAX_MESSAGE value is declared as a > longword constant = 504, and MSG::S$_BUFFER is a fixed length string > declared using the same C$_MAX_MESSAGE constant. There shouldn't be > any question that the buffer area is sufficient to hold the largest > message. > > According to the linker map, the MSG data structure is allocated in a > psect which occurs well before the IOSB. So a (very large) overwrite > of the MSG buffer would be needed to clobber the IOSB. > > By looking at the log from the mailbox writer process the largest > message being written to the mailbox is around 160 bytes. I still > need to verify that the writer is not writing a message larger than > the mailbox maximum message size. However, I would expect an error > from the $QIOW on the writer process if that were happening, and an SS > $_BUFFEROVF on the reader side. > > The program is failing at the test of the IOSB status value, with the > message about "failed to read ... (IOSB)" getting printed. As you can > see, nothing occurs between the $QIOW completion and the test of the > IOSB. I have to guess that the $QIOW is clobbering the status block. > > >>That's why I suggest to create a formatted print of the memory around >>the IOSB. You might just recognize the data when there is a little more of it. > > > Did that, and yes it's very recognizable if I were looking at the > mailbox writer, not the reader. > > That is, the data that's clobbering the IOSB appears to only exist in > the writer process. A completely independent process from the reader > where the invalid value is occurring. Very bizarre. Again suggesting > that either the writer is dumping too large a message into the > mailbox, or that the mailbox driver is getting quite confused, or > both. > It really sounds like this is happening somehow (too long a message.) Are you sure there isn't a "passed by value"/"passed by reference" confusion somewhere? (P1, the buffer address, is passed by ref, but P2, the size of the buffer is passed by value. If what the driver is seeing via the qio arg list is in fact the address of the length rather than the length, it would most likely see some enormous buffer starting in the right place. If the same bug exists in the sender, it could be sending an enormous message, with valid stuff at the beginning. Due to differences in memory allocation, it could be stomping on something harmless in the test system, but on the IOSB on the production system.) One way to test this, beside dumping out the call stack right before the call to sys$qiow, would be to try sending a message of length c$_max_message+1 from the sender and see if the receiver gets an error SS$_BUFFEROVF. If it doesn't get an error, then the $QIOW isn't seeing the correct value for c$_max_message. P.S. Assuming c$_max_message is defined by your own code, not part of an HP facility, it shouldn't have a "$" in its name. (Or is it something defined by the C RTL?) "$" in a symbol name is supposed to be reserved for DEC/HP code and interfaces, or registered facilities. This convention is probably more honored in the breach, but it could jump up and bite you someday. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Tue, 12 Feb 2008 20:48:06 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: <24304a22-17fb-432d-ad7f-71fed5490d98@v4g2000hsf.googlegroups.com> On Feb 12, 9:31=A0pm, John Santos wrote: > Are you sure there isn't a "passed by value"/"passed by reference" confusi= on > somewhere? The %INCLUDE "STARLET" %FROM %LIBRARY takes care of declaring the parameter data types and passing mechanisms. The compiler is responsible for making sure the rest is handled correctly. If this were happening anyway, then I would expect it to happen much more often. Out of literally thousands of messages passing through the mailbox the error occurred only 5 or 6 times. The length field in the IOSB is coming out correct those thousands of error-free times, as it is used to verify the data being received. > P.S. =A0Assuming c$_max_message is defined by your own code, not part of a= n > HP facility, it shouldn't have a "$" in its name. =A0(Or is it something > defined by the C RTL?) =A0"$" in a symbol name is supposed to be reserved > for DEC/HP code and interfaces, or registered facilities. =A0This conventi= on > is probably more honored in the breach, but it could jump up and bite you > someday. The naming convention for atomic variables (use of $ and the leading data type indicator) is one of the "coding standards" that my client has established. It's definitely not my preference at all. ------------------------------ Date: Tue, 12 Feb 2008 22:40:48 -0800 (PST) From: David B Sneddon Subject: Re: Unusual mailbox status value Message-ID: <158eec67-f10a-413e-bf25-9c3ce28b257e@b2g2000hsg.googlegroups.com> On Feb 13, 4:48 am, FrankS wrote: > On Feb 12, 9:31 pm, John Santos wrote: > > > Are you sure there isn't a "passed by value"/"passed by reference" confusion > > somewhere? > > The %INCLUDE "STARLET" %FROM %LIBRARY takes care of declaring the > parameter data types and passing mechanisms. The compiler is > responsible for making sure the rest is handled correctly. It is my understanding that the definitions are there to allow the compiler to generate warnings about your code, not change the code. It is possible to pass something by reference and have the same result as passing something else by value and vice versa e.g. passing the address of a variable by value is the same as passing the variable by reference. > > If this were happening anyway, then I would expect it to happen much > more often. Out of literally thousands of messages passing through > the mailbox the error occurred only 5 or 6 times. The length field in > the IOSB is coming out correct those thousands of error-free times, as > it is used to verify the data being received. I have come across counltess examples of incorrectly coded calls to system services that have run for many many years (by luck, rather than by design). If you want something passed by value then specify "BY VALUE". Your code is wrong. Fix it. Dave ------------------------------ Date: Tue, 12 Feb 2008 18:50:32 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Xerox 7760 on DCPS? Message-ID: Paul Anderson wrote: > In article , > Jan-Erik Söderholm wrote: > >> Ah, OK. As long as the actual printer still has an PS emulator >> builtin, right ? > > Right. Actually, a PostScript "translator", not "emulator", although > some consider non-Adobe PostScript translators to be an emulator. > > Paul > OK, that explains what they mean when saying "Postscript (emulated)" in some product flyers. :-) B.t.w, got the font-TLB and it safe in the "sys$library" right now. Will get my HP LJ 2015n Thuesday or Friday, so there will be some weekend hacking, I guess... Jan-Erik. ------------------------------ End of INFO-VAX 2008.087 ************************