IBM Mainframe Forum

What does WS-INDEX1 contain in the dump, please?

We should be just chasing our tails with this, as you have SSRANGE, which, however weird the code, should protect from using a reference modification outside the storage occupied by the field.

Have you got anywhere with the comple with the LIST?

Yes I know.. I just copy pasted. Since we're not the owner of ProgB we cannot do it.

I couldn't see anything in the dump related to WS-INDEX1. Might be because I see this message


I could view the listing only in endevor. Is there any specific information that I need to look on for it? Sorry if I'm missing something.

OK, I suppose DumpMaster not being able to locate it is another indication of overwriting.

Try to get the compile listing I asked for. I'm going to go back through what you've said so far and see if I can sort out some anomalies.

The code with the reference modification is not very good. Are you saying you can't do anything to ProgB even just for testing? Did "they" put the display in, and why?

You mean the compile listing with the Pseudo assembler that you mentioned earlier. I will check it.

For testing, we can do the modifications to ProgB for fixing this issue. Which display you're referring to?

brb.

There is a display as the first statement in ProgB, according to something you said earlier. Those sort of things are often put in when "something" is wrong but no-one has an idea of what. I was wondering how it got there in this instance.

Can you give some background? Is ProgB already in production? Is your change just involving use of ProgB or is it coordinated with changes made by "them", that sort of thing. What I want to know is, is there some program which was previously working and now isn't, or is this all new, or are parts of it new?

The code for the spaces thing seems to be absolute crap. Do you know what it is supposed to be doing?

For instance, with



where b represents a space/blank, it will look at the first character, find it is a space, then move the whole field one to the left, so the first space is replaced by the second space and in a byte position which has already been looked at, so it will contain a leading space after the perform.

Then after the perform it does the overlapping move to try to, apparently, get rid of the spaces.

Even though it is crap, the SSRANGE should stop any overwriting, even if the space counter is not initialised at any point than the start of the program. If this code is causing the problem, it would imply a bug in the SSRANGE code, and you don't find compiler bugs every day of the week. Bear it in mind as a culprit, but only think of it for the actual problem if you get more evidence of it.

Both the pgms ProgA and ProgB are new. ProgA involves the use of ProgB which is interface between us and translation engine. We send the bunch of texts which we require for translation and engine will send us back the translated stuff in the same copybook via ProgB.
And yes they are trying to get rid of spaces. Let me check, the logic looks bit weird, I'll have to check with them . Thanks Billy.

You can see the "patch" that has been made to get it to work, the stuff in lowever-case in you snippet. With an even-number of spaces it will "work", with an odd-number it will loose data.

As I say, though, I don't think this is the problem. Only concern is where you say the dump points to this address.

Any joy with the listing?

Do you have a DD statement for a full dump, outside of Dump Master? Might be SYSUDUMP, but is installation dependent.

Something has overwritten the very start of your program with spaces. This must have been something when the program was called the second time, so the next call failed.