Re: FTP question

[CarlosM Martinez]

No it is not it's some programmers JCL. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, July 20, 2019 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP question

On Fri, 19 Jul 2019 21:10:19 -0400, CarlosM Martinez  wrote:

>I will have to take a look at the JCL. But it seems you are correct it is a
>BATCH OS/MVS SFTP to UNIX.
>
So it isn't your JCL?

>...
>Would anyone know what 65280 return code from an FTP could be?
>Command:
>Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131
>Failed with a return code 65280
>
That looks like a PARM to BPXBATCH.  If so, provide DD statements
allocating STDOUT and STDERR to SYSOUT for far more information.

>Thank you all
>Newbe to MVS
>
If you are new to MVS, would logging on to a UNIX shell be a more
familiar environment to you?

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

[Paul Gilmartin]

On Fri, 19 Jul 2019 21:10:19 -0400, CarlosM Martinez  wrote:

>I will have to take a look at the JCL. But it seems you are correct it is a
>BATCH OS/MVS SFTP to UNIX.
>
So it isn't your JCL?

>...
>Would anyone know what 65280 return code from an FTP could be?
>Command:
>Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131
>Failed with a return code 65280
>
That looks like a PARM to BPXBATCH.  If so, provide DD statements
allocating STDOUT and STDERR to SYSOUT for far more information.

>Thank you all
>Newbe to MVS
>
If you are new to MVS, would logging on to a UNIX shell be a more
familiar environment to you?

-- gil

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

Re: FTP question

[CarlosM Martinez]

I will have to take a look at the JCL. But it seems you are correct it is a
BATCH OS/MVS SFTP to UNIX.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Friday, July 19, 2019 6:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP question

Are you using the z/OS FTP client?  It doesn't look like it.  It looks like
you are trying to invoke a Unix shell with the 'rm' command.  Not something
that FTP supports, as far as I know.


From: IBM Mainframe Discussion List  on behalf of
CarlosM Martinez 
Sent: Friday, July 19, 2019 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: FTP question

Sorry I sent this before with the wrong subject

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of CarlosM Martinez
Sent: Friday, July 19, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hello ;
Would anyone know what 65280 return code from an FTP could be?
Command:
Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131
Failed with a return code 65280

Thank you all
Newbe to MVS

Carlos Martinez
SUNY

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Carmen Vitullo
Sent: Friday, July 19, 2019 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hey Bob, IIRC that's what a lot of folks did on the ISPF Primary option
until IBM started shipping the panel that way, I may be wrong, I've been
wrong before :)
thanks



Carmen Vitullo

- Original Message -

From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2019 11:00:41 AM
Subject: Re: SDSF initial display and z/OS 2.3

Yes, if you can find the correct place to insert a .RESP=ENTER in panel
logic of ISFPCU41 that will not cause issues. I took a fast look and would
assume that after the "ABC" logic for the action bar stuff might be
appropriate. I can't pursue this at the moment. Maybe a SDSF developer will
chime in. Then again, they probably want you to see the logo. :-(

I have already coded two dozen command table entries for all the options in
SDSF that I want direct access to, especially ones like SYS, APF, LINK, SP,
etc. :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Carmen Vitullo
Sent: Friday, July 19, 2019 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF initial display and z/OS 2.3

Is it possible to bypass the logo pop-up in SDSF on z/OS 2.3 ?

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

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


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

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

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

[Frank Swarbrick]

Are you using the z/OS FTP client?  It doesn't look like it.  It looks like you 
are trying to invoke a Unix shell with the 'rm' command.  Not something that 
FTP supports, as far as I know.


From: IBM Mainframe Discussion List  on behalf of 
CarlosM Martinez 
Sent: Friday, July 19, 2019 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: FTP question

Sorry I sent this before with the wrong subject

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CarlosM Martinez
Sent: Friday, July 19, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hello ;
Would anyone know what 65280 return code from an FTP could be?
Command:
Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131
Failed with a return code 65280

Thank you all
Newbe to MVS

Carlos Martinez
SUNY

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, July 19, 2019 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hey Bob, IIRC that's what a lot of folks did on the ISPF Primary option until 
IBM started shipping the panel that way, I may be wrong, I've been wrong before 
:)
thanks



Carmen Vitullo

- Original Message -

From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2019 11:00:41 AM
Subject: Re: SDSF initial display and z/OS 2.3

Yes, if you can find the correct place to insert a .RESP=ENTER in panel logic 
of ISFPCU41 that will not cause issues. I took a fast look and would assume 
that after the "ABC" logic for the action bar stuff might be appropriate. I 
can't pursue this at the moment. Maybe a SDSF developer will chime in. Then 
again, they probably want you to see the logo. :-(

I have already coded two dozen command table entries for all the options in 
SDSF that I want direct access to, especially ones like SYS, APF, LINK, SP, 
etc. :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, July 19, 2019 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF initial display and z/OS 2.3

Is it possible to bypass the logo pop-up in SDSF on z/OS 2.3 ?

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

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


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

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

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

[Charles Mills]

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.halu001/ftpstret.htm
 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CarlosM Martinez
Sent: Friday, July 19, 2019 12:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FTP question

Sorry I sent this before with the wrong subject 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CarlosM Martinez
Sent: Friday, July 19, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hello ;
Would anyone know what 65280 return code from an FTP could be?
Command:
Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131 
Failed with a return code 65280

Thank you all
Newbe to MVS

Carlos Martinez 
SUNY 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, July 19, 2019 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hey Bob, IIRC that's what a lot of folks did on the ISPF Primary option until 
IBM started shipping the panel that way, I may be wrong, I've been wrong before 
:) 
thanks 



