I agree with Ray. However, I don't remember anything about a switch which could affect runtime parameter alignment. Given that my memory doesn't always perform as well as I'd like, it doesn't really prove anything. :-(
Since recompiling seems to fix the problem, it would appear either the subroutine or the main program has been recompiled since the upgrade. Recompiling the other makes them match again.
Can you tell if the COBCNTL.PUB.SYS file was changed? Did you customize it?
Are you using custom compile options ($CONTROL)? Sync16/Sync32, Index16/Index32, Linkaligned comes to mind.
Are you using the standard COB85XL command files?
HTH,
François
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of Ray Shahan
Sent: Tuesday, May 08, 2007 12:00 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Subroutine Returns Parameters Displaced
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 *
|
