subject:"TRSMAIN"

Re: TRSMAIN AMATERSE

2023-08-13 Thread Erik Janssen

It is documented in the original patent as far as I can see, but I haven't 
looked in dept into both the patent and the java example:

https://www.freepatentsonline.com/4814746.html

But I'm not sure if that will give you enough information. It depends on what 
you are trying to achieve with the information I guess.

On Sun, 13 Aug 2023 01:30:49 +, kekronbekron  
wrote:

>Is the **algorithm** documented... you know, in words, with examples?
>
>
>--- Original Message ---
>On Saturday, August 12th, 2023 at 10:21 PM, Erik Janssen 
> wrote:
>
>
>> See:
>> https://github.com/openmainframeproject/tersedecompress
>> 
>> Kind regards,
>> Erik.
>> 
>> 
>> On Sat, 12 Aug 2023 05:19:43 +, kekronbekron kekronbek...@protonmail.com 
>> wrote:
>> 
>> > By any chance, is the algorithm for tersing/untersing publicly available?
>> > 
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread kekronbekron

Is the **algorithm** documented... you know, in words, with examples?


--- Original Message ---
On Saturday, August 12th, 2023 at 10:21 PM, Erik Janssen 
 wrote:


> See:
> https://github.com/openmainframeproject/tersedecompress
> 
> Kind regards,
> Erik.
> 
> 
> On Sat, 12 Aug 2023 05:19:43 +, kekronbekron kekronbek...@protonmail.com 
> wrote:
> 
> > By any chance, is the algorithm for tersing/untersing publicly available?
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread kekronbekron

Is LZW the exact same as TRSMAIN/AMATERSE?


--- Original Message ---
On Sunday, August 13th, 2023 at 1:42 AM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:


> At a guess, in the IBM and Unisys patent files that have expired at the US 
> Patent Office. Not sure if USPO requires any payment to view/print patent 
> files, but they are supposed to be “public record” so should be available.
> 
> For Lempel-Ziv-Welch compression, Wikipedia article here: 
> https://en.wikipedia.org/wiki/Lempel–Ziv–Welch
> 
> Peter
> 
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> kekronbekron
> 
> Sent: Saturday, August 12, 2023 9:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TRSMAIN AMATERSE
> 
> 
> 
> From the thread...
> 
> 
> 
> "The algorithm is reasonably well documented, and the encapsulation is not 
> complex. And
> 
> as I said, the patents have expired."
> 
> 
> 
> Well-documented where?
> 
> 
> 
> 
> 
> --- Original Message ---
> 
> On Saturday, August 12th, 2023 at 5:17 PM, Mike Schwab 
> mailto:mike.a.sch...@gmail.com> wrote:
> 
> 
> 
> 
> 
> 
> > https://urldefense.com/v3/__https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KgFPMf4W43fW9fcVLr7EhIaqolCaXFEi6c4Eyn8KvEeFq0rbFE7vXdS9bjmOCJ82dR98eJ0K7rxzp6thvoX4Ot5MCrSG6LFC8_kf5FjA$https://urldefense.com/v3/__https:/hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KgFPMf4W43fW9fcVLr7EhIaqolCaXFEi6c4Eyn8KvEeFq0rbFE7vXdS9bjmOCJ82dR98eJ0K7rxzp6thvoX4Ot5MCrSG6LFC8_kf5FjA$
> 
> > Now over at groups.io .
> 
> > On Sat, Aug 12, 2023, 00:20 kekronbekron <
> 
> > 02dee3fcae33-dmarc-requ...@listserv.ua.edumailto:02dee3fcae33-dmarc-requ...@listserv.ua.edu>
> >  wrote:
> 
> > > By any chance, is the algorithm for tersing/untersing publicly available?
> 
> 
> --
> 
> 
> 
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Charles Mills

Claimed implementations here in many languages, including C, PL/I and Rexx.

https://rosettacode.org/wiki/LZW_compression 

CM

On Sat, 12 Aug 2023 17:20:47 -0400, Tony Harminc  wrote:

>On Sat, 12 Aug 2023 at 09:30, kekronbekron
><02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> From the thread...
>>
>> "The algorithm is reasonably well documented, and the encapsulation is not 
>> complex. And
>> as I said, the patents have expired."
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Paul Gilmartin

On Sat, 12 Aug 2023 20:12:32 +, Farley, Peter wrote:

>At a guess, in the IBM and Unisys patent files that have expired at the US 
>Patent Office.  Not sure if USPO requires any payment to view/print patent 
>files, but they are supposed to be “public record” so should be available.
>
>For Lempel-Ziv-Welch compression, Wikipedia article here: 
>https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
>
Is there an envelope around the LZW body that a programmer would need to 
understand?
I believe AMATERSE offers a choice of two algorithms, PACK and SPACK.  SPACK 
atands
for "not simple".

How does it deal with CSOrG=PO (And DSNTYPE=LIBRARY)?

Likewise, are there portable FOSS utilities for NETDATA?
(Extra credit for pre-compiled.)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Tony Harminc

On Sat, 12 Aug 2023 at 09:30, kekronbekron
<02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> From the thread...
>
> "The algorithm is reasonably well documented, and the encapsulation is not 
> complex. And
> as I said, the patents have expired."

That was me writing, 15 years ago.

> Well-documented where?

The *algorithm* is in the patent, but I'm not sure that IBM's
terse/deterse/TRSMAIN/AMATERSE etc. implementation of LZW is fully
publically documented. But there is enough out there to write your own
by starting with the patent and then experimenting, as several people
have done.

Some more snippets of stuff I wrote on lists and private emails around
the same time:

The pointer http://marknelson.us/1989/10/01/lzw-data-compression/
is a good one. (This is now 404, but available on the Wayback Machine).
The Wikipedia articles on LZW are also useful, and they have some
tables that help to get
the idea across. Who the "W" is in LZW is open to debate. Most people say it's
Welch, but IBM would say it's Wegman. There is some discussion in the
comp.compression newsgroup on this by Wegman himself. It seems both Ws invented
roughly the same thing at roughly the same time, and somehow both
patents managed to be issued (which says a lot about the US patent
system). Regardless, both patents are now
long expired.

The IBM US patent (Wegman - not Welch)  is 4814746, available at
Google patents, or
http://www.freepatentsonline.com/4814746.html or of course any other
source for US patents.