Carmen Vitullo 

- Original Message -

From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 19, 2019 11:00:41 AM 
Subject: Re: SDSF initial display and z/OS 2.3 

Yes, if you can find the correct place to insert a .RESP=ENTER in panel logic 
of ISFPCU41 that will not cause issues. I took a fast look and would assume 
that after the "ABC" logic for the action bar stuff might be appropriate. I 
can't pursue this at the moment. Maybe a SDSF developer will chime in. Then 
again, they probably want you to see the logo. :-( 

I have already coded two dozen command table entries for all the options in 
SDSF that I want direct access to, especially ones like SYS, APF, LINK, SP, 
etc. :-) 

Bob 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Friday, July 19, 2019 9:14 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: SDSF initial display and z/OS 2.3 

Is it possible to bypass the logo pop-up in SDSF on z/OS 2.3 ? 

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

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


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

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

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

[Paul Gilmartin]

On Fri, 19 Jul 2019 15:46:09 -0400, CarlosM Martinez wrote:
>
>Would anyone know what 65280 return code from an FTP could be?
>Command:
>Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131 
>Failed with a return code 65280
> 
Is it significant that that's 0xff00?

-- gil

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

FTP question

[CarlosM Martinez]

Sorry I sent this before with the wrong subject 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CarlosM Martinez
Sent: Friday, July 19, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hello ;
Would anyone know what 65280 return code from an FTP could be?
Command:
Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131 
Failed with a return code 65280

Thank you all
Newbe to MVS

Carlos Martinez 
SUNY 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, July 19, 2019 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF initial display and z/OS 2.3

Hey Bob, IIRC that's what a lot of folks did on the ISPF Primary option until 
IBM started shipping the panel that way, I may be wrong, I've been wrong before 
:) 
thanks 



Carmen Vitullo 

- Original Message -

From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 19, 2019 11:00:41 AM 
Subject: Re: SDSF initial display and z/OS 2.3 

Yes, if you can find the correct place to insert a .RESP=ENTER in panel logic 
of ISFPCU41 that will not cause issues. I took a fast look and would assume 
that after the "ABC" logic for the action bar stuff might be appropriate. I 
can't pursue this at the moment. Maybe a SDSF developer will chime in. Then 
again, they probably want you to see the logo. :-( 

I have already coded two dozen command table entries for all the options in 
SDSF that I want direct access to, especially ones like SYS, APF, LINK, SP, 
etc. :-) 

Bob 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Friday, July 19, 2019 9:14 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: SDSF initial display and z/OS 2.3 

Is it possible to bypass the logo pop-up in SDSF on z/OS 2.3 ? 

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

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


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

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

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

Base64 (was: z/OS Secure FTP Question)

[Paul Gilmartin]

On Tue, 8 Aug 2017 14:29:00 -0500, Walt Farrell wrote:

>On Tue, 8 Aug 2017 10:35:08 -0600, Paul Gilmartin wrote:
>
>>(Interesting: another base64 body I can't quote on the Web interface.)
>
>If you use Firefox you might consider installing the LeetKey extension, which 
>will allow such quoting with relative ease. Just select the encoded text, 
>right-click, choose LeetKey, Text Tranformers, Base64 Decode.
>
Why should that be necessary?  LISTSERV is broken; it should be fixed.

As it is, I just reply to such messages from the email interfact.

The existence of a circumvention does not remove the desirability of a repair;
the first thing a user tries should work, not the second, or third, or ...

Thanks,
gil

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

Re: z/OS Secure FTP Question

[Walt Farrell]

On Tue, 8 Aug 2017 10:35:08 -0600, Paul Gilmartin  wrote:

>(Interesting: another base64 body I can't quote on the Web interface.)

If you use Firefox you might consider installing the LeetKey extension, which 
will allow such quoting with relative ease. Just select the encoded text, 
right-click, choose LeetKey, Text Tranformers, Base64 Decode.

-- 
Walt

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

Re: z/OS Secure FTP Question

[Jousma, David]

It all depends on how often you order/receive maintenance.   I do it weekly, 
and get by with a 4Gb NTS.   If I wait several weeks, and some "large" 
maintenance comes out(think java replacements) then I've run out.   I currently 
run with a 8Gb NTS.   When I order a new Serverpack, I go by what the doc says, 
but I typically allocate a temporary 30-40Gb NTS that stays around long enough 
to populate all the datasets, and then it goes away.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Veryl Ellis
Sent: Tuesday, August 08, 2017 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

CAUTION EXTERNAL EMAIL

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

--
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 **DO NOT open 
attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: z/OS Secure FTP Question

[Paul Gilmartin]

(Interesting: another base64 body I can't quote on the Web interface.)
On 2017-08-08, at 09:55, Allan Staller wrote:

> SMPWKDIR should be at least 3 times the size of the package.
> IIRC, there is a minimal increase in the root filesystem.
> 
> -Original Message-
> From: Veryl Ellis
> Sent: Tuesday, August 8, 2017 10:47 AM
> 
> Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
> files?
> I seem to keep running out.
>  
Interesting.  But a quality client could send an HTTP HEAD request and
use a "Content-Length:" header (if the server supplies one) to verify
sufficient target space or make a recommendation.

-- gil

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

Re: z/OS Secure FTP Question

[Allan Staller]

SMPWKDIR should be at least 3 times the size of the package.
IIRC, there is a minimal increase in the root filesystem.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Veryl Ellis
Sent: Tuesday, August 8, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: z/OS Secure FTP Question

[Carmen Vitullo]

my shopz zfs is 10,000 Cyl's 
SMPWRKDIR is a tfs for me 

MOUNT FILESYSTEM('TMPSMPWK') 
MOUNTPOINT('/SYST/usr/local/smpe/workdir') 
TYPE(TFS) /* Filesystem type TFS */ 
MODE(RDWR) /* Mounted for read/write */ 
PARM('-s 2147380171 -b 1') 


- Original Message -

From: "Veryl Ellis" <veryl.el...@sungardas.com> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 8, 2017 10:46:51 AM 
Subject: Re: z/OS Secure FTP Question 

Another question. 

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files? 
I seem to keep running out. 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman 
Sent: Tuesday, August 08, 2017 12:48 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS Secure FTP Question 

I agree, HTTPS is much easier to both implement and use. IBM supplies the 
directions on every order in ShopZSeries (off on the right side). I think they 
also tell you right in each shipment, but I could be wrong. 

Brian 

-- 
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: z/OS Secure FTP Question

[Veryl Ellis]

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

--
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: z/OS Secure FTP Question

[Brian Westerman]

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

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

Re: z/OS Secure FTP Question

[Kurt Quackenbush]

On 8/7/2017 9:13 AM, Veryl Ellis wrote:

I'm attempting to setup a secure FTP so I get PUT/RSU maintenance
via FTP and move away from requesting tape.



Can someone tell me if I should use;
GeoTrust Global CA
Or
GeoTrust Global CA 2


You want GeoTrust Global CA (serial number 02 34 56).  I suggest you 
refer to the following for more help:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.gim3000/dsetups.htm

I also suggest you use HTTPS instead of FTPS.

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: FTP Question

[Paul Gilmartin]

On Mon, 29 Sep 2014 09:35:36 -0400, John Gilmore wrote:

The notion that some code points in a character set---SBCS, DBCS, or
MBCS---are characters and others are not is, however, a supremely
silly one.

At best, it's an utter impediment to bijective (round-trip) conversion.
Fortunately, however, z/OS iconv does not enforce that notion:

13 *-* 'iconv -f IBM-1047 -t UTF-8 a1 a2'
  iconv -f IBM-1047 -t UTF-8 a1 a2
14 *-* 'iconv -t IBM-1047 -f UTF-8 a2 a3'
  iconv -t IBM-1047 -f UTF-8 a2 a3
15 *-* 'ls -alrt'
  ls -alrt
total 48
drwxr-sr-x  67 user group383 Oct  2 16:45 ..
-rwxr-xr-x   1 user group328 Oct  2 16:56 ctest
-rw-r--r--   1 user group826 Oct  2 16:57 report
-rw-r--r--   1 user group256 Oct  2 16:57 a3
-rw-r--r--   1 user group384 Oct  2 16:57 a2
-rw-r--r--   1 user group256 Oct  2 16:57 a1
drwxr-sr-x   2 user group  7 Oct  2 16:57 .
16 *-* 'cksum a*'
  cksum a*
1313719201 256 a1
716397259 384 a2
1313719201 256 a3
17 *-* 'diff -su a1 a3'
  diff -su a1 a3
Files a1 and a3 are identical
total 48
4724741 drwxr-sr-x  67 user group383 Oct  2 16:45 ..
10695729 -rwxr-xr-x   1 user group328 Oct  2 16:56 ctest
10695735 -rw-r--r--   1 user group826 Oct  2 16:57 report
10695734 -rw-r--r--   1 user group256 Oct  2 16:57 a3
10695733 -rw-r--r--   1 user group384 Oct  2 16:57 a2
10695730 -rw-r--r--   1 user group256 Oct  2 16:57 a1
10695728 drwxr-sr-x   2 user group  7 Oct  2 16:57 .

The z/OS LF-NL flipflop remains a nonconformance to standard
and an obstacle to portability.

-- gil

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

Re: FTP Question

[John Gilmore]

It is traditional and often useful to distinguish control characters
and graphic characters, printable/displayable ones; and some very
different dichotomizing terminology has been used to make this
distinction.

The notion that some code points in a character set---SBCS, DBCS, or
MBCS---are characters and others are not is, however, a supremely
silly 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 Question

[Shmuel Metz (Seymour J.)]

In 041d01cfdacf$3b377790$b1a666b0$@mcn.org, on 09/27/2014
   at 08:49 PM, Charles Mills charl...@mcn.org said:

You could argue that X'01' is not a character. 

See http://en.wikipedia.org/wiki/C0_and_C1_control_codes, or Table
2-3. Types of Code Points in The Unicode 5.0 Standard. SOH would
appear to be a character in IBM-1-47 and ISO-8859-1, but not in
Unicode, despite
https://www.iana.org/assignments/charset-reg/IBM1047. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Shmuel Metz (Seymour J.)]

In 4337039103798508.wa.paulgboulderaim@listserv.ua.edu, on
09/27/2014
   at 08:55 PM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

I suppose it comes down to whom you trust in this matter:

Neither, but IANA is certainly more reliable than wiki. The IANA chart
shows, e.g., 

*CP  UCS   GCGIDSYNONYM   ISO 10646 NAME
 08   0097  ...GE... ..EPA...  (CC) End of Guarded Area

I doubt that was the cause of the FTP error,

Not given Bill's results.

My longer test case failed even with a trailing NL

Ouch!

FTP may be WAD; I'd say BAD.

Yes to the second, but no to the first.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Shmuel Metz (Seymour J.)]

In 54236565.90...@aim.com, on 09/24/2014
   at 06:44 PM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

Shmuel has an incorrigible bad habit of
trimming to where the citation is unidentifiable.

You have a bad habit of denmanding citations of things that are not
relevant to my responses.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Shmuel Metz (Seymour J.)]

In 2874406462216786.wa.paulgboulderaim@listserv.ua.edu, on
09/25/2014
   at 11:15 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

There's *no* character that can't be converted from IBM-1047 to
UTF-8.

While https://www.iana.org/assignments/charset-reg/IBM1047 shows
translations for all code points,
http://en.wikipedia.org/wiki/EBCDIC_1047 shows a bunch that
allegedly have no equivalent. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Paul Gilmartin]

