|
View previous topic :: View next topic
|
| Author |
Message |
pema_yozer
New User
Joined: 16 Feb 2009
Posts: 54
Location: pune
|
|
|
|
I have used a terada export job to create a variable length file in my development server
| Code: |
DISP=(,CATLG),MGMTCLAS=M0DLY03M,
DATACLAS=D010CYLS,RECFM=VB,
LRECL=800 |
shows the below info
| Code: |
,Used bytes . . . . :,525,774,442
,Used extents . . . :,7 |
when i transfer the file on to my desktop in text mode the file seems correct as a variable file with size arounf 150mb
i then transfer it to the production server and rn the PKZIP to zip it on unzipipinf every thign seems alrite
Now i create the file directly in production.. it shows the same
,Used bytes . . . . :,525,774,442
,Used extents . . . :,7
how ever when i do a pk zip on it now when i unzip it i get a file which is a fixed length fileinstead of the previous variable length
any idea
below is the pkzip parameter used
| Code: |
-ARCHIVE_DSNAME(EHY.PEMA.CUS.FILE.ZIP)
-OUTFILE_OVERWRITE(Y)
-OUTFILE_DSNTYPE(SEQ)
-OUTFILE_LRECL(1069)
-OUTFILE_RECFM(VB)
-OUTFILE_SPACE_MULTIVOL=Y
-OUTFILE_UNIT(SYSDA)
-OUTFILE_SPACE_PRIMARY(2000)
-OUTFILE_SPACE_SECONDARY(2000)
-DATA_TYPE(TEXT)
-CRLF(Y)
-DATA_DELIMETER(CRLF)
EHY.PEMA.CUS.FILE |
|
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
How do you explain 150mb on PC and 500mb on mainframe?
Are the above cards identical in test/prod. If so, there must be some default which is different between the two to get you different results. Maybe if you look at the output from each, you can track down some difference? |
|
| Back to top |
|
|
pema_yozer
New User
Joined: 16 Feb 2009
Posts: 54
Location: pune
|
|
|
|
basically i'm only doing a zip in production ..
when i download the 500 mbfrile onto my desktop it is downloaded as a 150 mb file .
when i upload teh same file and zip it every thing is alright..
how ever when i directly zip the file without any downloading it's giving me an issue |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
You start of with 500mb.
You compress (zip) the data getting you 150mb.
You transfer it to your PC.
You transfer it back your PC.
You uncompress (unzip) the data getting you 500mb.
Then:
You start of with 500mb.
You compress (zip) the data getting you 150mb.
You uncompress (unzip) the data getting you 500mb.
And something has gone wrong.
Is this what you are trying to say? |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| pema_yozer wrote: |
I have used a terada export job to create a variable length file in my development server
| Code: |
DISP=(,CATLG),MGMTCLAS=M0DLY03M,
DATACLAS=D010CYLS,RECFM=VB,
LRECL=800 |
shows the below info
| Code: |
,Used bytes . . . . :,525,774,442
,Used extents . . . :,7 |
when i transfer the file on to my desktop in text mode the file seems correct as a variable file with size arounf 150mb
i then transfer it to the production server and rn the PKZIP to zip it on unzipipinf every thign seems alrite
Now i create the file directly in production.. it shows the same
,Used bytes . . . . :,525,774,442
,Used extents . . . :,7
how ever when i do a pk zip on it now when i unzip it i get a file which is a fixed length fileinstead of the previous variable length
any idea
below is the pkzip parameter used
| Code: |
-ARCHIVE_DSNAME(EHY.PEMA.CUS.FILE.ZIP)
-OUTFILE_OVERWRITE(Y)
-OUTFILE_DSNTYPE(SEQ)
-OUTFILE_LRECL(1069)
-OUTFILE_RECFM(VB)
-OUTFILE_SPACE_MULTIVOL=Y
-OUTFILE_UNIT(SYSDA)
-OUTFILE_SPACE_PRIMARY(2000)
-OUTFILE_SPACE_SECONDARY(2000)
-DATA_TYPE(TEXT)
-CRLF(Y)
-DATA_DELIMETER(CRLF)
EHY.PEMA.CUS.FILE |
|
Use TRSMAIN or AMATERSE. |
|
| Back to top |
|
|
pema_yozer
New User
Joined: 16 Feb 2009
Posts: 54
Location: pune
|
|
|
|
I crete a varible length file..
i do a info and it shows me 500 mb
i do not zip it but transfer it to my desk top i see the file is 150 mb.
now i transfer it back and zip it every thing is normal.
now i directly zip the file without any transfer and pk zip gives a a fixed length file instead of a variable one |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
AMATERSE any file and the resulting file will be FB with an LRECL of 1024. "un"AMATERSE it and it will be back to what it was.
SIASD |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
OK, so here we are again.
First, how did you create the file?
Second, what is the recfm etc of the file?
If you FTP a file as TEXT, you will "loose" all the trailing blanks (unless you ask it not to do that). That happened to be what you "want", but there will be a way to get your output without involving the PC or a whole slew of other products. |
|
| Back to top |
|
|
pema_yozer
New User
Joined: 16 Feb 2009
Posts: 54
Location: pune
|
|
|
|
The problem was in the file produced initially.
there were spaces in the file initially which were reflected when it was zipped directly.
whne the file was transferred these trailing spaces were removed by the transfer parameter hence the file size was much smaller.
did avl trim on the file and that solves the probem..
thank you guys for your time nsupport |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Pema,
Just out of interest, what did you use to create the file originally, and is AVL TRIM part of it? |
|
| Back to top |
|
|
pema_yozer
New User
Joined: 16 Feb 2009
Posts: 54
Location: pune
|
|
|
|
the file was created from teredata wsing the fast export utility..
it gives two byte rdw at start of each record..
to by pass this we cast the whole record as character but this results in a FB record..
our trasfers are automatically configured to remove the trailing spaces.
how ever this time we created a pkzip step to zip the file before transferring form mainframe as a result our transfer couldnt remove the spaces.
added vltrim as an addition step in my jcl..not part of fastexport. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| pema_yozer wrote: |
[...]
it gives two byte rdw at start of each record..
[...] |
I may, or may not, try to check on the rest later, but for the above:
RDW = Record Descriptor Word
Word = 4 Bytes
RDW consists of Record Length (half-word) and a "reserved" half-word, which I've only ever seen as 0000. If you search for RDW in a posting by Robert Sample you'll find what the 0000 bit is ever used for.
So, you don't get "two byte rdw"s. The RDW you get for every variable-length record. If you see (on the mainframe) two bytes then your data, that is something extra just showing you the length of the data, put there by a particular application/package, not by the operating system. If you use something that can show you the RDW, then you'll see the RDW, followed by this data-length thing, followed by the data. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Often, trailing blanks are removed when a file is transferred to a pc.
Check with your support people to see if thisd causes the difference in the length of the files. . . |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
| I've read this post about 10 times now, and I have absolutely no idea what the issue is. There is nothing within PKZIP that would either add or remove trailing spaces from the data if they're present to begin with. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Kevin,
| Quote: |
our trasfers are automatically configured to remove the trailing spaces.
how ever this time we created a pkzip step to zip the file before transferring form mainframe as a result our transfer couldnt remove the spaces. |
I may be misunderstanding, but i believe the confusion is the difference when the file is transmitted without pkzip and with it.
When the plain text file is sent to the pc, the trailing spaces get deleted.
When the file is zipped, there are no "trailing spaces" so the ftp cannot remove them.
When the file is unzipped on the pc, the trailing spaces are back in the records. . . |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Extract from Teradata. TS unable to do so without trailing blanks.
Eventually dropped trailing blanks with DFSORT (there is another topic over there by same TS).
Transfer to PC was one way of dropping trailing blanks. Then upload back to mainframe! The, apparently, zip it.
Neither of the two posts contain much useful content.
Ends up as: extract from Teradata with trailing blanks. VLTRIM with DFSORT. Zip it for some purpose. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I suspect the compress was to reduce the size of the file to be transmitted?
Unfortunately, compressed trailing spaces expand again when de-compressed . . . |
|
| Back to top |
|
|
|
|
