You know, while on the subject of VMARC, I wonder how many times I've wished 
that I could:

PIPE < HUGE VMARC * | VMARC UNPK | loads of filters or whatever... | Output 
stage 

It's still hard to believe that I have no choice but to VMARC UNPK a file to a 
disk (sometimes really large, 2-5K cylinders), before the second pass read 
using Pipes with all the filtering options.  

John

-----Original Message-----
From: CMSTSO Pipelines Discussion List [mailto:cms-pipeli...@vm.marist.edu] On 
Behalf Of Schuh, Richard
Sent: Monday, December 06, 2010 3:28 PM
To: CMS-PIPELINES@VM.MARIST.EDU
Subject: Re: Reblocking a binary file

I do not currently have one; however, a VMARC packed dump file that I sent to 
CA about 6 months ago had the problem. They said that the unpack failed, so I 
sent it a second time. When they could not unpack the second copy, I had them 
try the fblock 80 00. That worked - the unpacked record and byte counts were 
correct. I had no problem unpacking the file at my end. I will try to remember 
that you would like to see one of the failing files the next time I run into 
it. 

Regards,
Richard Schuh 

 

> -----Original Message-----
> From: CMSTSO Pipelines Discussion List 
> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Paul Gilmartin
> Sent: Monday, December 06, 2010 1:34 PM
> To: CMS-PIPELINES@VM.MARIST.EDU
> Subject: Re: Reblocking a binary file
> 
> On 2010-12-06 13:52, Schuh, Richard wrote:
> > I generally try VMARC UNPACK first. If it fails, I try the
> 'fblock 80 00' approach. It usually does solve the problem. I have had 
> infrequent cases where dumps that I have packed using VMARC could not 
> be unpacked by the vendor without using 'FBLOCK 80 00'. It may or may 
> not be a horrid practice; however, it is sometimes a necessity, 
> whether horrid or not.
> >
> Have you a test case that fails without the '00' but succeeds with the 
> '00'?  I'd be interested in seeing it.
> 
> -- gil
> 

Reply via email to