On Sat, 27 Sep 2014 21:32:33 -0400, Shmuel Metz (Seymour J.) wrote:

There's *no* character that can't be converted from IBM-1047 to
UTF-8.

While https://www.iana.org/assignments/charset-reg/IBM1047 shows
translations for all code points,
http://en.wikipedia.org/wiki/EBCDIC_1047 shows a bunch that
allegedly have no equivalent.
 
I suppose it comes down to whom you trust in this matter: IANA or
Wikipedia.  (I wonder which the IBM coders relied on?)

While my shorter test case certainly contained characters in that bunch,
I doubt that was the cause of the FTP error, since Bill Godfrey's suggestion
to add a trailing NL removed the error.  My longer test case failed even
with a trailing NL while containing no code points absent from the shorter.

FTP may be WAD; I'd say BAD.

-- gil

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

Re: FTP Question

[Charles Mills]

I have a product that uses IBM Unicode Services to translate from 1047 to
UTF-8. When (due to an error or confused input) it translates non-printable
1047 data, I know that Unicode Services reports that it could not convert
all of the characters.

Well, two quibbly points:

- As Bill Clinton never said, it depends on what you mean by character.
Every 8-bit code point is apparently not translatable from 1047 to UTF-8.
You could argue that X'01' is not a character. I think every reasonable
glyph known to man has a UTF-8 code point, so in that sense, every
*character* is translatable.
- I suppose you could argue that every code point is translatable -- it's
just that some get translated to SUB.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Saturday, September 27, 2014 6:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP Question

In 2874406462216786.wa.paulgboulderaim@listserv.ua.edu, on
09/25/2014
   at 11:15 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

There's *no* character that can't be converted from IBM-1047 to UTF-8.

While https://www.iana.org/assignments/charset-reg/IBM1047 shows
translations for all code points, http://en.wikipedia.org/wiki/EBCDIC_1047
shows a bunch that allegedly have no equivalent. 

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

Re: FTP Question

[Paul Gilmartin]

On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:

I have seen the very misleading 451 message when attempting this with a USS 
file in which the last line does not end with hex 15.

I tried the following script (on Solaris):

550$ cat bin/longline
#! /bin/sh -x
# Doc: create a large file consisting of only a single line.

target=$HOME/work/bigline

# On ASCII system, \n is '\012'
: amp; { tr -d '\012' /dev/random |
ssh $MVS_USER@$MVS_HOST set -x
{ dd bs=1000 count=1000; echo; } |
tee $target | wc; }

cd $TMPDIR
ftp $MVS_HOST eod
verbose
ascii
cd $HOME/work

get bigline long1

site encoding=mbcs
site mbdataconn=(IBM-1047,UTF-8)
get $target long2

quit
eod

... with the results:
...
+ dd bs=1000 count=1000 
+ wc 
FSUM6384 844+156 records in
844+156 records out
+ echo 
  1   17014  863161 

... Why not 101?  That's for MVS-OE.

...
Verbose mode on.
200 Representation type is Ascii NonPrint
250 HFS directory .../work is the current working directory

200 Port request OK.
125 Sending data set .../work/bigline
250 Transfer completed successfully.
local: long1 remote: bigline
862162 bytes received in 0.037 seconds (22973.67 Kbytes/s)

