Re: Zfs from 1 LPAR to another

[Vernooij, Kees (ITOP NM) - KLM]

Barbara,

Did you transport the catalog dump dataset with ftp? 
If yes, this might again point to ftp.
If not, the problem must be in the dump dataset. Then DFdss dump produces (can 
produce) a non-standard recfm=u dataset, that will be processed correctly by 
dfdss restore, but might confuse other programs reading it. This should be 
documented with DFdss in my opinion.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: 07 November 2019 06:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

>For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that 
>needed it.  Worked fine, until it didn't.  IBM's response to the PMR that I 
>opened is that the only 100% reliable way to FTP a DFDSS dump file was to 
>terse it first.  IBM does not support direct FTP of a DFDSS dump file.  So I 
>now terse every DFDSS dump file before FTPing it to other systems, and I 
>haven't had another failure in 6 years.  As I said, it will work until it 
>doesn't.

And just to add my two cents: A few years back I tried to migrate a (user) 
catalog from one RDT lpar (where I had things customized) to another RDT lpar 
(at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS 
imported the catalog with RC=0, but the content was completely unusable. Trying 
to access any data set in that catalog on the DASD (that had also been 
migrated, but not via ftp) resulted in a plethora of strange rc/rsn 
combinations that really didn't make any sense. I eventually tersed the catalog 
dump and untersed/restored/imported on the other side. Now the data sets were 
accessible without any problems.
I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I 
need to send it somewhere via ftp otherwise the results could get 
unpredictable. I don't think there's anything worse than a dataset that may or 
may not have been altered subtly. Don't take any chances, even if this is not 
clearly documented anywhere.

Regards, Barbara

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: MIPS chart for all IBM hardware model

[Parwez Hamid]

https://www-01.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r2?OpenDocument
IBM Resource Link: IBM Z LSPR ITR ratios for IBM processors where each model is 
configured with multiple z/OS images based on an average LPAR profile of client 
systems
This IBM Resource Link web page is the source for IBM Z LSPR ITR ratios for IBM 
processors where each model is configured with multiple z/OS images based on an 
average LPAR profile of client systems.
www-01.ibm.com


Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
Peter 
Sent: 07 November 2019 07:16
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: MIPS chart for all IBM hardware model

Hi All

I am looking for a document which describes all the IBM machine model with
their MIPS, SU/sec etc .

There used to be used to be site which used to provide but i am unable to
find it.

Could someone please forward it to me?

Peter

--
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: MIPS chart for all IBM hardware model

[Gerhard Adam]

You can see it on the IBM site  (search -SRM Constant ).  You should also see 
it in the Planning WLM manual, I believe Appendix B


MIPS do NOT exist, and are simply made up numbers.They are a loose 
conglomeration that is similar to ITR.   (where a 370/158 is considered a 1 
MIPS machine).   The concept simply doesn't exist in today's systems so that 
anyone claims it represents something, I would really like to hear the basis 
for their belief and evidence.

G.

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

MIPS chart for all IBM hardware model

[Peter]

Hi All

I am looking for a document which describes all the IBM machine model with
their MIPS, SU/sec etc .

There used to be used to be site which used to provide but i am unable to
find it.

Could someone please forward it to me?

Peter

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

Re: Zfs from 1 LPAR to another

[Bruce Hewson]

Tom,

one reason for IODF Restore to build an unusable file is when it restores with 
multiple extents.

IODF datasets must be single extent only.

Regards
Bruce Hewson

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

Re: Zfs from 1 LPAR to another

[Barbara Nitz]

>For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that 
>needed it.  Worked fine, until it didn't.  IBM's response to the PMR that I 
>opened is that the only 100% reliable way to FTP a DFDSS dump file was to 
>terse it first.  IBM does not support direct FTP of a DFDSS dump file.  So I 
>now terse every DFDSS dump file before FTPing it to other systems, and I 
>haven't had another failure in 6 years.  As I said, it will work until it 
>doesn't.

And just to add my two cents: A few years back I tried to migrate a (user) 
catalog from one RDT lpar (where I had things customized) to another RDT lpar 
(at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS 
imported the catalog with RC=0, but the content was completely unusable. Trying 
to access any data set in that catalog on the DASD (that had also been 
migrated, but not via ftp) resulted in a plethora of strange rc/rsn 
combinations that really didn't make any sense. I eventually tersed the catalog 
dump and untersed/restored/imported on the other side. Now the data sets were 
accessible without any problems.
I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I 
need to send it somewhere via ftp otherwise the results could get 
unpredictable. I don't think there's anything worse than a dataset that may or 
may not have been altered subtly. Don't take any chances, even if this is not 
clearly documented anywhere.

Regards, Barbara

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

Re: File I/O Metal C documentation error

[Joseph Reichman]

I originally took out all libraries that reference LE as metal is not dependent 
on them I now put them in and got a clean link/bind hope is does not blow up 
when I try run it as LE structure is different then metal

  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack J. Woehr
Sent: Wednesday, November 6, 2019 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File I/O Metal C documentation error

On 11/6/19 5:35 PM, Joseph Reichman wrote:
> Looking at the cross reference at the bottom of the  z/OS Metal C 
> Programming Guide and Reference  "fopen() library function 57" However 
> fopen is nowhere to be found anywhere else

fopen() is a Standard C Library function. If you have a standard C compiler, 
fopen() is there and documented everywhere.

E.g.,
https://en.wikibooks.org/wiki/C%2B%2B_Programming/Code/Standard_C_Library/Functions/fopen

-- 
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe 
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
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: File I/O Metal C documentation error

[Jack J. Woehr]

On 11/6/19 5:35 PM, Joseph Reichman wrote:

Looking at the cross reference at the bottom of the  z/OS Metal C
Programming Guide and Reference  "fopen() library function 57" However fopen
is nowhere to be found anywhere else


fopen() is a Standard C Library function. If you have a standard C 
compiler, fopen() is there and documented everywhere.


E.g., 
https://en.wikibooks.org/wiki/C%2B%2B_Programming/Code/Standard_C_Library/Functions/fopen


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

File I/O Metal C documentation error

[Joseph Reichman]

Hi

 

Looking at the cross reference at the bottom of the  z/OS Metal C
Programming Guide and Reference  "fopen() library function 57" However fopen
is nowhere to be found anywhere else

 

Seem that if I have to do file i/o in Metal C I have to write my own library
functions ?

 

 


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

Re: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Salva Carrasco]

As i remember:

ispf/rexx spawn a java that redirect stdin/stdout to unix pipes filetypes.

Rexx open the pipes with syscall functions. Send request to stdin & receive 
response from stdout, with a start/end of response known protocol.

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

Re: git with it

[Paul Gilmartin]

On Wed, 6 Nov 2019 18:48:30 +, Seymour J Metz wrote:

>How do I write "plus ça change, plus c'est la même chose" or "רד ממני" in 
>ASCII?
>It's even more limited than EBCDIC.
>
>...  I hate ASCII and all of those code pages, and hope that everything will 
>soon be Unicode.
>
+1
EBCDIC is scarcely better.  Is there an EBCDIC CCSID that handles
your example?  (But I suspect you're using 1208.):
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"


On Wed, 6 Nov 2019 07:59:54 -0600, Mohammad Khan wrote:
>
>Is there a wired version as well !? 
>
Like many web pages nowadays, the handheld version appears
radically different from the desktop.


On Wed, 6 Nov 2019 11:11:06 wrote:
>...
>yeah a lot of people are not found of EBCDIC ...ascii much easier
>
Mostly, "When in Rome ..."  (But think globally.)

-- gil

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

Re: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Paul Gilmartin]

On Wed, 6 Nov 2019 14:30:31 -0600, Lionel B Dyck wrote:

>The biggest gain was using the environmental stem for bpxwunix that I 
>implemented this morning after some testing.  I will check out that 
>bpx_shareas shortly as it sounds interesting.
> 
Details?  What did you put in that environmental stem?
env.0=???
env.1=???
...???

>-Original Message-
>From:  Salva Carrasco
>Sent: Wednesday, November 6, 2019 2:20 PM
>...
>Some time ago, I was working in a similar issue: Ispf calling Java. The 
>creation of the JVM was really heavy, so we changed java code to accept 
>subcommand from stdin, "forked" it and communicate with the Ispf/Rexx code 
>using pipes.
>
I assume POSIX pipes rather than CMS/TSO/BATCHPIPES.  Can
your forked address space address ISPEXEC/ISREDIT subcommands
through such a pipe?  I believe you'd need a daemon lingering in
the parent process to do that.

--gil

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

Re: RUCSA

[Tom Conley]

On 11/6/2019 4:02 PM, Chris Hoelscher wrote:

At our shop we finally altered IDMS environments to run in KEY 4 - IDMS was the 
last holdout requiring USERKEY(YES)

Thank You,
Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 
502.476.2538  or 502.407.7266



CA, er, Broadcom, could have changed IDMS to fix this, instead of 
fobbing it off on us.  I've never used another product where I had to 
set the USERKEY.  They were just too lazy to modernize and use 
cross-memory instead of the SVC.  Don't get me started.


Regards,
Tom Conley

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

Re: Zfs from 1 LPAR to another

[Tom Conley]

On 11/6/2019 10:02 AM, Vernooij, Kees - KLM , ITOP NM wrote:

Can you point to where that is documented?
We FTP a lot b.m.o. DFDSS between Sysplexes.

Kees.



Kees,

I cannot find it documented anywhere.  It's what IBM told me in response 
to a PMR.


Regards,
Tom Conley

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

Re: RUCSA

[Charles Mills]

I got the impression -- hopefully not talking out of school here -- that MVS 
development dropped everything to do the feature, so there was a distinct cost 
to IBM, and I think part of the model was that it was to be a chargeable 
feature. 

Customers were saying "we really, really, really need you to do this" so the 
obvious question becomes "would you be willing to pay for it?"

Also I think a certain amount of "if we TELL them it is a bad idea they will go 
on doing it forever anyway. If we CHARGE them for it perhaps they will make it 
a priority to stop doing it."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Wednesday, November 6, 2019 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

On 11/6/2019 2:38 PM, Jousma, David wrote:
> Folks,
> 
> Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
> manual, the only clue I find is it is a separate line-item in ShopZ, so 
> thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for a 
> bit of confirmation
> 
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
> [cid:image003.png@01D4F915.C9E34050]
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 616.653.8429  |  fax: 616.653.2717

Dave,

It is chargeable.  Youse wants to break da rules, IBM wants da money ;-)

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