It includes a sample PL/I program that claims to implement the
invention, but it is full of errors and omissions, has some dead code,
and has been OCR'd from something in a manner I can only believe was
intended to make it difficult to copy. Nonetheless I re-OCR'd and
corrected it to the point of readibility, but not compileability.

Another place to look for assembler source for LZW is the VMARC
program. Google something like "vmarc" "lzw" to get started. There's a
bunch of discussion on IBM-VM going back many years.
[...]
I have spent some time looking at the output created by these programs,
and it is certainly LZW of a sort, although there are two quite
different implementations (the PACK and SPACK options, where SPACK
generally outperforms PACK). I have done
the basic analysis of the headers, and some of the actual
decompression algorithms (based just on data - *not* disassembling IBM code).
[...]
I was able to write a mostly complete decoder in OO REXX, but that was, again,
around 15 years ago, and I've forgotten most of the details.

I can try to dig up what I have, but it'll take a while.

The layout of a tersed file is very simple - there is a 12-byte*
header, followed by a stream of 12-bit (i.e. 1 1/2 bytes) "symbols",
and terminated by a symbol of zero. Then there is typicallly a
trailer, but it seems to contain nothing necessary or even useful in
decoding the symbol stream. Notably neither the header nor trailer
contains the length of the data stream. (This makes sense in the
context of smart compressing modems, where the uncompressed data
stream is effectively infinite and hence unknowable, and which is
where I believe IBM and Unisys made their money on their respective
patents.)

(* For Flag1 = 01 below, the header is shorter. This is pretty much
"raw" LZW[egman], with no concept of records, blocks, and similar
MVS-like stuff.)

For a tersed PDS[E] there is a directory structure that is part of the
compressed data stream, and precedes the member data.

The header is roughly like this (from my days of experimenting in an
old email that I was able to dig up just now with a quick search):

XL1Flag1;   01 = unknown 02 = PACK, 05 = SPACK, 07 =
PDS[E]/PACK, 09 = PDS[E]/SPACK
XL1Flag2;   00 = fixed?, 01 = variable? It's 01 for V and U.
XL2RecordLen;  For VB it seems to be 4 less than expected (no RDW?)
XL1Flag3;   04 = F or V, 0C = FB or VB, 1C = FBS,
4C=FBA/FBM, 84=U, 8C for load module PDS
XL1Unknown1;usually 00, but 01 for a load module PDS
XL2BlockSize;   For VB it does match the expected.
XL4Unknown2;Always seen as zero.

Flag3 meaning?
80RECFM U
40Carriage control=A
20Carriage control=M
10RECFM S
08RECFM B (but also found with U!)
04always on
02never on
01never on

As Charles just said, the algorithm is incredibly cool! But in
practice these days there are much better performing algorithms in
wide use.

Cheers... Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Charles Mills

I have a lot of personal experience with the LZW patent, up to and including 
paying royalties to Unisys.

I will not bore this group with my whole long story. Suffice it to say that 
this was one of the first "stealth" patents. At the time I implemented and used 
the algorithm there was no public clue that Unisys had a patent pending. That 
is harder to do now.

Yes, the patents have long since expired -- I am going to say that we stopped 
paying royalties around 2000.

You can implement LZW. I did it in HLASM, and an employee of mine cloned the 
code into C. I would think you could find the algorithm, or perhaps even public 
code, on-line.

The algorithm is incredibly cool! It is dictionary compression, where recurring 
strings are replaced with a single code. What is really cool is that the two 
ends never explicitly exchange the dictionary. The sender builds the dictionary 
as it goes, and the receiver is able to mimic the process and build an 
equivalent dictionary. There is one special case where the receiver sees a code 
that is not in its dictionary -- and since there is only one such case, it 
knows how to work around it.

CM

On Sat, 12 Aug 2023 20:12:32 +, Farley, Peter  
wrote:

>At a guess, in the IBM and Unisys patent files that have expired at the US 
>Patent Office.  Not sure if USPO requires any payment to view/print patent 
>files, but they are supposed to be “public record” so should be available.
>
>For Lempel-Ziv-Welch compression, Wikipedia article here: 
>https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
>
>Peter
>
>From: IBM Mainframe Discussion List  On Behalf Of 
>kekronbekron
>Sent: Saturday, August 12, 2023 9:30 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: TRSMAIN AMATERSE
>
>
>
>From the thread...
>
>
>
>"The algorithm is reasonably we l ducumented, and the encapsulation is not 
>complex. And
>
>as I said, the patents have expired."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Farley, Peter

At a guess, in the IBM and Unisys patent files that have expired at the US 
Patent Office.  Not sure if USPO requires any payment to view/print patent 
files, but they are supposed to be “public record” so should be available.

For Lempel-Ziv-Welch compression, Wikipedia article here: 
https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron
Sent: Saturday, August 12, 2023 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN AMATERSE

From the thread...

"The algorithm is reasonably well documented, and the encapsulation is not 
complex. And

as I said, the patents have expired."

Well-documented where?

--- Original Message ---

On Saturday, August 12th, 2023 at 5:17 PM, Mike Schwab 
mailto:mike.a.sch...@gmail.com>> wrote:

> https://urldefense.com/v3/__https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KgFPMf4W43fW9fcVLr7EhIaqolCaXFEi6c4Eyn8KvEeFq0rbFE7vXdS9bjmOCJ82dR98eJ0K7rxzp6thvoX4Ot5MCrSG6LFC8_kf5FjA$<https://urldefense.com/v3/__https:/hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KgFPMf4W43fW9fcVLr7EhIaqolCaXFEi6c4Eyn8KvEeFq0rbFE7vXdS9bjmOCJ82dR98eJ0K7rxzp6thvoX4Ot5MCrSG6LFC8_kf5FjA$>

>

> Now over at groups.io .

>

> On Sat, Aug 12, 2023, 00:20 kekronbekron <

> 02dee3fcae33-dmarc-requ...@listserv.ua.edu<mailto:02dee3fcae33-dmarc-requ...@listserv.ua.edu>>
>  wrote:

>

> > By any chance, is the algorithm for tersing/untersing publicly available?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Erik Janssen

See:
https://github.com/openmainframeproject/tersedecompress

Kind regards,
Erik.


