Re: Rexx Idiom (was: FTP of EBCDIC file)

[Scott Ford]

Darth:


Personally, I believe everyone has their own techniques  in writing computer 
code. Where you cloned someone’s code and made changes or created it or read 
manuals and did one of the above. 






Sent from Windows Mail





From: Darth Keller
Sent: ‎Wednesday‎, ‎September‎ ‎10‎, ‎2014 ‎12‎:‎19‎ ‎PM
To: IBM Mainframe Discussion List





-->  he *cannot* write good REXX.

So what is "good" REXX?   Or did we mean 'he cannot write REXX well'? 
Isn't the point of the statement to describe how he writes?  Or is it to 
discuss what constitutes 'good' REXX?

Even those of us whose native language is English have problems with it 
and I freely admit I are one of those.

ddk






**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof. 
Thank you.

--
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: Rexx Idiom (was: FTP of EBCDIC file)

[Darth Keller]

-->  he *cannot* write good REXX.

So what is "good" REXX?   Or did we mean 'he cannot write REXX well'? 
Isn't the point of the statement to describe how he writes?  Or is it to 
discuss what constitutes 'good' REXX?

Even those of us whose native language is English have problems with it 
and I freely admit I are one of those.

ddk






**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof. 
Thank you.

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

Re: Rexx Idiom (was: FTP of EBCDIC file)

[Tony Harminc]

On 10 September 2014 10:30, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> One can speak German in English:  "I have been writing Rexx since ten years."

Or French, and probably Spanish:  "I am writing Rexx since ten years."

And another French giveaway: "It's not because he knows FORTRAN that
he can write good REXX."  Which doesn't sound like bad English until
you realize that it's intended to mean that he *cannot* write good
REXX.

Tony H.

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

Re: FTP of EBCDIC file

[Shmuel Metz (Seymour J.)]

In <2490004486696175.wa.paulgboulderaim@listserv.ua.edu>, on
09/09/2014
   at 03:08 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>True.  But utilities invoked under such environments are free to 
>use the interfaces provided by Rexx.  Does ISPEXEC count as 
>"such ... as TSO"?

I would have to say no, because in general commands in the ISPEXEC
environment expect variable names in parentheses rather than the
contents of those variable.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Rexx Idiom (was: FTP of EBCDIC file)

[Steve Comstock]

On 9/10/2014 8:30 AM, Paul Gilmartin wrote:

On Wed, 10 Sep 2014 08:26:53 -0400, Hobart Spitz wrote:


How about something like:

/* REXX */
"pipe < input.dsn | split after str x0D25 | joincont not trailing x0D25 | >
output.dsn"
exit RC


Looks like Batchpipes.  How prevalent is BatchPipes?


On Wed, Sep 10, 2014 at 3:07 AM, Martin Packer wrote:


Not knowing who the authors were, is it possible they were explaining REXX
to (what they thought to be) a CLIST-literate audience? TSO/E 2.1 would've
  been a shock to some. :-)


I suggested as much, perhaps sarcastically.  But it's a flawed pedagogic
practice.  Whether in a natural language or in a computer language, a
student becomes fluent by immersion, learning to think in the target
language, not by composing in a previously known language and
translating to the target language.

"One can write FORTRAN in any language."  Symptoms include:
o not exploiting compound symbols as associative arrays
o not using boolean values as first class data objects
o misuse of SIGNAL as if it were GOTO.

One can speak German in English:  "I have been writing Rexx
since ten years."

One can speak Hindi in English: "Please answer my doubt about
Rexx syntax."


Aww geez! Now I got coffee everywhere.

-Steve Comstock




-- gil

--
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: Rexx Idiom (was: FTP of EBCDIC file)

[Nims,Alva John (Al)]

I wish it was move prevalent than it is, I do not have it at my current JOB, 
but when I worked as a contractor to IBM in one of their GDF's, I used it quite 
HEAVILY to accomplish some very complicated tasks.  I did not use every "Stage" 
from BatchPipes, but I managed to use several.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, September 10, 2014 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx Idiom (was: FTP of EBCDIC file)

On Wed, 10 Sep 2014 08:26:53 -0400, Hobart Spitz wrote:

>How about something like:
>
>/* REXX */
>"pipe < input.dsn | split after str x0D25 | joincont not trailing x0D25 
>| > output.dsn"
>exit RC
>
Looks like Batchpipes.  How prevalent is BatchPipes?

>On Wed, Sep 10, 2014 at 3:07 AM, Martin Packer wrote:
>
>> Not knowing who the authors were, is it possible they were explaining 
>> REXX to (what they thought to be) a CLIST-literate audience? TSO/E 
>> 2.1 would've  been a shock to some. :-)
>>
I suggested as much, perhaps sarcastically.  But it's a flawed pedagogic 
practice.  Whether in a natural language or in a computer language, a student 
becomes fluent by immersion, learning to think in the target language, not by 
composing in a previously known language and translating to the target language.

"One can write FORTRAN in any language."  Symptoms include:
o not exploiting compound symbols as associative arrays o not using boolean 
values as first class data objects o misuse of SIGNAL as if it were GOTO.

One can speak German in English:  "I have been writing Rexx since ten years."

One can speak Hindi in English: "Please answer my doubt about Rexx syntax."

-- gil

--
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

Rexx Idiom (was: FTP of EBCDIC file)

[Paul Gilmartin]

On Wed, 10 Sep 2014 08:26:53 -0400, Hobart Spitz wrote:

>How about something like:
>
>/* REXX */
>"pipe < input.dsn | split after str x0D25 | joincont not trailing x0D25 | >
>output.dsn"
>exit RC
>
Looks like Batchpipes.  How prevalent is BatchPipes?

>On Wed, Sep 10, 2014 at 3:07 AM, Martin Packer wrote:
>
>> Not knowing who the authors were, is it possible they were explaining REXX
>> to (what they thought to be) a CLIST-literate audience? TSO/E 2.1 would've
>>  been a shock to some. :-)
>>
I suggested as much, perhaps sarcastically.  But it's a flawed pedagogic
practice.  Whether in a natural language or in a computer language, a
student becomes fluent by immersion, learning to think in the target
language, not by composing in a previously known language and
translating to the target language.

"One can write FORTRAN in any language."  Symptoms include:
o not exploiting compound symbols as associative arrays
o not using boolean values as first class data objects
o misuse of SIGNAL as if it were GOTO.

One can speak German in English:  "I have been writing Rexx
since ten years."

One can speak Hindi in English: "Please answer my doubt about
Rexx syntax."

-- gil

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

Re: FTP of EBCDIC file

[Hobart Spitz]

How about something like:

/* REXX */
"pipe < input.dsn | split after str x0D25 | joincont not trailing x0D25 | >
output.dsn"
exit RC

The SPLIT here restores the intended record breaks.  The JOINCONT brings
together record parts that were separated by unintended record breaks and
discards the x'0D25'.

On Wed, Sep 10, 2014 at 3:07 AM, Martin Packer 
wrote:

> Not knowing who the authors were, is it possible they were explaining REXX
> to (what they thought to be) a CLIST-literate audience? TSO/E 2.1 would've
>  been a shock to some. :-)
>
> 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:   Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   09/09/2014 21:09
> Subject:Re: FTP of EBCDIC file
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Tue, 9 Sep 2014 10:54:34 -0400, Shmuel Metz (Seymour J.) wrote:
>
> >on 09/08/2014
> >   at 02:23 PM, Paul Gilmartin said:
> >
> >>Remember that a host command argument is always a single string.
> > ]
> >Don't confuse a REXX expression with its value.
> >
> I know that well.  It appears that the authors of the TSO/E Rexx
> reference know it less well and are trying to share their bewilderment
> with their readers.  They repeatedly state as local rules what should
> be instances of global principles.  I suspect their minds have been
> rotted by excessive exposure to CLIST.
>
> >>I suspect the TMP parser might be uncomfortable with:
> >>address TSO 'EXECIO 1 DISKW' FileID '(string  ))) ((( )))'
> >
> >The TMP passes the operand to the command processor as is. The only
> >code changes needed would be in EXECIO itself.
> >
> I stand corrected.  Empirically errors are reported by EXECIO, not by the
> TMP.
>
> >>EXECIO is among very few command environments that uses the Direct
> >>rather than Symbolic interface to Rexx variables.
> >
> >First, such environments as TSO don't have any interface to REXX
> >
> True.  But utilities invoked under such environments are free to use
> the interfaces provided by Rexx.  Does ISPEXEC count as "such ...
> as TSO"?
>
> >variables. Second, the only interface to REXX variables is symbolic.
> >
> No.  Long ago the CMS Rexx reference explained the difference between
> the Direct interface and the symbolic.  Now I can find merely a vestige:
>
>
>
> http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/shvblk.htm
>
> The shared variable (request) block - SHVBLOCK
> z/OS TSO/E REXX Reference
> SA32-0972-00
>
> * Function Codes (Placed in SHVCODE):
> *
> * (Note that the symbolic name codes are lowercase)
> SHVFETCH EQU   C'F'  Copy value of variable to buffer
> SHVSTORE EQU   C'S'  Set variable from given value
> SHVDROPV EQU   C'D'  Drop variable
> SHVSYSET EQU   C's'  Symbolic name Set variable
> SHVSYFET EQU   C'f'  Symbolic name Fetch variable
> SHVSYDRO EQU   C'd'  Symbolic name Drop variable
> SHVNEXTV EQU   C'N'  Fetch "next" variable
> SHVPRIV  EQU   C'P'  Fetch private information
>
> Formerly the (uppercase) non-symbolic name codes were identified
> as "direct".  The documentation has largely evaporated; the function
> remains.  Documentation of which functions use the respective
> interfaces is sorely largely lacking.  Empiricism reigns.
>
> >In the statement
> >
> > address TSO 'EXECIO 1 DISKW' FileID
> >
> >the TSO environment does not see the name "FileID"; it sees the value
> >of the expression
> >
> > 'EXECIO 1 DISKW' FileID
> >
> Agreed.  The TSO/E reference instead makes local statments to
> the effect that quotes must be used here, but not there, failing
> to rely on the distinction between names and values.
>
> -- gil
>
> --
> 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
>