Re: RUCSA

[Chris Hoelscher]

At our shop we finally altered IDMS environments to run in KEY 4 - IDMS was the 
last holdout requiring USERKEY(YES)

Thank You,
Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 
502.476.2538  or 502.407.7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Conley
Sent: Wednesday, November 6, 2019 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] RUCSA

On 11/6/2019 2:38 PM, Jousma, David wrote:
> Folks,
> 
> Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
> manual, the only clue I find is it is a separate line-item in ShopZ, so 
> thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for a 
> bit of confirmation
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> [cid:image003.png@01D4F915.C9E34050]
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717

Dave,

It is chargeable.  Youse wants to break da rules, IBM wants da money ;-)

Regards,
Tom Conley

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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

Re: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Lionel B Dyck]

The biggest gain was using the environmental stem for bpxwunix that I 
implemented this morning after some testing.  I will check out that bpx_shareas 
shortly as it sounds interesting.

Thank you


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Salva Carrasco
Sent: Wednesday, November 6, 2019 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improving the performance of an ISPF app using OMVS services 
(bpxwunix)

Hi Lionel.

Have you tried bpx_shareas in the env. stem passed to BPXWUNIX?

Are you running a unix command or starting a shell script?

Is your command "apf"?

Some time ago, I was working in a similar issue: Ispf calling Java. The 
creation of the JVM was really heavy, so we changed java code to accept 
subcommand from stdin, "forked" it and communicate with the Ispf/Rexx code 
using pipes.

Regards, and good luck with zigi.

--
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: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Salva Carrasco]

Hi Lionel.

Have you tried bpx_shareas in the env. stem passed to BPXWUNIX?

Are you running a unix command or starting a shell script?

Is your command "apf"?

Some time ago, I was working in a similar issue: Ispf calling Java. The 
creation of the JVM was really heavy, so we changed java code to accept 
subcommand from stdin, "forked" it and communicate with the Ispf/Rexx code 
using pipes.

Regards, and good luck with zigi.

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

Re: RUCSA

[Tom Conley]

On 11/6/2019 2:38 PM, Jousma, David wrote:

Folks,

Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
manual, the only clue I find is it is a separate line-item in ShopZ, so 
thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for a 
bit of confirmation

_
Dave Jousma
AVP | Manager, Systems Engineering
[cid:image003.png@01D4F915.C9E34050]

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


Dave,

It is chargeable.  Youse wants to break da rules, IBM wants da money ;-)

Regards,
Tom Conley

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

Re: RUCSA

[Jousma, David]

Thank-you!  I looked, but must have missed that.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, November 6, 2019 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote:

>Remind me, is RUCSA support a chargeable feature?  I find nothing in 
>the manual, the only clue I find is it is a separate line-item in 
>ShopZ, so thinking it may be chargeable, and enabled via IFAPRDxx?
>Just looking for a bit of confirmation

Seems to be chargeable. From the z/OS 2.4 announcement:

Removal of support of YES setting for VSM ALLOWUSERKEYCSA DIAGxx parmlib 
parameter: z/OS V2.3 will be the last release of z/OS to support the YES 
setting for the VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter. If you run any 
software that requires the setting of this parameter to YES, the software will 
need to be changed to no longer require the setting of this parameter to YES or 
the optional priced RUCSA feature will be required.


--
Tom Marchant

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

**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: RUCSA

[Tom Marchant]

On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote:

>Remind me, is RUCSA support a chargeable feature?  I find nothing 
>in the manual, the only clue I find is it is a separate line-item in 
>ShopZ, so thinking it may be chargeable, and enabled via IFAPRDxx? 
>Just looking for a bit of confirmation

Seems to be chargeable. From the z/OS 2.4 announcement:

Removal of support of YES setting for VSM ALLOWUSERKEYCSA DIAGxx 
parmlib parameter: z/OS V2.3 will be the last release of z/OS to support 
the YES setting for the VSM ALLOWUSERKEYCSA DIAGxx parmlib 
parameter. If you run any software that requires the setting of this 
parameter to YES, the software will need to be changed to no longer 
require the setting of this parameter to YES or the optional priced RUCSA 
feature will be required.


-- 
Tom Marchant

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

RUCSA

[Jousma, David]

Folks,

Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
manual, the only clue I find is it is a separate line-item in ShopZ, so 
thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for a 
bit of confirmation

