Not exactly locked but in S5 the block is downloaded into spare memory (S5 needed enough space to load a block into) then during the PLC tidying up between scans of the program it changes the file allocation to the new block i.e. overwrites the FAT if you want to call it that, the old block originally in the early days was not deleted so every so often you had to do a compress which removed the old blocks, later versions automatically compressed the memory after a block download. So as S7 has a load memory I am assuming it does something similar i.e. it downloads the block into an area then at the plc tidying up period between scans does the same thing or something similar, I do not know exactly what it does but it either overwrites the original block in the work memory or places it there then changes the address of the header in the FAT table. As I said not really dug into it on S7 but I hound from my time working with siemens engineers many ways you can manipulate programs & do some really fancy things that are not generally documented, a couple of things I learnt.
How to read the header files on a disk with an S5 program i.e. a file allocation portion, find the DB, extract the Data & process it, The DB's were massive (for S5) at least 2000 words long they held alarm texts & pointers to the texts to make up alarm information to display on the WF470 graphics card, trouble was that these were entered through the WF470 system so there was no record of these alarms should you not have a copy of the data in the DB, the program I wrote in pascal extracted the data & compiled it into the alarm text & the relevan pointers & save it as a config file, it meant that if for some reason the data in the plc was changed by someone & the DB's were out of sync then we could very quickly set the texts & pointer in a second or two, I enhanced the program so I could type in the alarm texts very quickly & set the data in the DB's ready for download this saved lots of time rather than edit them on the WF470 which if you have used it, is very cumbersome for example to set up the text strings (4 per alarm) in other words 4 DB held 8 char strings then another held the address of these so for example an alarm message would consist of B03TK001, Motor001, Failed the pointers might be 001,003,004,152.
The other was an experiment where I typed in the MC5 codes for instructions into a DB, then by processing these words it ran a program where the instructions were held in a DB so no actual code like A M0.0 OUT Y5.0 It worked cannot remember the actual instruction now but it was something like L DW10 RSxx DO DW10. (Don't take this as actual code I cannot remember the actual instructions & cannot find my book with all those instruction in it. the code I wrote as just turn 4 outputs on in sequence all it took was some code with a couple of the special process codes & a DB populated with MC5 Hex codes) It worked a treat I realised that it would be possible to create self modifying code, imagine some code that modified it's self as it processed it by changing the Hex values for the instruction, very bad idea. although it took longer than writing in normal STL or ladder, imagine some unsuspecting engineer looking through the code & seeing no inputs, no outputs, timers etc. just loading loads of datawords & processing instructions you might as well have compiled exe file.