On Sat, 12 Aug 2023 05:19:43 +, kekronbekron  
wrote:

>By any chance, is the algorithm for tersing/untersing publicly available?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread kekronbekron

>From the thread...

"The algorithm is reasonably well documented, and the encapsulation is not 
complex. And
as I said, the patents have expired."

Well-documented where?


--- Original Message ---
On Saturday, August 12th, 2023 at 5:17 PM, Mike Schwab 
 wrote:


> https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux
> 
> Now over at groups.io .
> 
> On Sat, Aug 12, 2023, 00:20 kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > By any chance, is the algorithm for tersing/untersing publicly available?
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Steve Beaver

I doubt it

Sent from my iPhone

No one said I could type with one thumb 

> On Aug 12, 2023, at 06:47, Mike Schwab  wrote:
> 
> https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux
> 
> Now over at groups.io .
> 
>> On Sat, Aug 12, 2023, 00:20 kekronbekron <
>> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> By any chance, is the algorithm for tersing/untersing publicly available?
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN AMATERSE

2023-08-12 Thread Mike Schwab

https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux

Now over at groups.io .

On Sat, Aug 12, 2023, 00:20 kekronbekron <
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> By any chance, is the algorithm for tersing/untersing publicly available?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

TRSMAIN AMATERSE

2023-08-11 Thread kekronbekron

By any chance, is the algorithm for tersing/untersing publicly available?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-12 Thread Paul Gilmartin

On Mon, 11 Dec 2017 23:24:34 -0500, zMan wrote:

