On Wednesday, 12/03/2003 at 04:59 EST, David Boyes <[EMAIL PROTECTED]> wrote: > We've been doing some thinking about a more general way to enable access to > CP system services from Linux, and I'd like to get some opinions on one > approach we've considered. > > IMHO, there's 4 steps to this: > > - create a Linux-referencable connection to reserve workspace and set up the > call to the DIAGnose > - supplying requests to the DIAGnose > - getting the data back from the DIAGnose > - destroying the Linux-referencable connection to the service when you're > done with it.
I think I'd rather see files created of the sort cp/diag/0, cp/diag/8, cp/diag/24, and so on. Some of those files are r/w (8, 24), some are r/o (0). Some are capable of async, some are not. You write the input record (if appropriate) and read the output record. In other words, I'd like the diagnose code to not be part of the data stream. That just creates extra complexity without good reason. If you want to dynamically supply the diag code, then you use sprintf() to construct the file name. This provides the flexibility to let fopen() create any buffers it requires based on diag number, with close() getting rid of them. The paradigm holds for user-user comms. E.g. fopen(/cp/iucv/altmarka) or fopen(/cp/iucv/*MSG) establishes an IUCV connection immediately. If I'm looking at a trace, I will have no idea what fopen(/cp/diag/2/ctl) really is unless I see the data on the write call. I much prefer a self-documenting representation. Alan Altmark Sr. Software Engineer IBM z/VM Development