_
Dave Jousma
AVP | Manager, Systems Engineering
[cid:image003.png@01D4F915.C9E34050]

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



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: Zfs from 1 LPAR to another

[Seymour J Metz]

No, it has nothing to do with CKD, since it applies equally well to tape.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Wednesday, November 6, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has
> such a special (internal) format, that FTP cannot always handle it
> correctly, why can AMATERSE do this without problems?
>

A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on
DASD, with no imbedded (in the data) of where the record ends. This is a
artifact of the ECKD format that only the IBM z (as far as I know) uses.
AMATERSE encodes the length of each physical block actually read into its
data stream. And it produces FB output. So when you send it somewhere, the
LRECL is always known. AMATERSE uses the encoded data in the FB to restore
the data onto disk in the same PHYSICAL format that it was unloaded, making
it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS
format.



>
> If it FTP only, what is the special problem for FTP? What other dataset
> formats are a problem for FTP?
>

Not FTP only.



>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
>
--
People in sleeping bags are the soft tacos of the bear world.
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: git with it

[Seymour J Metz]

How do I write "plus ça change, plus c'est la même chose" or "רד ממני" in 
ASCII? It's even more limited than EBCDIC.

If you're going to talk about, e.g. ISO-8859-15, that's not ASCII.  I hate 
ASCII and all of those code pages, and hope that everything will soon be 
Unicode.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Wednesday, November 6, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git with it

Kirk:

yeah a lot of people are not found of EBCDIC ...ascii much easier

On Wed, Nov 6, 2019 at 11:10 AM scott Ford  wrote:

> Henri and Lionel,
>
> Wow , and Damn nice
>
> On Wed, Nov 6, 2019 at 9:00 AM Mohammad Khan  wrote:
>
>> On Tue, 5 Nov 2019 13:33:58 +, Henri Kuiper 
>> wrote:
>>
>> >;)
>> >
>> >Sent from my wireless iPhone
>> >
>>
>> Is there a wired version as well !?
>>
>> :)
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> http://secure-web.cisco.com/1lbn7zSQHTbLIb0vqnlDTreXnPT7Eoj-wHGTdOr3_YsGbVlnTJdwV_CxMl54EZY-D6I-UJt5rRSfLr3p76NfJKFB6BhEU22zUcy4CH6CgzuZTHc8BTL-Q3WvS6EnDHSJZsfkK6AWBJYdN9yW448KQV6iAD31RKX2EODIbbN_MbgQeBL5HZ4xUy2dhGt5da9u9TnTTh49RxpbTcGSGVsROKfaGA4q0S0jrKU0iwItdNzXn0PsSnLEc4NklpJcEjBqwKj3EBXITjJh42hlXatHc4zt1jYgc7AqQSajwNe2SczPuBQamNb8yDx7RENAwfmiAj0TC8edFNB1j0M7vR2kzhywMND2wwsI6gqQzSmoEYu_4CKE1DO5WKRZrQgvmjZATMfr1mrPz-sepBEHtU7yHbAbEgMIkOPNpP-90qbI7D-swCWCCet3-qv-k1F0AHhMR/http%3A%2F%2Fwww.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: 
> http://secure-web.cisco.com/13OxvxRwQMVIwxtlaCfNjf2MaB-6b9GQQm2WpO_2h5JKQgjuzbqK0ol5N4caA4-Cc7Bo57IexpKAQnZEsPjFn4BnZVGUaBoFGih0Ee_yHGGWxipMOwIKSnNDBDkeLc0nxb659ubmGLLxf3ZaezfQgP5CYYwPm9uKAbeDsUp6SnT6C-d3KQDqtasLgwauyfQ-uA_hyR5WNGP5pbiGN9HnEKdpL97vAlEE9l7LqmmBpR51ffp-zkqB4zEPGxf9TQp5fvrjORjFsVFq_Ofaz7G2fxaAjPciUsD734emU-zOkbAqdDQr7umLsoEBurJs1Gnu3PT2ez67VtZksYDu2w40mAVd-GSaVmVR4R4SeD7k5YQwV1DbHImFN7uPOeIIrSNxJ_8GjgLCBiX9_Xd5VE7RFZODXyF6S9jSMlNjcSK3whfiabc796fpbNbshyvC2ucsi/http%3A%2F%2Fwww.idmworks.com%2Fblog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>


--



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



http://secure-web.cisco.com/1lbn7zSQHTbLIb0vqnlDTreXnPT7Eoj-wHGTdOr3_YsGbVlnTJdwV_CxMl54EZY-D6I-UJt5rRSfLr3p76NfJKFB6BhEU22zUcy4CH6CgzuZTHc8BTL-Q3WvS6EnDHSJZsfkK6AWBJYdN9yW448KQV6iAD31RKX2EODIbbN_MbgQeBL5HZ4xUy2dhGt5da9u9TnTTh49RxpbTcGSGVsROKfaGA4q0S0jrKU0iwItdNzXn0PsSnLEc4NklpJcEjBqwKj3EBXITjJh42hlXatHc4zt1jYgc7AqQSajwNe2SczPuBQamNb8yDx7RENAwfmiAj0TC8edFNB1j0M7vR2kzhywMND2wwsI6gqQzSmoEYu_4CKE1DO5WKRZrQgvmjZATMfr1mrPz-sepBEHtU7yHbAbEgMIkOPNpP-90qbI7D-swCWCCet3-qv-k1F0AHhMR/http%3A%2F%2Fwww.idmworks.com

scott.f...@idmworks.com

Blog: 
http://secure-web.cisco.com/13OxvxRwQMVIwxtlaCfNjf2MaB-6b9GQQm2WpO_2h5JKQgjuzbqK0ol5N4caA4-Cc7Bo57IexpKAQnZEsPjFn4BnZVGUaBoFGih0Ee_yHGGWxipMOwIKSnNDBDkeLc0nxb659ubmGLLxf3ZaezfQgP5CYYwPm9uKAbeDsUp6SnT6C-d3KQDqtasLgwauyfQ-uA_hyR5WNGP5pbiGN9HnEKdpL97vAlEE9l7LqmmBpR51ffp-zkqB4zEPGxf9TQp5fvrjORjFsVFq_Ofaz7G2fxaAjPciUsD734emU-zOkbAqdDQr7umLsoEBurJs1Gnu3PT2ez67VtZksYDu2w40mAVd-GSaVmVR4R4SeD7k5YQwV1DbHImFN7uPOeIIrSNxJ_8GjgLCBiX9_Xd5VE7RFZODXyF6S9jSMlNjcSK3whfiabc796fpbNbshyvC2ucsi/http%3A%2F%2Fwww.idmworks.com%2Fblog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: git with it

[Mike Schwab]

Not much you can do with 127 characters and null.  Have you considered UTF-8?

