Variable length fields have a fixed header per field that is around 26 bytes in size (give or take one or two, I can’t recall and I’m not going to look it up lol). This header contains information related to whether or not the actual data fits into a “very small” fixed data portion of the header, the “very small” data portion (which can be larger if you use VARLEN but which exists even if you don’t), information to access the data if it doesn’t fit in the data portion, etc. You don’t see this header in your program, but it’s there all the same.
If your 2-byte value is small then the amount of disk used is the size of the header plus anything you added due to the use of VARLEN. If your 2-byte value is large then the amount of disk used is the value plus the header size (which would include the 2-byte size value).
Actual disk space used can also be a tad more due to loss caused by alignment, fragmentation of the overflow area, and the like.
The two bytes at the start of the varying length field tells the system how many bytes of the field to use, not necessarily how many actual bytes long the field is.
Speaking from experience on a System/36 many years ago, although I would expect similar on the AS/400, data was compressed on the disk using a relatively simple algorithm.
On the S/36 repeating characters of three or more were compressed down into a series of three bytes something along the lines of an x’00’ to flag compression, a byte with the number of repeats and the repeating character so a 1024 character field containing all blanks would be compressed to 15 bytes
All the best
The only reasonable interpretation of the question is if the field is in a database file which has nothing to do with RPG, neither ILE nor OPM. In that case, the field takes up as much space as the length of the value plus two bytes for the length. E.g., if the value is 1000 bytes, the field takes up 1002 bytes. If the field is updated with a value that is 10 bytes more, then the field will take up 1012 bytes. Simple, mostly.
There is an extra consideration.
When declaring a variable-length database field, you also assign an ALLOCATE() value. This part of the field is fixed-length. When ALLOCATE(50) is set, the field will take up 50 bytes even if the value is only 10 bytes long. The ALLOCATE() size is the minimum.
Every record in the file will have <i>at least</i> 50 bytes for the field. (Note that without variable-length, every record would have to have <i>at least</i> 1010 bytes for the field in the case noted above.)
The best guideline is to ALLOCATE() enough to account for most field lengths. Try to minimize how much overflow space is used. This is a balance between unused space multiple physical I/Os to access the base recordarea plus the overflow area.