Rob, That's all way too complicated. :-)
My stage uses Diag A8 to do the tape io, no interrupts to contend with etc. Diag A8 doesn't complete until the io is all done, CP then gives me back device and subchannel status etc. What's wrong with the existing tape stage? It won't handle blocks larger than 64K. Yes, user-written stages can use the pipxxx macros, I use pipword, piptokn, etc to parse the arg string, convert text to binary numbers, etc. I use piperm to display error messages very consistent with the built in stages etc. So yes, I want to use the same mechanism to prevent attempting to use the same device by two different stages, whether they are two of my user-written stages or one of mine and one of something else. Donald Russell On Tuesday, December 29, 2015, Rob Van der Heij <[email protected]> wrote: > > > > Thanks John, > > > > I'm dealing with tape drives. So I don't want somebody to accidentally > try > > to write to the drive they're reading from. :-) though hopefully they'd > > mount the input tape as input/noring and a write ccw would choke and I'd > > exit on the unit check. > > > > Prior to pipcommt 0, I'd like to make sure the device isn't in use > > somewhere else in the pipeline. > > > > I guess I was envisioning a simple macro like > > pipregdv , R1 has the device number to "register" > > jnz alreadyInUse > > > > Where pipregdv updates a table with the device number and stage number > > requesting it. If it's already in the table, return the stage number in > r1 > > and set a non-zero cc. > > > > But, if there's some sort of control/parm block I can build and call an > > existing function, that's all good too. :-) > > > > What's missing in the tape support in CMS Pipelines? I have done quite some > plumbing with tapes in the ancient past... > > I kept quiet because I didn't realize the pipeline vector allows > user-written stages to use it. And by using the same mechanism you also > guard yourself against a rogue 'tape' stage going after the device. Your > stage would also need to something to handle I/O interrupts, and post an > ECB, isn't it? Yes, it's pretty much what you envisioned, be it that some > of the error handling is basically offloaded to IOSNQ rather than letting > the stage pick it up. > > Rob > > --- > Rob van der Heij > z/VM Development, CMS PipelinesTenzij hierboven anders aangegeven: / > Unless stated otherwise above: > IBM Nederland B.V. > Gevestigd te Amsterdam > Inschrijving Handelsregister Amsterdam Nr. 33054214 > -- Sent from iPhone Gmail Mobile
