OpenVMS 7.3-1 and CSWING
Carlos Costa
I recently upgraded VMS to 7.3-1 (from VMS 7.3-0) on two separate
clusters. I have also been using CSWING for years now on various VMS
versions and I love it.
However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
it goes to search a new directory tree it goes off to never-never
land.
Has anyone else experienced this, and more importantly, is there a fix
out?
This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
own words, "100% binary compatibility with previous versions".
Thanks in advance.
Carlos
Mark Buda
"Carlos Costa" <carlos...@datawest.ca> wrote in message
news:7edc7395.02102...@posting.google.com...
> This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
> own words, "100% binary compatibility with previous versions".
Does CSWING use all public interfaces or CMKRNL to interrogate internal
data structures?
mark
Rob Brooks
> news:7edc7395.02102...@posting.google.com...
>
> This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
> own words, "100% binary compatibility with previous versions".
Are you the person who contacted the support centre? If so, did you
get a response to your report?
I've seen this problem discussed on our internal Notes system. The problem
*appears* to be a poorly-written application with some rather glaring
coding errors. That it worked at all in the past is somewhat surprising.
--
Rob Brooks VMS Engineering -- I/O Exec Group brooks!cuebid.zko.dec.com
Arne Vajhøj
Since CSWING is a file-manager, then I find it very hard to
believe that it uses internal data structures.
Arne
Arne Vajhøj
> "Carlos Costa" <carlos...@datawest.ca> wrote in message
>>news:7edc7395.02102...@posting.google.com...
>>This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
>>own words, "100% binary compatibility with previous versions".
> I've seen this problem discussed on our internal Notes system. The problem
> *appears* to be a poorly-written application with some rather glaring
> coding errors. That it worked at all in the past is somewhat surprising.
CSWING has worked for thosands of people for many many
years.
So it is a surprise if it breaks with VMS 7.3-1.
I assume it was developed for VAX C 3.2.
Which may explain at least some things that
look weird today.
Arne
Paddy O'Brien
Arne Vajhøj wrote:
> Mark Buda wrote:
>
>> "Carlos Costa" <carlos...@datawest.ca> wrote in message
>> news:7edc7395.02102...@posting.google.com...
>>
>>> This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
>>> own words, "100% binary compatibility with previous versions".
>>
>>
>> Does CSWING use all public interfaces or CMKRNL to interrogate internal
>> data structures?
>
>
> Since CSWING is a file-manager, then I find it very hard to
> believe that it uses internal data structures.
>
> Arne
I agree with Arne. I looked at the code several years ago and haven't
done anything than use it since.
It uses SMG and simple file management code. It is run on our system
from the most banal (in the sense of privileges) accounts. Nothing is
installed with/without privileges. It's just a process executable.
The original code was written in Fortran. I forget who changed it to C
and I forget the current maintainers. Regardless, they are names that I
know I have encountered elsewhere in the VMS world and the person who
said that it was poorly written and should never have worked
(paraphrasing) is denigrating some people who, IIRC, have helped to make
the VMS world a better place.
Perhaps Carlos or anyone else who uses CSWING and has moved to 7.3-1
should investigate this and help the maintainers, though CSWING does
seem to be in a sort of maintenance mode.
I am unlikely to move from 7.3 in the near future, but when I do, I
shall certainly check/debug this if I have not seen any upgrade.
Perhaps the denigrator might like to check all the other code that
enthusiasts have ported to VMS to try to give us a better environment in
line with what people are saying that VMS does not have. No doubt not
written to his high standards, and I'm sure he can find fault with the
code that I write to earn a few dollars.
Regards, Paddy
***********************************************************************
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now
firstname...@transgrid.com.au"
***********************************************************************
Rainer Giese
"Paddy O'Brien" <paddy.o'br...@tg.nsw.gov.au> schrieb im Newsbeitrag
news:3DB66C3...@tg.nsw.gov.au...
> The original code was written in Fortran. I forget who changed it to C
> and I forget the current maintainers.
It apparently was John E.Davis (found in main.c), but it is no longer on his
homepage (http://space.mit.edu/~davis/index.html). Modifications made by
Foteos Macrides (http://www.ku.edu/cwis/people/Foteos.Macrides.html).
--
Regards,
Rainer Giese
Phillip Helbig
> his homepage (http://space.mit.edu/~davis/index.html).
A quick glance didn't find it, but I think his JED editor will allow one
EDT-like features on other platforms.
> Modifications made by Foteos Macrides
> (http://www.ku.edu/cwis/people/Foteos.Macrides.html).
of LYNX fame.
Paul Anderson
Costa <carlos...@datawest.ca> wrote:
> However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
> it goes to search a new directory tree it goes off to never-never
> land.
It was mentioned in one of the internal Notes conferences that there is
a coding error in CSWING that causes this problem. Specifically, there
is an unitialized character array being used as a string descriptor.
The example given was:
dsc$w_length = strlen( str ) ;
I am the second-hand messenger and cannot vouch for the accuracy of
this bug report, as I don't use CSWING and haven't seen the code
myself.
Paul
--
Paul Anderson
OpenVMS Engineering
Hewlett-Packard Company
Carlos Costa
Unfortunately, although I know C, I have not programmed much under VMS
to be able to answer you fully. But, maybe if I explain what I have
found, more knowledgable people may see something. I have tried to
debug the code, and have found that the problem is in a function
called "get_dirs()" in the file SWING.C. This function is recursively
called to scan through a directory tree.
What happens is that when the scan hits the last leaf, it loops,
always returning that directory name. For example, if I have the
following structure:
[COSTA} --- BIN --- TOOLS
|
--- COM --- UTIL
then get_dirs() will get COSTA, BIN, TOOLS, then TOOLS, TOOLS, TOOLS,
... forever. it never goes back up the tree.
The actual call to VMS to read the directory is:
status = sys$qiow(0,
channel,
IO$_ACCESS,
&iosb[0],
0,
0,
&fib_desc,
DSC1(dir_template),
&file_length,
DSCA1(filename),
acb,
0);
if (status != SS$_NORMAL)
panic(status,"io$_access directory lookup","get dirs");
if (iosb[0] == SS$_NOMOREFILES){
fprintf(fcac,"after sys$qiow, NOMOREFILES\n");
return(TRUE);
}
Carlos
Carlos Costa
> "Carlos Costa" <carlos...@datawest.ca> wrote in message
> > news:7edc7395.02102...@posting.google.com...
> >
> > This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
> > own words, "100% binary compatibility with previous versions".
>
> Are you the person who contacted the support centre? If so, did you
> get a response to your report?
>
> I've seen this problem discussed on our internal Notes system. The problem
> *appears* to be a poorly-written application with some rather glaring
> coding errors. That it worked at all in the past is somewhat surprising.
If only one person put in a call, then, yes, that was me. There's two
things here.
1) Even if the code is poorly written (I'm not a judge of that as I
have not done much VMS C programming), I still don't understand why it
would break under VMS 7.3-1 and not 7.3-0. When I upgraded from 7.1-2
to 7.3-0, at that point I would have expected something to perhaps
break, but 7.3-0 to 7.3-1 is supposed be 100% compatible. Page 1-3 of
the release notes say, and I quote,
"Compaq is confident that the new release has 100% binary
compatibility with the previous release. If an application
compatibility problem is discovered, Compaq will assign the problem a
high priority and commit to providing a fix. There is no need for ISVs
to test on the new release or produce a new application kit."
So, as I read it, Compaq is committing to get CSWING to work under
7.3-1, but I have not heard much from my TAM on the subject except
that he put in a question to Engineering on it.
2) Would you be willing to share what you have found in the code so it
could be improved? You know, CSWING and programs like it (FLIST) are
so useful in a VMS environmen that I think HP/Compaq should really
have something like them.
Carlos
Carlos Costa
> Regards, Paddy
I have tried to get hold of the maintainers. There are a couple of
names listed in the readme files. Both the addresses bounced, but I
was able to get hold of Harry Flowers through another address. He said
that he is no longer maintaining the CSWING, so I don't know who is.
If there is someone, could they speak up?
Harry did wonder, though, if I was using the now filesystem, ODS5, as
he was pretty certain that CSWING would not work with it. I am *not*
using ODS5, but his comment got me to thinking that perhaps that is
where the problem in VMS lies. Whatever they put into VMS for ODS5
perhaps is not 100% binary compatible with 7.3-0. This has wider
implications than just CSWING. What else isn't going to work?
Harry also said that VMS has speeded up the file internals that made
reading the filesystem directory necessary in CSWING, and he thought
that it would be an idea for someone to re-write the directory
searching code (in get_dirs() on SWING.C) to use the improved file
lookup calls. Any willing VMS C programmers out there? It would be a
great service to the VMS community.
At any rate, I will keep you all informed of what happens.
Carlos
VAXman-
First, there are no guarantees here!
Where is the latest and greatest code base for CSWING? I'll take a look
at it to see if there is anything that can be done to easily remedy the
situation.
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
DAniel Allen
The status checking in this code snippet is not correct:
1) The QIO status should check not for SS$_NORMAL but any error value
2) After the IOSB check for SS$_NOMOREFILES you need to check for
any other error conditions. This is probably the cause of the
your problem.
This is not an issue with the OS version per se. This type of specific
error checking is simply poor coding which manifests itself when the OS
or run-time environment generates a new/unexpected error status.
Dan
"Mark Buda" <bu...@tabasco.zko.dec.no.spam.com> wrote in message
news:<N0gt9.22$oF.2...@news.cpqcorp.net>...
> "Carlos Costa" <carlos...@datawest.ca> wrote in message
> news:7edc7395.02102...@posting.google.com...
>
> > This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
> > own words, "100% binary compatibility with previous versions".
>
> Does CSWING use all public interfaces or CMKRNL to interrogate internal
> data structures?
>
Bob Koehler
> CSWING has worked for thosands of people for many many
> years.
>
> So it is a surprise if it breaks with VMS 7.3-1.
I've seen a lot of broken code that accidentally worked until
someone changed the accident that made it work. It's amaizing how
many programmers will ignore a documented API and just keep hacking
until something works. Sometimes you can tell why it worked (tested
an unused by reserved bit field, for example), sometimes you can't
(formatted an I/O with a Fortran FORMAT statement that really did
work but seemed to have little to do with the desired affect).
Keeps maintenance programmers happily employed, but it gets to be a
drag fixing the same thing over and over again.
If you're good, you can always make your system work correctly when
used as documented, but you cannot make it always fail to work when
not used as documented.
Remember how much trouble MS had getting WNT to run DOS programs on
platforms they hadn't thought of themselves?
DAniel Allen
>1) Even if the code is poorly written (I'm not a judge of that as I
>have not done much VMS C programming), I still don't understand why it
>would break under VMS 7.3-1 and not 7.3-0. When I upgraded from 7.1-2
>to 7.3-0, at that point I would have expected something to perhaps
>break, but 7.3-0 to 7.3-1 is supposed be 100% compatible. Page 1-3 of
>the release notes say, and I quote,
In VMS lingo compatible means if you code to the rules your code
will work in the new release. As I said in my previous post the
SWING code does not thouroughly interrogate the status returns from
the QIO; it ASSUMES the only status other than "normal" returned in
the IOSB is SS$_NOMOREFILES. A properly written test of VMS status
codes should always check the status code for conditions other than
the special case conditions they are specifically handling.
>2) Would you be willing to share what you have found in the code so it
>could be improved? You know, CSWING and programs like it (FLIST) are
>so useful in a VMS environmen that I think HP/Compaq should really
>have something like them.
I just shared. And I would add that VMS will not benefit from a
portfolio of poorly coded programs regardless of the source of the
code. I'd suggest you do a little reading on VMS ststus codes and
the use of the QIO status block. Once you understand that, go back
over the SWING (FLIST) code and verify that all of the return codes
are properly checked and your programs will benefit greatly from the
quality and consistency of the VMS environment.
Dan
"It if ain't broke you're probably using VMS"
me
Carlos Costa
>that he is no longer maintaining the CSWING, so I don't know who is.
>If there is someone, could they speak up?
>
First, there are no guarantees here!
Where is the latest and greatest code base for CSWING? I'll take a
look
at it to see if there is anything that can be done to easily remedy
the
situation.
--
VAXman- OpenVMS APE certification number: AAA-0001
VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
Ok, Mr VAXman. Here is where I found the code. The latest version that
I have found is 3.7.6.
http://www.tmk.com/ftp/vms-freeware/narnia/
Thanks.
Carlos
Carlos Costa
> The status checking in this code snippet is not correct:
>
> 1) The QIO status should check not for SS$_NORMAL but any error value
I am missing something here. The code doesn't check for SS$_NORMAL it
checks for not-equal-to SS$_NORMAL. Wouldn't that be the same as
checking for any error value? In other words, if the statis is NOT
NORMAL then an error occurs. If there was an error then SS$_NORMAL
would not return, would it? (again, I'm not an expert in VMS C, does
the status return mean that the system call itself was ok or not or
that the system call found an error? In other words, if some bad value
was passed to the sys$qiow would that result in a NOT SS$_NORMAL, or
only if the sys$qiow found an disk error or something? does that make
sense to anyone but me??)
> 2) After the IOSB check for SS$_NOMOREFILES you need to check for
> any other error conditions. This is probably the cause of the
> your problem.
This is what I mean. Are you saying that even if SS$_NORMAL is true
that there could be errors?
>
> This is not an issue with the OS version per se. This type of specific
> error checking is simply poor coding which manifests itself when the OS
> or run-time environment generates a new/unexpected error status.
Yes, but a point I've made before, that I think is important, is that
according to HP/Compaq 7.3-1 is "binary compatible" and that "there is
no need for ISVs to test on the new release", so there should not be
any "new/unexpected error status's".
> status = sys$qiow(0,
> channel,
> IO$_ACCESS,
> &iosb[0],
> 0,
> 0,
> &fib_desc,
> DSC1(dir_template),
> &file_length,
> DSCA1(filename),
> acb,
> 0);
>
> if (status != SS$_NORMAL)
> panic(status,"io$_access directory lookup","get dirs");
> if (iosb[0] == SS$_NOMOREFILES){
> return(TRUE);
> }
>
Carlos
Hoff Hoffman
:...I have not programmed much under VMS to be able to answer you fully...
Interesting. Please see topic (1661) in the OpenVMS Ask The Wizard
area, and please see the Programming Concepts manual for information.
: status = sys$qiow(0,
: channel,
: IO$_ACCESS,
: &iosb[0],
: 0,
: 0,
: &fib_desc,
: DSC1(dir_template),
: &file_length,
: DSCA1(filename),
: acb,
: 0);
:
: if (status != SS$_NORMAL)
: panic(status,"io$_access directory lookup","get dirs");
This construct is usually indicative of a more general programming
error, since this construct mishandles all but one of the possible
successful condition returns from sys$qiow. In other words, there
are a gazzillion potential successful status code returns that will
trigger the display of the panic message -- erroneously.
: if (iosb[0] == SS$_NOMOREFILES){
: fprintf(fcac,"after sys$qiow, NOMOREFILES\n");
: return(TRUE);
: }
Based solely on the quoted C code, this looks like latent bugs in
the code were exposed, as the error handling appears inadequate.
I'd want to see how to rest of the routine actually processes that
$qio, however.
In other words, the odd behaviour you are seeing could easily be
that of cswing and how cswing is coded, and not that of OpenVMS.
Ask The Wizard topic (1661) contains a list of some of the more
common latent bugs found lurking within various applications.
I have yet to find what I am sure is a full and current copy of
the cswing code, though I've found and looked at at least one
of the various copies found archived around the 'net. What I saw
had at least a few latent bugs, based on a cursory inspection. As
at least one other poster has requested, please provide a pointer
to what you believe is the current cswing kit.
I also lack the cycles to debug Freeware. I can't promise I'll
even have a chance to look at the cswing code, if the pointer is
provided (Folks here in OpenVMS are obviously rather busy working
on the port of OpenVMS over to Intel Itanium. I have a file system
to write. No pun intended. :-)
I spent quite some time debugging zip back around the release of
OpenVMS V7.2, as I was certain that the OpenVMS V7.2 upgrade had
broken it -- I was (very) wrong, BTW. The version of zip I was
working with had latent bugs, and the OpenVMS upgrade had changed
the timings and the stack layout enough to expose the bugs.
We went through a very similar exercise a couple of months back
both here in OpenVMS Engineering and here in the newsgroup, when
timing changes within the OpenVMS XFC support exposed a latent
bug within the Freeware VD64 package. (Of course, it was assumed
that XFC was at fault. Erroneously, as it turned out.)
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
Carlos Costa
<ho...@hp.nospam> wrote:
> Interesting. Please see topic (1661) in the OpenVMS Ask The Wizard
> area, and please see the Programming Concepts manual for information.
>
> ...
> In other words, the odd behaviour you are seeing could easily be
> that of cswing and how cswing is coded, and not that of OpenVMS.
>
> Ask The Wizard topic (1661) contains a list of some of the more
> common latent bugs found lurking within various applications.
>
One of my points, though, that no one has really answered is how about the
assertion from HP/Compaq that
"Compaq is confident that the new release has 100% binary
compatibility with the previous release. If an application
compatibility problem is discovered, Compaq will assign the problem a
high priority and commit to providing a fix. There is no need for ISVs
to test on the new release or produce a new application kit."
Certainly, CSWING is not the only application in the VMS world that has
dubious coding. And just because an application is not freeware does not
make it automatically good code (and vice versa!).
The above statement even says that "There is no need for ISVs to test". To
me that means that if it works under 7.3-0, no matter what bugs it has in
it, it should work under 7.3-1. By the way, my Gold Support TAM confirmed
and duplicated the problem, so it's not just me. Apparently they use CSWING
too, but they haven't upgraded to 7.3-1 yet.
Doesn't the fact that an application that works under 7.3-0 but not under
7.3-1 concern any of the VMS engineers?? Couldn't this be an indication of
some bug that crept into VMS, for example, because of the ODS5 coding.
(that's just an example, I have no idea, and I'm *not* using ODS5).
> I have yet to find what I am sure is a full and current copy of
> the cswing code, though I've found and looked at at least one
> of the various copies found archived around the 'net. What I saw
> had at least a few latent bugs, based on a cursory inspection. As
> at least one other poster has requested, please provide a pointer
> to what you believe is the current cswing kit.
>
I got my copy (version 3.7.6) from
http://www.tmk.com/ftp/vms-freeware/narnia/
> I also lack the cycles to debug Freeware. I can't promise I'll
> even have a chance to look at the cswing code, if the pointer is
> provided (Folks here in OpenVMS are obviously rather busy working
> on the port of OpenVMS over to Intel Itanium. I have a file system
> to write. No pun intended. :-)
Well, whatever you can find would be helpful. From the emails I've been
getting there are apparently a *lot* of people using CSWING out there.
CSWING users UNITE!
>
> I spent quite some time debugging zip back around the release of
> OpenVMS V7.2, as I was certain that the OpenVMS V7.2 upgrade had
> broken it -- I was (very) wrong, BTW. The version of zip I was
> working with had latent bugs, and the OpenVMS upgrade had changed
> the timings and the stack layout enough to expose the bugs.
>
> We went through a very similar exercise a couple of months back
> both here in OpenVMS Engineering and here in the newsgroup, when
> timing changes within the OpenVMS XFC support exposed a latent
> bug within the Freeware VD64 package. (Of course, it was assumed
> that XFC was at fault. Erroneously, as it turned out.)
Have you ever come across the other case? Where you thought that it was an
application bug but then found that it was a VMS bug?
>
> ---------------------------- #include <rtfaq.h> -----------------------------
> For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
> --------------------------- pure personal opinion ---------------------------
> Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
>
Carlos
Arne Vajhøj
> "DAniel Allen" <dal...@nist.gov> wrote in message news:<BCEGLBGJDODLELBJI...@nist.gov>...
>>The status checking in this code snippet is not correct:
>>
>> 1) The QIO status should check not for SS$_NORMAL but any error value
>>
>
> I am missing something here. The code doesn't check for SS$_NORMAL it
> checks for not-equal-to SS$_NORMAL. Wouldn't that be the same as
> checking for any error value? In other words, if the statis is NOT
> NORMAL then an error occurs. If there was an error then SS$_NORMAL
> would not return, would it?
I think one of the points is that there are other good status'es
than SS$_NORMAL.
Arne
Dave Weatherall
<paddy.o'br...@tg.nsw.gov.au> wrote:
>> > Since CSWING is a file-manager, then I find it very hard to
> > believe that it uses internal data structures.
> >
> > Arne
>
> I agree with Arne. I looked at the code several years ago and haven't
> done anything than use it since.
>
> It uses SMG and simple file management code. It is run on our system
> from the most banal (in the sense of privileges) accounts. Nothing is
> installed with/without privileges. It's just a process executable.
>
> The original code was written in Fortran. I forget who changed it to C
> and I forget the current maintainers. Regardless, they are names that I
> know I have encountered elsewhere in the VMS world and the person who
> said that it was poorly written and should never have worked
> (paraphrasing) is denigrating some people who, IIRC, have helped to make
> the VMS world a better place.
Hi Paddy
The last time I changed TREE (nee SWING) I
finally changed the the compiler command line to do an "IMPLICIT
NONE". This found all sorts of peculiarities, which I then fixed by
positively typing everything and, more importantly, corrected a
function return that got rid of a bug that bugged me since I fist
started using it 10 years before. I sent Glenn the latest earlier this
year.
--
Cheers - Dave.
PS It's still DEC-FORTRAN (77) and there are images for both VAX and
Alpha, linked on VMS 6.2.
Dave Weatherall
Costa) wrote:
> > status = sys$qiow(0,
> > channel,
> > IO$_ACCESS,
> > &iosb[0],
> > 0,
> > 0,
> > &fib_desc,
> > DSC1(dir_template),
> > &file_length,
> > DSCA1(filename),
> > acb,
> > 0);
> >
> > if (status != SS$_NORMAL)
> > panic(status,"io$_access directory lookup","get dirs");
> > if (iosb[0] == SS$_NOMOREFILES){
> > return(TRUE);
> > }
> >
To generalise >-
The check on status detemines whether the QIOW directive operated
correctly _not_ the result of the operation. e.g. the system is happy
with the argument list. What the code does appears acceptable assuming
PANIC exits with the status/error message.
The check on IOSB (I/O Status Block) gives information on the result.
One always checks both. Hoff's point is that IOSB could return a code
other than 'nomorefiles' and this condition is _not_ detected. Hence
an endless loop could occur... What could have changed in VMS to
return a different error code I dunno,
(XFC ???).
--
Cheers - Dave.
Carlos Costa
<ar...@vajhoej.dk> wrote:
> Carlos Costa wrote:
>
> > status = sys$qiow(0,
> > channel,
> > IO$_ACCESS,
> > &iosb[0],
> > 0,
> > 0,
> > &fib_desc,
> > DSC1(dir_template),
> > &file_length,
> > DSCA1(filename),
> > acb,
> > 0);
> >
> > if (status != SS$_NORMAL)
> > panic(status,"io$_access directory lookup","get dirs");
> > if (iosb[0] == SS$_NOMOREFILES){
> > return(TRUE);
> > }
> >
Yes, I see what they are saying now. I should add, though, that a "panic"
has not occurred. I've gotten "panics" in the past and they output a message
and exit the application. This has not happened. So I guess that means that
SS$_NORMAL is always being returned, which is a good thing I guess.
To be more correct, a "panic" does occur but only if you leave the program
running for a long time, but the error that occurs is an out of memory
error, caused I figured because the endless recursive calling of get_dirs()
eventually exausted the allocated memory of the process.
SS$_NOMOREFILES is being returned (sometimes anyways) as I've seen it during
my own feeble attempts to figure out what is going on.
Carlos
Bob Koehler
>> The status checking in this code snippet is not correct:
>>
>> 1) The QIO status should check not for SS$_NORMAL but any error value
>
> I am missing something here. The code doesn't check for SS$_NORMAL it
> checks for not-equal-to SS$_NORMAL. Wouldn't that be the same as
> checking for any error value?
No. Lots of success status other than SS$_NORMAL exist, including
the infamous %SYSTEM-S-ACCVIO (9).
> In other words, if the statis is NOT
> NORMAL then an error occurs. If there was an error then SS$_NORMAL
> would not return, would it? (again, I'm not an expert in VMS C, does
> the status return mean that the system call itself was ok or not or
> that the system call found an error? In other words, if some bad value
> was passed to the sys$qiow would that result in a NOT SS$_NORMAL, or
> only if the sys$qiow found an disk error or something? does that make
> sense to anyone but me??)
This doesn't depend on C. No matter what language you call it from
the return value indicates whether the I/O was put into the I/O queue
and the IOSB indicates whether the I/O actually executed correctly.
>> 2) After the IOSB check for SS$_NOMOREFILES you need to check for
>> any other error conditions. This is probably the cause of the
>> your problem.
>
> This is what I mean. Are you saying that even if SS$_NORMAL is true
> that there could be errors?
Absolutely. Since the I/O system is by its nature asynchronous VMS
provides two different status returns with two different meanings.
John E. Malmberg
> On 10/23/02 11:05 PM, in article 3DB78DA0...@vajhoej.dk, "Arne Vajhøj"
> <ar...@vajhoej.dk> wrote:
>
>
>>Carlos Costa wrote:
>>
>>
>>> status = sys$qiow(0,
>>> channel,
>>> IO$_ACCESS,
>>> &iosb[0],
>>> 0,
>>> 0,
>>> &fib_desc,
>>> DSC1(dir_template),
>>> &file_length,
>>> DSCA1(filename),
>>> acb,
>>> 0);
>>>
>>> if (status != SS$_NORMAL)
>>> panic(status,"io$_access directory lookup","get dirs");
>>> if (iosb[0] == SS$_NOMOREFILES){
>>> return(TRUE);
>>> }
>>>
>
> SS$_NOMOREFILES is being returned (sometimes anyways) as I've seen it during
> my own feeble attempts to figure out what is going on.
Not shown in the code fragment is that the variable iosb is declared as
an array of longwords. So the comparison of iosb[0] is 32 bits instead
of the lower 16 bits.
For the IO$_ACCESS function, the iosb is defined with the second
longword as "Unused". That does not mean that you should assume that it
contains 0.
If you remove the /VAXC and add /WARN=ENABLE=(LEVEL4, QUESTCODE) all
sorts of problems start showing up.
The most interesting is that several functions return unspecified values
when certain execution paths are taken.
Unless you turn on the enhanced warnings, the C compiler will not
diagnose this programming error. It is legal in C to deliberatly code
this way, even though there is no way to predict what value the function
will return.
It also appears that the smg*.h header files are missing some #pragma
statements.
The following workaround can be used for smgdef.
#pragma message save
#pragma message disable nestedcomment
#pragma message disable misalgndstrct
#include <smgdef.h>
#pragma message restore
-John
malm...@dskwld.zko.dec.compaq.hp
Personal Opinion Only
Paul Repacholi
> I recently upgraded VMS to 7.3-1 (from VMS 7.3-0) on two separate
> clusters. I have also been using CSWING for years now on various VMS
> versions and I love it.
> However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
> it goes to search a new directory tree it goes off to never-never
> land.
> Has anyone else experienced this, and more importantly, is there a
> fix out?
It has done this `forever' with ISO9660 CDs.
> This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
> own words, "100% binary compatibility with previous versions".
I think you missunderstand the statment, and some of the moderatly sus
things CSWING does. But I too am curious as to what has changed.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Keith A. Lewis
>Hello, everyone.
>
>I recently upgraded VMS to 7.3-1 (from VMS 7.3-0) on two separate
>clusters. I have also been using CSWING for years now on various VMS
>versions and I love it.
>
>However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
>it goes to search a new directory tree it goes off to never-never
>land.
Confirmed.
7.3 7.3-1
--- -----
old image works never-never land
relinked image works access violation
Recompiling the source fails because my relatively recent C compiler whines
about getenv() being an int...
--Keith Lewis klewis$mitre.org
The above may not (yet) represent the opinions of my employer.
Keith A. Lewis
>Harry did wonder, though, if I was using the now filesystem, ODS5, as
>he was pretty certain that CSWING would not work with it. I am *not*
>using ODS5, but his comment got me to thinking that perhaps that is
>where the problem in VMS lies. Whatever they put into VMS for ODS5
>perhaps is not 100% binary compatible with 7.3-0. This has wider
>implications than just CSWING. What else isn't going to work?
I am using ODS-5 on my 7.2-1, 7.3 and 7.3-1 cluster nodes. The old systems
work, 7.3-1 doesn't. As you said, it goes off into never-never land.
When I relink the old .OBJ files on 7.3-1 and then run it bombs with an
access violation regardless of the runtime VMS version.
I couldn't get the C source to recompile on the Compaq C 6.4. It thinks
getenv() is an int for some reason.
>Harry also said that VMS has speeded up the file internals that made
>reading the filesystem directory necessary in CSWING, and he thought
>that it would be an idea for someone to re-write the directory
>searching code (in get_dirs() on SWING.C) to use the improved file
>lookup calls. Any willing VMS C programmers out there? It would be a
>great service to the VMS community.
Send me an Elsa Gloria Synergy card and I'll do it! :^)
Dale King
> carlos...@datawest.ca (Carlos Costa) writes:
>
>> I recently upgraded VMS to 7.3-1 (from VMS 7.3-0) on two separate
>> clusters. I have also been using CSWING for years now on various VMS
>> versions and I love it.
>
>> However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
>> it goes to search a new directory tree it goes off to never-never
>> land.
>
>> Has anyone else experienced this, and more importantly, is there a
>> fix out?
>
> It has done this `forever' with ISO9660 CDs.
>
>> This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
>> own words, "100% binary compatibility with previous versions".
>
> I think you missunderstand the statment, and some of the moderatly sus
> things CSWING does. But I too am curious as to what has changed.
One thing I've noticed between V7.3 and V7.3-1 that I can't find in the release
notes is that the output of the DIRECTORY command has changed.
Where the command:
$ DIR/COLUMNS=1/SIZE=ALL/WIDTH=FILENAME=40/DATE=MODI
used to look "nice" under the former, it now wraps under the latter. I presume
this is to allow larger filesizes to be displayed.
I wonder if this is related?
Martin Vorlaender
> Recompiling the source fails because my relatively recent C compiler whines
> about getenv() being an int...
Easy: just add
#include <stdlib.h>
at the top of the SWING.C. And while we're at it: add
#include <string.h>
as well to get rid of the %CC-I-INTRINSICINT messages about the intrinsic
strlen()'s return being converted from size_t to int.
But there's a *lot* more to clean up to get a clean compile with DEC C even
in /STANDARD=VAXC mode, e.g. many routines returning char* are declared
with an implicit int return type. And no prototypes. But I might be tempted
to give it a try...
cu,
Martin
--
Your mouse has moved. | Martin Vorlaender | VMS & WNT programmer
Windows must be restarted | work: m...@pdv-systeme.de
for the change to take | http://www.pdv-systeme.de/users/martinv/
effect. Reboot now? [OK] | home: mar...@radiogaga.harz.de
Dave Weatherall
True, one would normally test for 'odd'ness. Odd being good, even bad.
The point being that bit 0 signals success(1) or fail(0), other bits
in the status return qualify the 'goodness' or describe the failure.
In DEC-Fortran you can test the INTEGER return as though it were a
LOGICAL ,i.e. TRUE (good) or FALSE (bad).
In C I've used a macro vms_ok(status) which tests the state of bit 0.
What I do in PASCAL .... ISTR if odd(status).
In macro, use BLBS/BLBC instructions.
That's my languages exhausted.
--
Cheers - Dave.
gr...@rigel.cc.wmich.edu
eliminate the gross compile errors. When I get that done, and have
cleaned up the error checks, iosb usage, item list declarations, etc.
I'd be happy to let any of you try it on 7.3-1 (I'm at 7.3). If it
works (or we can find the remaining problem), that may make a good
base for he suggested improvements to directory read performance.
I should have something available early next week.
Dan Allen
> -----Original Message-----
> From: Carlos Costa [mailto:ca...@shaw.ca]
> Sent: Thursday, October 24, 2002 12:13 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: OpenVMS 7.3-1 and CSWING
> One of my points, though, that no one has really answered is how about the
> assertion from HP/Compaq that
>
> "Compaq is confident that the new release has 100% binary
> compatibility with the previous release. If an application
> compatibility problem is discovered, Compaq will assign the problem a
> high priority and commit to providing a fix. There is no need for ISVs
> to test on the new release or produce a new application kit."
>
> Certainly, CSWING is not the only application in the VMS world that has
> dubious coding. And just because an application is not freeware does not
> make it automatically good code (and vice versa!).
>
> The above statement even says that "There is no need for ISVs to test". To
> me that means that if it works under 7.3-0, no matter what bugs it has in
> it, it should work under 7.3-1. By the way, my Gold Support TAM confirmed
> and duplicated the problem, so it's not just me. Apparently they use CSWING
> too, but they haven't upgraded to 7.3-1 yet.
Are you serious! Do you really think that ANY operating system vendor
can or will commit to maintaining compatability with latent bugs in
all of the application software ever developed for the OS! While I don't
speak for VMS engineering or HP I'm confident they do not think that the
assurances they gave with regard to compatability apply to buggy applications
i.e. they do not warrant 7.3-1 to be "bug compatible" with 7.3. Obviously
fixing an OS bug that allowed an application bug to be masked or ignored
will cause the application to fail. New releases often fix bugs - duh!
With regard to the "no need for ISV's to test" assertion they are obviously
silly and any ISV who believes that there is no need to test their product
on a new release is silly too.
It's been two days since I pointed out the weakness in the status checking
in the code snippet you posted and the likelyhood that it's failing to properly
detect and report a system service error. Have you applied the one line
patch I offered and determined that my suspicions are or are not confirmed?
If not I'd suggest you quit whining about what MIGHT be an OS bug and give us
some hard info on what's actually happening. If I had the environment to test
the damn thing myself I would have already done it for you! This isn't rocket
science, it's not even computer science, it's programming 101.
Rob Young
Exactly and very well said. I've been following this a while
and most of my thoughts are similar. Binary compatability people
is NOT:
Bug for bug compatability across OS rev levels
Rob
Carlos Costa
> > -----Original Message-----
> > From: Carlos Costa [mailto:ca...@shaw.ca]
> > Sent: Thursday, October 24, 2002 12:13 AM
> > To: Info...@Mvb.Saic.Com
> > Subject: Re: OpenVMS 7.3-1 and CSWING
> > One of my points, though, that no one has really answered is how about the
> > assertion from HP/Compaq that
> >
> > "Compaq is confident that the new release has 100% binary
> > compatibility with the previous release. If an application
> > compatibility problem is discovered, Compaq will assign the problem a
> > high priority and commit to providing a fix. There is no need for ISVs
> > to test on the new release or produce a new application kit."
> >
> > Certainly, CSWING is not the only application in the VMS world that has
> > dubious coding. And just because an application is not freeware does not
> > make it automatically good code (and vice versa!).
> >
> > The above statement even says that "There is no need for ISVs to test". To
> > me that means that if it works under 7.3-0, no matter what bugs it has in
> > it, it should work under 7.3-1. By the way, my Gold Support TAM confirmed
> > and duplicated the problem, so it's not just me. Apparently they use CSWING
> > too, but they haven't upgraded to 7.3-1 yet.
>
> Are you serious! Do you really think that ANY operating system vendor
> can or will commit to maintaining compatability with latent bugs in
> all of the application software ever developed for the OS!
Excuse me, but yes, I am serious. If you read the above statement
carefully you will see that that is exactly what HP/Compaq has done.
They have committed to maintaining 100% binary compatability. I didn't
say it, THEY did. If they didn't mean it they shouldn't have said it.
Binary compatibility is a pretty tight compatibility. It means that no
program needs to be re-compiled or re-linked. It will work as it is.
They even say "no testing needed".
Secondly, one of the reasons I pointed that statement out is because
that statement means, to me, that there is a bug in the VMS code.
HP/Compaq expected something like it because they said "If an
application compatibility problem is encountered...". Well, my friend,
an application compatibility problem *has* been encountered. So, now,
instead of them crying out about all the the bugs in application code
and about how great, and solid, and bug-free VMS is, they ought to be
looking at *why* there is an application compatibility problem and
honouring their word.
There seems to be lots of scorn thrown the way of CSWING merely
because it is freeware. Non-free programs have bugs too, and lousy
code. The point is not whether there are bugs or not, but that there
is a compatibility issue, and whether that issue is the result of bad
coding either in CSWING or in VMS is immaterial. HP/Compaq has
"committed" to fixing it. Their word. They didn't say they would only
fix it "if it's a commercial program", or "if it is bug free code".
However, having said that, I don't expect HP/Compaq to admit that the
CSWING issue is caused by a bug in VMS. This is why I appealed to this
group of fine VMS users.
> While I don't
> speak for VMS engineering or HP I'm confident they do not think that the
> assurances they gave with regard to compatability apply to buggy applications
> i.e. they do not warrant 7.3-1 to be "bug compatible" with 7.3. Obviously
> fixing an OS bug that allowed an application bug to be masked or ignored
> will cause the application to fail. New releases often fix bugs - duh!
>
Yes, that is true. That is why they added the statement "If an
application compatibility problem is discovered, Compaq will assign
the problem a high priority and commit to providing a fix.". They know
that that may happen, and guess what? It did. No surprise there. The
only surprise is why people are opposed to finding a solution.
>With regard to the "no need for ISV's to test" assertion they are
obviously
>silly and any ISV who believes that there is no need to test their
product
>on a new release is silly too.
No, not silly. Merely confident. This is why this is an "Enhancement
release". The release notes go on to say "The release may contain new
hardware support, software support, software enhancements and
maintenance, but the changes are isolated and have no impact on
applications."
Their words are "no impact on applications". Seems pretty clear to me.
If they had done everything right then CSWING would still be working.
If there is an impact in applications (as there clearly is) then it
means that someone screwed up. So, let's be adult about it, 'fess up,
fix the problem, and get on with our lives.
If 7.3-1 is more than an Enhancment release, then it should have been
called 7.4. as someone has already pointed out. But they didn't call
it 7.4 because they were expecting CSWING to work. Must have slipped
their testing somehow.
>It's been two days since I pointed out the weakness in the status
checking
>in the code snippet you posted and the likelyhood that it's failing
to properly
>detect and report a system service error. Have you applied the one
line
>patch I offered and determined that my suspicions are or are not
confirmed?
Actually, I did. What I got was:
Searching, root = SHODAN:[000000]
%SYSTEM-W-NOSUCHFILE, no such file
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC
abs PC
CSWING 0 0000000000021310
0000000000031310
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 0000000000023064
0000000000033064
CSWING 0 0000000000022D80
0000000000032D80
CSWING 0 0000000000023C94
0000000000033C94
CSWING 0 00000000000209F4
00000000000309F4
CSWING 0 0000000000020070
0000000000030070
0 FFFFFFFF8027B63C
FFFFFFFF8027B63C
%SYSTEM-W-NOMOREFILES, no more files
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC
abs PC
CSWING 0 0000000000021310
0000000000031310
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 0000000000023064
0000000000033064
CSWING 0 0000000000022D80
0000000000032D80
CSWING 0 0000000000023C94
0000000000033C94
CSWING 0 00000000000209F4
00000000000309F4
CSWING 0 0000000000020070
0000000000030070
0 FFFFFFFF8027B63C
FFFFFFFF8027B63C
%SYSTEM-W-NOSUCHFILE, no such file
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC
abs PC
CSWING 0 0000000000021310
0000000000031310
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 00000000000214A8
00000000000314A8
CSWING 0 0000000000023064
0000000000033064
CSWING 0 0000000000022D80
0000000000032D80
CSWING 0 0000000000023C94
0000000000033C94
CSWING 0 00000000000209F4
00000000000309F4
CSWING 0 0000000000020070
0000000000030070
0 FFFFFFFF8027B63C
FFFFFFFF8027B63C
%SYSTEM-W-NOMOREFILES, no more files
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC
abs PC
CSWING 0 0000000000021310
0000000000031310
CSWING 0 00000000000214A8
00000000000314A8
etc, etc.
It means absolutely nothing to me. Told you I was weak in VMS systems
programming.
>If not I'd suggest you quit whining about what MIGHT be an OS bug and
give us
>some hard info on what's actually happening. If I had the environment
to test
>the damn thing myself I would have already done it for you! This
isn't rocket
>science, it's not even computer science, it's programming 101.
I don't know about that, the particular code is recursive and full of
VMS specifics. Not for the faint of heart. And please don't get
personal about this. You're hinting that I'm not as smart as you to
not have fixed this myself, and you could very well be right. But
"Don't judge someone until you've walked a mile in his shoes." But
you've only seen a small code fragment. There are many more thousands
of lines.
I admitted as such at the beginning of this thread. I don't know my
way around the VMS programming world too well. Sir, this is why I
appealed to this group. If I was able to fix it myself I assure you
that I would have. And, perhaps, given another few months I'll know
enough about the VMS calls and idiosyncracies to figure it out. After
looking at this for a while, and getting nowhere, I thought I'd see if
anyone more knowledgable and experienced may have already have looked
at it. Please don't begrudge me that. I wouldn't exactly call it
whining, more like a feeble cry for help in the wilderness. Instead of
a helping hand do I now get wolves on my trail? :-)
Carlos
John E. Malmberg
> carlos...@datawest.ca (Carlos Costa) writes:
>
>>I recently upgraded VMS to 7.3-1 (from VMS 7.3-0) on two separate
>>clusters. I have also been using CSWING for years now on various VMS
>>versions and I love it.
>
>>However, in 7.3-1 CSWING no longer works (it does under 7.3-0). When
>>it goes to search a new directory tree it goes off to never-never
>>land.
>
>>Has anyone else experienced this, and more importantly, is there a
>>fix out?
>
According to the Compaq C compiler, when you remove the /VAXC which
basically suppresses most warning messages, and add
/WARN=ENABLE=(LEVEL4, QUESTCODE):
Several of the routines involved in doing the directory transversal do
not always specify their return value. This means that they are
returning pseudo random numbers instead of either a logical value or a
pointer.
C99 is required to diagnose this bug. C89 and earlier is not required
to diagnose this bug.
The latest Compaq C compiler can diagnose these bugs, but that is not
the default mode.
> It has done this `forever' with ISO9660 CDs
It really depends on what is in the R0 register at the time the routine
exits. That is not easily predictable. A small change in the run-time
library, or even the compile options could change things.
>>This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
>>own words, "100% binary compatibility with previous versions".
>
> I think you missunderstand the statment, and some of the moderatly sus
> things CSWING does. But I too am curious as to what has changed.
It will probably take me a few more lunch hours to get it to compile
cleanly. Currently I have up to swing_4.c compiling with no errors.
But I have had to make several updates to the source, most of them by
adding prototypes and correcting the types of variables and structure
members.
Most of the problems that I have seen are minor, but effectively the
directoy node transversal routines have always been sometimes returning
random numbers.
As pointed out on my earlier post, which seems to have been missed, the
following errors are present:
The directory transversal routines are sometimes returning psuedo random
numbers instead of valid values.
The status value in an IOSB is a 16 bit value, but is being declared in
the routine as a longword. This bug is probably not causing the
problem. But there is no guarantee that the upper 16 bits will be zero
in this case.
It also appears that the smg*.h are missing #pragma settings that are
needed for Compaq/DEC C.
-John
wb8...@qsl.network
Personal Opinion Only
Robert Deininger
carlos...@datawest.ca (Carlos Costa) wrote:
<snip>
>There seems to be lots of scorn thrown the way of CSWING merely
>because it is freeware. Non-free programs have bugs too, and lousy
>code.
I think most folks hear have a lot of appreciation for freeware. If there
is any scorn, it is likely for the bugs that are being found. Bugs
happen, but some of these are pretty blatant.
<snip>
>Yes, that is true. That is why they added the statement "If an
>application compatibility problem is discovered, Compaq will assign
>the problem a high priority and commit to providing a fix.". They know
>that that may happen, and guess what? It did. No surprise there. The
>only surprise is why people are opposed to finding a solution.
I think several folks _here_ have offered pointers toward a solution.
The first part of the solution is to remove any latent bugs in CSWING that
might be the cause of the symptom. If bugs remain that are due to V7.3-1,
then it's time to beat HP over the head with them.
IMHO, Compaq's compatibility statement is far too strong to be realistic.
It was probably written by a marketing person. I can't picture a sane
engineer making this statement with a straight face. HP will have to sort
it out.
>>It's been two days since I pointed out the weakness in the status
>checking
>>in the code snippet you posted and the likelyhood that it's failing
>to properly
>>detect and report a system service error. Have you applied the one
>line
>>patch I offered and determined that my suspicions are or are not
>confirmed?
>
>Actually, I did. What I got was:
>
>Searching, root = SHODAN:[000000]
>%SYSTEM-W-NOSUCHFILE, no such file
Ah! This is useful. "No such file" means we asked for a file spec that
isn't there.
Might be worth looking at whether the program deals with this condition
properly.
The traceback is useful if you are trying to debug with a link map and
compiler listings. It shows each level in the call chain of functions.
The addresses given here can be matched up with specific lines of code and
specific machine instructions. The traceback answers the question, "how
did we get here".
But this isn't a very fun way to debug. It's much easier to use the VMS
debugger. There's a fair learning curve for that, but the debugger manual
is quite good.
>%TRACE-W-TRACEBACK, symbolic stack dump follows
<snip>
>%SYSTEM-W-NOMOREFILES, no more files
This is a different condition, "no more files".
>%SYSTEM-W-NOSUCHFILE, no such file
And another "no such file"...
etc.
>It means absolutely nothing to me. Told you I was weak in VMS systems
>programming.
I given one or two hints above. I don't have the program in front of me
to do more investigating. See the C documentation and the debugger manual
if you are interested in gaining debugging skills, and feel free to post
questions here.
>>If not I'd suggest you quit whining about what MIGHT be an OS bug and
>give us
>>some hard info on what's actually happening. If I had the environment
>to test
>>the damn thing myself I would have already done it for you! This
>isn't rocket
>>science, it's not even computer science, it's programming 101.
Well, that comment was uncalled for. Old timers tend to forget how
overwhelming a big program appears to someone with little experience.
>I don't know about that, the particular code is recursive and full of
>VMS specifics. Not for the faint of heart.
Agreed. If you don't have much VMS programming experience, CSWING doesn't
look like an ideal self-study aid. It has a number of errors, many of
which have been dormant for years. C lends itself to this problem in a
number of ways which I won't get into at the moment. And the old VAX C
was rather weak at pointing out bad programming practice.
Carlos Costa
rdeininger-25...@1cust118.tnt2.nashua.nh.da.uu.net, "Robert
Deininger" <rdein...@mindspring.com> wrote:
>
>> Yes, that is true. That is why they added the statement "If an
>> application compatibility problem is discovered, Compaq will assign
>> the problem a high priority and commit to providing a fix.". They know
>> that that may happen, and guess what? It did. No surprise there. The
>> only surprise is why people are opposed to finding a solution.
>
> I think several folks _here_ have offered pointers toward a solution.
>
Yes, you are right. My sincere apologies if I sounded like I was disparaging
the group. I didn't mean to. 99% of the postings have been very helpful. I
just got riled by the particular poster's tone. Not like me, actually, I'm
usually meek and mild... My only excuse is that I'm going through CWS
(CSWING Withdrawal Syndrome. :-)
> The first part of the solution is to remove any latent bugs in CSWING that
> might be the cause of the symptom. If bugs remain that are due to V7.3-1,
> then it's time to beat HP over the head with them.
>
> IMHO, Compaq's compatibility statement is far too strong to be realistic.
> It was probably written by a marketing person. I can't picture a sane
> engineer making this statement with a straight face. HP will have to sort
> it out.
>
It does seem strong to me too. I was not trying to say that it was true,
only that that's what HP said. But there are several types of updates and
this one is supposed to be the mildest sort (Enhancement Release) so I
really think that they expected most, if not all, code to be compatible. It
just looks like something slipped between the cracks. And really, it matters
little to me whether it is a VMS or a CSWING bug or a combination. I'd just
like to get CSWING working again.
>>
>> Actually, I did. What I got was:
>>
>> Searching, root = SHODAN:[000000]
>> %SYSTEM-W-NOSUCHFILE, no such file
>
> Ah! This is useful. "No such file" means we asked for a file spec that
> isn't there.
>
> Might be worth looking at whether the program deals with this condition
> properly.
Actually, it does. The next little bit of code checks for this condition. It
looks to me that NOSUCHFILE and the NOMOREFILES seem to be the two
conditions checked for.
>
> The traceback is useful if you are trying to debug with a link map and
> compiler listings. It shows each level in the call chain of functions.
> The addresses given here can be matched up with specific lines of code and
> specific machine instructions. The traceback answers the question, "how
> did we get here".
>
> But this isn't a very fun way to debug. It's much easier to use the VMS
> debugger. There's a fair learning curve for that, but the debugger manual
> is quite good.
>> %TRACE-W-TRACEBACK, symbolic stack dump follows
>
> <snip>
>
>> %SYSTEM-W-NOMOREFILES, no more files
>
> This is a different condition, "no more files".
>
>> %SYSTEM-W-NOSUCHFILE, no such file
>
> And another "no such file"...
>
> etc.
>
>
>> It means absolutely nothing to me. Told you I was weak in VMS systems
>> programming.
>
> I given one or two hints above. I don't have the program in front of me
> to do more investigating. See the C documentation and the debugger manual
> if you are interested in gaining debugging skills, and feel free to post
> questions here.
Thanks for your hints. I have also been reading the stuff that was suggested
earlier (VMS Answer Man articles, etc). The debugger manual is BIG and
daunting, but I think that will be my next go at trying to see what is
happening. I guess one must start somewhere, but I suspect that someone will
get CSWING working before I do.
Carlos
Craig A. Berry
<rdeininger-25...@1cust118.tnt2.nashua.nh.da.uu.net>,
> >Searching, root = SHODAN:[000000]
> >%SYSTEM-W-NOSUCHFILE, no such file
>
> Ah! This is useful. "No such file" means we asked for a file spec that
> isn't there.
>
> Might be worth looking at whether the program deals with this condition
> properly.
/*
** file in dir but not indexf.sys
*/
if (iosb[0] == SS$_NOSUCHFILE)
{
fib.fib$l_wcc++;
continue;
}
Isn't the "wild card context" of the file information block one of
those opaque longword values that one should not depend on coming in
sequence, much less increment oneself and hope that doing so will not
get you in trouble? I certainly don't see anything in the I/O User's
Guide that suggests I could predict or should attempt to influence the
value of the wcc. I have a strong suspicion that the code I've quoted
is the source of the looping problem. Section 1.3.1.2 of the I/O
User's Guide says:
"On the first lookup, FIB$L_WCC should contain zero entries. On each
lookup, the ACP returns a nonzero value in FIB$L_WCC, which must be
passed back on the next lookup call. In addition, you must pass the
resultant name string returned by the previous lookup using the P4
result string buffer, and its length in the P3 result length word.
This string is used together with FIB$L_WCC to continue the wildcard
search at the correct position in the directory."
The code in question, in addition to depending on what appears to be
undocumented (and apparently obsolete) behavior of the context value,
also does not pass the previous result name on subsequent calls (it
zeros the first byte of the name string before each QIO and also zeros
the length).
John Malmberg's approach of following the compiler warnings will no
doubt bring great improvement to the package, but there are also
things that should be rethought and possibly reimplemented. I would
expect that lib$find_file (or even readdir() for that matter) would
offer a more maintainable method for getting a directory listing than
the QIO method.
Dan Allen
> -----Original Message-----
> From: Carlos Costa [mailto:carlos...@datawest.ca]
> Sent: Friday, October 25, 2002 6:21 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: OpenVMS 7.3-1 and CSWING
>
>
> "Dan Allen" <dal...@nist.gov> wrote in message news:<JFEPKAPBPMDFDBOIA...@nist.gov>...
> > > -----Original Message-----
> >
> > Are you serious! Do you really think that ANY operating system vendor
> > can or will commit to maintaining compatability with latent bugs in
> > all of the application software ever developed for the OS!
>
> Excuse me, but yes, I am serious. If you read the above statement
> carefully you will see that that is exactly what HP/Compaq has done.
> They have committed to maintaining 100% binary compatability. I didn't
> say it, THEY did. If they didn't mean it they shouldn't have said it.
> Binary compatibility is a pretty tight compatibility. It means that no
> program needs to be re-compiled or re-linked. It will work as it is.
> They even say "no testing needed".
>
> Secondly, one of the reasons I pointed that statement out is because
> that statement means, to me, that there is a bug in the VMS code.
See Craig Berry's post on the misuse of the context value and name string
in the FIB in the CSWING source code. Most likely the problem. Note also
that this is what I would call a latent application bug, i.e. it is not
providing the proper input to the QIO call. The fact that it worked by
chance in 7.3 but fails in 7.3-1 is not what I would call a bug in the
OS and I doubt VMS engineering would be motivated to restore the old
behavior.
> >If not I'd suggest you quit whining about what MIGHT be an OS bug and
> give us
> >some hard info on what's actually happening. If I had the environment
> to test
> >the damn thing myself I would have already done it for you! This
> isn't rocket
> >science, it's not even computer science, it's programming 101.
>
> I don't know about that, the particular code is recursive and full of
> VMS specifics. Not for the faint of heart. And please don't get
> personal about this. You're hinting that I'm not as smart as you to
> not have fixed this myself, and you could very well be right. But
> "Don't judge someone until you've walked a mile in his shoes." But
> you've only seen a small code fragment. There are many more thousands
> of lines.
I said absolutely nothing about your "smarts". The comment was directed
at your focus on your believe that you had uncovered an OS bug based
solely on YOUR interpretation what binary compatability meant and the
lack of additional data with regard to problems identified by folks
more familiar with VMS coding practices. I encourage you to learn
more about the VMS operating system. I've walked many a mile in your
shoes and I learned fairly early on that these problems are invariably
a latent problem in MY code not the OS.
I've lurked on this list for quite some time now and I believe the people
here are more than willing to give of their time and experience helping
anyone from the pure neophyte to the seasoned internals programmer diagnose
and correct problems with their codes. But the way to accomplish that is to
post a complete problem description and source code when available. Then
follow up and test problems identified by this process and report the results
to the list if you are unable to make sense of them yourself.
And as Craig Berry has pointed out (see below) the problem would appear to be
an application error in CSWING. Had you posted a more extensive code snippet
including the error processing of the SS$_NOSUCHFILE condition code you
likely could have shortcut this effort considerably.
*********** The following analysis thanks to Craig Berry *************
gr...@rigel.cc.wmich.edu
found so it compiles without errors. I think I got past the few cases
of routines with inconsistent numbers of arguments, several cases of
referencing non-existent structure members, and a library function which
doesn't exist in the C headers (lib$erase_page). I also cleaned up all
the IOSBs, corrected some longs which should have been shorts (channels,
and lengths) and a few improperly initialized descriptors, but, there
were a few coding errors I don't have time to pursue, including two
global routines named "rest_cursor" and an attempt to assign a pointer
to an integer.
However, I don't have the time or ambition to do the kind of rewrite
which is indicated by Craig Berry's observation.
If anyone would like to either take on that job starting with a
compilable copy of the source, or just try the compilable version to
see whether it works any better than the old executable, you can mail
be and I'll ship you the zip with the original and my changes.
Good luck
In article <JFEPKAPBPMDFDBOIA...@nist.gov>, "Dan Allen" <dal...@nist.gov> writes:
>
>
John E. Davis
wrote:
>It apparently was John E.Davis (found in main.c), but it is no longer on his
>homepage (http://space.mit.edu/~davis/index.html). Modifications made by
>Foteos Macrides (http://www.ku.edu/cwis/people/Foteos.Macrides.html).
I had nothing to do with CSWING other than writing MOST, which CSWING
used for paging files. You will find that I still maintain MOST-- see
http://www.jedsoft.org/most/ for more info.
--John
Hoff Hoffman
In article <B9DCEA92.18D0%ca...@shaw.ca>, Carlos Costa <ca...@shaw.ca> writes:
:Yes, I see what they are saying now. I should add, though, that a "panic"
:has not occurred. I've gotten "panics" in the past and they output a message
:and exit the application. This has not happened. So I guess that means that
:SS$_NORMAL is always being returned, which is a good thing I guess.
You cannot generalize quite this far. You just haven't gotten caught yet
by this bug. You have clearly gotten caught by at least one other latent
bug, and the specified code path will mishandle all successful completions
other than SS$_NORMAL.
:SS$_NOMOREFILES is being returned (sometimes anyways) as I've seen it during
:my own feeble attempts to figure out what is going on.
Please start by skimming the programming concepts manual and some of the
related documentation. If you don't know the rules and some of the basic
assumptions of OpenVMS programming as yet -- and no offense is intended
here, as every experienced OpenVMS programmer once had no clue how this
stuff works and how it fits together -- you won't know a latent coding
bug even when you are looking directly at it.
For a list of some of the more common programming bugs found lurking in
various code modules, please see topic (1661) in the Ask The Wizard area.
On Wed, 23 Oct 2002 09:30:27 UTC, Paddy O'Brien
<paddy.o'br...@tg.nsw.gov.au> wrote:
:> Regardless, they are names that I know I have encountered elsewhere
:> in the VMS world and the person who said that it was poorly written
:> and should never have worked (paraphrasing) is denigrating some people
:> who, IIRC, have helped to make the VMS world a better place.
The cited chunk of C error-handling code is poorly written, and is
(IMNSHO) insufficiently defense. There is no shortage of bad code.
If we take this or other discussions of mistakes personally, we will
never learn how to avoid the problems. If we learn what defensive
error handling and proper synchronization and other such code should
look like, we will have fewer (repeat) problems with application code,
and hopefully fewer folks having troubles with upgrades.
(Thought question: how do you think that I know that the code construct
that was shown was questionable? Do you think I might have once coded
this particular construct into my own application code, and subsequently
encountered problems with the construct? :-)
Craig A. Berry
"Dan Allen" <dal...@nist.gov> wrote:
> And as Craig Berry has pointed out (see below) the problem would appear to be
> an application error in CSWING.
I want to make clear that my intention was to point aficionados of
CSWING toward a possible solution. The ratio of blame to insight in
this thread has been a bit depressing.
Dan Allen
I would like to add that I'm not trying to point fingers or blame anyone.
Just trying to help someone not familiar with VMS APIs with a coding problem.
I don't know who wrote CSWING and don't care. It's undoubtedly been tweaked
by more than one individual and as Hoff pointed out everyone including your's
truly, has written their share of weak code and hopefully most of us have learned
from our errors. I'll try to follow up with Grant at Western Michigan with
regard to his patches and Craig's observations. Quite frankly, without having
read the relevant I/O User's Guide sections and having seen only the posted code
snippets from Craig and Carlos, I'm surprised that get_dirs() ever worked! That
alone piques my interest.
Dan
> -----Original Message-----
> From: Craig A. Berry [mailto:craig...@nospam.telocity.com]
> Sent: Monday, October 28, 2002 11:10 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: OpenVMS 7.3-1 and CSWING
>
>
John E. Malmberg
> Just for the heck of it, I updated the copy of the cSWING sources I
> found so it compiles without errors.
What settings did you use for the Compaq C Compiler?
> I think I got past the few cases
> of routines with inconsistent numbers of arguments, several cases of
> referencing non-existent structure members, and a library function which
> doesn't exist in the C headers (lib$erase_page). I also cleaned up all
> the IOSBs, corrected some longs which should have been shorts (channels,
> and lengths) and a few improperly initialized descriptors, but, there
> were a few coding errors I don't have time to pursue, including two
> global routines named "rest_cursor" and an attempt to assign a pointer
> to an integer.
I have slowly been doing the same.
> However, I don't have the time or ambition to do the kind of rewrite
> which is indicated by Craig Berry's observation.
>
> If anyone would like to either take on that job starting with a
> compilable copy of the source, or just try the compilable version to
> see whether it works any better than the old executable, you can mail
> be and I'll ship you the zip with the original and my changes.
There seem to be enough latent bugs in the code that it probably will
take a long time and multiple eyes to shake out all but the most
apparent ones.
Can someone who has a working version let me know if the help function
works correctly? It appears to be using the length of an array of char
as the address to return the amount of characters entered in to the
prompt. The program it self does not seem to use the data, and since I
do not have a link map of the original, I have no idea what memory cell
is being corrupted.
There are also two arrays that look like they are supposed to be NULL
terminated, but instead are apparently being initialized to the ascii
characters '/' '0'.
There is also a case where "==" is apparently being used for an
assignment of a return value.
At the rate I am going over my lunch time, It will probably take a while
before I get all the modules compiled.
gr...@rigel.cc.wmich.edu
> gr...@rigel.cc.wmich.edu wrote:
>> Just for the heck of it, I updated the copy of the cSWING sources I
>> found so it compiles without errors.
>
> What settings did you use for the Compaq C Compiler?
/OPT/NODEBUG
Otherwise, defaults.
Carlos Costa
excellent tidbits of information and suggestions. I have learned a lot in
the last month. I have gotten CSWING working now under VMS 7.3-1. Craig
Berry hit the nail right on the head with his observation that CSWING does
not maintain the search context because it zeros the file_length parameter
and sets the filename to null before each QIOW call. Moving the setting of
these variables outside the "while(1)" loop maintains the search context and
all is well:
ORIGINAL CODE (from get_dirs() in SWING.C):
while(1)
{
static char dir_template[20];
strcpy(dir_template, "*.dir;*");
filename[0] = 0;
file_length = 0;
uchar = 0;
status = sys$qiow(0,
channel,
IO$_ACCESS,
&iosb[0],
0,
0,
&fib_desc,
DSC1(dir_template),
&file_length,
DSCA1(filename),
acb,
0);
WORKING CODE:
filename[0] = 0;
file_length = 0;
while(1)
{
static char dir_template[20];
strcpy(dir_template, "*.dir;*");
uchar = 0;
status = sys$qiow(0,
channel,
IO$_ACCESS,
&iosb[0],
0,
0,
&fib_desc,
DSC1(dir_template),
&file_length,
DSCA1(filename),
acb,
0);
He, and others, are also correct that CSWING could use some major
overhauling. It seems that noone is maintaining the code anymore which is
too bad, but if those people that have gotten a version compiled could make
it available (I know at least one person, Grant, has done that) it would be
a start.
As well, Dan Allen's comments:
>
> See Craig Berry's post on the misuse of the context value and name string
> in the FIB in the CSWING source code. Most likely the problem. Note also
> that this is what I would call a latent application bug, i.e. it is not
> providing the proper input to the QIO call. The fact that it worked by
> chance in 7.3 but fails in 7.3-1 is not what I would call a bug in the
> OS and I doubt VMS engineering would be motivated to restore the old
> behavior.
proved to be right on the money also.
I looked through he release notes again, though, and was not able to find
any indication that this area of the VMS code had been worked on and fixed.
I can appreciate that they can't put *every* change that was made in the
release notes, but maybe HP/Compaq could rethink their assertion that 7.3-1
is "binary compatible" and "needs no testing", as several people have
already mentioned.
Again, thanks to everyone.
Carlos
On 10/26/02 7:56 AM, in article
7f15589f.02102...@posting.google.com, "Craig A. Berry"
Everhart
> The status checking in this code snippet is not correct:
>
> 1) The QIO status should check not for SS$_NORMAL but any error value
> any other error conditions. This is probably the cause of the
> your problem.
>
> error checking is simply poor coding which manifests itself when the OS
> or run-time environment generates a new/unexpected error status.
>
> Dan
>
> "Mark Buda" <bu...@tabasco.zko.dec.no.spam.com> wrote in message
> news:<N0gt9.22$oF.2...@news.cpqcorp.net>...
>
>>"Carlos Costa" <carlos...@datawest.ca> wrote in message
>>news:7edc7395.02102...@posting.google.com...
>>
>>
>>>This problem is also disconcerting because 7.3-1 has, in HP/Compaq's
>>>own words, "100% binary compatibility with previous versions".
>>
>>data structures?
>>
>>mark
>
>
> Unfortunately, although I know C, I have not programmed much under VMS
> to be able to answer you fully. But, maybe if I explain what I have
> found, more knowledgable people may see something. I have tried to
> debug the code, and have found that the problem is in a function
> called "get_dirs()" in the file SWING.C. This function is recursively
> called to scan through a directory tree.
>
> What happens is that when the scan hits the last leaf, it loops,
> always returning that directory name. For example, if I have the
> following structure:
>
> [COSTA} --- BIN --- TOOLS
> |
> --- COM --- UTIL
>
> then get_dirs() will get COSTA, BIN, TOOLS, then TOOLS, TOOLS, TOOLS,
> .. forever. it never goes back up the tree.
>
> The actual call to VMS to read the directory is:
>
> status = sys$qiow(0,
> channel,
> IO$_ACCESS,
> &iosb[0],
> 0,
> 0,
> &fib_desc,
> DSC1(dir_template),
> &file_length,
> DSCA1(filename),
> acb,
> 0);
>
> panic(status,"io$_access directory lookup","get dirs");
> if (iosb[0] == SS$_NOMOREFILES){
> return(TRUE);
> }
>
> Carlos
>
I am looking over a heavily cleaned up cswing. The error codes tested for
are the only ones that show up here. Incomplete testing is not causing the
problem. Hopefully I can get a simple enough pair of cases to see exactly
what is going on different. The cswing linked in 7.3-1 also functions
in 7.3, but does not in 7.3-1 by the way. The behavior in get_dirs is
as described far as I can see but this is impractical to analyze save in
a small directory tree. The increment of the wcc field does occur, but it
is not sufficient to remove it; the scan never gets passed any nosuchfile
case.
If someone thought that an inappropriately initialized descriptor was causing
this I should be very happy to see any details. The loop that gets into
trouble is in swing.c and there are no such constructs in that file, and
execution seems never to exit from there. Mind I have only looked briefly though.
Glenn Everhart
Everhart
>>> channel,
>>> IO$_ACCESS,
>>> &iosb[0],
>>> 0,
>>> 0,
>>> &fib_desc,
>>> DSC1(dir_template),
>>> &file_length,
>>> DSCA1(filename),
>>> acb,
>>> 0);
>>>
>>> if (status != SS$_NORMAL)
>>> panic(status,"io$_access directory lookup","get dirs");
>>> if (iosb[0] == SS$_NOMOREFILES){
>>> }
>>>
>>>"DAniel Allen" <dal...@nist.gov> wrote in message
>>>news:<BCEGLBGJDODLELBJI...@nist.gov>...
>>>
>>>>The status checking in this code snippet is not correct:
>>>>
>>>>1) The QIO status should check not for SS$_NORMAL but any error value
>>>>
>>>
>>>checks for not-equal-to SS$_NORMAL. Wouldn't that be the same as
>>>checking for any error value? In other words, if the statis is NOT
>>>NORMAL then an error occurs. If there was an error then SS$_NORMAL
>>>would not return, would it?
>>
>>
>>than SS$_NORMAL.
>>
>>Arne
>>
>
>
> Yes, I see what they are saying now. I should add, though, that a "panic"
> has not occurred. I've gotten "panics" in the past and they output a message
> and exit the application. This has not happened. So I guess that means that
> SS$_NORMAL is always being returned, which is a good thing I guess.
>
> running for a long time, but the error that occurs is an out of memory
> error, caused I figured because the endless recursive calling of get_dirs()
> eventually exausted the allocated memory of the process.
>
> SS$_NOMOREFILES is being returned (sometimes anyways) as I've seen it during
> my own feeble attempts to figure out what is going on.
>
>
The revised code I got tests for the 1 bit set or not, tests immediate and
iosb tests.
Only observed return iosb statuses are normal, nosuchfile, nomorefiles.
Nothing else.
I am working on getting a simple test dir tree so I can track the pattern of returns
from io$_access, comparing 7.3 with vioc and 7.3-1 with xfc.
The autoinc of the wildcard context might be involved, though every time it
gets bumped it started at zero to my observation...it is most peculiar.
Earl Lakia
To those who have fixed it, could you post
an executable version for Alpha?
Anyone want to mail me their executable? (zipped so I can
get it to VMS from VMS).
Thanks for the work you've all done.
-earl
Joseph Huber
> I like cswing and would like to use it again.
> To those who have fixed it, could you post
> an executable version for Alpha?
> Anyone want to mail me their executable? (zipped so I can
> get it to VMS from VMS).
Poor guy without a C compiler !
I have an executable with the small correction applied for the filename
string reset problem, otherwise unchanged version 3.7.5 from H.Flowers 1994.
See http://wwwvms/pub/vmssig/flowers/ :
[4]CSWING.EXE, 359 Kb, Wed Nov 13 10:15:49 2002
[5]CSWING.NOTE, 7 Kb, Mon Nov 4 10:11:30 2002
[6]CSWING.README, 3 Kb, Tue Nov 23 13:34:30 1993
[7]CSWING_ANN.TXT, 5 Kb, Fri Apr 2 08:47:30 1993
[8]CSWING_V375_SRCDOC.ZIP, 385 Kb, Tue Nov 22 13:33:30 1994
CSWING.exe built on AXP VMS 7.3, Compaq C V6.4-008
--
Joseph "Sepp" Huber, Max-Planck-Institut Physik,Muenchen,
http://wwwvms.mppmu.mpg.de/~huber