The program has been running for several years and this command started failing. The program tests records in QADSPOBJD for last change date. We are not interested in physical or logical file types. The command is: IF ODOBAT <> 'PF'
Lately, 'PF38' objects have been flagged.
I've spoken to programmers on staff (most of us with 20+ years of experience) and we all believe the compare should result in a false for PF38. That is, the compare should only look at the two characters presented, left to right.

I ran the program in debug, changed the ODOBAT value to PF38 prior to the command and sure enough, the result was true. What are we missing?

Gail,

If the program has been running fine for years and suddenly changes behavior, either you're running a different version from what you thought you were (unlikely since you debugged it), or the operating system has changed.

Has there been a PTF applied between the time it worked and the time it failed?

Bill

Ops just verified that no PTS were applied.
The PF38 objects are all user-created. They belong with legacy processes. Interestingly, the problem indicated that files the owner thought were "inactive", were in fact active.

I actually thought the change dates may have been activated by OPs preparations for an OS upgrade. We are at V5R2 now and will soon upgrade.

Usually part of an upgrade is to run a program that scans all of the objects on the system looking for objects that will not convert correctly. I would have thought that program objects would be the only ones checked, but I guess it must look at files as well. This is likely your answer as to why they seem active.

By "active" do you mean the last used date has been reset to a recent date?

Bill

That is an interesting possibility. I did notice the two times this appeared was about the same time of day; about 4:20pm. That is just before the OPs manager leaves for the day. I had been suspicious of a scheduled process, but the first time was a Friday and the second on Tuesday; eleven days apart. I'll check on the scan process and see if that bubbles any information to the top.

It is definitely change date - ODLDAT. It doesn't seem that a scan would update the change date. Last used date is changed (ODUDAT, but our backup process seems to change that too. I do't know why since there is a save date field.

Not in my memory. As far as I can recall, when you compare a field to a shorter literal, it will pad the literal to the right with blanks and do a compare. I don't have a V5R2 machine to check, but I know that this is the behavior for V5R3 and above, and this isn't the sort of language change that IBM would make lightly.

Since this is the behavior I see in the debug, I must agree. Without getting my hands on the function manual for the test, I can't otherwise prove it to myself.

I am planning to watch the objects for the next change date change and review the journals for the source of the change. It seems the objects are being changed by something after being inactive for a very long time. I'll update the thread if I get a different answer.

I am missing something here.

If ODOBAT = 'PF38', then the condition

Code:

IF ODOBAT <> 'PF'

should be true, because ODOBAT isn't equal to 'PF'.

Why is everyone thinking it should be false?


If you really want to look at the first two characters:

Code:

IF %subst(ODOBAT:1:2) <> 'PF'