Solved

RPG display file stops compiling

Posted on 2014-02-19
15
701 Views
Last Modified: 2014-02-24
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.
0
Comment
Question by:--TripWire--
  • 6
  • 5
  • 4
15 Comments
 
LVL 27

Expert Comment

by:tliotta
ID: 39872565
...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
0
 
LVL 34

Assisted Solution

by:Gary Patterson
Gary Patterson earned 375 total points
ID: 39873566
This isn't really a compile error.  Before you can compile a file, the tool you are using or the CRTDSPF command must delete the current version of the file to make room for the new object.

It can't do that if the current display file is currently in use.

When a user runs a program that contains a display file (or any file object, for that matter), the file is locked (usually a shared lock, but any lock will prevent another process from deleting the file) until the display file is closed or the program ends.  

Different rules apply to program objects - no lock is actually held on *PGM objects - so you can replace a *PGM that is in use, but not a *FILE.

Maybe you are the culprit - are you running a program that uses the display file in a different session?  As Tom indicates above, maybe a program that locks this display file is still activated (ended without *INLR, for example), but not actively running - it will still hold a lock on the DSPF if the DSPF hasn't been closed by the program before it issued a RETURN.

Anyway, before compiling a *FILE object, you need to make sure no other job is locking it.  Use the WRKOBJLCK command to see if you or anyone else has a lock on the display file before you recompile, and if they do, work with the user(s) holding locks (or log off your jobs or take steps to release locks held by your jobs) in order to get exclusive access to the display file for a moment before compiling.

Object locks when compiling files of any kind is a common issue.  

You didn't mention if this is a development/test version of the object, or the production object.  If it is dev/test, then you are probably the culprit yourself - maybe you are locking the object yourself.  If it is a production object, then this is really a change management issue.

I don't know how you handle change management in your shop, but it is a pretty common practice to designate a daily/weekly/monthly "quiet period" when users are off the system, and replace production objects only during those periods.  A good time is immediately before or after backups - especially if you take the interactive subsystems down during backups.

Tom also make a good point - why recompile your display file if you haven't made any changes to it?

- Gary Patterson
0
 

Author Comment

by:--TripWire--
ID: 39873578
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.
0
 

Author Comment

by:--TripWire--
ID: 39873639
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?
0
 
LVL 34

Assisted Solution

by:Gary Patterson
Gary Patterson earned 375 total points
ID: 39874057
Without access to your system, I can't tell you what is locking the file.  But, based on the message, it looks like some job is locking the file.

You use WRKOBJLCK to troubleshoot object locks.  A display file is just one kind of *FILE object.  SO the next time you get this error, log onto a green-screen session and do this:

WRKOBJLCK OBJ(yourDisplayFileNameGoesHere) OBJTYPE(*FILE)

It will show you the name of every job that is holding a lock on your display file - that usually provides a pretty strong clue.
0
 

Author Comment

by:--TripWire--
ID: 39874943
When I ran that command, I got back this message...
(There are no locks for the specified object)
0
 
LVL 27

Assisted Solution

by:tliotta
tliotta earned 125 total points
ID: 39875654
To get the command string for option 14=Compile, you type the option "14" and press the F4 key instead of <Enter>. The CRTDSPF command should be prompted if you do that. When a command is prompted, you can press F14 to see the actual command string.

It's possible that defaults for the command are set differently for your site, or your PDM settings might have specific values. But it's likely that the file simply isn't released at the time the compile runs.

When recompiling *PGM objects, PDM can move the current *PGM to QRPLOBJ so that current execution by users can continue even as the new object is being placed in the original location. The new *PGM object will be used for any user who makes a fresh call to the *PGM. Any job that uses the old pointer will get the version from QRPLOBJ.

But files can't be expected to work the same since they are likely to cause level-checks and for other reasons (e.g., data in externally-described database files). A *FILE object is locked when opened, and the MOVOBJ command can't move it to QRPLOBJ until the locks are released. Note that *PGM objects are not locked when they are running.

After you run WRKOBJLCK and find no locks, does the compile succeed? You might not be able to run WRKOBJLCK effectively after a compile fails. Locks might be gone by then. Technically, WRKOBJLCK should run at the same time the compile step is trying to place the new object into the library. It's only at that part of the compile step that locks are an issue.

Catching the lock in progress can be tricky.

Tom
0
Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

 
LVL 34

Accepted Solution

by:
Gary Patterson earned 375 total points
ID: 39876893
If the display file is locked at the moment you try to replace it, the command will fail with the "Unable to allocate" error.  If it isn't locked, the recompile will succeed.

If this is a test system, and no other user could be using the file, then you are probably locking it yourself - probably by running a program that RETURNS without closing the file.  

Another possibility is that you were running the program in a session that was disconnected (shut down the emulator without logging out first), and that session was still holding a lock on the display file.

It is also possible that your system uses a feature called "group jobs" to allow programs to be suspended and run in the background while the user does a different task.  If the program that uses the display file is suspended like this, it can hold a lock on the DSPF.

But, if there is a lock being held, WRKOBJLCK will show it.

To prove it:

1) Open two green-screen sessions.
2) In session 1, run the program that uses this display file.
3) Switch to your second session, and run the WRKOBJLCK command.

A couple of things to keep in mind when using WRKOBJLCK:

You may have multiple copies of this display file in different libraries in your system.  If you are replacing the one in library "FRED", then make sure you specify that library name on the WRKOBJLCK command.  Otherwise, the system will search the library list (soft of like the PATH in Windows), and could pick up a different copy of the display file.

WRKOBJLCK OBJ(FRED/yourDisplayFileNameGoesHere) OBJTYPE(*FILE)

If you use the 14<F4> prompt technique that Tom described when compiling, you should see which library you are compiling into - it will usually be the same library as the source file (probably QDDSSRC) that you are compiling from.

Anyway, if there is no lock on the display file, then you won't get the "Unable to allocate" error.  If there is, switch to a different session, and use the WRKOBJLCK command to see what job is locking the file, and end that job.  Once that job has ended, you should be able to recompile the file.  You have to be careful about ending jobs on a production system, but in test it is less likely to cause problems.

- Gary Patterson
0
 
LVL 27

Expert Comment

by:tliotta
ID: 39878582
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
0
 

Author Comment

by:--TripWire--
ID: 39884114
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.
0
 

Author Closing Comment

by:--TripWire--
ID: 39884117
The problem was resolved on its own.  Perhaps some kind of system refresh.
0
 
LVL 27

Expert Comment

by:tliotta
ID: 39884466
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
0
 

Author Comment

by:--TripWire--
ID: 39884502
I know.  It isn't satisfying.
Have you found this environment to be as unstable on some level?
0
 
LVL 27

Expert Comment

by:tliotta
ID: 39884554
Practically zero instability. Some unpredictability before learning underlying concepts.

Tom
0
 
LVL 34

Expert Comment

by:Gary Patterson
ID: 39884569
It is extremely unlikely this is the result of environment stability.  Odds are you were doing something that was locking the file.
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Even if you have implemented a Mobile Device Management solution company wide, it is a good idea to make sure you are taking into account all of the major risks to your electronic protected health information (ePHI).
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
An introduction to basic programming syntax in Java by creating a simple program. Viewers can follow the tutorial as they create their first class in Java. Definitions and explanations about each element are given to help prepare viewers for future …
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

24 Experts available now in Live!

Get 1:1 Help Now