Ref: Your note of Mon, 18 Mar 2013 09:12:09 -0600 I have seen various tools which have emulated a macro library from separate CMS files, but they were all somewhat flaky. For the code I work with on CMS I keep the macros in SFS directories and create the MACLIB dynamically at the start of each build step, using CMS Pipelines (including the MACWRITE example in the book). For the 300 or so macros involved, this takes much less than a second and means that I'm building from standard CMS maclibs which contain a snapshot of the relevant files. (I also use product macros, but those are kept in large static MACLIBs).
It would of course be quite straightforward to implement support for macros and copy books in individual CMS files using the user exit mechanism, which I've recently used and found it easier than I had expected. However, I already had an even easier solution. CMS minidisk read integrity can be tricky. I used to have particular problems reading small control files which were frequently updated because the round-robin algorithm for block allocation was only round-robin at the byte level in the allocation map, which meant that if a small file was repeatedly updated, it could keep reusing blocks within the same group of 8, causing repeated I/O errors. I fixed that in about 1999 by modifying DMSTRK locally to add a bit-level index to the round-robin scheme, so you would never need more than one reaccess to be able to read a file without errors, and I think that fix is now included in CMS itself. However, we still needed I/O error handling logic which would reaccess once and retry. Nowadays I use SFS instead. Paul Gilmartin wrote: > That modularity implies that it would be fairly easy on VM/CMS > to implement macros and copy books as members of an SFS directory > rather than the wretched CMS MACLIBs. > > We had a development project founder on CMS and move to MVS > because of problems maintaining referential integrity during > concurrent read access to CMS MACLIBs while they were being > serially updated by other processes. (The MACLIBs were never > corrupted; they only appeared so to the viewers.) > > -- gil Jonathan Scott HLASM Development, IBM Hursley, UK