-- 
OREXXMan

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

Re: FTP of EBCDIC file

[Martin Packer]

Not knowing who the authors were, is it possible they were explaining REXX 
to (what they thought to be) a CLIST-literate audience? TSO/E 2.1 would've 
 been a shock to some. :-)

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:   Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   09/09/2014 21:09
Subject:        Re: FTP of EBCDIC file
Sent by:IBM Mainframe Discussion List 



On Tue, 9 Sep 2014 10:54:34 -0400, Shmuel Metz (Seymour J.) wrote:

>on 09/08/2014
>   at 02:23 PM, Paul Gilmartin said:
>
>>Remember that a host command argument is always a single string.
> ]
>Don't confuse a REXX expression with its value.
> 
I know that well.  It appears that the authors of the TSO/E Rexx
reference know it less well and are trying to share their bewilderment
with their readers.  They repeatedly state as local rules what should
be instances of global principles.  I suspect their minds have been
rotted by excessive exposure to CLIST.

>>I suspect the TMP parser might be uncomfortable with:
>>address TSO 'EXECIO 1 DISKW' FileID '(string  ))) ((( )))'
>
>The TMP passes the operand to the command processor as is. The only
>code changes needed would be in EXECIO itself.
> 
I stand corrected.  Empirically errors are reported by EXECIO, not by the 
TMP.

>>EXECIO is among very few command environments that uses the Direct
>>rather than Symbolic interface to Rexx variables.
>
>First, such environments as TSO don't have any interface to REXX
>
True.  But utilities invoked under such environments are free to use
the interfaces provided by Rexx.  Does ISPEXEC count as "such ...
as TSO"?

>variables. Second, the only interface to REXX variables is symbolic.
> 
No.  Long ago the CMS Rexx reference explained the difference between
the Direct interface and the symbolic.  Now I can find merely a vestige:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/shvblk.htm
 

The shared variable (request) block - SHVBLOCK
z/OS TSO/E REXX Reference
SA32-0972-00 

* Function Codes (Placed in SHVCODE):
*
* (Note that the symbolic name codes are lowercase)
SHVFETCH EQU   C'F'  Copy value of variable to buffer
SHVSTORE EQU   C'S'  Set variable from given value
SHVDROPV EQU   C'D'  Drop variable
SHVSYSET EQU   C's'  Symbolic name Set variable
SHVSYFET EQU   C'f'  Symbolic name Fetch variable
SHVSYDRO EQU   C'd'  Symbolic name Drop variable
SHVNEXTV EQU   C'N'  Fetch "next" variable
SHVPRIV  EQU   C'P'  Fetch private information

Formerly the (uppercase) non-symbolic name codes were identified
as "direct".  The documentation has largely evaporated; the function
remains.  Documentation of which functions use the respective
interfaces is sorely largely lacking.  Empiricism reigns.

>In the statement
>
> address TSO 'EXECIO 1 DISKW' FileID
>
>the TSO environment does not see the name "FileID"; it sees the value
>of the expression
>
> 'EXECIO 1 DISKW' FileID
> 
Agreed.  The TSO/E reference instead makes local statments to
the effect that quotes must be used here, but not there, failing
to rely on the distinction between names and values.

-- gil

--
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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Tue, 9 Sep 2014 15:08:57 -0500, Paul Gilmartin wrote:
>On Tue, 9 Sep 2014 10:54:34 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>>EXECIO is among very few command environments that uses the Direct
>>>rather than Symbolic interface to Rexx variables.
>>
>>... Second, the only interface to REXX variables is symbolic.
>> 
>No.  Long ago the CMS Rexx reference explained the difference between
>the Direct interface and the symbolic.  Now I can find merely a vestige:
>
I'll stand corrected again.  I found it easily enough:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/shvcode.htm
Function codes (SHVCODE)
z/OS TSO/E REXX Reference
SA32-0972-00

The function code is specified in the SHVCODE field in the SHVBLOCK.
Three function codes (S, F, and D) may be given either in lowercase or in 
uppercase:

Lowercase
(The Symbolic interface). The names must be valid REXX symbols
(in mixed case if desired), and normal REXX substitution will
occur in compound variables.

Uppercase
(The Direct interface). No substitution or case translation
takes place. Simple symbols must be valid REXX variable names
(that is, in uppercase and not starting with a digit or a
period), but in compound symbols any characters (including
lowercase, blanks, and so on) are permitted following a valid
REXX stem.

>...  Documentation of which functions use the respective
>interfaces is sorely largely lacking.  Empiricism reigns.
> 
I still believe so.  But I've already been wrong several times.

-- gil

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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Tue, 9 Sep 2014 10:54:34 -0400, Shmuel Metz (Seymour J.) wrote:

>on 09/08/2014
>   at 02:23 PM, Paul Gilmartin said:
>
>>Remember that a host command argument is always a single string.
> ]
>Don't confuse a REXX expression with its value.
> 
I know that well.  It appears that the authors of the TSO/E Rexx
reference know it less well and are trying to share their bewilderment
with their readers.  They repeatedly state as local rules what should
be instances of global principles.  I suspect their minds have been
rotted by excessive exposure to CLIST.

>>I suspect the TMP parser might be uncomfortable with:
>>address TSO 'EXECIO 1 DISKW' FileID '(string  ))) ((( )))'
>
>The TMP passes the operand to the command processor as is. The only
>code changes needed would be in EXECIO itself.
> 
I stand corrected.  Empirically errors are reported by EXECIO, not by the TMP.

>>EXECIO is among very few command environments that uses the Direct
>>rather than Symbolic interface to Rexx variables.
>
>First, such environments as TSO don't have any interface to REXX
>
True.  But utilities invoked under such environments are free to use
the interfaces provided by Rexx.  Does ISPEXEC count as "such ...
as TSO"?

>variables. Second, the only interface to REXX variables is symbolic.
> 
No.  Long ago the CMS Rexx reference explained the difference between
the Direct interface and the symbolic.  Now I can find merely a vestige:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/shvblk.htm
 
The shared variable (request) block - SHVBLOCK
z/OS TSO/E REXX Reference
SA32-0972-00 

* Function Codes (Placed in SHVCODE):
*
* (Note that the symbolic name codes are lowercase)
SHVFETCH EQU   C'F'  Copy value of variable to buffer
SHVSTORE EQU   C'S'  Set variable from given value
SHVDROPV EQU   C'D'  Drop variable
SHVSYSET EQU   C's'  Symbolic name Set variable
SHVSYFET EQU   C'f'  Symbolic name Fetch variable
SHVSYDRO EQU   C'd'  Symbolic name Drop variable
SHVNEXTV EQU   C'N'  Fetch "next" variable
SHVPRIV  EQU   C'P'  Fetch private information

Formerly the (uppercase) non-symbolic name codes were identified
as "direct".  The documentation has largely evaporated; the function
remains.  Documentation of which functions use the respective
interfaces is sorely largely lacking.  Empiricism reigns.

>In the statement
>
> address TSO 'EXECIO 1 DISKW' FileID
>
>the TSO environment does not see the name "FileID"; it sees the value
>of the expression
>
> 'EXECIO 1 DISKW' FileID
> 
Agreed.  The TSO/E reference instead makes local statments to
the effect that quotes must be used here, but not there, failing
to rely on the distinction between names and values.

-- gil

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

Re: FTP of EBCDIC file

[Shmuel Metz (Seymour J.)]

In <540e1024.6010...@aim.com>, on 09/08/2014
   at 02:23 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Remember that a host command argument is always a single string.

Don't confuse a REXX expression with its value.

>I suspect the TMP parser might be uncomfortable with:
>address TSO 'EXECIO 1 DISKW' FileID '(string  ))) ((( )))'

The TMP passes the operand to the command processor as is. The only
code changes needed would be in EXECIO itself.

>EXECIO is among very few command environments that uses the Direct
>rather than Symbolic interface to Rexx variables.


First, such environments as TSO don't have any interface to REXX
variables. Second, the only interface to REXX variables is symbolic.

In the statement

 address TSO 'EXECIO 1 DISKW' FileID

the TSO environment does not see the name "FileID"; it sees the value
of the expression

 'EXECIO 1 DISKW' FileID

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: FTP of EBCDIC file

[Barry Merrill]

If you then need to upload that "RECFM=U" file back to z/os, you would upload 
into
a z/OS file with BLKSIZE=32760 and that file's BDW and RDWs can be read and 
deblocked
to create valid V/VB/VBS files on z/OS from the RECFM=U format6
MXG provides both a SAS (UDEBLOCK) and an ASM program (ASMDBLKU) to do that 
deblocking.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, September 09, 2014 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP of EBCDIC file

On Tue, 9 Sep 2014 09:16:44 -0500, John McKown wrote:

>On Tue, Sep 9, 2014 at 9:01 AM, Barry Merrill wrote:
>> To send V/VB/VBS data from z/OS to a non-z/OS site and preserve the BDW and 
>> RDWs:
>>
>>   //FTP  EXEC PGM=FTP,PARM='(EXIT=4'
>>   //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR
>>   //INPUT DD *
>>   bin
>>   put //DD:SMFFILE  yourname.smf
>
>That is interesting. What about if you then needed to upload that file 
>back to z/OS? I was thinking you could use RECFM=U, but then realized 
>that the RECFM=U still has block boundries which would make reading the 
>file difficult. That is you could not upload as RECFM=U, then just use 
>JCL DCB=(RECFM=VBS) to read it.
> 
Yup.  I've decoded such with a Rexx program.  Particularly ugly since prior to 
z/OS 2.1 Rexx couldn't handle RECFM=U (I haven't tried 2.1).
I REPROed it from RECFM=U to RECFM=V and processed that.

An alternative might be IEBGENER to a UNIX file, then parse with Rexx.

BTW, this is the format used by GIMZIP for RELFILEs.

-- gil

--
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: FTP of EBCDIC file

[Paul Gilmartin]

On Tue, 9 Sep 2014 09:16:44 -0500, John McKown wrote:

