× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Tommy,

The failing point was due to the GetOSInfo() procedure in the service
program.  I restructed the procedure to return a varying field (in this
case the BasicInfo DS)

It's because you're writing blanks into 31434 bytes of memory that don't belong to you. As luck would have it, you seem to be accidentally hitting the area of memory where the system stores the indicator that keeps track of whether a file is open.

Who knows what else you're corrupting!

Here's where you're calling GetOsInfo():

         // Get OS/400 Information From The User's Profile

          GetOSInfo( BasicInfo
                   : %Size(BasicInfo)
                   : 'USRI0300'
                   : Kr_SxUser
                   : Successful);

The first parameter is BasicInfo, which is defined as a data structure that's 1333 bytes long. Here's the PI for the GetOsInfo proc:

     pGetOSInfo        B                   Export
     d GetOSInfo       PI
     d  ReturnData                32767a   Options(*VarSize)
     d  ReturnLength                 10i 0 Const
     d  Format                        8a   Const
     d  UserProfile                  10a   Const
     d  Successful                     n

Note that in this place, you've defined the first parameter as 32767 bytes long. Later in this procedure, you do the following:

         ReturnData = BasicInfo;

OOps... now you've made a mess of things. This statement doesn't just set the first 1333 bytes of ReturnData! It sets the first 1333 bytes to match what's in the BasicInfo data structure, and sets the other 31434 bytes to blanks.

Unfortunately, ReturnData doesn't have any memory declared for it. It's using the memory of the BasicInfo data structure from the calling module! And that's only 1333 bytes long.

That's, ostensibly, why you're passing the ReturnLength parameter. So that you know how much space the caller has allocated to the ReturnData parameter -- but you're not using ReturnLength anywhere!

The fix should be to change that statement to read as follows:

         %subst(ReturnData:1:ReturnLength) = BasicInfo;

That will prevent it from corrupting memory. Assuming you're not doing the same thing somewhere else, your problem should be solved.

Please remember to be very, very, very careful whenever you use OPTIONS(*VARSIZE).

program KR0057EX & it works fine now.  Should this be reported to IBM???
What's your opinion??

No, this is clearly a bug in your code, not IBM's.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.