Ray, good point.
Regardless of the OS, the problem ultimately lies in the code. Sure,
the OS may indeed alter the way code executes, but usually it is because
of poor coding or trying to code using various shortcuts.
The fact is, the OS changed not the compiler. If the program no longer
works under the new OS, the program took advantage of some part of the
older OS which the new OS has further stabilized.
This is a case where I would believe in the OS first and the program
second since this is MPE, and we all know that MPE is the greatest with
very few flaws. And if by rare chance the OS is at fault, it will
necessitate a work around in the program unless HP is willing to make
the fix.
Just my 2 cent worth.
Regards, Olav
Ray Shahan wrote:
>Just to add this thought: all of the resolutions/tests suggested thus
>far, while certainly worth trying, should not be required. There is no
>reason that I'm aware of why a linkage section that's been working for
>years screws up because you've upgraded the OS version (if there is a
>reason, then it should be documented in the OS release notes). I'd try
>to go back to the previous OS version to see if that corrects the issue,
>and if it does, I'd get hp on the phone.
>
>The array bounds violation, COMP fields, etc. would have presented
>themselves as a problem long ago if, in fact, theses data constructs
>were in error.
>
>One suggestion might need to read through the install notes from hp to
>see if they make any mention of issues related to COBOL linkage sections
>for your OS upgrade.
>
>That your problem goes away with a recompile suggests that some form of
>data alignment is being done under your new OS version that was not done
>under previous OS versions. The install notes for your OS version may
>show you how to set a run switch (or other parm) that allows existing
>programs to run using an older data alignment scheme?
>
>
>HTH,
>
>
>
>Raymond Shahan
>Information Systems
> REPUBLIC TITLE OF TEXAS, INC.
> 2701 W Plano Parkway
>Plano, TX 75075
>
>
>direct 214.556.0202
>main 972.578.8611
>fax 972.424.5621
> www.republictitle.com
>[log in to unmask]
>Life is not a journey to the grave with the
>intention of arriving safely in a pretty and
>well preserved body, but rather to skid in
>broadside, thoroughly used up, totally worn out,
>and loudly proclaiming:
>-- WOW!!! What a Ride!!!
>
>-----Original Message-----
>From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
>Behalf Of okappert
>Sent: Tuesday, May 08, 2007 10:44 AM
>To: [log in to unmask]
>Subject: Re: [HP3000-L] Subroutine Returns Parameters Displaced
>
>Edward:
>
>The last question first, I am responding to both you and posting this on
>
>the forum.
>
>Next, does the programs use arrays. Sometimes when defining and array,
>it is possible to go beyond the last index. In fact, you can go way
>past the end. All the way to the end of the working storage section.
>
>Thus, check for this possibility through debugging methods and look at
>the bounds option on the control line.
>
>Regards, Olav.
>
>Walsh, Edward wrote:
>
>
>
>>Olav,
>>
>>Yes, I have been displaying the output on my terminal (actually a PC
>>with reflection) and on a printer. And I have considered that what I
>>am seeing may be thrown off by unprintable characters.
>>
>>And while that may be going on, I do not think it can totally explain
>>what is happening.
>>
>>First, I have run the test with "display functions" on in Reflection,
>>and I did not see any strange characters embedded.
>>
>>Secondly, I have experienced another form of the problem on input.
>>One of the parameters passed is an Image data base ID. The called
>>program checks this to see if the data base is already open, by
>>checking the first two characters. If not, it opens the DB itself.
>>Well, in this test, the calling program moved spaces to the data base
>>field, but the subroutine returned an error (displaced in the
>>parameters) which said, "BAD DATA BASE REFERENCE (FIRST 2
>>
>>
>CHARACTERS)".
>
>
>>
>>This tells me that the parameters are being corrupted during input to
>>the subroutine, not just on the return.
>>
>>So this is yet another indication that this is not an artifact of the
>>printer.
>>
>>Thirdly, what I first thought I was going to find was some funny
>>garbage in the data used by the subroutine that was somehow causing
>>this problem. However, I can pass the subroutine all default values,
>>and I still see this problem. Or I can pass different parameter data
>>values. The problem keeps happening.
>>
>>Lastly, I am not at the moment a member of this forum. A colleague
>>suggested I post this question here. These further clarifications
>>that your questions have elicited may be helpful to other forum
>>members thinking about this problem. So, could you post my replies to
>>
>>
>
>
>
>>your question, or tell me how to do it myself?
>>
>>Thanks for your help.
>>
>>Ed Walsh
>>Preferred Care -- Systems Analyst II
>>259 Monroe Ave.
>>Rochester, NY 14607
>>585.327.2489
>>
>>
>>
>>
>>
>>
>------------------------------------------------------------------------
>
>
>>From: okappert [mailto:[log in to unmask]]
>>Sent: Tuesday, May 08, 2007 11:05 AM
>>To: Walsh, Edward; HP3000-ListForum
>>Subject: Re: Subroutine Returns Parameters Displaced
>>
>>Edward:
>>
>>Are you checking this by printing the data ?
>>
>>If you are, maybe the problem is that NULL's are embedded in the data.
>>
>>Regards, Olav.
>>
>>Walsh, Edward wrote:
>>
>>
>>
>>>Olav, thanks for your reply.
>>>
>>>First, there is no COMP data being passed. Everything is defined as
>>>alphanumeric (pic X) or display numeric (pic S9). And furthermore,
>>>
>>>
>all
>
>
>>>field lengths are in even numbers of bytes.
>>>
>>>Secondly, the displacement is much more than merely over a word or
>>>
>>>
>byte
>
>
>>>boundary. Some of the data appears to be displaced about 9 (nine)
>>>characters.
>>>
>>>
>>>Ed Walsh
>>>Preferred Care -- Systems Analyst II
>>>259 Monroe Ave.
>>>Rochester, NY 14607
>>>585.327.2489
>>>
>>>-----Original Message-----
>>>From: okappert [mailto:[log in to unmask]]
>>>Sent: Tuesday, May 08, 2007 10:53 AM
>>>To: Walsh, Edward
>>>Cc: [log in to unmask]
>>>Subject: Re: Subroutine Returns Parameters Displaced
>>>
>>>Edward:
>>>
>>>One of the most common problems in the linkage section is when data is
>>>stored as COMP. If COMP does not have the additional option of being
>>>SYNC you can get conditions where data is split. Try making all
>>>
>>>
>COMP's
>
>
>>>a COMP SYNC.
>>>
>>>Generally, there is no harm in doing so unless the program was written
>>>poorly or if needed for reasons of a very tight data storage
>>>requirements.
>>>
>>>Olav Kappert.
>>>IOMIT International
>>>www.IOMIT.UnitedStates.com
>>>
>>>Walsh, Edward wrote:
>>>
>>>
>>>
>>>
>>>
>>>>This is an XL-resident subroutine written in Cobol which has been
>>>>running without change for years. Suddenly, after upgrading the HP
>>>>3000 to C.75.00, when the subroutine returns to its caller, its
>>>>
>>>>
>output
>
>
>>>>parameters are displaced.
>>>>
>>>>With appropriate input parameters, the subroutine runs successfully
>>>>
>>>>
>and
>
>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>tries to return good data. However, because the parameters are
>>>>displaced in the linkage buffer, they look like garbage to the
>>>>
>>>>
>caller.
>
>
>>>>Recompiling the program makes the problem go away, but I am concerned
>>>>
>>>>
>
>
>
>>>>for all other subroutines, both programs written at this site and
>>>>vendor-supplied software, that might be affected by this error.
>>>>
>>>>If you have any insight into this problem, please reply to me here at
>>>>
>>>>
>
>
>
>>>>[log in to unmask]
>>>>
>>>>Thank you for your help.
>>>>
>>>>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 *
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>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.
>
>
>>>
>>>
>>>
>>>
>>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 *
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
>
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