>OK, but that's not the intended use case for TRSMAIN, is it? So why risk
>breakage for folks using it as intended?
>Seems like you want a slightly different tool.
>(Yes, I'm being a hardass here!)
>
One use of TRSMAIN (AMATERSE?) often requested by IBM SR is submitting
supporting information with a problem report.  This is partly because Terse
format is relatively immune to the vagaries of FTP.

Once, for a UNIX problem, IBM pointed me to their instruction page which
required Terse.  So I made a tar of the UNIX files and Tersed that and left
IBM to deal with it.  They did; didn't even complain.

And many sites shun connecting the z to the Internet, so the path is:

z/OS -> some desktop -> testcase.IBM

(Sometimes one of the steps is sneakernet.)

>On Mon, Dec 11, 2017 at 6:58 PM, John McKown wrote:
>
>> My application is: z/OS -> Linux -> different z/OS . I can't go directly
>> from z/OS #1 to z/OS #2.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread zMan

OK, but that's not the intended use case for TRSMAIN, is it? So why risk
breakage for folks using it as intended?
Seems like you want a slightly different tool.
(Yes, I'm being a hardass here!)

On Mon, Dec 11, 2017 at 6:58 PM, John McKown <john.archie.mck...@gmail.com>
wrote:

> On Mon, Dec 11, 2017 at 5:47 PM, zMan <zedgarhoo...@gmail.com> wrote:
>
> > Seems like a bad idea, since it will produce something that can't
> > necessarily be unTERSEd on another box.
> >
>
> My application is: z/OS -> Linux -> different z/OS . I can't go directly
> from z/OS #1 to z/OS #2.
>
>
>
> >
> > On Mon, Dec 11, 2017 at 1:45 PM, John McKown <
> john.archie.mck...@gmail.com
> > >
> > wrote:
> >
> > > On Mon, Dec 11, 2017 at 12:28 PM, David Mingee <ming...@prodigy.net>
> > > wrote:
> > >
> > > > You might consider using the MODE C command in FTP vs.
> AMTERSE/UNTERSE
> > > > utility.  It will run much faster and save CPU time.
> > > >
> > >
> > > Does that work with data sets which are RECFM=U which are stored on a
> > > non-z/OS system (in my case - Linux).
> > >
> > > --
> > > I have a theory that it's impossible to prove anything, but I can't
> prove
> > > it.
> > >
> > > Maranatha! <><
> > > John McKown
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> >
> > --
> > zMan -- "I've got a mainframe and I'm not afraid to use it"
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread John McKown

On Mon, Dec 11, 2017 at 5:47 PM, zMan  wrote:

> Seems like a bad idea, since it will produce something that can't
> necessarily be unTERSEd on another box.
>

My application is: z/OS -> Linux -> different z/OS . I can't go directly
from z/OS #1 to z/OS #2.



>
> On Mon, Dec 11, 2017 at 1:45 PM, John McKown  >
> wrote:
>
> > On Mon, Dec 11, 2017 at 12:28 PM, David Mingee 
> > wrote:
> >
> > > You might consider using the MODE C command in FTP vs. AMTERSE/UNTERSE
> > > utility.  It will run much faster and save CPU time.
> > >
> >
> > Does that work with data sets which are RECFM=U which are stored on a
> > non-z/OS system (in my case - Linux).
> >
> > --
> > I have a theory that it's impossible to prove anything, but I can't prove
> > it.
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread zMan

Seems like a bad idea, since it will produce something that can't
necessarily be unTERSEd on another box.

On Mon, Dec 11, 2017 at 1:45 PM, John McKown 
wrote:

> On Mon, Dec 11, 2017 at 12:28 PM, David Mingee 
> wrote:
>
> > You might consider using the MODE C command in FTP vs. AMTERSE/UNTERSE
> > utility.  It will run much faster and save CPU time.
> >
>
> Does that work with data sets which are RECFM=U which are stored on a
> non-z/OS system (in my case - Linux).
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread John McKown

On Mon, Dec 11, 2017 at 12:28 PM, David Mingee  wrote:

> You might consider using the MODE C command in FTP vs. AMTERSE/UNTERSE
> utility.  It will run much faster and save CPU time.
>

Does that work with data sets which are RECFM=U which are stored on a
non-z/OS system (in my case - Linux).

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread David Mingee

You might consider using the MODE C command in FTP vs. AMTERSE/UNTERSE utility. 
 It will run much faster and save CPU time.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, December 11, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN

On 12/11/2017 9:51 AM, PINION, RICHARD W. wrote:
> Is there a way to make TRSMAIN use hardware compression, PCIE hardware 
> compression?

No. AMATERSE uses it's own compression.
Sounds like a good SHARE requirement tho...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2017-12-11 Thread Ed Jaffe


On 12/11/2017 9:51 AM, PINION, RICHARD W. wrote:

Is there a way to make TRSMAIN use hardware compression, PCIE hardware 
compression?


No. AMATERSE uses it's own compression.
Sounds like a good SHARE requirement tho...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

TRSMAIN

2017-12-11 Thread PINION, RICHARD W.

Is there a way to make TRSMAIN use hardware compression, PCIE hardware 
compression?
FIRST TENNESSEE

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN - Influencing the temporary dataset allocation

2013-12-13 Thread Alan Field

I have this note from 2009 (I don't know if it is still relevant).

An unsupported undocumented option for the current TRSMAIN is adding the 
TMPSPACE DD. This usually will let you terse PDSE or other things that 
mess up it's calculations for work space like a large RECFM VB PDS. 
 
   //TMPSPACE  DD   UNIT=SYSDA,SPACE=(CYL,(4369,1),RLSE) 


Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826





From:   Jake anderson justmainfra...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/13/2013 04:57
Subject:TRSMAIN - Influencing the temporary dataset allocation
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Hello,

I am performing a unters for  a Rel file using TRSMAIN. Unfortunately it 
is
failing due to  insufficient allocation during temporary dataset creation.
Are there any parameter within TRSMAIN step that can influence or create a
larger Temporary dataset.

 Right now the RELFILE is sitting on Multi-vol(4 volumes), so its kind of
pretty bigger one.

Any suggestions or advise would be helpful for me to unpack the RELFILE.


Jake

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN - Influencing the temporary dataset allocation

2013-12-13 Thread Miklos Szigetvari


Hi

I'm using  the AMATERSE program with TMPSPACE DD(to allocate the temporary)

On 13.12.2013 11:56, Jake anderson wrote:

Hello,

I am performing a unters for  a Rel file using TRSMAIN. Unfortunately it is
failing due to  insufficient allocation during temporary dataset creation.
Are there any parameter within TRSMAIN step that can influence or create a
larger Temporary dataset.

  Right now the RELFILE is sitting on Multi-vol(4 volumes), so its kind of
pretty bigger one.

Any suggestions or advise would be helpful for me to unpack the RELFILE.


Jake

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Staller, Allan

Yes. However, I suggest use of AMATERSE. The supported version of TRSMAIN.

HTH,

snip
A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary 
format, to a non-z/OS server.  For whatever reason the compressed file on the 
server is incomplete.  When the compressed file is transmitted, using binary 
format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set 
is incomplete?
/snip

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Tony Harminc

On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote:
 A data set is compressed using TRSMAIN on z/OS. It is transmitted, using 
 binary format, to a non-z/OS server.  For whatever reason the compressed file 
 on the server is incomplete.  When the compressed file is transmitted, using 
 binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the 
 data set is incomplete?

Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed
data stream consists of a short header, and then 12-bit units with a
value from 1 to 4096, terminated by a unit of zeros. The header does
not contain an overall length field. (There is also a trailer, but I'm
not sure it's used for anything.) If decompression hits EOF before
seeing that ending zero unit, it should complain, though I don't know
how elegantly. So if your data is truncated, it can and should be
detected. But if you restore your damaged data into an FB dataset, the
last block may be zero padded regardless, so a silent failure seems
quite possible.

If your compressed stream is missing a chunk in the middle, it's
possible - and with anything bigger than a very small dataset, even
likely - that what remains is decodable, but after the gap it
certainly won't decode into anything much like the original.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Barry Merrill

It's an easy JCL exercise to conduct an experiment to confirm what happens:

TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was 
truncated.

I copied a 105472 byte valid tersed file into a 
DISP=(,CATLG,CATLG),SPACE=(TRK,(1)).
The original untersed to 360,480 bytes, while the truncated file untersed to 
only 48152,
and there was no message nor warning that the input file was short.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, August 21, 2013 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN

On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote:
 A data set is compressed using TRSMAIN on z/OS. It is transmitted, using 
 binary format, to a non-z/OS server.  For whatever reason the compressed file 
 on the server is incomplete.  When the compressed file is transmitted, using 
 binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the 
 data set is incomplete?

Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data 
stream consists of a short header, and then 12-bit units with a value from 1 to 
4096, terminated by a unit of zeros. The header does not contain an overall 
length field. (There is also a trailer, but I'm not sure it's used for 
anything.) If decompression hits EOF before seeing that ending zero unit, it 
should complain, though I don't know how elegantly. So if your data is 
truncated, it can and should be detected. But if you restore your damaged data 
into an FB dataset, the last block may be zero padded regardless, so a silent 
failure seems quite possible.

If your compressed stream is missing a chunk in the middle, it's possible - and 
with anything bigger than a very small dataset, even likely - that what remains 
is decodable, but after the gap it certainly won't decode into anything much 
like the original.


Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Tony Harminc

On 21 August 2013 20:39, Barry Merrill ba...@mxg.com wrote:

 It's an easy JCL exercise to conduct an experiment to confirm what happens:

 TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was 
 truncated.

 I copied a 105472 byte valid tersed file into a 
 DISP=(,CATLG,CATLG),SPACE=(TRK,(1)).
 The original untersed to 360,480 bytes, while the truncated file untersed to 
 only 48152,
 and there was no message nor warning that the input file was short.

Can you look at the last record in the truncated tersed dataset and
see if it's zero-padded? Strictly one should look for a 12-bit zero,
but a run of three of the 8-bit kind we're more used to would more
than do the trick.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Barry Merrill

How could it?  
GENER did the truncation, AMATERSE was not involved,
so the last bytes are whatever the last bytes were.
The file just ended with one track filled and B37
for the GENER.  But I did look and there are no 00
bytes in the last 20 or so bytes of the last 1024
byte record that had been created by AMATERSE.

Then AMATERSE just decompressed the bytes that were there
in that one track.


Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, August 21, 2013 7:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN

On 21 August 2013 20:39, Barry Merrill ba...@mxg.com wrote:

 It's an easy JCL exercise to conduct an experiment to confirm what happens:

 TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was 
 truncated.

 I copied a 105472 byte valid tersed file into a 
 DISP=(,CATLG,CATLG),SPACE=(TRK,(1)).
 The original untersed to 360,480 bytes, while the truncated file 
 untersed to only 48152, and there was no message nor warning that the input 
 file was short.

Can you look at the last record in the truncated tersed dataset and see if it's 
zero-padded? Strictly one should look for a 12-bit zero, but a run of three of 
the 8-bit kind we're more used to would more than do the trick.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Richard Pinion

I tried your suggestion and had the same results as you described Mr. Merrill.

--- ba...@mxg.com wrote:

From: Barry Merrill ba...@mxg.com
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN
Date: Wed, 21 Aug 2013 19:39:31 -0500

It's an easy JCL exercise to conduct an experiment to confirm what happens:

TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was 
truncated.

I copied a 105472 byte valid tersed file into a 
DISP=(,CATLG,CATLG),SPACE=(TRK,(1)).
The original untersed to 360,480 bytes, while the truncated file untersed to 
only 48152,
and there was no message nor warning that the input file was short.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, August 21, 2013 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TRSMAIN

On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote:
 A data set is compressed using TRSMAIN on z/OS. It is transmitted, using 
 binary format, to a non-z/OS server.  For whatever reason the compressed file 
 on the server is incomplete.  When the compressed file is transmitted, using 
 binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the 
 data set is incomplete?

Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data 
stream consists of a short header, and then 12-bit units with a value from 1 to 
4096, terminated by a unit of zeros. The header does not contain an overall 
length field. (There is also a trailer, but I'm not sure it's used for 
anything.) If decompression hits EOF before seeing that ending zero unit, it 
should complain, though I don't know how elegantly. So if your data is 
truncated, it can and should be detected. But if you restore your damaged data 
into an FB dataset, the last block may be zero padded regardless, so a silent 
failure seems quite possible.

If your compressed stream is missing a chunk in the middle, it's possible - and 
with anything bigger than a very small dataset, even likely - that what remains 
is decodable, but after the gap it certainly won't decode into anything much 
like the original.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN

2013-08-21 Thread Paul Gilmartin

On Wed, 21 Aug 2013 19:39:31 -0500, Barry Merrill wrote:

It's an easy JCL exercise to conduct an experiment to confirm what happens:

TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was 
truncated.
 
Checksum is your friend.  Here's how to generate one using standard z/OS 
utilities:

user@MVS:130$ cp //'sys1.maclib(splevel)' /dev/fd/1 | cksum
317904754 29808

cksum is a POSIX utility, so the checksum can be verified on any
other UNIXy system; perhaps even on Windows with Cygwin,
available at a very attractive price.

I copied a 105472 byte valid tersed file into a 
DISP=(,CATLG,CATLG),SPACE=(TRK,(1)).
The original untersed to 360,480 bytes, while the truncated file untersed to 
only 48152,
and there was no message nor warning that the input file was short.

I am dismayed to find among IBM VM download instructions at:

http://www.vm.ibm.com/download/

the suggestion:

PIPE  fn VMARC A | fblock 80 00 |  fn VMARC A F 80

where the 00 means pad any short record with nulls.  I
have repeatedly railed against this: the null padding is less
likely to repair a transmission error than to conceal it, to be
encountered later in the proces, at greater expense.

I'm routinely outvoted with the specious argument that in
those cases where the truncated characters were nulls or
irrelevant the process will (seem to) work and the programer
is spared the effort of diagnosing and repairing the process
flaw and re-transmitting.  I'm unsympathetic.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

TRSMAIN or AMATERSE on z/VSE

2013-05-22 Thread Richard Pinion

I've searched using Google but haven't come up with a definitive answer.  Is 
there an AMATERSE/TRSMAIN compatible utility on the z/VSE operating system?



_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN or AMATERSE on z/VSE

2013-05-22 Thread Bill Godfrey

On Wed, 22 May 2013 08:00:45 -0700, Richard Pinion wrote:

I've searched using Google but haven't come up with a definitive answer.  Is 
there an AMATERSE/TRSMAIN compatible utility on the z/VSE operating system?

There was a TERSE program for VSE/ESA. I don't know about z/VSE.

If you go to the link below and search for terse, there will be some hits about 
TERSE for VSE/ESA.

https://groups.google.com/forum/?fromgroups#!forum/bit.listserv.vse-l

Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TRSMAIN or AMATERSE on z/VSE

2013-05-22 Thread Chuck Arney

Check out SC33-8336 System Utilities Chapter 10.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iesste60/3.5?ACTION=MATCHESREQUEST=terseTYPE=FUZZYSHELF=IESVSE91DT=20100706131149CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANKScrollTOP=FIRSTHIT#FIRSTHIT

Chuck Arney
Arney Computer Systems

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Pinion
Sent: Wednesday, May 22, 2013 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TRSMAIN or AMATERSE on z/VSE

I've searched using Google but haven't come up with a definitive answer.  Is 
there an AMATERSE/TRSMAIN compatible utility on the z/VSE operating system?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-20 Thread ibmmain

 Consider though that AMATERSE uses SYSUT1/SYSUT2, not INFILE/OUTFILE which is 
 used with TRSMAIN.
Except when you call AMATERSE (from sys1.linklib) as TRSMAIN, the expected 
input/output DD is INFILE/OUTFILE. Just so customers don't have to change their 
JCL. One should have removed all steplib references to the old, not supported 
trsmain.

See '7.1 Planning for AMATERSE' in ToolsService Aids.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-20 Thread R.S.

Oh really?
How do you know?

Over the years TRSMAIN was somehow obtained from IBM (later: downloaded)
and installed in some sysprog library. The library is called via STEPLIB
or can reside on top of LNKLST for other reasons.

Result: an old version is still called.
How many shops do have such setup? I don't know, but I know mainframe
people tend to be really conservative.

Last, but not least: I just ask the question. ;-)
--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-12-20 02:12, Roger Bolan pisze:

I think on almost all systems nowadays TRSMAIN is just an alias for
AMATERSE.

On Tue, Dec 18, 2012 at 12:42 PM, R.S. r.skoru...@snip.com.plwrote:

W dniu 2012-12-18 18:51, Binyamin Dissen pisze:

Wild guess: Customer used AMATERSE and yo are using TRSMAIN.

AFAIK AMATERSE support more data formats than TRSMAIN. Can it be the issue?

--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-20 Thread R.S.

W dniu 2012-12-20 08:57, Martin Packer pisze:

Certainly when I get data from customers they might've used either TRSMAIN
or AMATERSE and it still unpacks fine with either. This is something I do
on a regular and frequent basis.

I thnk there is some misunderstood here.
AMATERSE is backward compatible, but old TRSMAIN is not forward
compatible. So, you can pack data with TRSMAIN and unpack with AMATERSE.
However the opposite is not always feasible (although usually it is).

Is it the reason for OP problems? I've no idea.
--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-20 Thread Shmuel Metz (Seymour J.)

In 50d2c87a.2090...@bremultibank.com.pl, on 12/20/2012
   at 09:12 AM, R.S. r.skoru...@bremultibank.com.pl said:

I thnk there is some misunderstood here.

Yes; pay closer attention.

AMATERSE is backward compatible, but old TRSMAIN is not forward 
compatible.

There is a difference between using TRSMAIN and using an old version
of TRSMAIN. The current version of TRSMAIN is AMATERSE.

So, you can pack data with TRSMAIN and unpack with AMATERSE. 
However the opposite is not always feasible (although usually it
is).

Did you deliberately leave out the word old? It is always feasible
to use the name AMATERSE to pack and TRSMAIN to unpack; it is not
always feasible to use an old version of TRSMAIN to unpack.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-20 Thread Paul Gilmartin

On Dec 20, 2012, at 01:12, R.S. wrote:
 
 I thnk there is some misunderstood here.
 AMATERSE is backward compatible, but old TRSMAIN is not forward compatible. 
 So, you can pack data with TRSMAIN and unpack with AMATERSE. However the 
 opposite is not always feasible (although usually it is).
 
 Is it the reason for OP problems? I've no idea.
  
So much speculation, yet no one has attempted the merest
confirmation that the data on the receiving end are the
same as on the sending end.  And a gross inconsistency
in data set sizes provokes a strong suspicion that they
are not.  (But it might just be overallocation.)

Again:

   cp -B //'censored.trs' /dev/fd/1 | wc

   cp -B //'censored.trs' /dev/fd/1 | cksum

Or, use similar, probably better, ICSF functions.  IBM
computers don't make mistakes; the Net does.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-19 Thread Robert Prins

The emulator may also be to blame, Tom Brennan's Vista TN3270 has an
option to remove the obsolete EOF (x'1A') from text files upon
z/OS-to-PC IND$FILE, but the initial version containing this option
would also remove the same character (for binary files!) if it
occurred as the last character of a z/OS record in the middle of a
file, which would (for me) cause PCTERSE to loop, writing out files
that on one occasion (I'd been making coffee) reached several tens of
gigabytes.

The bug has long been fixed (at Tom's usual break-neck speed), and I'm
not even sure if it's the stable version, but if the client used a
test version, it's not impossible that this might be the cause.

Robert
-- 
Robert AH Prins
robert(a)prino(d)org


On 2012-12-18 19:57, Scott Ford wrote: Roger,

 IND$FILE also has upload issues , include file location and location unless 
 its per allocated

 Scott ford
 www.identityforge.com

 Tell me and I'll forget; show me and I may remember; involve me and I'll 
 understand. - Chinese Proverb


 On Dec 18, 2012, at 2:11 PM, Roger Bolan rogerbo...@gmail.com wrote:

 Uploading (from workstation to MVS data set) is a step where unintentional
 changes can easily happen.   Using either FTP or a terminal emulator like
 Personal Communications, you may have to send SITE commands or set values
 to control the allocation, both size and DCB attributes) of the  host data
 set on the receiving end of the upload.   When I have clients send MVS data
 sets to me, I typically have them terse it first, then do BINARY
 downloads/uploads and make sure the final target sequential data set didn't
 end with 16 extents.  For binary FTP upload  of tersed data I specify the
 space and DCB.  For example:
 SITE recfm=fb lrecl=1024 cylinders primary=100 secondary=10 blksize=0
 for the tersed data set.  Then I use JCL for the AMATERSE UNPACK step which
 pre-allocates a large output data set and releases the extra space.

 --Roger



 On Tue, Dec 18, 2012 at 11:31 AM, Binyamin Dissen 
 bdis...@dissensoftware.com wrote:

 Yes, I uploaded it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-19 Thread Paul Gilmartin

On Wed, 19 Dec 2012 20:59:49 +, Robert Prins wrote:

The emulator may also be to blame, ...

If you have access to both the originating and receiving systems,
you may learn a lot by executing both the following commands on each:

cp -B //'censored.trs' /dev/fd/1 | wc

cp -B //'censored.trs' /dev/fd/1 | cksum

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-19 Thread Roger Bolan

I think on almost all systems nowadays TRSMAIN is just an alias for
AMATERSE.


On Tue, Dec 18, 2012 at 12:42 PM, R.S. r.skoru...@bremultibank.com.plwrote:

 W dniu 2012-12-18 18:51, Binyamin Dissen pisze:


  Wild guess: Customer used AMATERSE and yo are using TRSMAIN.
 AFAIK AMATERSE support more data formats than TRSMAIN. Can it be the issue?





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-19 Thread Scott Barry

On Wed, 19 Dec 2012 18:12:37 -0700, Roger Bolan rogerbo...@gmail.com wrote:

I think on almost all systems nowadays TRSMAIN is just an alias for
AMATERSE.


On Tue, Dec 18, 2012 at 12:42 PM, R.S. r.skoru...@bremultibank.com.plwrote:

 W dniu 2012-12-18 18:51, Binyamin Dissen pisze:


  Wild guess: Customer used AMATERSE and yo are using TRSMAIN.
 AFAIK AMATERSE support more data formats than TRSMAIN. Can it be the issue?





Consider though that AMATERSE uses SYSUT1/SYSUT2, not INFILE/OUTFILE which is 
used with TRSMAIN.

Scott Barry
SBBWorks, Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-19 Thread Martin Packer

Certainly when I get data from customers they might've used either TRSMAIN 
or AMATERSE and it still unpacks fine with either. This is something I do 
on a regular and frequent basis.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Roger Bolan rogerbo...@gmail.com
To: IBM-MAIN@listserv.ua.edu, 
Date:   12/20/2012 01:12 AM
Subject:Re: Why would TRSMAIN end with RC=0 but not unpack the 
data?
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu



I think on almost all systems nowadays TRSMAIN is just an alias for
AMATERSE.


On Tue, Dec 18, 2012 at 12:42 PM, R.S. 
r.skoru...@bremultibank.com.plwrote:

 W dniu 2012-12-18 18:51, Binyamin Dissen pisze:


  Wild guess: Customer used AMATERSE and yo are using TRSMAIN.
 AFAIK AMATERSE support more data formats than TRSMAIN. Can it be the 
issue?





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Binyamin Dissen

I am only getting part of the first record of the dump

DR2 H ..Á.@IEAVTSDT
CDF4C40056F7CCCEEECEC
4920800005FC200095153243A

The TRS file is 200 cylinders

Output is

** AMA572I STARTING TERSE DECODE   UNPACK   01:28:13  12/19/2012    
** AMA527I  INPUT  - DDNAME : INFILE   DSNAME: censored.trs  
** AMA528I  OUTPUT - DDNAME : OUTFILE  DSNAME: censored.dump 
** AMA555I  THE VALUES ARE:  BLKSIZE= 24960   LRECL=4160PACKTYPE=PACK
RECFM=FIXED
** AMA573I TERSE COMPLETE DECODE   UNPACK   01:28:13  12/19/2012    
** AMA504I  RETURN CODE: 0  

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Roger Bolan

Could the original data set have been truncated before it was tersed?   Can
you verify that the original data set was okay before tersing, and that the
PACK step also got return code 0?



On Tue, Dec 18, 2012 at 10:51 AM, Binyamin Dissen 
bdis...@dissensoftware.com wrote:

 I am only getting part of the first record of the dump

 DR2 H ..Á.@IEAVTSDT
 CDF4C40056F7CCCEEECEC
 4920800005FC200095153243A

 The TRS file is 200 cylinders

 Output is

 ** AMA572I STARTING TERSE DECODE   UNPACK   01:28:13  12/19/2012 
 ** AMA527I  INPUT  - DDNAME : INFILE   DSNAME: censored.trs
 ** AMA528I  OUTPUT - DDNAME : OUTFILE  DSNAME: censored.dump
 ** AMA555I  THE VALUES ARE:  BLKSIZE= 24960   LRECL=4160PACKTYPE=PACK
RECFM=FIXED
 ** AMA573I TERSE COMPLETE DECODE   UNPACK   01:28:13  12/19/2012 
 ** AMA504I  RETURN CODE: 0

 --
 Binyamin Dissen bdis...@dissensoftware.com
 http://www.dissensoftware.com

 Director, Dissen Software, Bar  Grill - Israel


 Should you use the mailblocks package and expect a response from me,
 you should preauthorize the dissensoftware.com domain.

 I very rarely bother responding to challenge/response systems,
 especially those from irresponsible companies.

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Miklos Szigetvari


Hi

I'm using AMATERSE:
** AMA572I STARTING TERSE DECODE   UNPACK   18:58:22 12/18/2012 
** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: 
SYS12353.T185739.RA000.ESAT.TEMPTRS.H01

** AMA528I  OUTPUT - DDNAME : SYSUT2   DSNAME: ESA.X.UNTERSED
** AMA555I  THE VALUES ARE:  BLKSIZE= 27930   LRECL=133 PACKTYPE=PACK
RECFM=FIXED
** AMA583I  INPUT DATASET SIZE IN BYTES: 3355648 OUTPUT DATASET SIZE IN 
BYTES: 29072603

** AMA573I TERSE COMPLETE DECODE   UNPACK   18:58:28 12/18/2012 
** AMA504I  RETURN CODE: 0

- I don't know if TRSMAIN has also AMA583I message
- I'm wondering about the datasetnames , is this HFS ?
- Is the input really 200 cyl (if you browse, it is so big? )

On 18.12.2012 18:51, Binyamin Dissen wrote:

I am only getting part of the first record of the dump

DR2 H ..Á.@IEAVTSDT
CDF4C40056F7CCCEEECEC
4920800005FC200095153243A

The TRS file is 200 cylinders

Output is

** AMA572I STARTING TERSE DECODE   UNPACK   01:28:13  12/19/2012 
** AMA527I  INPUT  - DDNAME : INFILE   DSNAME: censored.trs
** AMA528I  OUTPUT - DDNAME : OUTFILE  DSNAME: censored.dump
** AMA555I  THE VALUES ARE:  BLKSIZE= 24960   LRECL=4160PACKTYPE=PACK
RECFM=FIXED
** AMA573I TERSE COMPLETE DECODE   UNPACK   01:28:13  12/19/2012 
** AMA504I  RETURN CODE: 0

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Binyamin Dissen

I don't know. The customer is home now.

On Tue, 18 Dec 2012 11:06:54 -0700 Roger Bolan rogerbo...@gmail.com wrote:

:Could the original data set have been truncated before it was tersed?   Can
:you verify that the original data set was okay before tersing, and that the
:PACK step also got return code 0?
:
:
:
:On Tue, Dec 18, 2012 at 10:51 AM, Binyamin Dissen 
:bdis...@dissensoftware.com wrote:
:
: I am only getting part of the first record of the dump
:
: DR2 H ..Á.@IEAVTSDT
: CDF4C40056F7CCCEEECEC
: 4920800005FC200095153243A
:
: The TRS file is 200 cylinders
:
: Output is
:
: ** AMA572I STARTING TERSE DECODE   UNPACK   01:28:13  12/19/2012 
: ** AMA527I  INPUT  - DDNAME : INFILE   DSNAME: censored.trs
: ** AMA528I  OUTPUT - DDNAME : OUTFILE  DSNAME: censored.dump
: ** AMA555I  THE VALUES ARE:  BLKSIZE= 24960   LRECL=4160PACKTYPE=PACK
:RECFM=FIXED
: ** AMA573I TERSE COMPLETE DECODE   UNPACK   01:28:13  12/19/2012 
: ** AMA504I  RETURN CODE: 0

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Binyamin Dissen

On Tue, 18 Dec 2012 19:08:09 +0100 Miklos Szigetvari
miklos.szigetv...@isis-papyrus.com wrote:

: Hi
:
:I'm using AMATERSE:
:** AMA572I STARTING TERSE DECODE   UNPACK   18:58:22 12/18/2012 
:** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: 
:SYS12353.T185739.RA000.ESAT.TEMPTRS.H01
:** AMA528I  OUTPUT - DDNAME : SYSUT2   DSNAME: ESA.X.UNTERSED
:** AMA555I  THE VALUES ARE:  BLKSIZE= 27930   LRECL=133 PACKTYPE=PACK
:RECFM=FIXED
:** AMA583I  INPUT DATASET SIZE IN BYTES: 3355648 OUTPUT DATASET SIZE IN 
:BYTES: 29072603
:** AMA573I TERSE COMPLETE DECODE   UNPACK   18:58:28 12/18/2012 
:** AMA504I  RETURN CODE: 0
:
:- I don't know if TRSMAIN has also AMA583I message
:- I'm wondering about the datasetnames , is this HFS ?

No, I just removed the dsnames as they are sekrit

:- Is the input really 200 cyl (if you browse, it is so big? )

Yes, I uploaded it.

:On 18.12.2012 18:51, Binyamin Dissen wrote:
: I am only getting part of the first record of the dump
:
: DR2 H ..Á.@IEAVTSDT
: CDF4C40056F7CCCEEECEC
: 4920800005FC200095153243A
:
: The TRS file is 200 cylinders
:
: Output is
:
: ** AMA572I STARTING TERSE DECODE   UNPACK   01:28:13  12/19/2012 
: ** AMA527I  INPUT  - DDNAME : INFILE   DSNAME: censored.trs
: ** AMA528I  OUTPUT - DDNAME : OUTFILE  DSNAME: censored.dump
: ** AMA555I  THE VALUES ARE:  BLKSIZE= 24960   LRECL=4160PACKTYPE=PACK   
 RECFM=FIXED
: ** AMA573I TERSE COMPLETE DECODE   UNPACK   01:28:13  12/19/2012 
: ** AMA504I  RETURN CODE: 0
:
: --
: Binyamin Dissen bdis...@dissensoftware.com
: http://www.dissensoftware.com
:
: Director, Dissen Software, Bar  Grill - Israel
:
:
: Should you use the mailblocks package and expect a response from me,
: you should preauthorize the dissensoftware.com domain.
:
: I very rarely bother responding to challenge/response systems,
: especially those from irresponsible companies.
:
: --
: For IBM-MAIN subscribe / signoff / archive access instructions,
: send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
:
:
:
:--
:For IBM-MAIN subscribe / signoff / archive access instructions,
:send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Roger Bolan

Uploading (from workstation to MVS data set) is a step where unintentional
changes can easily happen.   Using either FTP or a terminal emulator like
Personal Communications, you may have to send SITE commands or set values
to control the allocation, both size and DCB attributes) of the  host data
set on the receiving end of the upload.   When I have clients send MVS data
sets to me, I typically have them terse it first, then do BINARY
downloads/uploads and make sure the final target sequential data set didn't
end with 16 extents.  For binary FTP upload  of tersed data I specify the
space and DCB.  For example:
SITE recfm=fb lrecl=1024 cylinders primary=100 secondary=10 blksize=0
for the tersed data set.  Then I use JCL for the AMATERSE UNPACK step which
pre-allocates a large output data set and releases the extra space.

--Roger



On Tue, Dec 18, 2012 at 11:31 AM, Binyamin Dissen 
bdis...@dissensoftware.com wrote:

 Yes, I uploaded it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Paul Gilmartin

On Tue, 18 Dec 2012 20:31:58 +0200, Binyamin Dissen  wrote:

On Tue, 18 Dec 2012 19:08:09 +0100 Miklos Szigetvari wrote:

:** AMA583I  INPUT DATASET SIZE IN BYTES: 3355648 OUTPUT DATASET SIZE IN
:BYTES: 29072603
:** AMA573I TERSE COMPLETE DECODE   UNPACK   18:58:28 12/18/2012 
:** AMA504I  RETURN CODE: 0

:- Is the input really 200 cyl (if you browse, it is so big? )

Yes, I uploaded it.
 
3355648 bytes / 200 cylinders gives me 16779 bytes/cylinder.  What kind
of device is this?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread R.S.

W dniu 2012-12-18 18:51, Binyamin Dissen pisze:

I am only getting part of the first record of the dump

DR2 H ..Á.@IEAVTSDT
CDF4C40056F7CCCEEECEC
4920800005FC200095153243A

The TRS file is 200 cylinders

Output is

** AMA572I STARTING TERSE DECODE UNPACK 01:28:13 12/19/2012
** AMA527I INPUT - DDNAME : INFILE DSNAME: censored.trs
** AMA528I OUTPUT - DDNAME : OUTFILE DSNAME: censored.dump
** AMA555I THE VALUES ARE: BLKSIZE= 24960 LRECL=4160PACKTYPE=PACK
RECFM=FIXED
** AMA573I TERSE COMPLETE DECODE UNPACK 01:28:13 12/19/2012
** AMA504I RETURN CODE: 0

Wild guess: Customer used AMATERSE and yo are using TRSMAIN.
AFAIK AMATERSE support more data formats than TRSMAIN. Can it be the issue?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would TRSMAIN end with RC=0 but not unpack the data?

2012-12-18 Thread Scott Ford

Roger,

IND$FILE also has upload issues , include file location and location unless its 
per allocated

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Dec 18, 2012, at 2:11 PM, Roger Bolan rogerbo...@gmail.com wrote:

 Uploading (from workstation to MVS data set) is a step where unintentional
 changes can easily happen.   Using either FTP or a terminal emulator like
 Personal Communications, you may have to send SITE commands or set values
 to control the allocation, both size and DCB attributes) of the  host data
 set on the receiving end of the upload.   When I have clients send MVS data
 sets to me, I typically have them terse it first, then do BINARY
 downloads/uploads and make sure the final target sequential data set didn't
 end with 16 extents.  For binary FTP upload  of tersed data I specify the
 space and DCB.  For example:
 SITE recfm=fb lrecl=1024 cylinders primary=100 secondary=10 blksize=0
 for the tersed data set.  Then I use JCL for the AMATERSE UNPACK step which
 pre-allocates a large output data set and releases the extra space.
 
 --Roger
 
 
 
 On Tue, Dec 18, 2012 at 11:31 AM, Binyamin Dissen 
 bdis...@dissensoftware.com wrote:
 
 Yes, I uploaded it.
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

52 matches

Mail list logo