200 SITE command was accepted
200 SITE command was accepted
200 Port request OK.
125 Sending data set .../work/bigline
451 File transfer failed. Multi-byte data conversion error occurred

221 Quit command received. Goodbye. 

There's *no* character that can't be converted from IBM-1047 to UTF-8.
I suspect that when doing a MBCS conversion, FTP attempts to break the
input data into lines and convert them one at a time.  Perhaps it is done
this way from concern that a buffer might otherwise contain an incomplete
character.  In:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.bpxbd00/iconvp.htm
 
iconv() — Code conversion
z/OS XL C/C++ Runtime Library Reference
SC14-7314-00
...
If the input buffer ends with an incomplete character or shift sequence, 
conversion stops
after the previous successfully converted bytes, and iconv() sets errno to 
EINVAL.

There's a straightforward technique to recover from this that does not require 
breaking
the input data into lines nor a priori knowedge of where the data may be 
separated
into characters.

They could have done better.

-- gil

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

Re: FTP Question

[Paul Gilmartin]

On Tue, 23 Sep 2014 20:08:55 -0400, Shmuel Metz (Seymour J.) wrote:

Awww c'mon! what codepoint can possibly have no UTF-8
representation!?

Is it saying that an EBCDIC character has no Unicode equivalent, or
that a Unicode character has no EBCDIC equivalent? The later is likely
to be a frequent occurrence.
 
My source was IBM-1047; my destination was UTF-8.  But Bill Godfrey
had the correct explanation (perhaps through bitter experience?)  It's
the z/OS FTP server's enigmatic way of telling me the last line of the
file was incomplete.

-- gil

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

Re: FTP Question

[Shmuel Metz (Seymour J.)]

In 3301410553087520.wa.paulgboulderaim@listserv.ua.edu, on
09/24/2014
   at 01:14 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

My source was IBM-1047; my destination was UTF-8.  But Bill Godfrey
had the correct explanation

Curiouser and curiouser. RFC 959 does not define 557, nor does it
require an end-of-line sequence for data in stream mode.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Bill Godfrey]

On Wed, 24 Sep 2014 07:57:21 -0400, Shmuel Metz (Seymour J.) 
shmuel+ibm-m...@patriot.net wrote:

In 3301410553087520.wa.paulgboulderaim@listserv.ua.edu, on
09/24/2014
   at 01:14 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

My source was IBM-1047; my destination was UTF-8.  But Bill Godfrey
had the correct explanation

Curiouser and curiouser. RFC 959 does not define 557, nor does it
require an end-of-line sequence for data in stream mode.


On the off chance that this is worth trying to unravel, here is an excerpt from 
Paul's post:

(begin quote)

ftp quote site encoding=sbcs
200 SITE command was accepted
ftp quote site sbdataconn=(IBM-1047,UTF-8)
200-Some characters cannot be translated between UTF-8 and IBM-1047
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8
local: chars.UTF-8 remote: chars.a2e
229 Entering Extended Passive Mode (|||11526|)
125 Sending data set /u/user/chars.a2e
 00.00 KiB/s 
557 Data contains codepoints that cannot be translated

Awww c'mon! what codepoint can possibly have no UTF-8 representation!?

ftp quote site encoding=mbcs
200 SITE command was accepted
ftp quote site mbdataconn=(IBM-1047,UTF-8)
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8-M
local: chars.UTF-8-M remote: chars.a2e
229 Entering Extended Passive Mode (|||11528|)
125 Sending data set /u/user/chars.a2e
12  162.75 KiB/s
451 File transfer failed. Multi-byte data conversion error occurred
12 bytes received in 00:00 (0.30 KiB/s)

(end quote)

I was able to explain the 451 message as being related to a missing end-of-line.

Paul mistakenly thought your quoting his Awww c'mon comment was about the 
problem with the 451 message, but it wasn't.

The 557 message is from a different transfer, and has a different explanation, 
which is that UTF-8 translation was being attempted with SBCS.

There was a 200 warning that some characters cannot be translated even before 
the get command.

Bill

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

Re: FTP Question

[Paul Gilmartin]

On 2014-09-24 15:29, Bill Godfrey wrote:
 On Wed, 24 Sep 2014 07:57:21 -0400, Shmuel Metz (Seymour J.) wrote:
 
 on 09/24/2014
   at 01:14 AM, Paul Gilmartin said:

 My source was IBM-1047; my destination was UTF-8.  But Bill Godfrey
 had the correct explanation

 Curiouser and curiouser. RFC 959 does not define 557, nor does it

I thought implementers are given some latitude to invent new codes
and full freedom to define message texts within any severity level

 require an end-of-line sequence for data in stream mode.

It's IBMthink.  Every file must consist of a sequence of records.
But the message should be more explicit -- multiple lines if needed.

 On the off chance that this is worth trying to unravel, here is an excerpt 
 from Paul's post:
  
Barely worth it -- Shmuel has an incorrigible bad habit of
trimming to where the citation is unidentifiable.  But I'll
trim some more.

 (begin quote)
 
 ftp quote site sbdataconn=(IBM-1047,UTF-8)
 200-Some characters cannot be translated between UTF-8 and IBM-1047