On Wed, Nov 6, 2019 at 10:12 AM scott Ford  wrote:
>
> Kirk:
>
> yeah a lot of people are not found of EBCDIC ...ascii much easier
>
> On Wed, Nov 6, 2019 at 11:10 AM scott Ford  wrote:
>
> > Henri and Lionel,
> >
> > Wow , and Damn nice
> >
> > On Wed, Nov 6, 2019 at 9:00 AM Mohammad Khan  wrote:
> >
> >> On Tue, 5 Nov 2019 13:33:58 +, Henri Kuiper 
> >> wrote:
> >>
> >> >;)
> >> >
> >> >Sent from my wireless iPhone
> >> >
> >>
> >> Is there a wired version as well !?
> >>
> >> :)
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
> > --
> >
> >
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
> >
> >
> >
> > “By elevating a friend or Collegue you elevate yourself, by demeaning a
> > friend or collegue you demean yourself”
> >
> >
> >
> > www.idmworks.com
> >
> > scott.f...@idmworks.com
> >
> > Blog: www.idmworks.com/blog
> >
> >
> >
> >
> >
> > *The information contained in this email message and any attachment may be
> > privileged, confidential, proprietary or otherwise protected from
> > disclosure. If the reader of this message is not the intended recipient,
> > you are hereby notified that any dissemination, distribution, copying or
> > use of this message and any attachment is strictly prohibited. If you have
> > received this message in error, please notify us immediately by replying to
> > the message and permanently delete it from your computer and destroy any
> > printout thereof.*
> >
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Using malloc/Calloc under metal C

[Joseph Reichman]

Thanks regarding debugging I see David Cole Created another niche 





> On Nov 6, 2019, at 11:25 AM, scott Ford  wrote:
> 
> I had to dig around for Metal C info ..so been there
> 
>> On Wed, Nov 6, 2019 at 11:23 AM Joseph Reichman 
>> wrote:
>> 
>> Thanks BTW the only way to debug this code is debug the generated
>> assembler
>> 
>> 
>> There is no debug tool support for this which really isn’t a big deal for
>> me as getting zos explorer to work for AMODE 64 C code had proved to be a
>> challenge of its own
>> 
>> 
>> Thanks
 On Nov 6, 2019, at 11:16 AM, scott Ford  wrote:
>>> 
>>> Joe,
>>> 
>>> Did you checkout this url ?
>>> 
>>> https://www.metalc.guru/
>>> 
 On Wed, Nov 6, 2019 at 10:04 AM Joseph Reichman 
 wrote:
 
 Hi
 
 I am having all sorts of problems with LE in regards to XL C and
>> thinking
 of switching to METAL C
 
 I have a DLL but in practical purposes  that can be looked at as a bunch
 of C routines
 
 The routines work on storage accessed by the first function
 
 My question is under METAL C when you do a malloc / Calloc what is the
 life span of that storage
 
 Is it around after you leave the routine that allocated it
 
 Thanks
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
>>> 
>>> 
>>> --
>>> 
>>> 
>>> 
>>> *IDMWORKS *
>>> 
>>> Scott Ford
>>> 
>>> z/OS Dev.
>>> 
>>> 
>>> 
>>> 
>>> “By elevating a friend or Collegue you elevate yourself, by demeaning a
>>> friend or collegue you demean yourself”
>>> 
>>> 
>>> 
>>> www.idmworks.com
>>> 
>>> scott.f...@idmworks.com
>>> 
>>> Blog: www.idmworks.com/blog
>>> 
>>> 
>>> 
>>> 
>>> 
>>> *The information contained in this email message and any attachment may
>> be
>>> privileged, confidential, proprietary or otherwise protected from
>>> disclosure. If the reader of this message is not the intended recipient,
>>> you are hereby notified that any dissemination, distribution, copying or
>>> use of this message and any attachment is strictly prohibited. If you
>> have
>>> received this message in error, please notify us immediately by replying
>> to
>>> the message and permanently delete it from your computer and destroy any
>>> printout thereof.*
>>> 
>>> --
>>> 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
>> 
> 
> 
> -- 
> 
> 
> 
> *IDMWORKS *
> 
> Scott Ford
> 
> z/OS Dev.
> 
> 
> 
> 
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
> 
> 
> 
> www.idmworks.com
> 
> scott.f...@idmworks.com
> 
> Blog: www.idmworks.com/blog
> 
> 
> 
> 
> 
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
> 
> --
> 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: Using malloc/Calloc under metal C

[scott Ford]

I had to dig around for Metal C info ..so been there

On Wed, Nov 6, 2019 at 11:23 AM Joseph Reichman 
wrote:

> Thanks BTW the only way to debug this code is debug the generated
> assembler
>
>
> There is no debug tool support for this which really isn’t a big deal for
> me as getting zos explorer to work for AMODE 64 C code had proved to be a
> challenge of its own
>
>
> Thanks
> > On Nov 6, 2019, at 11:16 AM, scott Ford  wrote:
> >
> > Joe,
> >
> > Did you checkout this url ?
> >
> > https://www.metalc.guru/
> >
> >> On Wed, Nov 6, 2019 at 10:04 AM Joseph Reichman 
> >> wrote:
> >>
> >> Hi
> >>
> >> I am having all sorts of problems with LE in regards to XL C and
> thinking
> >> of switching to METAL C
> >>
> >> I have a DLL but in practical purposes  that can be looked at as a bunch
> >> of C routines
> >>
> >> The routines work on storage accessed by the first function
> >>
> >> My question is under METAL C when you do a malloc / Calloc what is the
> >> life span of that storage
> >>
> >> Is it around after you leave the routine that allocated it
> >>
> >> Thanks
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
> > --
> >
> >
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
> >
> >
> >
> > “By elevating a friend or Collegue you elevate yourself, by demeaning a
> > friend or collegue you demean yourself”
> >
> >
> >
> > www.idmworks.com
> >
> > scott.f...@idmworks.com
> >
> > Blog: www.idmworks.com/blog
> >
> >
> >
> >
> >
> > *The information contained in this email message and any attachment may
> be
> > privileged, confidential, proprietary or otherwise protected from
> > disclosure. If the reader of this message is not the intended recipient,
> > you are hereby notified that any dissemination, distribution, copying or
> > use of this message and any attachment is strictly prohibited. If you
> have
> > received this message in error, please notify us immediately by replying
> to
> > the message and permanently delete it from your computer and destroy any
> > printout thereof.*
> >
> > --
> > 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
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Using malloc/Calloc under metal C

[Joseph Reichman]

Thanks BTW the only way to debug this code is debug the generated assembler 


There is no debug tool support for this which really isn’t a big deal for me as 
getting zos explorer to work for AMODE 64 C code had proved to be a challenge 
of its own 


Thanks 
> On Nov 6, 2019, at 11:16 AM, scott Ford  wrote:
> 
> Joe,
> 
> Did you checkout this url ?
> 
> https://www.metalc.guru/
> 
>> On Wed, Nov 6, 2019 at 10:04 AM Joseph Reichman 
>> wrote:
>> 
>> Hi
>> 
>> I am having all sorts of problems with LE in regards to XL C and thinking
>> of switching to METAL C
>> 
>> I have a DLL but in practical purposes  that can be looked at as a bunch
>> of C routines
>> 
>> The routines work on storage accessed by the first function
>> 
>> My question is under METAL C when you do a malloc / Calloc what is the
>> life span of that storage
>> 
>> Is it around after you leave the routine that allocated it
>> 
>> Thanks
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> 
> -- 
> 
> 
> 
> *IDMWORKS *
> 
> Scott Ford
> 
> z/OS Dev.
> 
> 
> 
> 
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
> 
> 
> 
> www.idmworks.com
> 
> scott.f...@idmworks.com
> 
> Blog: www.idmworks.com/blog
> 
> 
> 
> 
> 
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
> 
> --
> 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: Using malloc/Calloc under metal C

[scott Ford]

Joe,

Did you checkout this url ?

https://www.metalc.guru/