>On Tue, Sep 9, 2014 at 9:01 AM, Barry Merrill wrote:
>> To send V/VB/VBS data from z/OS to a non-z/OS site and preserve the BDW and 
>> RDWs:
>>
>>   //FTP  EXEC PGM=FTP,PARM='(EXIT=4'
>>   //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR
>>   //INPUT DD *
>>   bin
>>   put //DD:SMFFILE  yourname.smf
>
>That is interesting. What about if you then needed to upload that file
>back to z/OS? I was thinking you could use RECFM=U, but then realized
>that the RECFM=U still has block boundries which would make reading
>the file difficult. That is you could not upload as RECFM=U, then just
>use JCL DCB=(RECFM=VBS) to read it.
> 
Yup.  I've decoded such with a Rexx program.  Particularly ugly since
prior to z/OS 2.1 Rexx couldn't handle RECFM=U (I haven't tried 2.1).
I REPROed it from RECFM=U to RECFM=V and processed that.

An alternative might be IEBGENER to a UNIX file, then parse with Rexx.

BTW, this is the format used by GIMZIP for RELFILEs.

-- gil

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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Tue, 9 Sep 2014 09:01:50 -0500, Barry Merrill wrote:

>To send V/VB/VBS data from z/OS to a non-z/OS site and preserve the BDW and 
>RDWs:
>
> A. Sending data to MXG support.
>
>i. ftp instructions for sending data to the MXG ftp site
>
>   Using the IBM ftp program, you can ftp any MVS data file to the
>   MXG ftp site with this syntax; do NOT change the DCB attributes
>   of the //SMFFILE DD: even though it points to a VBS DSNAME, the
>   RECFM=U,BLKSIZE=32760 must be used to include BDW and RDWs.
>
>  //FTP  EXEC PGM=FTP,PARM='(EXIT=4'
>  //SYSPRINT DD  SYSOUT=*
>  //OUTPUT   DD  SYSOUT=*
>  //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR
>  //INPUT DD *
>  ...
>  put //DD:SMFFILE  yourname.smf
>  ...
Now this is interesting.  It has been my experience in the past that when
I tried to supply overriding DCB parameters FTP reverted to the values
in the DSCB.  Perhaps something has changed.  And I rember something
like:

//FTPFILE  DD  FILEDATA=TEXT,RECFM=VB,LRECL=999,PATH'/some/unix/path'
//INPUT  DD  *
...
ASCII
PUT //DD:FTPFILE remote.data.set

My intent was that FILEDATA=TEXT in the DD statement would cause the
file to be broken at into records at  separators.  It didn't work.

