"You cannot create namespace-specific mappings to resources that are mapped in the %ALL namespace, as %ALL mappings override any namespace-specific mappings to the same resource." - Docs

A few thoughts: 

1. I consider <FILEFULL> or <DSKFUL> errors to be risks for data integrity -- the system is unable to write everything attempted. This is less of a risk with IRISTEMP, especially if the entire instance fails. However, if other databases are affected, you may have some physical or logical data integrity issues to resolve. 
2. Check your SQL query plans. I suspect you're generating some large temp tables if your IRISTEMP is the database that is filling up your disk. 
3. IRISTEMP is special -- it tries to keep the blocks in memory as much as possible before writing them out to the disk. If you're exhausting your disk space because IRISTEMP grew too large, then Alexander is correct: some additional global buffers could help. However, if your load exceeds your capacity, the bag will eventually burst. 
4. Setting a Maximum Size for IRISTEMP will not completely resolve the issue. However, it may make the situation more readily recoverable. If your IRISTEMP is on the same filesystem as your OS, it can be more difficult to recover without a restart. 
5. Consider setting MaxIRISTempSizeAtStart to be be able to recover more readily by automatically reducing the size of IRISTEMP

%request.Get("Top") will return the value which is stored in %request.Data("Top", 1). 

If you want to iterate through all the values, I'd use @Ashok Kumar 's solution or $ORDER on %request.Data. 

+1 for %ResultSet being deprecated. I'd suggest using %SQL.Statement instead.

For your immediate question, it's a good practice to always check status codes. 

set status = rs.Execute()
if ('status) {
    write $SYSTEM.Status.GetErrorText(status) 
}

You also might find some information in Auditing if there is a security issue. 

You should definitely avoid putting strange journal files in your local journal directory! 

As Dmitry suggested, the Journal APIs will let you read the contents of a journal file. You can also use the existing Journal Profile utility for a general sense of which globals are most active in the file.

set path = ##class(%SYS.Journal.System).GetLastFileName() //example, use any journal file
do ##class(%CSP.UI.System.OpenJournalPane).ComputeJournalProfile(path)
zw:$ZV["Cach" ^CacheTemp.JournalProfile(path)
zw:$ZV["IRIS" ^IRIS.Temp.JournalProfile(path)

Thanks for the feedback. We made sure that the product teams heard your perspective.

There is a button somewhere in the new rules editor for switching back to the old one. System wide, you can also disable the web application for the new rules editor. 

We expect that the old ZEN based rules editor will be deprecated eventually. However, there are plenty of enhancements to the new in the pipeline based on valuable feedback like this. 

Consider $System.OBJ.ExportToStream() and .LoadStream() to avoid local files with a change to the appropriate implicit namespace between.