FTP is just being cautious here; it can't anticipate whether I intend
to do a GET from IBM-1047 to UTF-8 or a PUT from UTF-8 to IBM-1047.

 200 SITE command was accepted 

I hate that.  It says 200 even for the most invalid SITE command.  I've
argued with IBM about that.  They say it means only that there was no
transmission error passing the SITE command, not that it was valid.

 ftp get chars.a2e chars.UTF-8
 local: chars.UTF-8 remote: chars.a2e
 229 Entering Extended Passive Mode (|||11526|)
 125 Sending data set /u/user/chars.a2e
  00.00 KiB/s 
 557 Data contains codepoints that cannot be translated
 
 Awww c'mon! what codepoint can possibly have no UTF-8 representation!?

 I was able to explain the 451 message as being related to a missing 
 end-of-line.
 
 Paul mistakenly thought your quoting his Awww c'mon comment was about the 
 problem with the 451 message, but it wasn't.
 
 The 557 message is from a different transfer, and has a different 
 explanation, which is that UTF-8 translation was being attempted with SBCS.
  
Why is there a distinction between encoding=mbcs and encoding=sbcs?
Isn't that implicit in the code pages being used, or is there a code
page with a single ID that exists in both SB and MB variants?

-- gil

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

Re: FTP Question

[Shmuel Metz (Seymour J.)]

In 542047ec.2060...@custserv.com, on 09/22/2014
   at 12:01 PM, Mark Jacobs mark.jac...@custserv.com said:

One of my users is trying to send a mainframe file to another sever, 
converting it to UTF-8 with Byte Order Mark(BOM).

BOM? For UTF-8? Why?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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 Question

[Paul Gilmartin]

On Mon, 22 Sep 2014 12:01:48 -0400, Mark Jacobs wrote:

One of my users is trying to send a mainframe file to another sever,
converting it to UTF-8 with Byte Order Mark(BOM). So far he hasn't been
able to get it to work, Has anyone here been able to do so? These are
some of the things he's tried. (and variations of)

site encoding=mbcs
site mbdataconn(IBM-037,UTF-8)
site unicodefilesystembom=always **

OK.  There's a consensus (Shmuel and I agree) that BOM is undesirable
in UTF-8.  Beyond that, I've long suspected that z/OS FTP is inadequate
in that it will not translate SBCS--MBCS.  This really ought to be worth
an ER.  An experiment with OS X client and z/OS server:

ftp quote site encoding=sbcs
200 SITE command was accepted
ftp quote site sbdataconn=(IBM-1047,UTF-8)
200-Some characters cannot be translated between UTF-8 and IBM-1047
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8
local: chars.UTF-8 remote: chars.a2e
229 Entering Extended Passive Mode (|||11526|)
125 Sending data set /u/user/chars.a2e
 00.00 KiB/s 
557 Data contains codepoints that cannot be translated

Awww c'mon! what codepoint can possibly have no UTF-8 representation!?


ftp quote site encoding=mbcs
200 SITE command was accepted
ftp quote site mbdataconn=(IBM-1047,UTF-8)
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8-M
local: chars.UTF-8-M remote: chars.a2e
229 Entering Extended Passive Mode (|||11528|)
125 Sending data set /u/user/chars.a2e
12  162.75 KiB/s
451 File transfer failed. Multi-byte data conversion error occurred
12 bytes received in 00:00 (0.30 KiB/s)

ftp quote SYST
215 UNIX is the operating system of this server. FTP Server is running on z/OS.

-- gil

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

Re: FTP Question

[Paul Gilmartin]

On Mon, 22 Sep 2014 12:01:48 -0400, Mark Jacobs  wrote:

One of my users is trying to send a mainframe file to another sever,
converting it to UTF-8 with Byte Order Mark(BOM). So far he hasn't been
able to get it to work, Has anyone here been able to do so? These are
some of the things he's tried. (and variations of)

(Ignoring the BOM compulsion)

I was able to do this using the unusual FIFO facility of z/OS FTP,
performing the conversion with iconv(1).  On z/OS:

user@HOST: cd /tmp/user
user@HOST: mkfifo utfpipe
user@HOST: ( cp //'sys1.maclib(yregs)' /dev/fd/1 |
iconv -f IBM-1047 -t UTF-8  utfpipe )  

(This might as well be done using a temporary file.)
Then on an OS X client (I rarely run FTP server on my desktop):

516 $ ftp user@mvs
220-FTPD1 IBM FTP CS V1R13 at LSTC3MVS.US.ORACLE.COM, 13:04:09 on 
2014-09-23.
Password: 
Remote system type is MVS.
ftp binary
ftp quote site UNIXFILETYPE=FIFO
ftp cd /tmp/user
ftp get utfpipe utf8
local: utf8 remote: utfpipe
ftp quit

-- gil

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

Re: FTP Question

[Bill Godfrey]

On Tue, 23 Sep 2014 07:16:39 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

On Mon, 22 Sep 2014 12:01:48 -0400, Mark Jacobs wrote:

One of my users is trying to send a mainframe file to another sever,
converting it to UTF-8 with Byte Order Mark(BOM). So far he hasn't been
able to get it to work, Has anyone here been able to do so? These are
some of the things he's tried. (and variations of)