The memory is fuzzy; I may try to reconstruct.

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Tue, Sep 9, 2014 at 9:01 AM, Barry Merrill  wrote:
> To send V/VB/VBS data from z/OS to a non-z/OS site and preserve the BDW and 
> RDWs:
>
>  A. Sending data to MXG support.
>
> i. ftp instructions for sending data to the MXG ftp site
>
>Using the IBM ftp program, you can ftp any MVS data file to the
>MXG ftp site with this syntax; do NOT change the DCB attributes
>of the //SMFFILE DD: even though it points to a VBS DSNAME, the
>RECFM=U,BLKSIZE=32760 must be used to include BDW and RDWs.
>
>   //FTP  EXEC PGM=FTP,PARM='(EXIT=4'
>   //SYSPRINT DD  SYSOUT=*
>   //OUTPUT   DD  SYSOUT=*
>   //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR
>   //INPUT DD *
>   ftp.mxg.com
>   mxgtech mxgtech
>   quote PASV
>   bin
>   put //DD:SMFFILE  yourname.smf
>   close
>   quit
>   /*
>

Dr. Merrill,

That is interesting. What about if you then needed to upload that file
back to z/OS? I was thinking you could use RECFM=U, but then realized
that the RECFM=U still has block boundries which would make reading
the file difficult. That is you could not upload as RECFM=U, then just
use JCL DCB=(RECFM=VBS) to read it.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Barry Merrill]

To send V/VB/VBS data from z/OS to a non-z/OS site and preserve the BDW and 
RDWs:



 A. Sending data to MXG support.

i. ftp instructions for sending data to the MXG ftp site

   Using the IBM ftp program, you can ftp any MVS data file to the
   MXG ftp site with this syntax; do NOT change the DCB attributes
   of the //SMFFILE DD: even though it points to a VBS DSNAME, the
   RECFM=U,BLKSIZE=32760 must be used to include BDW and RDWs.

  //FTP  EXEC PGM=FTP,PARM='(EXIT=4'
  //SYSPRINT DD  SYSOUT=*
  //OUTPUT   DD  SYSOUT=*
  //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR
  //INPUT DD *
  ftp.mxg.com
  mxgtech mxgtech
  quote PASV
  bin
  put //DD:SMFFILE  yourname.smf
  close
  quit
  /*

  IMPORTANT:  userid/password may be mixed case
  do NOT change the DCB attributes of the //SMFFILE DD.

  IMPORTANT:  Some sites MUST use the "quote PASV" argument, so it
  is the default, but for some sites it can NOT be use
  and must be removed. Try both.

  IMPORTANT:  One site found that they had to use the syntax
mxgt...@ftp.mxg.com
mxgtech
  for the first two lines.

  IMPORTANT:  The ftp control statements MUST BE UNNUMBERED.

  IMPORTANT:  If you do NOT see a message
  220 Serv-U FTP Server v11.1 ready...
  then you never connected and most likely have a
  local installation firewall issue with your network.
  
 
   Note: if your SMF data is on tape, you should use:
 RCMD='SITE RDW READTAPEFORMAT=S'


  This ftp can be used for MVS files with RECFM=U,F,FB,V,VB, or VBS,
  but for F/FB files, please email us the LRECL value of each file.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Monday, September 08, 2014 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP of EBCDIC file

So true!

I also had a hard time some time ago to explain this simple facts to some 
people who tried to send me a binary VB data set from a z/OS system by FTP 
across other (non-z/OS) systems. The information about record length etc. 
simply gets lost, because the VB file (if binary) will be transferred as a byte 
string without record structure (one large string of bytes), or otherwise, you 
will get record termination characters inserted, which is also plain wrong.

The problem is not EBCDIC; you can do a transmission without code translation 
by FTP by using "binary"; the problem is the record oriented file structure of 
the z system compared to the byte oriented paradigm of FTP (unix tool). This 
works fine, if you do FTP between two z systems, but if there are other systems 
in between, you're in a real mess.

"Fixed length" would be a solution, too; if FTP inserts record termination 
characters at some stage of the transmission, they all appear at fixed known 
offsets and can be easily removed at the target system. But: the sender will 
have to fill all records to the same maximum length ... don't know if the 
sending party is able to do this.

If variable length is really needed: generate fixed length records anyway, but 
put a logical length field in front of each record. This, too, has to be done 
by the sending party.

Kind regards

Bernd



Am 08.09.2014 16:25, schrieb John McKown:
> On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel 
>  wrote:
>> It's not my creation, it was delivered by a bank for a test. Thanks 
>> for your suggestions, but if there are no standard ftp commands I 
>> refuse to work with that file.
>> Anyway, I tested your way and it almost worked, Unfortunately there 
>> are packed fields in the records containing x'15' which are not a line end.
>>
>> Thanks,
>> Werner
>>
> If the bank is trying to send you EBCDIC information from a z/OS 
> system, but needs it to survive transfer across non-z/OS systems, then 
> the bank really needs to either use AMATERSE or TRANSMIT to put the 
> data into a more transportable format. Those both result in an FB 
> file, which can easily be binary ftp'ed from z/OS to Windows, then 
> back to z/OS and restored. Doing a normal BINary FTP of variable data 
> will just result in frustration and data corruption.
>


--
Bernd Oppolzer
—
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
—
Tel.: +49 711 7949591 (neu!)
priv.: +49 711 7949590
eMail: bernd.oppol...@t-online.de <mailto:bernd.oppol...@t-online.de>
—
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
—

Re: FTP of EBCDIC file

[John Gilmore]

Paul,

You have now raised some questions that I cannot give you full answers
to without some further experimentation.  More later but quite soon.

John Gilmore, Ashland, MA 01721 - USA

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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 22:32:36 -0400, John Gilmore wrote:

>TRTT is not in any way Unicode-dependent.  It is table-driven, does
>what it is told to do.  The only requirement is that both source and
>target character sets be DBCSs.  The TRTE (translate and Test
>Extended) instruction is also 1) Unicode-independent and 2) processes
>either SBCSs or DBCSs parametrically.   Halfword alignment is
>irrelevant in all of these cases. SBCS, DBCS, or MBCS.   (A
>character-set element must of course begin on some byte boundary, but
>this 'restriction' is not really an interesting one.)
> 
I take it you're saying that TRTT/TRTE will recognize alike the x'0D 25'
digraph in either x'C1 C2 0D 25 C3 C4' or x'C1 0D 25 C2 C3 C4', with
no shift-in...shift-out indicators, which are not to be expected in the
OP's misbegotten data?

I'm somewhat surprised.

(I purposely said "digraph" rather than "double byte character".)

-- gil

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

Re: FTP of EBCDIC file

[John Gilmore]

TRTT is not in any way Unicode-dependent.  It is table-driven, does
what it is told to do.  The only requirement is that both source and
target character sets be DBCSs.  The TRTE (translate and Test
Extended) instruction is also 1) Unicode-independent and 2) processes
either SBCSs or DBCSs parametrically.   Halfword alignment is
irrelevant in all of these cases. SBCS, DBCS, or MBCS.   (A
character-set element must of course begin on some byte boundary, but
this 'restriction' is not really an interesting one.)

John Gilmore, Ashland, MA 01721 - USA

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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Tue, 9 Sep 2014 01:49:52 +0200, Bernd Oppolzer wrote:
>
>The problem is not EBCDIC; you can do a transmission without code translation
>by FTP by using "binary"; the problem is the record oriented file structure of 
>the
>z system compared to the byte oriented paradigm of FTP (unix tool). This works 
>fine,
>
Not really.  You still lose record boundaries if RECFM=VB.

>if you do FTP between two z systems, but if there are other systems in between,
>you're in a real mess.
> 
The FTP standard provides a couple accommodations for this:

STRU R and
TYPE E; MODE B

both work, but they're generally unavailable on non-IBM systems.
Sometimes one can fool the IBM server from another client by:

BINARY  # client thinks it's doing binary transfers.
quote TYPE E
quote MODE B  # z/OS server thinks it's transmitting in block mode.

This is not directly available with a non-IBM host, but one can do it
from IBM to IBM, then transmit in BINARY to non-IBM, then decipher
by reversing the process.

-- gil

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

Re: FTP of EBCDIC file

[Bernd Oppolzer]

So true!

I also had a hard time some time ago to explain this simple facts
to some people who tried to send me a binary VB data set from a z/OS
system by FTP across other (non-z/OS) systems. The information about
record length etc. simply gets lost, because the VB file (if binary) 
will be
transferred as a byte string without record structure (one large string 
of bytes),

or otherwise, you will get record termination characters inserted, which is
also plain wrong.

The problem is not EBCDIC; you can do a transmission without code 
translation
by FTP by using "binary"; the problem is the record oriented file 
structure of the
z system compared to the byte oriented paradigm of FTP (unix tool). This 
works fine,
if you do FTP between two z systems, but if there are other systems in 
between,

you're in a real mess.

"Fixed length" would be a solution, too; if FTP inserts record 
termination characters
at some stage of the transmission, they all appear at fixed known 
offsets and can
be easily removed at the target system. But: the sender will have to 
fill all records
to the same maximum length ... don't know if the sending party is able 
to do this.


If variable length is really needed: generate fixed length records 
anyway, but put
a logical length field in front of each record. This, too, has to be 
done by the sending

party.

Kind regards

Bernd



Am 08.09.2014 16:25, schrieb John McKown:

On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel
 wrote:

It's not my creation, it was delivered by a bank for a test. Thanks for
your suggestions, but if there are no standard ftp commands I refuse to
work with that file.
Anyway, I tested your way and it almost worked, Unfortunately there are
packed fields in the records containing x'15' which are not a line end.

Thanks,
Werner


If the bank is trying to send you EBCDIC information from a z/OS
system, but needs it to survive transfer across non-z/OS systems, then
the bank really needs to either use AMATERSE or TRANSMIT to put the
data into a more transportable format. Those both result in an FB
file, which can easily be binary ftp'ed from z/OS to Windows, then
back to z/OS and restored. Doing a normal BINary FTP of variable data
will just result in frustration and data corruption.




--
Bernd Oppolzer
—
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
—
Tel.: +49 711 7949591 (neu!)
priv.: +49 711 7949590
eMail: bernd.oppol...@t-online.de 
—
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
—
7. April 1964: Ankündigung IBM S/360
2014: 50. Geburtstag der Plattform


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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 18:20:09 -0400, John Gilmore wrote:

>The TRTT instruction is available, and at the price of a [very] little
>assembly language or PL/I, but not C or REXX, x'0d15' and/or  x'0d25'
>can be dealt with directly.
> 
TRTT appears to be Unicode-dependent.  Does it then require that the
object be halfword-aligned?  This is not guaranteed for RECFM=VB.

>I have, however, concluded for myself that this discussion is not a
>seri�s one.  Others may, of course, view it differently; and even if
>they do not they are entitled to have their fun with it.
> 
Even on Monday?

-- gil

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

Re: FTP of EBCDIC file

[John Gilmore]

The TRTT instruction is available, and at the price of a [very] little
assembly language or PL/I, but not C or REXX, x'0d15' and/or  x'0d25'
can be dealt with directly.

I have, however, concluded for myself that this discussion is not a
seriös one.  Others may, of course, view it differently; and even if
they do not they are entitled to have their fun with it.

John Gilmore, Ashland, MA 01721 - USA

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

Re: FTP of EBCDIC file

[Shmuel Metz (Seymour J.)]

In <3313686178050527.wa.paulgboulderaim@listserv.ua.edu>, on
09/08/2014
   at 10:15 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>The "Windows weenies" might be motivated to prove the mainframe 
>deficient by creating a data image according to their 
>misunderstanding of z/OS access methods in order to demonstrate 
>that the result is unusable.

So there is no problem with EBCDIC, only with the windoze weenies. If
the hypothesis is correct, the NL issue is far from the only way to
sabotage you in order to claim a spurious deficiency in the mainframe.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: FTP of EBCDIC file

[Shmuel Metz (Seymour J.)]

In , on 09/08/2014
   at 08:12 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>John M's suggestion should work if the "packed" fields are
>conventional Packed Decimal, because (I believe) that neither x'0D25'
>nor x'0D15' can appear in Packed Decimal.

While neither 0D15 nor 0D25 can appear in a *single* packed decimal
field, they can appear in an adjacent pair of packed decimal fields.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08 12:26, Thomas Berg wrote:
>> -Original Message-
>> From: Paul Gilmartin
>> Sent: Monday, September 08, 2014 7:26 PM 
> 
>> CMS EXECIO provides an "EXECIO ... (VAR" as well as stem.  I wonder why
>> z/OS lacks the former.  CMS also provides "EXECIO ... (STRING", but I
>> suspect z/OS balked at the parsing considerations.
> 
> I can't see that to be a problem really (or do miss something?), they could 
> just use the standard string routines when "parsing" the input for EXECIO.  
>  
Remember that a host command argument is always a single string.
I can code:

address CMS 'EXECIO 1 DISKW' FileID '(string  ))) ((( ))) '

... in which the string written is " ))) ((( ))) "

I suspect the TMP parser might be uncomfortable with:

address TSO 'EXECIO 1 DISKW' FileID '(string  ))) ((( ))) '

> If you restrict the name of the variable to end with a numeric you have (just 
> guessing how ..(VAR works in CMS) something alike  ..(VAR:
> 
> r1 = 'foo'
> 'EXECIO 1 DISKW xxx (STEM R FINIS'  [apostrophe added -- gil]
> 
I believe you're right.  That and:
  'EXECIO 1 DISKW xxx (VAR R1 FINIS'
  'EXECIO 1 DISKW xxx (FINIS STRING' R1

... the attraction of STRING is that it may introduce an evaluated
expression (which extends to the end of the command), often eliminating
the need for an assignment or stacking:

'EXECIO 1 DISKW xxx (FINIS STRING' 2 + 2

... writes '4' to xxx.

EXECIO is among very few command environments that uses the
Direct rather than Symbolic interface to Rexx variables.

-- gil

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

Re: FTP of EBCDIC file

[Bill Godfrey]

On Mon, 8 Sep 2014 14:31:05 -0500, John McKown  
wrote:
>
>Sure that can happen. No, it is not a problem. Why? Because if the
>variable "data" ends with a x'0d', the code will NOT split it. If will
>be in the "left over" portion of data. And the line: data=data||record
>will put the contents of the _next_ record immediately _after_ any
>"left overs". Which will be what is wanted because the x'25' which
>starts the next record will then be right after the x'oD' left over at
>the end of "data". And the next go though of the DO WHILE will then
>use that to split the data. It's hard to show, but assume that ^
>stands for x'0D' and ~ stands for x'25'. Suppose the data in the file
>looks like:
>
>abc^~def^
>~ghi^~qr^b^~
>
>The code will read abc^~def^ into record. Concatenate to data, which
>is initially ''. So this results in output being abc (and written out)
>and data being def^. It reads again & concatenates. result is
>def^~ghi^qr~b , DO WHILE will split this into def and ghi^~qr~b,
>output def, then loop. 2nd time through, split is ghi and qr~b. Output
>ghi. data now qr^br^~ which has a ^~ and so loop 3rd time, output
>qr^b, leaving data ''. No ^` in data, so exit DO WHILE. continue DO
>FOREVER. EXECIO failes because of EOF, so exit DO FOREVER. execute
>second DO WHILE but nothing output because data is still ''. Hum, the
>code does have a bug. If the data in the input file does not exit with
>x'0D25', the last record will not be written.
>
Thanks for the detailed explanation with example.

Bill

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 2:01 PM, Bill Godfrey  wrote:
> On Mon, 8 Sep 2014 09:08:47 -0500, John McKown  
> wrote:
>>
>>Possible REXX program:
>>
>>/* rexx */
>>data=''
>>CRLF='0D25'X
>>do forever
>>   "execio 1 diskr sysut1"
>>   if rc <> 0 then leave
>>   parse pull record
>>   data=data||record
>>   i=pos(CRLF,data)
>>   do while i <> 0;
>>  output=left(data,i-1);
>>  queue output
>>  "execio 1 diskw sysut2"
>>  data=substr(data,i+2)
>>  i=pos(CRLF,data)
>>   end
>>end
>>i=pos(CRLF,data)
>>do while i <> 0;
>>   output=left(data,i-1);
>>   queue output
>>   "execio 1 diskw sysut2"
>>   data=substr(data,i+2)
>>   i=pos(CRLF,data)
>>end
>>"execio 0 diskr sysut1(finis"
>>"execio 0 diskw sysut2(finis"
>>
>
> You know REXX better than I do - I couldn't have written this in such a short 
> time. But is it not possible that in rare cases the original data might have 
> been split into separate records right between the '0D'X and the '25'X, in 
> which case this would produce problematic results? Just wanted to mention it.
>

Sure that can happen. No, it is not a problem. Why? Because if the
variable "data" ends with a x'0d', the code will NOT split it. If will
be in the "left over" portion of data. And the line: data=data||record
will put the contents of the _next_ record immediately _after_ any
"left overs". Which will be what is wanted because the x'25' which
starts the next record will then be right after the x'oD' left over at
the end of "data". And the next go though of the DO WHILE will then
use that to split the data. It's hard to show, but assume that ^
stands for x'0D' and ~ stands for x'25'. Suppose the data in the file
looks like:

abc^~def^
~ghi^~qr^b^~

