Link to home
Start Free TrialLog in
Avatar of --TripWire--
--TripWire--

asked on

RPG display file stops compiling

I have a very strange problem to report.

Sometimes when I'm programming in RPG, I will have to compile my display file.
Randomly my display file started giving an error; even after I haven't made any changes to it.

The error reads: 40 - "Cannot allocate object [filename] in [username] type *FILE."
40 - " File [filename] not created in library [directory]."

If I rename the display file to something else and change in my code every place the display file was mentioned, the file works fine, and will compile a few more times.
Then the same thing happens all over again.

Is there someone who has had a similar problem?  Is it a setting on the server?
There are no active processes that I can see.
I can't really post all of my code here.  I'm just curious as to why this happens.
Avatar of Member_2_276102
Member_2_276102

...I will have to compile my display file.
Randomly my display file started giving an error; even after I haven't made any changes to it.


First, why are you recompiling when you haven't made any changes?

Second, how are you recompiling? In particular, what is the value of the command string that holds the CRTDSPF command? Please show the command string including parameter values. (You can prompt the command string on a green-screen display, then press F14 to show the full command string. Copy/paste that back here.) Is the CRTDSPF command executed by itself, or is it in some custom program (e.g., in a CMS function)?

Third, what activation group is your RPG program running in? Has the activation group been reclaimed before the recompile? It might need to be, depending on how the recompile is done and other factors. Does the error still occur if any job that is testing the display file is ended before the recompile is done?

The error doesn't seem to be that the display file is giving an error. Rather, the CRTDSPF command is giving the error; and that would seem to come from a combination of factors involving how jobs are using the display file, how the display file is released and how the newly compiled display file object is replacing the previous object.

Tom
SOLUTION
Avatar of Gary Patterson, CISSP
Gary Patterson, CISSP
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of --TripWire--

ASKER

tiliotta,

1)  When I made changes, it was giving me an error.  So I started compiling working copies to prove to myself that it wasn't a change that I was doing.

2) I am using the menu option 14 on the file name, I'm not actually entering the parameters myself.

3) I'm not sure how to do this, as I'm new to this environment.  Can you please tell me how to check that?

I've used the same settings/environment on previous projects, and this is the first time I've had this problem.
Gary,

I'm using a test environment.

I've used wrkusrjob and wrkactjob to make sure that nothing else was running that would interfere.

I tried wrkobjlck but I don't see an option for dspf.

I've also logged out and in several times, shouldn't this then release any such lock?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
When I ran that command, I got back this message...
(There are no locks for the specified object)
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Having a second session could allow you to have a WRKOBJLCK command already running. You can switch to that session and press F5=Refresh quickly, possibly quickly enough to see related locks for the DSPF.

But a second session could conceivably also be the source of a lock. It all depends on how any program handles its files and how a job that runs such programs works.

Tom
Thanks for all the help, but the problem seems to have resolved itself for now.
Perhaps someone on the maintenance team did something.  Who knows.
I'll still award points though. Thanks again.
The problem was resolved on its own.  Perhaps some kind of system refresh.
Glad it's working. For a developer like you, though, this kind of resolution can't be very satisfactory. You don't get to learn a cause, so you can't be sure the problem won't resurface.

Tom
I know.  It isn't satisfying.
Have you found this environment to be as unstable on some level?
Practically zero instability. Some unpredictability before learning underlying concepts.

Tom
It is extremely unlikely this is the result of environment stability.  Odds are you were doing something that was locking the file.