HP3000-L Archives

May 2007, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Walsh, Edward" <[log in to unmask]>
Reply To:
Walsh, Edward
Date:
Fri, 11 May 2007 14:04:33 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
Members of this forum have been so responsive and quick to offer help,
and so many have requested that I tell them the status, that I am
responding now, even though the problem has not been resolved.

A very experienced lady from HP has logged on to our system and
witnessed the error with debug enabled.  In spite of this we still have
not resolved the problem.

She is the first person I have met who has had contact with the HP 3000
longer than I have.  I started in 1980, she in 1976.  But I have not
been continuously working in the HP 3000 world.

She explained to me that a major change between about 6.5 MPE (and even
earlier) and 7.5 is that earlier versions of MPE, before they handed a
new stack to a process, they initialized the stack area (I think to
spaces).  This acted to obscure coding errors where a variable was not
initialized properly.  In other words, the operating system was
initializing the variables in the stack.  There were a number of changes
during this evolution, and by the time of 7.5, the OS was no longer
pre-initializing stack.  This change in behavior may have been made in
the name of POSIX compliance.

This change to the OS caught many sites.  Programs that had run
correctly for years suddenly started malfunctioning.  All kinds of big
name customers, including HP themselves, were caught with software they
had written that started failing for this reason.

There were other major changes she mentioned, principally that a wider
set of registers is used in 7.5 than in, say, 6.5 and earlier.  However,
from my point of view, this must be transparent to a Cobol program.  The
programmer in Cobol can not in any way have any influence over what
registers are being used.  However, for the problem that I am facing,
this may have something to do with the fact that recompiling the program
suppresses the error.

The HP technician and I have both looked at the program searching for
variables that were not properly initialized, and neither of us have
found any.

But beyond this, I am unable to correlate the behavior I have observed:
namely data displaced in a linkage area, with an uninitialized variable.


And in the technician's debug listing, it is apparent that the flow of
control visited another subroutine (which only returns the program's
compile time stamp and version).  I have looked at the code and I cannot
see how that is happening.  And please don't ask 15 questions of basic
programming technique.  Let me just say that control transfers (e.g.,
performing logic) are always handled according to good professional
coding techniques.

This peculiar problem behaves badly on our test computer, but (1) is not
showing up in any other software, and (2) is not failing on our
production computer.  And the user community on the test box are not at
the moment using that subroutine.  That being the case, my management
has directed that I spend less time on this problem and make progress on
other assignments.

So it is unresolved, and on the back burner.

Ed Walsh
Preferred Care -- Systems Analyst II
259 Monroe Ave.
Rochester, NY 14607
585.327.2489


Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information.  If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited.  If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.


* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2