My apologies as well if the "tone" in my wording sounded offensive. I thought that I have picked apart the index and help files and author's help files pretty well. I never referred to NETDATA files, I was purely commenting on the apparently only one option for reading a VMARC FILE, which requires two full reads of the data, one for VMARC UNPK, and then another to actually read the unpacked file. Tone?? Guess that I'm happy that I only have to read VMARC files only twice, considering things could always be worse, I'm pleased that I don't have to re-read VMARC files 3 or 4 times before I'm actually processing the data...
-----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, December 07, 2010 6:50 AM To: CMS-PIPELINES@VM.MARIST.EDU Subject: Re: The Missing Stages (was: Reblocking a binary file, and VMARC) On Dec 7, 2010, at 01:49, Rob van der Heij wrote: > On Tue, Dec 7, 2010 at 3:34 AM, Paul Gilmartin <paulgboul...@aim.com> wrote: > >> Worse yet, if it's in the spool in NETDATA format (well, then it's >> likely not so huge): > > Sorry, but it appears you have not even read the book. Most plumbers > on the list would at least look in the index and find the idiom to > deal with netdata files. There's built-in stages to block and deblock > netdata just fine. The generic solution is just a bit more complicated > than you suggest (there's the netdata envelopes that need to be > handled to pass the meta data as well). The same applies to things > like VMARC and VMFPLC that frequently handle stacked files. > I'm familiar with the READER and NETDATA stages; I use them; I cited them in the 3-line example I posted (yes, abbreviated, absent necessary arguments.) I was echoing John Larson's observation that there seems to be no conventional way to deal with large VMARCs other than unpacking them entirely, with large disk space requirements. Is the book you mention: Title: z/VM V6R1 CMS Pipelines Reference Document Number: SC24-6169-00 Build Date: 07/24/09 14:05:06 ? This contains no mention of VMFPLC*, and only an incidental mention of VMARC in connection with obtaining RXSOCKET. the FTP archive at vm.marist.edu contains VMARC MODULE and several files with filetype VMARC; nothing relevant to VMFPLC*. Are there other sources I should be consulting? Well, yes. A Google search finds a thread I started early this year, to which Rick Troth and John Hartman, among others replied. Rick Troth mentions that "[tar and VMFPLC B]oth can be neatly wrapped into plumbing." Nothing more specific. And John Hartmann states, "The undocumented LISTDIR stage will get you all the information you require." pipe listdir | console PIPFPI011E Null or blank parameter list found. PIPSCA003I ... Issued from stage 1 of pipeline 1. PIPSCA001I ... Running "listdir". Ready(00011); T=0.01/0.01 07:37:31 Undocumented, indeed. And there is a VMFPLC thread about 5 years old, to which you contributed. A glance at the code and at a VMFPLC archive shows a mismatch, "FPLH" in the code, and "FPLC" in the archive. Perhaps the format changed in the interim. > You can write filters in REXX or even in assembler if you need. Many > of us have written their own filters for specific scenarios, and most > are willing to share if you ask (and if their employer allows that). > It may be me, but the tone of your posts on the list right now does > not encourage me to dig in my plumbers' toolbox and throw in some > fittings and appendices to build something. > I'm considerably constrained by the need to provide code to customers. My own systems programmer won't install the Pipelines Runtime; I must assume that some customers will feel likewise. And they may have similar aversions to complex tools; I want to keep things standard and simple for them. Thanks for your assistance; you've provided some useful suggestions and encouragement. And my apologies if I offended. -- gil