On Wed, Nov 6, 2019 at 10:04 AM Joseph Reichman 
wrote:

> Hi
>
> I am having all sorts of problems with LE in regards to XL C and thinking
> of switching to METAL C
>
> I have a DLL but in practical purposes  that can be looked at as a bunch
> of C routines
>
> The routines work on storage accessed by the first function
>
> My question is under METAL C when you do a malloc / Calloc what is the
> life span of that storage
>
> Is it around after you leave the routine that allocated it
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: git with it

[scott Ford]

Kirk:

yeah a lot of people are not found of EBCDIC ...ascii much easier

On Wed, Nov 6, 2019 at 11:10 AM scott Ford  wrote:

> Henri and Lionel,
>
> Wow , and Damn nice
>
> On Wed, Nov 6, 2019 at 9:00 AM Mohammad Khan  wrote:
>
>> On Tue, 5 Nov 2019 13:33:58 +, Henri Kuiper 
>> wrote:
>>
>> >;)
>> >
>> >Sent from my wireless iPhone
>> >
>>
>> Is there a wired version as well !?
>>
>> :)
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: git with it

[scott Ford]

Henri and Lionel,

Wow , and Damn nice

On Wed, Nov 6, 2019 at 9:00 AM Mohammad Khan  wrote:

> On Tue, 5 Nov 2019 13:33:58 +, Henri Kuiper 
> wrote:
>
> >;)
> >
> >Sent from my wireless iPhone
> >
>
> Is there a wired version as well !?
>
> :)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Zfs from 1 LPAR to another

[Sean Gleann]

I'd probably be inclined to use a TERSEd DFDSS dump, too - but that's just
because I don't implicitly 'trust' (read: 'understand') UNIXy things.

One such 'thing' I was shown was:
tar -cf -  ¦ ssh  -l  "cd  ; tar -vxf -"
Apparently this means something like: "create a tar ball of  on
stdout then pipe it through to stdin for input to an un-tar command, after
logging on to logging on to  and cd-ing to "
It worked without a problem the only time I used it but, as I say, I was
too darn scared of using it again. Too many possible ways of screwing up,
as far as I was concerned.

Sean

On Wed, 6 Nov 2019 at 15:45, David Spiegel  wrote:

> Hi Itschak AMV"SH,
> Why did you use IDTF format instead of TRS?
>
> Regards,
> David
>
> On 2019-11-06 10:22, ITschak Mugzach wrote:
> > Kees,
> >
> > Dfdss in general is not ftp freindly. When we faced that in a large data
> > movement project, we used xmit to convert the file format to xmt on one
> > side and rexyeive it on the other side.
> >
> > ITschak
> >
> >
> >
> > בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM ‏<
> > kees.verno...@klm.com>:
> >
> >> So do we.
> >>
> >> And I wonder what the actual problem is? If the DFDSS dump dataset has
> >> such a special (internal) format, that FTP cannot always handle it
> >> correctly, why can AMATERSE do this without problems?
> >>
> >> If it FTP only, what is the special problem for FTP? What other dataset
> >> formats are a problem for FTP?
> >>
> >> Questions, Fear, Uncertainty and Doubt...
> >>
> >> Kees.
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Lizette Koehler
> >> Sent: 06 November 2019 16:11
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Zfs from 1 LPAR to another
> >>
> >> I have always FTP a DFDSS dump of "things"  - What I was told to do long
> >> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS.
> >>
> >> This has never caused an issue (DFDSS ignores the Blksize).  And my
> >> Transfer have (knock wood) not failed.  And I have always been able to
> >> restore from the DFDSS dump.
> >>
> >>
> >> Lizette
> >>
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> >>> Sent: Wednesday, November 06, 2019 8:02 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Zfs from 1 LPAR to another
> >>>
> >>> Can you point to where that is documented?
> >>> We FTP a lot b.m.o. DFDSS between Sysplexes.
> >>>
> >>> Kees.
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Tom Conley
> >>> Sent: 06 November 2019 15:46
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Zfs from 1 LPAR to another
> >>>
> >>> On 11/5/2019 6:54 PM, Jousma, David wrote:
>  Terse, dont terse, your call.  I have 100% reliability as long as
>  the
> >>> destination disk dataset for the ftp is newly created.  If the
> >>> destination dataset already exists, then yes, there have been problems.
>  As you mention there are some specific options on the transfer to
>  specify,
> >>> and as long as you do, it will work fine.
>  Sending the dump file outside the company, probably not bad idea to
>  terse
> >>> since we are all familiar with it.
>  
>  __
>  ___
> 
>  Dave Jousma
> 
>  AVP | Manager, Systems Engineering
>  Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
>  Rapids, MI 49546
> 
>  616.653.8429  |  fax: 616.653.2717
>  
>  From: Tom Conley 
>  Sent: Tuesday, November 5, 2019 5:17 PM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: Re: Zfs from 1 LPAR to another
> 
> 
>  **CAUTION EXTERNAL EMAIL**
> 
>  **DO NOT open attachments or click on links from unknown senders or
>  unexpected emails**
> 
>  On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> > I always terse the dump file too. Had issues with Restore if the
> > file wasn't  tersed.
> >
> > On Wed, Nov 6, 2019, 03:53 Pierre Fichaud 
> wrote:
> >
> >> Dave,
> >>I'll do that. The files are not big.
> >>They can be sent as ZIP files.
> >> Thanks, Pierre
> >>
> >> --
> >> --
> >> -- 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
> >
>  Wayne 

Re: Zfs from 1 LPAR to another

[David Spiegel]

Hi Itschak AMV"SH,
Why did you use IDTF format instead of TRS?

Regards,
David

On 2019-11-06 10:22, ITschak Mugzach wrote:
> Kees,
>
> Dfdss in general is not ftp freindly. When we faced that in a large data
> movement project, we used xmit to convert the file format to xmt on one
> side and rexyeive it on the other side.
>
> ITschak
>
>
>
> בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM ‏<
> kees.verno...@klm.com>:
>
>> So do we.
>>
>> And I wonder what the actual problem is? If the DFDSS dump dataset has
>> such a special (internal) format, that FTP cannot always handle it
>> correctly, why can AMATERSE do this without problems?
>>
>> If it FTP only, what is the special problem for FTP? What other dataset
>> formats are a problem for FTP?
>>
>> Questions, Fear, Uncertainty and Doubt...
>>
>> Kees.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Lizette Koehler
>> Sent: 06 November 2019 16:11
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Zfs from 1 LPAR to another
>>
>> I have always FTP a DFDSS dump of "things"  - What I was told to do long
>> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS.
>>
>> This has never caused an issue (DFDSS ignores the Blksize).  And my
>> Transfer have (knock wood) not failed.  And I have always been able to
>> restore from the DFDSS dump.
>>
>>
>> Lizette
>>
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>>> Behalf Of Vernooij, Kees (ITOP NM) - KLM
>>> Sent: Wednesday, November 06, 2019 8:02 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Zfs from 1 LPAR to another
>>>
>>> Can you point to where that is documented?
>>> We FTP a lot b.m.o. DFDSS between Sysplexes.
>>>
>>> Kees.
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Tom Conley
>>> Sent: 06 November 2019 15:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Zfs from 1 LPAR to another
>>>
>>> On 11/5/2019 6:54 PM, Jousma, David wrote:
 Terse, dont terse, your call.  I have 100% reliability as long as
 the
