On Mon, Oct 24, 2016 at 7:20 AM, John McKown <[email protected]> wrote:
> On Sun, Oct 23, 2016 at 11:08 AM, Steve Horein <[email protected]> > wrote: > > > > Not being very fluent in 'nix, shouldn't there be a way to set/export > > variables in memory, avoiding the I/O with reading to/from a file? > > I could see the desire to flush the variables to disk for preservation, > but > > repeated look-ups would probably be more efficient. > > > > > Perhaps you are thinking of UNIX environment variables. Those can be > "exported" so that any _children_ of a process _may_ inherit them. But the > child cannot then update the parent's environment variable. Nor can it > affect the environment variables of another "sibling" process. So they are > not good as a general purpose sharing mechanism. > > I am replacing CA-OPS/MVS message rules (losing product) with System REXX > program which are invoked by using the AXREXX macro. What I am needing to > emulate is the OPS "global" variables. These are _global_ (to the product) > variables which can be read / written / deleted in any rule at any time. > They retain their value over restarts of the product and even over an IPL. > Therefore, I am basically forced to use a disk resident facility (not > name/token or other memory method). I use UNIX files in preference to z/OS > data sets simple because _I_ consider them to be easier to use as well as > more efficient. I say more efficient because creating or deleting a UNIX > file does not have any DADSM overhead. Also, the data itself is read / > written from/to via the UNIX kernel (or colony address space), which > buffers (for the entire system) the data automatically (periodically > flushing asynchronously to disk), as well as sharing it, which makes > multiple readers more efficient. Also, UNIX directories are, themselves, > simply UNIX files (with some metadata which indicates that they are > directories instead of a data file, or FIFO, or ???) and so are also > buffered in the UNIX kernel. So doing a look up repeatedly will likely not > do any I/O. Which is very unlike a z/OS data set (catalog lookup to get > volume of data sets, VTOCIX lookup to get pointer to VTOC entry, VTOC read > to get extent information & DSCB information ... lots of I/O) which would > not be buffed "globally". > > -- > Heisenberg may have been here. > > Unicode: http://xkcd.com/1726/ > > Maranatha! <>< > John McKown > > Thank you for the explanation and reasoning sir! I supported OPS/MVS in a previous life (loved it), and I am now supporting NetView automation (love it), so I am lucky to be able to currently work with "COMMON" variables, which are accessible to any NetView task, very similar to OPS' Global variables. There is also the concept of NetView "task" level variables, known only to the specific task. It's good to know the overhead associated with filesystems is not as bad as "traditional" datasets, especially the buffering aspects. On a side note, I always thought you would be a fun guy to work with, based on the things you do! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