The code will read abc^~def^ into record. Concatenate to data, which
is initially ''. So this results in output being abc (and written out)
and data being def^. It reads again & concatenates. result is
def^~ghi^qr~b , DO WHILE will split this into def and ghi^~qr~b,
output def, then loop. 2nd time through, split is ghi and qr~b. Output
ghi. data now qr^br^~ which has a ^~ and so loop 3rd time, output
qr^b, leaving data ''. No ^` in data, so exit DO WHILE. continue DO
FOREVER. EXECIO failes because of EOF, so exit DO FOREVER. execute
second DO WHILE but nothing output because data is still ''. Hum, the
code does have a bug. If the data in the input file does not exit with
x'0D25', the last record will not be written.

> Bill



-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Bill Godfrey]

On Mon, 8 Sep 2014 09:08:47 -0500, John McKown  
wrote:
>
>Possible REXX program:
>
>/* rexx */
>data=''
>CRLF='0D25'X
>do forever
>   "execio 1 diskr sysut1"
>   if rc <> 0 then leave
>   parse pull record
>   data=data||record
>   i=pos(CRLF,data)
>   do while i <> 0;
>  output=left(data,i-1);
>  queue output
>  "execio 1 diskw sysut2"
>  data=substr(data,i+2)
>  i=pos(CRLF,data)
>   end
>end
>i=pos(CRLF,data)
>do while i <> 0;
>   output=left(data,i-1);
>   queue output
>   "execio 1 diskw sysut2"
>   data=substr(data,i+2)
>   i=pos(CRLF,data)
>end
>"execio 0 diskr sysut1(finis"
>"execio 0 diskw sysut2(finis"
>

You know REXX better than I do - I couldn't have written this in such a short 
time. But is it not possible that in rare cases the original data might have 
been split into separate records right between the '0D'X and the '25'X, in 
which case this would produce problematic results? Just wanted to mention it.

Bill

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

Re: FTP of EBCDIC file

[Thomas Berg]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Monday, September 08, 2014 7:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP of EBCDIC file
> 
> On Mon, 8 Sep 2014 18:52:03 +0200, Thomas Berg wrote:
> >
> >I have no problems with the stack (or rather: not more than with any other of
> the language "constructs").
> >Although I nearly always uses QUEUE/PULL/EXECIO with
> NEWSTACK/DELSTACK.
> >
> >There is a theoretical performance enhancement with using the stack instead
> of stem.
> >With stack REXX need only one "parsing" of variable and don't need to setup a
> stem.
> >This depends of course much on how smart the REXX interpreter or compiler is.
> >
> Does the stem setup cost affect every reference to a compound symbol,
> or only the first?

I don't know.  But it would be very surprising if the stem setup would be done 
more than one time.  

> CMS EXECIO provides an "EXECIO ... (VAR" as well as stem.  I wonder why
> z/OS lacks the former.  CMS also provides "EXECIO ... (STRING", but I
> suspect z/OS balked at the parsing considerations.

I can't see that to be a problem really (or do miss something?), they could 
just use the standard string routines when "parsing" the input for EXECIO.  

If you restrict the name of the variable to end with a numeric you have (just 
guessing how ..(VAR works in CMS) something alike  ..(VAR:

r1 = 'foo'
EXECIO 1 DISKW xxx (STEM R FINIS' 

(etc.)  ... :)

> There's good empirical evidence for the reasonable assumption that writing
> multiple records in a single EXECIO performs better than record-by-record.
> But John's objective was not performance but didactic transparency.
> 
> And that stack performs better than stem, but that doesn't move me to use
> the stack when it's avoidable, nor to avoid subroutines when they are
> clearer than straight-line code that might be more efficient.

One thing to maybe think about is that leaving out "Procedure" in subroutines 
may enhance performance (no setup of separate variable "pool"):

SLOW_SUBROUTINE: Procedure Expose foo
...

FAST_SUBROUTINE:
... 

> And if one chooses multiple-record EXECIO, one must beware of REGION
> constraints, which are fatal, and of paging, which can vitiate any advantage
> of blocking EXECIO.
> 
> I shirk "EXECIO 0 ddname (FINIS" and "FREE ddname" when I can rely
> on termination code to perform the operation and DDNAME or DCB
> exhaustion is not a concern.  If the data set was allocated in JCL, then
> JCL can flush it and free it.

I usually always recommend when the amount of file data could be large to code 
like this:

Reasonableamount = 5000
rcexecio = 0

Do  While rcexecio = 0
   'EXECIO' reasonableamount 'DISKR xxx (STEM R.'

   Do  j = 1 To r.0
  ...
   End

End

'EXECIO 0 DISKR xxx (FINIS'

YMMV!



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)







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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 18:52:03 +0200, Thomas Berg wrote:
>
>I have no problems with the stack (or rather: not more than with any other of 
>the language "constructs"). 
>Although I nearly always uses QUEUE/PULL/EXECIO with NEWSTACK/DELSTACK.  
>
>There is a theoretical performance enhancement with using the stack instead of 
>stem.
>With stack REXX need only one "parsing" of variable and don't need to setup a 
>stem.  
>This depends of course much on how smart the REXX interpreter or compiler is.  
> 
> 
Does the stem setup cost affect every reference to a compound symbol,
or only the first?

CMS EXECIO provides an "EXECIO ... (VAR" as well as stem.  I wonder why
z/OS lacks the former.  CMS also provides "EXECIO ... (STRING", but I
suspect z/OS balked at the parsing considerations.

There's good empirical evidence for the reasonable assumption that writing
multiple records in a single EXECIO performs better than record-by-record.
But John's objective was not performance but didactic transparency.

And that stack performs better than stem, but that doesn't move me to use
the stack when it's avoidable, nor to avoid subroutines when they are
clearer than straight-line code that might be more efficient.

And if one chooses multiple-record EXECIO, one must beware of REGION
constraints, which are fatal, and of paging, which can vitiate any advantage
of blocking EXECIO.

I shirk "EXECIO 0 ddname (FINIS" and "FREE ddname" when I can rely
on termination code to perform the operation and DDNAME or DCB
exhaustion is not a concern.  If the data set was allocated in JCL, then
JCL can flush it and free it.

-- gil

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

Re: FTP of EBCDIC file

[Thomas Berg]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Monday, September 08, 2014 4:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP of EBCDIC file
> 
> On 2014-09-08, at 08:08, John McKown wrote:
> > ...
> >  output=left(data,i-1);
> >  queue output
> >  "execio 1 diskw sysut2"
> > ...
> Is this preferable to:
>  ...
>  output.1=left(data,i-1);
>  "execio 1 diskw sysut2 (stem output."
>  ...
> ?
> I have a custom of avoiding the stack.  I've had too many
> problems with PUSH/POP mismatches.

I have no problems with the stack (or rather: not more than with any other of 
the language "constructs"). 
Although I nearly always uses QUEUE/PULL/EXECIO with NEWSTACK/DELSTACK.  

There is a theoretical performance enhancement with using the stack instead of 
stem.
With stack REXX need only one "parsing" of variable and don't need to setup a 
stem.  
This depends of course much on how smart the REXX interpreter or compiler is.   



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)

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

Re: FTP of EBCDIC file

[Gibney, Dave]

Slight point of terminology. A describing a file containing packed decimal 
fields as EBCDIC is not really telling the full story. Mainframe data file 
maybe a better yet still ambiguous description. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Werner Kuehnel
> Sent: Monday, September 08, 2014 6:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP of EBCDIC file
> 
> It's not my creation, it was delivered by a bank for a test. Thanks for your
> suggestions, but if there are no standard ftp commands I refuse to work with
> that file.
> Anyway, I tested your way and it almost worked, Unfortunately there are
> packed fields in the records containing x'15' which are not a line end.
> 
> Thanks,
> Werner
> 
> 
> 
> 
> Von:Paul Gilmartin <000433f07816-dmarc-
> requ...@listserv.ua.edu>
> An: IBM-MAIN@LISTSERV.UA.EDU,
> Datum:  08.09.2014 15:13
> Betreff:Re: FTP of EBCDIC file
> Gesendet von:   IBM Mainframe Discussion List  m...@listserv.ua.edu>
> 
> 
> 
> On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:
> 
> >I have a file on a WIN server with variable data records in EBCDIC and
> the
> >correct end-of-line marker of x'0D25'. In the end I need a file with
> >LRECL=582, RECFM=VB.
> >
> >When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
> >records are written contigously in chunks of 582 bytes. A second ftp
> >(within z/OS) then splits up the records at x'0D25', but additionally
> >at byte 582, which is wrong when a record flows over into the next record.
> >All attempts to get the right format failed up to now.
> >
> >Does anyone has an idea how to accomplish this?
> >
> Eek!  How did you get such a file.  It may have a correct (according to the
> standard definition of IBM-1047 and ISO8859-1) line separator of x'0D25', but
> z/OS prefers the incorrect x'0D15'.  Is your binary FTP to a UNIX file or to a
> legacy data set.
> 
> I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert every 
> x'25'
> to x'15' (and perhaps vice-versa), then use a common utility to delete every
> x'0D at the end of a line'.  The file is now a conventional z/OS UNIX file.  
> If I
> needed a legacy data set, I could pre-allocate the target to FB 582 and use
> cp(1) to transfer to that.
> 
> I hate EBCDIC!
> 
> -- gil
> 
> --
> 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: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 10:15 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> You and I might suspect sabotage -- you because of your recurring
> experiences; I from mere paranoia.  The "Windows weenies" might
> be motivated to prove the mainframe deficient by creating a data
> image according to their misunderstanding of z/OS access methods
> in order to demonstrate that the result is unusable.

To me, the above scenario is a fact of life here and has been for a
few years. And it finally worked. Granted, the company had to shut
down the entire division that I support to do it. But that was really
done thanks to the economy and the ACA (Obamacare). We're in the
process of shutting down the health portion of the business (scheduled
by Dec 2015 at the latest) and going to supplimental insurance only
(kind of similar to AFLAC, but no duck).

>
> -- gil



-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 10:04:04 -0500, John McKown wrote:
>
>I think that Gil initially had the impression that the file was
>actually somehow created on the Windows server. We now know that it
>came to that server from some bank. Likely originally from a z/OS
>system. And the bank refuses to change their procedures (whatever that
>may be) to use AMATERSE or TRANSMIT. Personally, I think the bank IT
>people need a trip behind the wood shed. Likely Windows weenies.
> 
It remains unclear whether the Windows server belongs to the bank or
to the OP, nor in either case how the bizarre data got there.

You and I might suspect sabotage -- you because of your recurring
experiences; I from mere paranoia.  The "Windows weenies" might
be motivated to prove the mainframe deficient by creating a data
image according to their misunderstanding of z/OS access methods
in order to demonstrate that the result is unusable.

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 9:54 AM, Bob Shannon  wrote:
>>The OP stated initially that the file resides on a Windows server.
>>Starting from that point, how would you proceed?
>
> I offered no  suggestions on how to handle the file as it exists on the 
> Windows server.  My suggestion was to start over and have the bank send a 
> "PACKED" file.

I think that Gil initially had the impression that the file was
actually somehow created on the Windows server. We now know that it
came to that server from some bank. Likely originally from a z/OS
system. And the bank refuses to change their procedures (whatever that
may be) to use AMATERSE or TRANSMIT. Personally, I think the bank IT
people need a trip behind the wood shed. Likely Windows weenies.

>
> Bob Shannon
> Rocket Software

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 08:47, John McKown wrote:

> On Mon, Sep 8, 2014 at 9:43 AM, Werner Kuehnel wrote:
>> Amen. That's also my opinion.
>> 
>> BTW, your REXX worked perfectly. Thanks.
> 
> Glad it worked for you. It is not 100% reliable. One other poster in
> this thread showed a possibility of data which would cause it to
> malfunction.
>  
Hardly a deficiency in the Rexx; rather a potential true ambiguity
in the data, likely to appear only in a large data set.  Even this
might be resolved, but only by heuristic methods.

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 9:57 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On 2014-09-08, at 08:08, John McKown wrote:
>> ...
>>  output=left(data,i-1);
>>  queue output
>>  "execio 1 diskw sysut2"
>> ...
> Is this preferable to:
>  ...
>  output.1=left(data,i-1);
>  "execio 1 diskw sysut2 (stem output."
>  ...
> ?

Not really. It's just my habit. Perhaps not the best one. But somewhat
lost in the crowd of other bad habits.

> I have a custom of avoiding the stack.  I've had too many
> problems with PUSH/POP mismatches.

Hum, I guess. In this case, it is not a concern. I don't use the stack
for much other than EXECIO.

>
> -- gil
>

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 08:08, John McKown wrote:
> ...
>  output=left(data,i-1);
>  queue output
>  "execio 1 diskw sysut2"
> ...   
Is this preferable to:
 ...
 output.1=left(data,i-1);
 "execio 1 diskw sysut2 (stem output."
 ...
?
I have a custom of avoiding the stack.  I've had too many
problems with PUSH/POP mismatches.

-- gil

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

Re: FTP of EBCDIC file

[Bob Shannon]

>The OP stated initially that the file resides on a Windows server.
>Starting from that point, how would you proceed?

I offered no  suggestions on how to handle the file as it exists on the Windows 
server.  My suggestion was to start over and have the bank send a "PACKED" file.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

Antwort: Re: FTP of EBCDIC file

[Werner Kuehnel]

Nothing is unclear, probably I chose the wrong words. What I meant was I 
doubt that they change their standard procedures to provide the file.

Werner




Von:Bob Shannon 
An: IBM-MAIN@LISTSERV.UA.EDU, 
Datum:  08.09.2014 16:44
Betreff:Re: FTP of EBCDIC file
Gesendet von:   IBM Mainframe Discussion List 



>>> That sounds counterproductive.  AMATERSE PACK followed by AMATERSE 
UNPACK will result in a faithful bit-for-bit copy containing the original 
x'0D25' sequences.
>
>>> Fortunately, I suspect AMATERSE is not available on the OP's Windows 
server.
>
>> The OP understood the suggestion.
>
>Oh?  Has anyone tried the suggestion and observed it to succeed? 
Otherwise, I'd consider it more wishful thinking than understanding.

"If they can resend, have them run AMATERSE PARM=PACK against the VB file. 
Send the output file to you. Upload to the host. Run AMATERSE 
PARM=UNPACK”"

"I doubt they can handle that file with AMATERSE, they aren't very 
flexible
introducing alternatives.

Thanks,
Werner"

What part of this is unclear? It requires the bank to "PACK" the file 
before sending it to the OP. This is a really basic method of sending VB 
files.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 
02451 ? +1 800.966.3270 ? +1 781.577.4321
Unsubscribe From Commercial Email ‐ unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html

Privacy Policy - 
http://www.rocketsoftware.com/company/legal/privacy-policy


--
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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 08:43, Bob Shannon wrote:
> 
> What part of this is unclear? It requires the bank to "PACK" the file before 
> sending it to the OP. This is a really basic method of sending VB files.
>  
The OP stated initially that the file resides on a Windows server.
Starting from that point, how would you proceed?

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 9:43 AM, Werner Kuehnel
 wrote:
> Amen. That's also my opinion.
>
> BTW, your REXX worked perfectly. Thanks.
>
> Werner
>

Glad it worked for you. It is not 100% reliable. One other poster in
this thread showed a possibility of data which would cause it to
malfunction.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 08:27, John Gilmore wrote:

> Werner Kuehnel wrote:
> 
> 
> When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
> records are written contigously in chunks of 582 bytes. A second ftp
> (within z/OS) then splits up the records at x'0D25', but additionally
> at byte 582, which is wrong when a record flows over into the next
> record.  All attempts to get the right format failed up to now.
> 
> 
> This language is less than pellucid, but the words ". . . wrong when a
> record flows over into the next record." do strongly suggest that a
> RECFM value of VBS---Variable [length], Blocked, Spanned---be
> specified instead of VB.  Here VBS means in effect that a [logical]
> record can span one or more [physical] blocks.
>  
I doubt that RECFM=VBS is involved (does FTP even support VBS?)
Rather, that in a BINARY transfer to a RECFM=FB data set FTP is
oblivious to record boundaries and stores each 582 bytes of the
data stream as one RECFM=FB record, treating the x'0D25' simply
as ordinary data.

> Rube Goldberg schemes that resort to UNIX processing to cope with the
> putative deficiencies of some IBM access method do sometimes 'work',
> just as it is possible to travel from London to Paris via Okahoma
> City; but they are ugly resource hogs.  Worse, they perpetuate
> ignorance of these AMs.
>  
I don't recall that the OP imputed any deficiencies to IBM access
methods (although I may have done so).  "It is what it is."  (Must
I apologize for the cliche?)  Merely incompatibilities.  "Rube
Goldberg" is appropriate.

-- gil

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

Re: FTP of EBCDIC file

[Bob Shannon]

>>> That sounds counterproductive.  AMATERSE PACK followed by AMATERSE UNPACK 
>>> will result in a faithful bit-for-bit copy containing the original x'0D25' 
>>> sequences.
>
>>> Fortunately, I suspect AMATERSE is not available on the OP's Windows server.
>
>> The OP understood the suggestion.
>
>Oh?  Has anyone tried the suggestion and observed it to succeed?  Otherwise, 
>I'd consider it more wishful thinking than understanding.

"If they can resend, have them run AMATERSE PARM=PACK against the VB file. Send 
the output file to you. Upload to the host. Run AMATERSE PARM=UNPACK”"

"I doubt they can handle that file with AMATERSE, they aren't very flexible
introducing alternatives.

Thanks,
Werner"

What part of this is unclear? It requires the bank to "PACK" the file before 
sending it to the OP. This is a really basic method of sending VB files.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

Re: FTP of EBCDIC file

[Werner Kuehnel]

Amen. That's also my opinion.

BTW, your REXX worked perfectly. Thanks.

Werner





Von:John McKown 
An: IBM-MAIN@LISTSERV.UA.EDU, 
Datum:  08.09.2014 16:26
Betreff:    Re: FTP of EBCDIC file
Gesendet von:   IBM Mainframe Discussion List 



On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel
 wrote:
> It's not my creation, it was delivered by a bank for a test. Thanks for
> your suggestions, but if there are no standard ftp commands I refuse to
> work with that file.
> Anyway, I tested your way and it almost worked, Unfortunately there are
> packed fields in the records containing x'15' which are not a line end.
>
> Thanks,
> Werner
>

If the bank is trying to send you EBCDIC information from a z/OS
system, but needs it to survive transfer across non-z/OS systems, then
the bank really needs to either use AMATERSE or TRANSMIT to put the
data into a more transportable format. Those both result in an FB
file, which can easily be binary ftp'ed from z/OS to Windows, then
back to z/OS and restored. Doing a normal BINary FTP of variable data
will just result in frustration and data corruption.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

--
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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 08:21, Bob Shannon wrote:

>> That sounds counterproductive.  AMATERSE PACK followed by AMATERSE UNPACK 
>> will result in a faithful bit-for-bit copy containing the original x'0D25' 
>> sequences.
> 
>> Fortunately, I suspect AMATERSE is not available on the OP's Windows server.
> 
> The OP understood the suggestion.
>  
Oh?  Has anyone tried the suggestion and observed it to
succeed?  Otherwise, I'd consider it more wishful thinking
than understanding.

-- gil

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

Re: FTP of EBCDIC file

[John Gilmore]

Werner Kuehnel wrote:


When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
records are written contigously in chunks of 582 bytes. A second ftp
(within z/OS) then splits up the records at x'0D25', but additionally
at byte 582, which is wrong when a record flows over into the next
record.  All attempts to get the right format failed up to now.


This language is less than pellucid, but the words ". . . wrong when a
record flows over into the next record." do strongly suggest that a
RECFM value of VBS---Variable [length], Blocked, Spanned---be
specified instead of VB.  Here VBS means in effect that a [logical]
record can span one or more [physical] blocks.

Rube Goldberg schemes that resort to UNIX processing to cope with the
putative deficiencies of some IBM access method do sometimes 'work',
just as it is possible to travel from London to Paris via Okahoma
City; but they are ugly resource hogs.  Worse, they perpetuate
ignorance of these AMs.

John Gilmore, Ashland, MA 01721 - USA

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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 09:16:18 -0500, John McKown wrote:

>On Mon, Sep 8, 2014 at 8:53 AM, Paul Gilmartin wrote:
 I have a file on a WIN server with variable data records in EBCDIC and the
 correct end-of-line marker of x'0D25'  ...
>
>Well, I don't know how the insane bank people generate _their_ file.
>But I did it simply by creating a text file on UNIX. Then did a
>"unix2dos" on it to change the LF to CRLF. I then used iconv -t
>iso8859-1 -t ibm-1047 to create the ugly EBCDIC file. Finally I ftp
>uploaded the EBCDIC file in binary to z/OS.
> 
By "UNIX", you must mean "Linux" or some such ASCII system which
separates lines with LF rather than NL, and that you ran iconv on
that non-z/OS system also.

IBM adamantly refuses to admit that iconv violates a standard, or
excuses itself with footnotes in various manuals.

I hate EBCDIC!

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel
 wrote:
> It's not my creation, it was delivered by a bank for a test. Thanks for
> your suggestions, but if there are no standard ftp commands I refuse to
> work with that file.
> Anyway, I tested your way and it almost worked, Unfortunately there are
> packed fields in the records containing x'15' which are not a line end.
>
> Thanks,
> Werner
>

If the bank is trying to send you EBCDIC information from a z/OS
system, but needs it to survive transfer across non-z/OS systems, then
the bank really needs to either use AMATERSE or TRANSMIT to put the
data into a more transportable format. Those both result in an FB
file, which can easily be binary ftp'ed from z/OS to Windows, then
back to z/OS and restored. Doing a normal BINary FTP of variable data
will just result in frustration and data corruption.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Norbert Friemel]

On Mon, 8 Sep 2014 08:12:05 -0600, Paul Gilmartin wrote:

>> Anyway, I tested your way and it almost worked, Unfortunately there are 
>> packed fields in the records containing x'15' which are not a line end.
>>  
>John M's suggestion should work if the "packed" fields are
>conventional Packed Decimal, because (I believe) that neither
>x'0D25' nor x'0D15' can appear in Packed Decimal.  If the
>"packed" fields contain arbitrary binary data, there's the
>possibility that a large enough sample will by happenstance
>contain the x'0D25' sequence not intended as a line separator.
>

Two packed fields?
FIELD1   DCP'-250'  
FIELD2   DCP'250'   

Norbert Friemel

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

Re: FTP of EBCDIC file

[Bob Shannon]

>That sounds counterproductive.  AMATERSE PACK followed by AMATERSE UNPACK will 
>result in a faithful bit-for-bit copy containing the original x'0D25' 
>sequences.

>Fortunately, I suspect AMATERSE is not available on the OP's Windows server.


The OP understood the suggestion.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

Re: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 09:08:47 -0500, John McKown wrote:

>On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel wrote:
>> It's not my creation, it was delivered by a bank for a test. Thanks for
>> your suggestions, but if there are no standard ftp commands I refuse to
>> work with that file.
>
If the constraint is to use only standard IBM utilities, that may exclude
Norbert's TODSN suggestion.

>Yuck! You're definitely looking at using a REXX program for this. I
>don't know the bank attitude in Germany. But I've had a number of
>large banks basically tell me: "This is what we are going to give you.
>No discussion, just deal with it."
> 
Have you ever needed to deal with the possibility that the transformations
they performed resulted in data loss or ambiguity?

I hate EBCDIC!

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 8:53 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 8 Sep 2014 08:39:52 -0500, John McKown wrote:
>
>>On Mon, Sep 8, 2014 at 4:43 AM, Werner Kuehnel wrote:
>>> I have a file on a WIN server with variable data records in EBCDIC and the
>>> correct end-of-line marker of x'0D25'  ...
>>
>>The good news is that I can duplicate your problem.  ...
>>
> How?  Is this something that could happen by accident?

Well, I don't know how the insane bank people generate _their_ file.
But I did it simply by creating a text file on UNIX. Then did a
"unix2dos" on it to change the LF to CRLF. I then used iconv -t
iso8859-1 -t ibm-1047 to create the ugly EBCDIC file. Finally I ftp
uploaded the EBCDIC file in binary to z/OS.

>
> -- gil



-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On 2014-09-08, at 07:46, Werner Kuehnel wrote:

> It's not my creation, it was delivered by a bank for a test. Thanks for 
> your suggestions, but if there are no standard ftp commands I refuse to 
> work with that file.
>   
Ah!  They were trying to help you!  They ran iconv (or equivalent)
on a Linux (perhaps Cygwin) system which obeys the standards and
converts x'0D0A' to x'OD25'.

> Anyway, I tested your way and it almost worked, Unfortunately there are 
> packed fields in the records containing x'15' which are not a line end.
>  
John M's suggestion should work if the "packed" fields are
conventional Packed Decimal, because (I believe) that neither
x'0D25' nor x'0D15' can appear in Packed Decimal.  If the
"packed" fields contain arbitrary binary data, there's the
possibility that a large enough sample will by happenstance
contain the x'0D25' sequence not intended as a line separator.

On 2014-09-08, at 07:51, Bob Shannon wrote:
> 
> If they can resend, have them run AMATERSE PARM=PACK against the VB file. 
> Send the output file to you. Upload to the host. Run AMATERSE PARM=UNPACK”.
>  

That sounds counterproductive.  AMATERSE PACK followed by
AMATERSE UNPACK will result in a faithful bit-for-bit copy
containing the original x'0D25' sequences.

Fortunately, I suspect AMATERSE is not available on the OP's
Windows server.

I hate EBCDIC!  WOMBAT!

-- gil

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel
 wrote:
> It's not my creation, it was delivered by a bank for a test. Thanks for
> your suggestions, but if there are no standard ftp commands I refuse to
> work with that file.
> Anyway, I tested your way and it almost worked, Unfortunately there are
> packed fields in the records containing x'15' which are not a line end.

Yuck! You're definitely looking at using a REXX program for this. I
don't know the bank attitude in Germany. But I've had a number of
large banks basically tell me: "This is what we are going to give you.
No discussion, just deal with it."

>
> Thanks,
> Werner
>

Possible REXX program:

/* rexx */
data=''
CRLF='0D25'X
do forever
   "execio 1 diskr sysut1"
   if rc <> 0 then leave
   parse pull record
   data=data||record
   i=pos(CRLF,data)
   do while i <> 0;
  output=left(data,i-1);
  queue output
  "execio 1 diskw sysut2"
  data=substr(data,i+2)
  i=pos(CRLF,data)
   end
end
i=pos(CRLF,data)
do while i <> 0;
   output=left(data,i-1);
   queue output
   "execio 1 diskw sysut2"
   data=substr(data,i+2)
   i=pos(CRLF,data)
end
"execio 0 diskr sysut1(finis"
"execio 0 diskw sysut2(finis"

JCL:

//STEP010  EXEC PGM=IKJEFT01,DYNAMNBR=40,REGION=0M
//SYSTSPRT DD   SYSOUT=*
//SYSEXEC  DD   DISP=SHR,DSN=rexx.library
//SYSTSIN  DD   *
EXECUTIL SEARCHDD(YES)
%CRLF
/*
//SYSUT1 DD DISP=SHR,DSN=INPUT.FILE.EBCDIC
//SYSUT2 DD DSN=OUTPUT.FILE.CRLF,
// DISP=(NEW,CATLG),UNIT=SYSDA,
// RECFM=VB,LRECL=582,DSORG=PS,BLKSIZE=0,
// SPACE=(TRK,(20,10),RLSE)

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Werner Kuehnel]

I doubt they can handle that file with AMATERSE, they aren't very flexible 
introducing alternatives.

Thanks,
Werner




Von:Bob Shannon 
An: IBM-MAIN@LISTSERV.UA.EDU, 
Datum:  08.09.2014 15:52
Betreff:    Re: FTP of EBCDIC file
Gesendet von:   IBM Mainframe Discussion List 



>>I have a file on a WIN server with variable data records in EBCDIC and
>>the correct end-of-line marker of x'0D25'. In the end I need a file
>>with LRECL=582, RECFM=VB

If they can resend, have them run AMATERSE PARM=PACK against the VB file. 
Send the output file to you. Upload to the host. Run AMATERSE 
PARM=UNPACK”.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 
02451 ? +1 800.966.3270 ? +1 781.577.4321
Unsubscribe From Commercial Email ‐ unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html

Privacy Policy - 
http://www.rocketsoftware.com/company/legal/privacy-policy


--
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: FTP of EBCDIC file

[Werner Kuehnel]

Norbert and Kirk,
well, we don't have Co:z so far, but it might be worth a try.
Thanks for pointing to that option.

Werner




Von:Kirk Wolf 
An: IBM-MAIN@LISTSERV.UA.EDU, 
Datum:  08.09.2014 15:52
Betreff:    Re: FTP of EBCDIC file
Gesendet von:   IBM Mainframe Discussion List 



On Mon, Sep 8, 2014 at 8:44 AM, Norbert Friemel  wrote:

> On Mon, 8 Sep 2014 08:12:43 -0500, Paul Gilmartin wrote:
>
> >On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:
> >
> >>I have a file on a WIN server with variable data records in EBCDIC and
> the
> >>correct end-of-line marker of x'0D25'. In the end I need a file with
> >>LRECL=582, RECFM=VB.
> >>
> >>When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
> >>records are written contigously in chunks of 582 bytes. A second ftp
> >>(within z/OS) then splits up the records at x'0D25', but additionally 
at
> >>byte 582, which is wrong when a record flows over into the next 
record.
> >>All attempts to get the right format failed up to now.
> >>
> >>Does anyone has an idea how to accomplish this?
> >>
> >Eek!  How did you get such a file.  It may have a correct (according to
> >the standard definition of IBM-1047 and ISO8859-1) line separator of
> >x'0D25', but z/OS prefers the incorrect x'0D15'.  Is your binary FTP
> >to a UNIX file or to a legacy data set.
> >
> >I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert
> >every x'25' to x'15' (and perhaps vice-versa), then use a common
> >utility to delete every x'0D at the end of a line'.  The file is now a
> >conventional z/OS UNIX file.  If I needed a legacy data set, I could
> >pre-allocate the target to FB 582 and use cp(1) to transfer to that.
> >
> >I hate EBCDIC!
> >
> >-- gil
>
> FTP in binary to a z/OS UNIX file, then "todsn -l 0x0D25" (
> http://www.dovetail.com/docs/coz/dsp-ref_todsn.html )  to a z/OS dataset
>
>
.. or you could use Co:Z SFTP instead of FTP with:

ls /+linerule=0x0d25,sourcecp=IBM-1047
ls /+recfm=vb,lrecl=582
put winfile //hlq.zos.dsn

Kirk Wolf
Dovetailed Technologies
http://dovetail.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: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 08:39:52 -0500, John McKown wrote:

>On Mon, Sep 8, 2014 at 4:43 AM, Werner Kuehnel wrote:
>> I have a file on a WIN server with variable data records in EBCDIC and the
>> correct end-of-line marker of x'0D25'  ...
>
>The good news is that I can duplicate your problem.  ...
> 
How?  Is this something that could happen by accident?

-- gil

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

Re: FTP of EBCDIC file

[Kirk Wolf]

On Mon, Sep 8, 2014 at 8:44 AM, Norbert Friemel  wrote:

> On Mon, 8 Sep 2014 08:12:43 -0500, Paul Gilmartin wrote:
>
> >On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:
> >
> >>I have a file on a WIN server with variable data records in EBCDIC and
> the
> >>correct end-of-line marker of x'0D25'. In the end I need a file with
> >>LRECL=582, RECFM=VB.
> >>
> >>When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
> >>records are written contigously in chunks of 582 bytes. A second ftp
> >>(within z/OS) then splits up the records at x'0D25', but additionally at
> >>byte 582, which is wrong when a record flows over into the next record.
> >>All attempts to get the right format failed up to now.
> >>
> >>Does anyone has an idea how to accomplish this?
> >>
> >Eek!  How did you get such a file.  It may have a correct (according to
> >the standard definition of IBM-1047 and ISO8859-1) line separator of
> >x'0D25', but z/OS prefers the incorrect x'0D15'.  Is your binary FTP
> >to a UNIX file or to a legacy data set.
> >
> >I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert
> >every x'25' to x'15' (and perhaps vice-versa), then use a common
> >utility to delete every x'0D at the end of a line'.  The file is now a
> >conventional z/OS UNIX file.  If I needed a legacy data set, I could
> >pre-allocate the target to FB 582 and use cp(1) to transfer to that.
> >
> >I hate EBCDIC!
> >
> >-- gil
>
> FTP in binary to a z/OS UNIX file, then "todsn -l 0x0D25" (
> http://www.dovetail.com/docs/coz/dsp-ref_todsn.html )  to a z/OS dataset
>
>
.. or you could use Co:Z SFTP instead of FTP with:

ls /+linerule=0x0d25,sourcecp=IBM-1047
ls /+recfm=vb,lrecl=582
put winfile //hlq.zos.dsn

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: FTP of EBCDIC file

[Bob Shannon]

>>I have a file on a WIN server with variable data records in EBCDIC and
>>the correct end-of-line marker of x'0D25'. In the end I need a file
>>with LRECL=582, RECFM=VB

If they can resend, have them run AMATERSE PARM=PACK against the VB file. Send 
the output file to you. Upload to the host. Run AMATERSE PARM=UNPACK”.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

Re: FTP of EBCDIC file

[Werner Kuehnel]

It's not my creation, it was delivered by a bank for a test. Thanks for 
your suggestions, but if there are no standard ftp commands I refuse to 
work with that file.
Anyway, I tested your way and it almost worked, Unfortunately there are 
packed fields in the records containing x'15' which are not a line end.

Thanks,
Werner 




Von:Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
An: IBM-MAIN@LISTSERV.UA.EDU, 
Datum:  08.09.2014 15:13
Betreff:    Re: FTP of EBCDIC file
Gesendet von:   IBM Mainframe Discussion List 



On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:

>I have a file on a WIN server with variable data records in EBCDIC and 
the
>correct end-of-line marker of x'0D25'. In the end I need a file with
>LRECL=582, RECFM=VB.
>
>When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
>records are written contigously in chunks of 582 bytes. A second ftp
>(within z/OS) then splits up the records at x'0D25', but additionally at
>byte 582, which is wrong when a record flows over into the next record.
>All attempts to get the right format failed up to now.
>
>Does anyone has an idea how to accomplish this?
> 
Eek!  How did you get such a file.  It may have a correct (according to
the standard definition of IBM-1047 and ISO8859-1) line separator of
x'0D25', but z/OS prefers the incorrect x'0D15'.  Is your binary FTP
to a UNIX file or to a legacy data set.

I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert
every x'25' to x'15' (and perhaps vice-versa), then use a common
utility to delete every x'0D at the end of a line'.  The file is now a
conventional z/OS UNIX file.  If I needed a legacy data set, I could
pre-allocate the target to FB 582 and use cp(1) to transfer to that.

I hate EBCDIC!

-- gil

--
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: FTP of EBCDIC file

[Norbert Friemel]

On Mon, 8 Sep 2014 08:12:43 -0500, Paul Gilmartin wrote:

>On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:
>
>>I have a file on a WIN server with variable data records in EBCDIC and the
>>correct end-of-line marker of x'0D25'. In the end I need a file with
>>LRECL=582, RECFM=VB.
>>
>>When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
>>records are written contigously in chunks of 582 bytes. A second ftp
>>(within z/OS) then splits up the records at x'0D25', but additionally at
>>byte 582, which is wrong when a record flows over into the next record.
>>All attempts to get the right format failed up to now.
>>
>>Does anyone has an idea how to accomplish this?
>> 
>Eek!  How did you get such a file.  It may have a correct (according to
>the standard definition of IBM-1047 and ISO8859-1) line separator of
>x'0D25', but z/OS prefers the incorrect x'0D15'.  Is your binary FTP
>to a UNIX file or to a legacy data set.
>
>I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert
>every x'25' to x'15' (and perhaps vice-versa), then use a common
>utility to delete every x'0D at the end of a line'.  The file is now a
>conventional z/OS UNIX file.  If I needed a legacy data set, I could
>pre-allocate the target to FB 582 and use cp(1) to transfer to that.
>
>I hate EBCDIC!
>
>-- gil

FTP in binary to a z/OS UNIX file, then "todsn -l 0x0D25" ( 
http://www.dovetail.com/docs/coz/dsp-ref_todsn.html )  to a z/OS dataset

Norbert Friemel

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

Re: FTP of EBCDIC file

[John McKown]

On Mon, Sep 8, 2014 at 4:43 AM, Werner Kuehnel
 wrote:
> I have a file on a WIN server with variable data records in EBCDIC and the
> correct end-of-line marker of x'0D25'. In the end I need a file with
> LRECL=582, RECFM=VB.
>
> When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
> records are written contigously in chunks of 582 bytes. A second ftp
> (within z/OS) then splits up the records at x'0D25', but additionally at
> byte 582, which is wrong when a record flows over into the next record.
> All attempts to get the right format failed up to now.
>
> Does anyone has an idea how to accomplish this?
>
> Werner Kuehnel

The good news is that I can duplicate your problem. The bad new is
that I don't have a simple solution. The good news is that I have a
somewhat complicated solution. The bad news is that it uses z/OS UNIX
facilities. OK, enough with the "good news / bad news" stuff.

I did try my solution with my test data. It does work. It _is_ a bit
complicated. And it assumes that the only use of x'0D' in your data
occurs immediately before a x'25' and is part of the CRLF control
sequence and never used as data in itself. The actually UNIX command
stream looks like (no JCL). The below is one long line, even if broken
up by email.

cp -B "//'some.input.dsn'" /dev/fd/1 | tr -d '\15' | tr '\45' '\n' |
cp -T -W "seqparms='LRECL=582,RECFM=FB,SPACE=(CYL,(10,1))' /dev/fd/0
"//'vb.output.file'"

What the above does is copy 'some.input.dsn' as a binary file (-B) to
"stdout" (/dev/fd/1). It then pipes this into the translate command
(tr) which deletes (-d) all the x'0D' (\15 which is octal) characters.
This is then piped into translate (tr) which converts the x'25' (\45
is octal of x'25') to '\n' which is the z/OS UNIX "new line" (NEL)
character. It then pipes this into the copy (cp) command in text
format (-T) passing the z/OS DSN allocation parameters (-W seqparms=).
/dev/fd/0 is the "file name" for "stdin" which is where the piped data
come in. It then outputs the data into the z/OS data set
'vb.output.file'

Why not just use REXX to read your input and write your data? If
necessary, I could probably create an example.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: FTP of EBCDIC file

[Paul Gilmartin]

On Mon, 8 Sep 2014 11:43:16 +0200, Werner Kuehnel wrote:

>I have a file on a WIN server with variable data records in EBCDIC and the
>correct end-of-line marker of x'0D25'. In the end I need a file with
>LRECL=582, RECFM=VB.
>
>When I ftp this file binary with "quote site lrecl=582 recfm=fb" all
>records are written contigously in chunks of 582 bytes. A second ftp
>(within z/OS) then splits up the records at x'0D25', but additionally at
>byte 582, which is wrong when a record flows over into the next record.
>All attempts to get the right format failed up to now.
>
>Does anyone has an idea how to accomplish this?
> 
Eek!  How did you get such a file.  It may have a correct (according to
the standard definition of IBM-1047 and ISO8859-1) line separator of
x'0D25', but z/OS prefers the incorrect x'0D15'.  Is your binary FTP
to a UNIX file or to a legacy data set.

I would FTP in binary to a z/OS UNIX file, then use tr(1) to convert
every x'25' to x'15' (and perhaps vice-versa), then use a common
utility to delete every x'0D at the end of a line'.  The file is now a
conventional z/OS UNIX file.  If I needed a legacy data set, I could
pre-allocate the target to FB 582 and use cp(1) to transfer to that.

I hate EBCDIC!

-- gil

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

FTP of EBCDIC file

[Werner Kuehnel]

I have a file on a WIN server with variable data records in EBCDIC and the 
correct end-of-line marker of x'0D25'. In the end I need a file with 
LRECL=582, RECFM=VB.

When I ftp this file binary with "quote site lrecl=582 recfm=fb" all 
records are written contigously in chunks of 582 bytes. A second ftp 
(within z/OS) then splits up the records at x'0D25', but additionally at 
byte 582, which is wrong when a record flows over into the next record. 
All attempts to get the right format failed up to now.

Does anyone has an idea how to accomplish this?

Werner Kuehnel

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