Create INODE version upgrade tool.

Currently for z/TPF TFS INODEs there is no available functionality to upgrade an INODE to the most current INODE version.  In some systems, directories/files have been present since the initialization of the TPF TFS and are still at INODE version ‘0’  ( TPF_FS_INODE_OLD_VERSION).  This situation affects the use of the options available in the ZFILE ATTR entry, in our case the desire to use the backup TO2 collection and shadow TO2 collection redundancy options as specified via ZFILE ATTR.

Here's an example of one system’s /dev directory backed by an INODE at version ‘0’:

zfile ls -lid /dev                                    

1 drwxr-xr-x  1 root  bin  14 Mar  8  2023 /dev       

zdrec linode.1 0.fff                                               

CSMP0097I 15.44.12 CPU-B SS-BSS  SSU-BSS  IS-01                    

DREC0011I 15.44.12 BEGIN DISPLAY OF FILE ADDRESS 000000005C29D001  

 00000000- FC2A1200 C3C6E5E2 00000000 00000000 ....CFVS ........   

 00000010- 00000000 00000001 00000000 00000000 ........ ........ _ 

 00000020- 0300FC16 D94E3F1E C9C6E2E7 C2E2E240 ....R... IFSXBSS    

 00000030- 00000000 8DC25416 00000000 00000000 .....B.. ........   

 00000040- 00000000 FFFFFFFF 00000000 FFFFFFFF ........ ........   

 00000050- 00000000 64094ED1 00000002 0000000E .......J ........   

 00000060- 010001ED 00000000 00000001 00000001 ........ ........ _ 

 00000070- 0000000C C2E2E240 FFFFFFFF 00000000 ....BSS  ........   

 00000FF0- 00000000 00000000 00000000 00000013 ........ ........   

END OF DISPLAY - ZEROED LINES NOT DISPLAYED+        

The ‘idea’ presented here is to create a function that will allow an INODE’s data layout to be upgraded to the most current release level via system entry (demand code).  The function would be available for execution while the system is in NORM state.  No change in INODE ordinal would occur as part of this update thereby allowing directory structure tables to remain unchanged.  Lastly the function should be able to perform the INODE version upgrade without causing application errors in access to the files/directories whose INODEs are being upgraded.

Ideally the function will be able to execute against a single INODE or a range of INODEs (possibly a directory tree’s INODEs) as opposed to a full upgrade of all INODEs in the TPF file system (TFS).  The main point here is that a limited range of INODE updates per function execution limits the scope of adverse system behavior if there is some unexpected result from the update.  This limited range of execution would be desirable from a recovery/fallback perspective.

Our main motivation in presenting this idea, is that we need a solution to allow shadowing or backing up of the collations of relatively highly used TFS directories that have existed since the TFS was initialized, '/etc' in particular,  without deleting and recreating the directories via standard ZFILE entries.  A tool to update the INODE version "in place" would address the situation nicely.