When you run an Application Engine program from within Application Designer (as we mentioned in our blog post on Application Engine Development Tips) and turn on the checkbox for sending output to a log file, it always defaults to sending the output to c:temp.
If you don’t have a c:temp directory though, you’ll end up getting the “Out of Available Memory” error message.
This problem doesn’t occur when running Application Engine via the process scheduler because the process scheduler has already arranged the output directories appropriately (so that each process instance’s output can be tied to the instance number).
It should default the output directory to %TEMP% and just expand that at runtime, but until it does, then the best thing to is just create a c:temp directory so that you don’t have to keep changing it all the time.
Continuing on in the cool stuff we’ve been working on series, I wanted to post something about a topic that goes way, way back.
Many years ago, Dave Yoder of Rainbird asked me at a DMUG user conference about how to get variable expansion support for file name references when building a project inside Application Designer.
Without having variables that you can expand, you always have to remember to change the name of the file that will be generated each time you build records/views/indexes, etc. It’s really easy to forget and lose old copies. If you care about saving copies for yourself or for audit purposes, then it gets tiresome to always remember.
Here’s some screenshots of what we have put together to address this particular issue. The first two screenshots show the Application Designer Build Settings dialog with the build log file set to c:temp%YEAR%%MONTH%%DAY%PSBUILD_%DBNAME%.log. Here we are just changing the log file, but it works for any of the files that would get generated when doing builds in Application Designer.
The strings that are between percent signs (YEAR, MONTH, etc.) are variables that get expanded out to real values at the appropriate moment.
Here is what it looks like when you actually run the build.
As you can see, the generated log file has been created as c:temp2009126PSBUILD_PTSYS.log. Since today is January 26, 2009 and I was working in a PTSYS database, that’s exactly what we expected
There are also tokens for things like current hour, minute, second so if you like to do lots of builds in a short time frame you might want to take advantage of those as well.
In addition to things like date/time and connectivity info, there are also tokens that are supported by other Grey Sparling products.
For example, when you are using Grey Sparling Version Control for PeopleSoft you can also do things like reference which ticket number that you are currently working on. Here’s the build settings showing the log file setting as c:tempTicket-%TICKET%PSBUILD_%DBNAME%.log
After running the build (note that our version control plugin is active now; it has to be to supply the current ticket number), you’ll see that the build log file was generated as c:tempTicket-4PSBUILD_PTSYS.log. We could have included the date/time tokens as well if we had wanted to.
Now the build scripts, log files, etc. can easily be associated with the work that you are doing, and even automatically attached to the ticketing system if you want. That helps when your developers and DBAs need an audit trail of these sorts of activities. Fun to use and keeps the suits happy!
So if you run into Dave Yoder at a conference, be sure to thank him for coming up with the idea (and asking about it enough that it finally got built!)
Labels: 2009, ApplicationDesigner, Database, Products, VersionControl