Yes, you right, but you should also remember, that your file can also be in another property, like `Content`. 

I think that you want to set some limit, for file which is available to upload to server. And in this case, this file will be uploaded at the server any way. And I would recommend to use FileAPI on client side, and you can check file size before loading it to the server.

What do you mean ?

To get this task running every hour every day, you should use Daily, and set every 60 minutes or 1 hours, and set a limit for this task in days time, like working only in business hours. And you can also use Weekly and Monthly schedule, with working every hours. It means that you can set task to work only in working days at business hours every hour.

And OnDemand tasks, will run only by manual, and will be run only once after start.

In a development process, you can use any latest version of Caché, and export all code to source control system, in version which you use in production. It is not so difficult as may looks. Except only if you use so old system, like 2010.1 or earlier, because export qualificator /cacheversion supports version 2010.2 and later. In this case, you should have some building process, which will be at right version, which you need. I've used this way for years, and for our client we built two versions 2010.2 and 2012.2 from the same repository. You just should not use some new features, or use macroconditions by version, except JSON, you can't use anyway if lowest version doesn't support it yet.

I haven't used SSD in production yet. I'm sure there lots of people who can say more about it. But anyway as I know, all modern SSD, and even which is special for servers, now has a very big count of rewrites. So, it means, that in most cases now you should care about it at all. And fragmentation could be a problem only when you have so many empty blocks, which should be cached, but you don't have some many RAM for it. 

So let's suggest you have some object with such properties (Legs=4, Fur=True, Tail=True, Attitude=100). In a global it will looks something like this

^MyPets("Cat")=$lb(4,1,1,100)

And in this case, we should have any pointer block in anyway, and while we don't have so many data in our global, yet. Type for pointer block will be 70

Block Repair Function (Current Block 3): 44
Block # 44               Type: 70 TOP/BOTTOM POINTER
Link Block: 0            Offset: 40
Count of Nodes: 1        Collate: 5
 
--more--
 
#    Node                    POINTER
1    ^MyPets                 78

But we also have not so big value for our object, and data block can store subscripts in this block, as well as a value.

Block Repair Function (Current Block 44): 78
Block # 78               Type: 8 DATA
Link Block: 0            Offset: 60
Count of Nodes: 2        Collate: 5             Big String Nodes: 0
Pointer Length:6         Next Pointer Length:0   Diff Byte:Hex 0
Pointer Reference:      ^MyPets
Next Pointer Reference:
Next pointer stored? No
 
 
--more--
 
#    Node                    Data
1    ^MyPets
2    ^MyPets("Cat")          $lb(4,1,1,100)

Or our global could be looks a bit different

^MyPets("Cat","Attitude")=100
^MyPets("Cat","Fur")=1
^MyPets("Cat","Legs")=4
^MyPets("Cat","Tail")=1

But change nothing.

Block Repair Function (Current Block 44): 78
Block # 78               Type: 8 DATA
Link Block: 0            Offset: 108
Count of Nodes: 5        Collate: 5             Big String Nodes: 0
Pointer Length:6         Next Pointer Length:0   Diff Byte:Hex 0
Pointer Reference:      ^MyPets
Next Pointer Reference:
Next pointer stored? No
 
 
--more--
 
#    Node                    Data
1    ^MyPets
2    ^MyPets("Cat","Attitude") 100 *
3    ^MyPets("Cat","Fur")    1 *
4    ^MyPets("Cat","Legs")   4 *
5    ^MyPets("Cat","Tail")   1 *

So, we can see that yes, our subscripts now stores only in data block, yes it is, but they represent here as a nodes, and could be named as branches in a tree, we still have to store data in a data block, but we also need to store information about global, that's why we can see it here. And when will get more data than could be stored in one block, this block will be splitted, and in a parent block will see two nodes, for first nodes in a children blocks.

Thanks for sharing this. But some comments about code.

  • postconditionals is a very good part of our language, but here is too much, and quite difficult to read such code. In this case much better will be simple if else
  • return in try block is a bad idea, you should throw an error, which will be caught anyway
  • we can do new $namespace, but in your code, this method returns to wrong namespace, look at my previous point
  • instead of $replace(database,"/","\"), use ##class(%File).NormalizeDirectory(database), in this case you should not check on OS, even you forgot some of OS's, and in this case NormalizeDirectory/NormalizeFilename, a bit better.
  • verbose mode will be better to do with a macros, something like $$$DebugInfo("some message")
  • In your code I see so many checks on errors, and looks like, after such error we should exit, but you go further. You should look at some system macroses like $$$ThrowOnError() and so on, I think you should use it. And code will much more clear for readers
  • and at the end you have some call to method checkRW, I think you should remove it, or show this method, because it's not clear what it does

And, before publishing, please change tabs to spaces, because tabs here is too big. And width of lines should be a bit less, because read such long lines a bit difficult. 

I fixed tabs here, for more readability.