site encoding=mbcs
site mbdataconn(IBM-037,UTF-8)
site unicodefilesystembom=always **

OK.  There's a consensus (Shmuel and I agree) that BOM is undesirable
in UTF-8.  Beyond that, I've long suspected that z/OS FTP is inadequate
in that it will not translate SBCS--MBCS.  This really ought to be worth
an ER.  An experiment with OS X client and z/OS server:

ftp quote site encoding=sbcs
200 SITE command was accepted
ftp quote site sbdataconn=(IBM-1047,UTF-8)
200-Some characters cannot be translated between UTF-8 and IBM-1047
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8
local: chars.UTF-8 remote: chars.a2e
229 Entering Extended Passive Mode (|||11526|)
125 Sending data set /u/user/chars.a2e
 00.00 KiB/s 
557 Data contains codepoints that cannot be translated

Awww c'mon! what codepoint can possibly have no UTF-8 representation!?


ftp quote site encoding=mbcs
200 SITE command was accepted
ftp quote site mbdataconn=(IBM-1047,UTF-8)
200 SITE command was accepted
ftp get chars.a2e chars.UTF-8-M
local: chars.UTF-8-M remote: chars.a2e
229 Entering Extended Passive Mode (|||11528|)
125 Sending data set /u/user/chars.a2e
12  162.75 KiB/s
451 File transfer failed. Multi-byte data conversion error occurred
12 bytes received in 00:00 (0.30 KiB/s)

ftp quote SYST
215 UNIX is the operating system of this server. FTP Server is running on z/OS.

I have seen the very misleading 451 message when attempting this with a USS 
file in which the last line does not end with hex 15.

If that is the case with your chars.a2e file, if you try the multi-byte 
transfer again after appending hex 15 to it, it should work.

Bill

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

Re: FTP Question

[Paul Gilmartin]

On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey bgodfrey...@gmail.com wrote:

125 Sending data set /u/user/chars.a2e
12  162.75 KiB/s
451 File transfer failed. Multi-byte data conversion error occurred
12 bytes received in 00:00 (0.30 KiB/s)

ftp quote SYST
215 UNIX is the operating system of this server. FTP Server is running on 
z/OS.

I have seen the very misleading 451 message when attempting this with a USS 
file in which the last line does not end with hex 15.

If that is the case with your chars.a2e file, if you try the multi-byte 
transfer again after appending hex 15 to it, it should work.
 
Yup.  Works.  Given that the TCP/IP message texts are implementation-defined
they could supply in this case a more meaniingful message text, such as:

451 Incomplete last line

Remote system type is MVS.
ftp ascii
200 Representation type is Ascii NonPrint
ftp quote site encoding=mbcs
200 SITE command was accepted
ftp site mbdataconn=(IBM-1047,UTF-8)
200 SITE command was accepted
ftp get chars.a2enl
local: chars.a2enl remote: chars.a2enl
229 Entering Extended Passive Mode (|||11776|)
125 Sending data set chars.a2enl
   387  560.72 KiB/s 
250 Transfer completed successfully.
387 bytes received in 00:00 (1.46 KiB/s)

501 $ cat chars.a2enl

!#$%'()*+,-./0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~€‚ƒ„
…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ 
¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ

Thanks,
gil

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

Incomplete last line (was: FTP Question)

[Paul Gilmartin]

On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:

I have seen the very misleading 451 message when attempting this with a USS 
file in which the last line does not end with hex 15.

If that is the case with your chars.a2e file, if you try the multi-byte 
transfer again after appending hex 15 to it, it should work.

Yes, it worked.  But it raises a number of questions.

o Is there a utility that will append \n only if the file doesn't already 
contain one?
  I tried a simple sed script.  It failed on z/OS because my test case, 
intentionally
  containing every EBCDIC code point, contained a NUL.  On Solaris, sed 
quietly
  discarded the NUL (which is hardly better); complained about the incomplete
  last line and supplied the n.

o So it's possible to have data errors in a text file.  It would be the least 
courtesy
  to the programmer to report the point of error; byte offset in a UNIX file, 
line and
  column in a legacy data set.  TCP/IP supports multi-line messages; this is a 
good
  application for such.

o Unterminated last lines are endemic in Windows; it may be a convention.  Will
  a Windows to Windows FTP transfer preserve them?

o What FTP agents enforce the LINE_MAX limit when transferring text files?

-- gil

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

Re: Incomplete last line (was: FTP Question)

[Bill Godfrey]

On Tue, 23 Sep 2014 15:03:21 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:

I have seen the very misleading 451 message when attempting this with a USS 
file in which the last line does not end with hex 15.

If that is the case with your chars.a2e file, if you try the multi-byte 
transfer again after appending hex 15 to it, it should work.

Yes, it worked.  But it raises a number of questions.

o Is there a utility that will append \n only if the file doesn't already 
contain one?
  I tried a simple sed script.  It failed on z/OS because my test case, 
 intentionally
  containing every EBCDIC code point, contained a NUL.  On Solaris, sed 
 quietly
  discarded the NUL (which is hardly better); complained about the incomplete
  last line and supplied the n.