>>> destination disk dataset for the ftp is newly created.  If the
>>> destination dataset already exists, then yes, there have been problems.
 As you mention there are some specific options on the transfer to
 specify,
>>> and as long as you do, it will work fine.
 Sending the dump file outside the company, probably not bad idea to
 terse
>>> since we are all familiar with it.
 
 __
 ___

 Dave Jousma

 AVP | Manager, Systems Engineering
 Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
 Rapids, MI 49546

 616.653.8429  |  fax: 616.653.2717
 
 From: Tom Conley 
 Sent: Tuesday, November 5, 2019 5:17 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Zfs from 1 LPAR to another


 **CAUTION EXTERNAL EMAIL**

 **DO NOT open attachments or click on links from unknown senders or
 unexpected emails**

 On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> I always terse the dump file too. Had issues with Restore if the
> file wasn't  tersed.
>
> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
>
>> Dave,
>>I'll do that. The files are not big.
>>They can be sent as ZIP files.
>> Thanks, Pierre
>>
>> --
>> --
>> -- 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
>
 Wayne beat me to it.  Terse any DFDSS file before sending.  You may
 get away with DFDSS with mode block and EBCDIC.  Until you don't.
 Terse it for 100% reliability.

 Regards,
 Tom Conley

>>> Dave,
>>>
>>> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR
>>> that needed it.  Worked fine, until it didn't.  IBM's response to the
>>> PMR that I opened is that the only 100% reliable way to FTP a DFDSS
>>> dump file was to terse it first.  IBM does not support direct FTP of a
>>> DFDSS dump file.  So I now terse every DFDSS dump file before FTPing
>>> it to other systems, and I haven't had another failure in 6 years.  As
>>> I said, it will work until it doesn't.
>>>
>>> Regards,
>>> Tom Conley
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>>> 

Re: Zfs from 1 LPAR to another

[Vernooij, Kees (ITOP NM) - KLM]

Yes, but what is the problem with recfm=u? Treat it as defined/documented: 
physical blocks, with undefined internal logic. So don't try to find logic in 
it. Is this what FTP tries to do?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 06 November 2019 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < 
kees.verno...@klm.com> wrote:

> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has 
> such a special (internal) format, that FTP cannot always handle it 
> correctly, why can AMATERSE do this without problems?
>

A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on 
DASD, with no imbedded (in the data) of where the record ends. This is a 
artifact of the ECKD format that only the IBM z (as far as I know) uses.
AMATERSE encodes the length of each physical block actually read into its data 
stream. And it produces FB output. So when you send it somewhere, the LRECL is 
always known. AMATERSE uses the encoded data in the FB to restore the data onto 
disk in the same PHYSICAL format that it was unloaded, making it usable once 
again by DFDSS. IMO, DFDSS should just have used VB or VBS format.



>
> If it FTP only, what is the special problem for FTP? What other 
> dataset formats are a problem for FTP?
>

Not FTP only.



>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
>
--
People in sleeping bags are the soft tacos of the bear world.
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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Zfs from 1 LPAR to another

[John McKown]

On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has
> such a special (internal) format, that FTP cannot always handle it
> correctly, why can AMATERSE do this without problems?
>

A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on
DASD, with no imbedded (in the data) of where the record ends. This is a
artifact of the ECKD format that only the IBM z (as far as I know) uses.
AMATERSE encodes the length of each physical block actually read into its
data stream. And it produces FB output. So when you send it somewhere, the
LRECL is always known. AMATERSE uses the encoded data in the FB to restore
the data onto disk in the same PHYSICAL format that it was unloaded, making
it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS
format.



>
> If it FTP only, what is the special problem for FTP? What other dataset
> formats are a problem for FTP?
>

Not FTP only.



>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
>
-- 
People in sleeping bags are the soft tacos of the bear world.
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: Zfs from 1 LPAR to another

[ITschak Mugzach]

Kees,

Dfdss in general is not ftp freindly. When we faced that in a large data
movement project, we used xmit to convert the file format to xmt on one
side and rexyeive it on the other side.

ITschak



בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM ‏<
kees.verno...@klm.com>:

> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has
> such a special (internal) format, that FTP cannot always handle it
> correctly, why can AMATERSE do this without problems?
>
> If it FTP only, what is the special problem for FTP? What other dataset
> formats are a problem for FTP?
>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: 06 November 2019 16:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
>
> I have always FTP a DFDSS dump of "things"  - What I was told to do long
> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS.
>
> This has never caused an issue (DFDSS ignores the Blksize).  And my
> Transfer have (knock wood) not failed.  And I have always been able to
> restore from the DFDSS dump.
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > Sent: Wednesday, November 06, 2019 8:02 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Zfs from 1 LPAR to another
> >
> > Can you point to where that is documented?
> > We FTP a lot b.m.o. DFDSS between Sysplexes.
> >
> > Kees.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tom Conley
> > Sent: 06 November 2019 15:46
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Zfs from 1 LPAR to another
> >
> > On 11/5/2019 6:54 PM, Jousma, David wrote:
> > > Terse, dont terse, your call.  I have 100% reliability as long as
> > > the
> > destination disk dataset for the ftp is newly created.  If the
> > destination dataset already exists, then yes, there have been problems.
> > >
> > > As you mention there are some specific options on the transfer to
> > > specify,
> > and as long as you do, it will work fine.
> > >
> > > Sending the dump file outside the company, probably not bad idea to
> > > terse
> > since we are all familiar with it.
> > >
> > > 
> > > __
> > > ___
> > >
> > > Dave Jousma
> > >
> > > AVP | Manager, Systems Engineering
> > > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > > Rapids, MI 49546
> > >
> > > 616.653.8429  |  fax: 616.653.2717
> > > 
> > > From: Tom Conley 
> > > Sent: Tuesday, November 5, 2019 5:17 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Zfs from 1 LPAR to another
> > >
> > >
> > > **CAUTION EXTERNAL EMAIL**
> > >
> > > **DO NOT open attachments or click on links from unknown senders or
> > > unexpected emails**
> > >
> > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> > >> I always terse the dump file too. Had issues with Restore if the
> > >> file wasn't  tersed.
> > >>
> > >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
> > >>
> > >>> Dave,
> > >>>   I'll do that. The files are not big.
> > >>>   They can be sent as ZIP files.
> > >>> Thanks, Pierre
> > >>>
> > >>> --
> > >>> --
> > >>> -- 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
> > >>
> > >
> > > Wayne beat me to it.  Terse any DFDSS file before sending.  You may
> > > get away with DFDSS with mode block and EBCDIC.  Until you don't.
> > > Terse it for 100% reliability.
> > >
> > > Regards,
> > > Tom Conley
> > >
> >
> > Dave,
> >
> > For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR
> > that needed it.  Worked fine, until it didn't.  IBM's response to the
> > PMR that I opened is that the only 100% reliable way to FTP a DFDSS
> > dump file was to terse it first.  IBM does not support direct FTP of a
> > DFDSS dump file.  So I now terse every DFDSS dump file before FTPing
> > it to other systems, and I haven't had another failure in 6 years.  As
> > I said, it will work until it doesn't.
> >
> > Regards,
> > Tom Conley
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 

Re: Zfs from 1 LPAR to another

[David Spiegel]

Because TRS produces FB records, whereas, DFSMSdss produces RECFM=U records.

