> dinosaurs still use 3350s. And I'm no dinosaur, even if I
> do still block at 6233 or less so that I can fit data onto
> even a 2314 if necessary.  


I'm a dinosaur and I'm pretty sure I remember 7294 bytes 
fitting on a 2314.  Where did 6233 come from?  

 

 

> Date: Wed, 9 Jun 2010 04:17:02 -0500
> From: mutazi...@gmail.com
> Subject: Re: SEASIK 1.0 released
> To: IBM-MAIN@bama.ua.edu
> 
> On Mon, 7 Jun 2010 03:11:20 -0400, Gerhard Postpischil 
> <gerh...@valley.net> wrote:
> 
> >There's good news and bad news <g>
> >
> >I've been trying to restore SEASIK since Friday, with no luck.
> >
> >1) There is a design error in DSSREST. When I added the RDW
> >code, I wrote the code so it only works when the block size is
> >equal to the sum of the lengths of all RDWs (+4 if there is a
> >BDW). When I use IND$FILE to restore, I get block boundaries
> >unrelated to the RDW sizes. I started to fix this, but the code
> >got more and more complicated, and failed after processing three
> >thousand blocks. I decided to redo Scott's code to eliminate one
> >intermediate buffer, and just use the input buffer directly.
> >That fails on the second block, and I ran out of time. But once
> >it works it will be faster than the old version. I also fixed
> >some spelling errors (leng for length).
> 
> Ok. I use the tape processing facility and block at
> RDW boundaries naturally.
> 
> >2) If you weren't such a sadist, I could have had this restored
> >on Friday. a) Use DSSDUMP to create an AWS or HET tape. b) zip
> >it. c) ftp or upload to wherever. d) user runs DSSREST against
> >the tape file and gets all the files. None of this IDCAMS and
> >special utility crap. For a real mainframe, there is an AWS
> >conversion utility to create a real tape between steps c) and d).
> 
> Don't look at me. IBM are the ones who created ftp
> with the RDW option, and I'm not the only user of that.
> 
> And the special utility is only required because IBM (again)
> neglected to provide a facility to reverse that. They will
> presumably fix that oversight one day. I've seen others
> complaining about that, and the need for a utility.
> 
> This process has nothing to do with tapes, so there's no
> need to force a tape format file into the mix, any more
> than forcing in a CKD VTOC.
> 
> > I uploaded a new version of DSSREST as part of the DSSDMP tape. 
> > It's still in 3350 format (I'll change it to 3390 when you 
> > change .SOURCE files to FB/80 <g>). It restored the SEASIK files 
> > without a hitch, using slightly less memory and time.
> 
> You've got to stop walking into these things. :-)
> 
> The only source code that is actually mine, is this one:
> 
> PDPCLIB.SOURCE SEASIK 10.160 PO FB 80 6160 1 41 4
> 
> And you'll notice that not only is it FB80 as requested, it's
> even blocked at the universal block size. The reason it is
> this way is because I was programming in MVS while you
> were still knee-high to a grasshopper. Well, maybe that's
> an exaggeration.
> 
> You must be looking at (my bundling of) source code from 
> Unix type people, where they don't seem to have gotten 
> the message about restricting the length of lines to 80 so 
> that it fits onto a card.
> 
> So anyway, where's my 3390 dump? I had to especially
> go and mount a 3350 disk just to load your new version
> (which works). Do you know how much those things
> weigh? My site has been all-3390 for WEEKS now (at
> least, pubicly-mounted). Just like all z/OS shops. Only
> dinosaurs still use 3350s. And I'm no dinosaur, even if I
> do still block at 6233 or less so that I can fit data onto
> even a 2314 if necessary.
> 
> BFN. Paul.

                                          
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to