#!/bin/sh
if [ $# -gt 0 ] ; then
 endbyte=`tail -c1 $1 | od -tc -An | awk '{ print $1 }'`
 if [ ${endbyte} != '\n' ] ; then
  echo  $1
 fi
fi


o So it's possible to have data errors in a text file.  It would be the least 
courtesy
  to the programmer to report the point of error; byte offset in a UNIX file, 
 line and
  column in a legacy data set.  TCP/IP supports multi-line messages; this is a 
 good
  application for such.

o Unterminated last lines are endemic in Windows; it may be a convention.  Will
  a Windows to Windows FTP transfer preserve them?

o What FTP agents enforce the LINE_MAX limit when transferring text files?


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

Re: Incomplete last line (was: FTP Question)

[Kirk Wolf]

Here's one way in the z/OS Unix shell to add a missing newline to the end
of a text file:

last=$(tail -c1 myfile)
test ${#last} != 0  echo   myfile

This is pretty efficient, but fails to add a newline if the file ends in a
nul (0x00) character.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Sep 23, 2014 at 3:03 PM, Paul Gilmartin 
000433f07816-dmarc-requ...@listserv.ua.edu wrote:

 On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:
 
 I have seen the very misleading 451 message when attempting this with a
 USS file in which the last line does not end with hex 15.
 
 If that is the case with your chars.a2e file, if you try the multi-byte
 transfer again after appending hex 15 to it, it should work.
 
 Yes, it worked.  But it raises a number of questions.

 o Is there a utility that will append \n only if the file doesn't
 already contain one?
   I tried a simple sed script.  It failed on z/OS because my test case,
 intentionally
   containing every EBCDIC code point, contained a NUL.  On Solaris, sed
 quietly
   discarded the NUL (which is hardly better); complained about the
 incomplete
   last line and supplied the n.

 o So it's possible to have data errors in a text file.  It would be the
 least courtesy
   to the programmer to report the point of error; byte offset in a UNIX
 file, line and
   column in a legacy data set.  TCP/IP supports multi-line messages; this
 is a good
   application for such.

 o Unterminated last lines are endemic in Windows; it may be a convention.
 Will
   a Windows to Windows FTP transfer preserve them?

 o What FTP agents enforce the LINE_MAX limit when transferring text files?

 -- 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: Incomplete last line (was: FTP Question)

[Paul Gilmartin]

On Tue, 23 Sep 2014 16:27:06 -0500, Bill Godfrey wrote:

o Is there a utility that will append \n only if the file doesn't already 
contain one?

#!/bin/sh
if [ $# -gt 0 ] ; then
 endbyte=`tail -c1 $1 | od -tc -An | awk '{ print $1 }'`
 if [ ${endbyte} != '\n' ] ; then
  echo  $1
 fi
fi

Ah!  I failed to think of the tail -c1.  I see you've struggled with
this and won.

o It modifies its input file.  But that's what I asked for.

o It converts an empty file to a file of one empty line.  That's
  literally what I asked for; I should have said, ... append \n
  only if the file has an incomplete last line.

A simplification, fixing my unintended second requirement:

#!/bin/sh
if [ $# -gt 0 ] ; then
 case $(tail -c1 $1) in
'' | '
' );;
*) echo $1;;  esac
fi

Thanks.  Now IBM-MAIN can return to its proper function of discussing
what's the fastest way to clear a register.

Thanks again,
gil

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

Re: FTP Question

[Shmuel Metz (Seymour J.)]

In 4714758658531703.wa.paulgboulderaim@listserv.ua.edu, on
09/23/2014
   at 07:16 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

Awww c'mon! what codepoint can possibly have no UTF-8
representation!?

Is it saying that an EBCDIC character has no Unicode equivalent, or
that a Unicode character has no EBCDIC equivalent? The later is likely
to be a frequent occurrence.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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

FTP Question

[Mark Jacobs]

One of my users is trying to send a mainframe file to another sever, 
converting it to UTF-8 with Byte Order Mark(BOM). So far he hasn't been 
able to get it to work, Has anyone here been able to do so? These are 
some of the things he's tried. (and variations of)


site encoding=mbcs

site mbdataconn(IBM-037,UTF-8)

site unicodefilesystembom=always **

--
Mark Jacobs
Time Customer Service
Tampa, FL


The standard you walk past is the standard you accept.
Lt. Gen. David Morrison, Australian Army Chief


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

Re: FTP Question

[Paul Gilmartin]

On Mon, 22 Sep 2014 12:01:48 -0400, Mark Jacobs wrote:

One of my users is trying to send a mainframe file to another sever,
converting it to UTF-8 with Byte Order Mark(BOM). So far he hasn't been
able to get it to work, Has anyone here been able to do so? These are
some of the things he's tried. (and variations of)

site encoding=mbcs
site mbdataconn(IBM-037,UTF-8)
site unicodefilesystembom=always **

Is UTF-8 really Byte Order sensitive?  That sucks!

http://en.wikipedia.org/wiki/UTF-8#Byte_order_mark
The Unicode Standard neither requires nor recommends the use of the BOM for 
UTF-8.[30]
The presence of the UTF-8 BOM may cause interoperability problems with 
existing software
that could otherwise handle UTF-8;

-- gil

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