On 2019-11-06 10:17, Vernooij, Kees (ITOP NM) - KLM wrote:
> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has such a 
> special (internal) format, that FTP cannot always handle it correctly, why 
> can AMATERSE do this without problems?
>
> If it FTP only, what is the special problem for FTP? What other dataset 
> formats are a problem for FTP?
>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Lizette Koehler
> Sent: 06 November 2019 16:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
>
> I have always FTP a DFDSS dump of "things"  - What I was told to do long ago 
> and far away was to include BLKSIZE=32760 on the dump file in DFDSS.
>
> This has never caused an issue (DFDSS ignores the Blksize).  And my Transfer 
> have (knock wood) not failed.  And I have always been able to restore from 
> the DFDSS dump.
>
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Vernooij, Kees (ITOP NM) - KLM
>> Sent: Wednesday, November 06, 2019 8:02 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Zfs from 1 LPAR to another
>>
>> Can you point to where that is documented?
>> We FTP a lot b.m.o. DFDSS between Sysplexes.
>>
>> Kees.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Tom Conley
>> Sent: 06 November 2019 15:46
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Zfs from 1 LPAR to another
>>
>> On 11/5/2019 6:54 PM, Jousma, David wrote:
>>> Terse, dont terse, your call.  I have 100% reliability as long as
>>> the
>> destination disk dataset for the ftp is newly created.  If the
>> destination dataset already exists, then yes, there have been problems.
>>> As you mention there are some specific options on the transfer to
>>> specify,
>> and as long as you do, it will work fine.
>>> Sending the dump file outside the company, probably not bad idea to
>>> terse
>> since we are all familiar with it.
>>> 
>>> __
>>> ___
>>>
>>> Dave Jousma
>>>
>>> AVP | Manager, Systems Engineering
>>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
>>> Rapids, MI 49546
>>>
>>> 616.653.8429  |  fax: 616.653.2717
>>> 
>>> From: Tom Conley 
>>> Sent: Tuesday, November 5, 2019 5:17 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Zfs from 1 LPAR to another
>>>
>>>
>>> **CAUTION EXTERNAL EMAIL**
>>>
>>> **DO NOT open attachments or click on links from unknown senders or
>>> unexpected emails**
>>>
>>> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
 I always terse the dump file too. Had issues with Restore if the
 file wasn't  tersed.

 On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:

> Dave,
>I'll do that. The files are not big.
>They can be sent as ZIP files.
> Thanks, Pierre
>
> --
> --
> -- 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

>>> Wayne beat me to it.  Terse any DFDSS file before sending.  You may
>>> get away with DFDSS with mode block and EBCDIC.  Until you don't.
>>> Terse it for 100% reliability.
>>>
>>> Regards,
>>> Tom Conley
>>>
>> Dave,
>>
>> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR
>> that needed it.  Worked fine, until it didn't.  IBM's response to the
>> PMR that I opened is that the only 100% reliable way to FTP a DFDSS
>> dump file was to terse it first.  IBM does not support direct FTP of a
>> DFDSS dump file.  So I now terse every DFDSS dump file before FTPing
>> it to other systems, and I haven't had another failure in 6 years.  As
>> I said, it will work until it doesn't.
>>
>> Regards,
>> Tom Conley
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> For information, services and offers, please visit our web site:
>> 

Re: Zfs from 1 LPAR to another

[Vernooij, Kees (ITOP NM) - KLM]

So do we.

And I wonder what the actual problem is? If the DFDSS dump dataset has such a 
special (internal) format, that FTP cannot always handle it correctly, why can 
AMATERSE do this without problems? 

If it FTP only, what is the special problem for FTP? What other dataset formats 
are a problem for FTP?

Questions, Fear, Uncertainty and Doubt...

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 06 November 2019 16:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

I have always FTP a DFDSS dump of "things"  - What I was told to do long ago 
and far away was to include BLKSIZE=32760 on the dump file in DFDSS.

This has never caused an issue (DFDSS ignores the Blksize).  And my Transfer 
have (knock wood) not failed.  And I have always been able to restore from the 
DFDSS dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Wednesday, November 06, 2019 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> Can you point to where that is documented?
> We FTP a lot b.m.o. DFDSS between Sysplexes.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Conley
> Sent: 06 November 2019 15:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> On 11/5/2019 6:54 PM, Jousma, David wrote:
> > Terse, dont terse, your call.  I have 100% reliability as long as 
> > the
> destination disk dataset for the ftp is newly created.  If the 
> destination dataset already exists, then yes, there have been problems.
> >
> > As you mention there are some specific options on the transfer to 
> > specify,
> and as long as you do, it will work fine.
> >
> > Sending the dump file outside the company, probably not bad idea to 
> > terse
> since we are all familiar with it.
> >
> > 
> > __
> > ___
> >
> > Dave Jousma
> >
> > AVP | Manager, Systems Engineering
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> > Rapids, MI 49546
> >
> > 616.653.8429  |  fax: 616.653.2717
> > 
> > From: Tom Conley 
> > Sent: Tuesday, November 5, 2019 5:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Zfs from 1 LPAR to another
> >
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or 
> > unexpected emails**
> >
> > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> >> I always terse the dump file too. Had issues with Restore if the 
> >> file wasn't  tersed.
> >>
> >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
> >>
> >>> Dave,
> >>>   I'll do that. The files are not big.
> >>>   They can be sent as ZIP files.
> >>> Thanks, Pierre
> >>>
> >>> --
> >>> --
> >>> -- 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
> >>
> >
> > Wayne beat me to it.  Terse any DFDSS file before sending.  You may 
> > get away with DFDSS with mode block and EBCDIC.  Until you don't.
> > Terse it for 100% reliability.
> >
> > Regards,
> > Tom Conley
> >
> 
> Dave,
> 
> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR 
> that needed it.  Worked fine, until it didn't.  IBM's response to the 
> PMR that I opened is that the only 100% reliable way to FTP a DFDSS 
> dump file was to terse it first.  IBM does not support direct FTP of a 
> DFDSS dump file.  So I now terse every DFDSS dump file before FTPing 
> it to other systems, and I haven't had another failure in 6 years.  As 
> I said, it will work until it doesn't.
> 
> Regards,
> Tom Conley
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this 

Re: Zfs from 1 LPAR to another

[Lizette Koehler]

I have always FTP a DFDSS dump of "things"  - What I was told to do long ago 
and far away was to include BLKSIZE=32760 on the dump file in DFDSS.

This has never caused an issue (DFDSS ignores the Blksize).  And my Transfer 
have (knock wood) not failed.  And I have always been able to restore from the 
DFDSS dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Vernooij, Kees (ITOP NM) - KLM
> Sent: Wednesday, November 06, 2019 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> Can you point to where that is documented?
> We FTP a lot b.m.o. DFDSS between Sysplexes.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Conley
> Sent: 06 November 2019 15:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> On 11/5/2019 6:54 PM, Jousma, David wrote:
> > Terse, dont terse, your call.  I have 100% reliability as long as the
> destination disk dataset for the ftp is newly created.  If the destination
> dataset already exists, then yes, there have been problems.
> >
> > As you mention there are some specific options on the transfer to specify,
> and as long as you do, it will work fine.
> >
> > Sending the dump file outside the company, probably not bad idea to terse
> since we are all familiar with it.
> >
> > __
> > ___
> >
> > Dave Jousma
> >
> > AVP | Manager, Systems Engineering
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> >
> > 616.653.8429  |  fax: 616.653.2717
> > 
> > From: Tom Conley 
> > Sent: Tuesday, November 5, 2019 5:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Zfs from 1 LPAR to another
> >
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> >> I always terse the dump file too. Had issues with Restore if the file
> >> wasn't  tersed.
> >>
> >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
> >>
> >>> Dave,
> >>>   I'll do that. The files are not big.
> >>>   They can be sent as ZIP files.
> >>> Thanks, Pierre
> >>>
> >>> 
> >>> -- 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
> >>
> >
> > Wayne beat me to it.  Terse any DFDSS file before sending.  You may
> > get away with DFDSS with mode block and EBCDIC.  Until you don't.
> > Terse it for 100% reliability.
> >
> > Regards,
> > Tom Conley
> >
> 
> Dave,
> 
> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that
> needed it.  Worked fine, until it didn't.  IBM's response to the PMR that I
> opened is that the only 100% reliable way to FTP a DFDSS dump file was to
> terse it first.  IBM does not support direct FTP of a DFDSS dump file.  So I
> now terse every DFDSS dump file before FTPing it to other systems, and I
> haven't had another failure in 6 years.  As I said, it will work until it
> doesn't.
> 
> Regards,
> Tom Conley
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain confidential
> and privileged material intended for the addressee only. If you are not the
> addressee, you are notified that no part of the e-mail or any attachment may
> be disclosed, copied or distributed, and that any other action related to
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you
> have received this e-mail by error, please notify the sender immediately by
> return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission of
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> For 

Using malloc/Calloc under metal C

[Joseph Reichman]

Hi

I am having all sorts of problems with LE in regards to XL C and thinking of 
switching to METAL C

I have a DLL but in practical purposes  that can be looked at as a bunch of C 
routines 

The routines work on storage accessed by the first function 

My question is under METAL C when you do a malloc / Calloc what is the life 
span of that storage 

Is it around after you leave the routine that allocated it 

Thanks   

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

Re: Zfs from 1 LPAR to another

[Vernooij, Kees (ITOP NM) - KLM]

Can you point to where that is documented?
We FTP a lot b.m.o. DFDSS between Sysplexes.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 06 November 2019 15:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On 11/5/2019 6:54 PM, Jousma, David wrote:
> Terse, dont terse, your call.  I have 100% reliability as long as the 
> destination disk dataset for the ftp is newly created.  If the destination 
> dataset already exists, then yes, there have been problems.
> 
> As you mention there are some specific options on the transfer to specify, 
> and as long as you do, it will work fine.
> 
> Sending the dump file outside the company, probably not bad idea to terse 
> since we are all familiar with it.
> 
> __
> ___
> 
> Dave Jousma
> 
> AVP | Manager, Systems Engineering
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 
> 616.653.8429  |  fax: 616.653.2717
> 
> From: Tom Conley 
> Sent: Tuesday, November 5, 2019 5:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
> 
> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
>> I always terse the dump file too. Had issues with Restore if the file 
>> wasn't  tersed.
>>
>> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
>>
>>> Dave,
>>>   I'll do that. The files are not big.
>>>   They can be sent as ZIP files.
>>> Thanks, Pierre
>>>
>>> 
>>> -- 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
>>
> 
> Wayne beat me to it.  Terse any DFDSS file before sending.  You may 
> get away with DFDSS with mode block and EBCDIC.  Until you don't.  
> Terse it for 100% reliability.
> 
> Regards,
> Tom Conley
> 

Dave,

For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that needed 
it.  Worked fine, until it didn't.  IBM's response to the PMR that I opened is 
that the only 100% reliable way to FTP a DFDSS dump file was to terse it first. 
 IBM does not support direct FTP of a DFDSS dump file.  So I now terse every 
DFDSS dump file before FTPing it to other systems, and I haven't had another 
failure in 6 years.  As I said, it will work until it doesn't.

Regards,
Tom Conley

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Zfs from 1 LPAR to another

[Tom Conley]

On 11/5/2019 6:54 PM, Jousma, David wrote:

Terse, dont terse, your call.  I have 100% reliability as long as the 
destination disk dataset for the ftp is newly created.  If the destination 
dataset already exists, then yes, there have been problems.

As you mention there are some specific options on the transfer to specify, and 
as long as you do, it will work fine.

Sending the dump file outside the company, probably not bad idea to terse since 
we are all familiar with it.

_

Dave Jousma

AVP | Manager, Systems Engineering
Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429  |  fax: 616.653.2717

From: Tom Conley 
Sent: Tuesday, November 5, 2019 5:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another


**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:

I always terse the dump file too. Had issues with Restore if the file
wasn't  tersed.

On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:


Dave,
  I'll do that. The files are not big.
  They can be sent as ZIP files.
Thanks, Pierre

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



Wayne beat me to it.  Terse any DFDSS file before sending.  You may get
away with DFDSS with mode block and EBCDIC.  Until you don't.  Terse it
for 100% reliability.

Regards,
Tom Conley



Dave,

For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that 
needed it.  Worked fine, until it didn't.  IBM's response to the PMR 
that I opened is that the only 100% reliable way to FTP a DFDSS dump 
file was to terse it first.  IBM does not support direct FTP of a DFDSS 
dump file.  So I now terse every DFDSS dump file before FTPing it to 
other systems, and I haven't had another failure in 6 years.  As I said, 
it will work until it doesn't.


Regards,
Tom Conley

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

Re: git with it

[Mohammad Khan]

On Tue, 5 Nov 2019 13:33:58 +, Henri Kuiper  wrote:

>;)
>
>Sent from my wireless iPhone
>

Is there a wired version as well !? 

:)

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

Re: CBPs (processors) - what is it?

[Attila Fogarasi]

I suspect anyone who knows is under NDA and cannot post here :)
I have noticed that WLM has a CBP field in various places, documented as
Reserved.
HMC has added extensive support to configure CBP processors in lpars, with
much the same characteristics as CP.
This is different from SSC which is limited to IFL or CP., I haven't
noticed CBP being added for SSC (but it might be).
z/OS has recently shipped support for system automation (such as GDPS)
managing CBP on z14 and z15.
Lots more similar support being pre-positioned, if you read the PTFs and
manual updates.
Not too hard to guess how CBP will work, given that today only zIIP is
allowed for zCX. .

On Wed, Nov 6, 2019 at 7:01 PM Martin Packer 
wrote:

>
>
> The only zCX specialty engine eligibility is for zIIP.
>
> Sent from my iPad
>
>
>

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

Re: CBPs (processors) - what is it?

[Martin Packer]

The only zCX specialty engine eligibility is for zIIP.

Sent from my iPad

> On 5 Nov 2019, at 15:08, Gord Tomlin 
wrote:
>
> On 2019-11-05 09:56, R.S. wrote:
>>> I suspect CBP would be for running docker payloads ?
>> Well, as I wrote, dockers (zCX) use zIIP. You are right the name is very

>> suggestive, but some presentations about docker on z/OS did not mention
>> CBP.
>
> zCX requires:
> - Z14 GA2
> - Hardware Feature Code 0104 (Container Hosting Foundation)
>
> I haven't been able to find much useful information on HFC 0104, but
> would not be surprised if it is related to CBP.
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support:
https://urldefense.proofpoint.com/v2/url?u=https-3A__actionsoftware.com_support_=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=07a4w1Oe7qAc_B5735tI4NwjfFsdq5gX1PCy7KKd0SA=DtrTZ0wHNAJJT6VoTRVuhDQbrqgHhdaPVmQux2FjPTk=

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