Re: OSA-ICC HMC panels do not work

[Doug]

Radoslaw,
Sounds somewhat like a problem I encountered while installing our EC12.
Importing the file from USB would appear to work but got an error during the 
validate.
Looking for my doc.
As I recall, it was related to never having any configuration on the OSA-ICC 
PCHID . 
Can you manually, without the import from USB, type in and validate a small 
config on the HMC. Try to validate, did it work? If you have already tried this 
then 
Maybe this is a different problem.
Doug

.

On Dec 28, 2015, at 13:39, R.S.  wrote:

I have problems with OSA-ICC configuration panels on HMC 2.13.0
Source file cannot be validated deu to "Unknown error", panel options also do 
not work.

Has anyone experienced such problems?

-- 
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Multiprise 3000 internal DASD hardware issues

[Mike Ross]

Hi folks

I'm bringing up an old Multiprise 3000 - 7060-30. For fun and
education rather than production needless to say!

All is mostly well so far but I'm having a problem configuring the
internal DASD. There are 11 18GB disks in there and 7 SSA jumpers. The
loop and plugging rules appear to be correct and that side of things
seems fine; I've read the manuals there carefully!

I've found I have one dud disk - if I run ISSACFG from the boot
floppies it formats test and certifies just fine - but for some reason
the internal disk subsytem configurator tool on the SE red-boxes it.

I have one spare disk - which turns out to be completely dead.

So I don't have enough working disks & jumpers to populate both groups
of internal DASD with the required 16 valid devices. And if there's
just one invalid or faulty device present the internal disk subsytem
configurator tool refuses to create a logical storage subsystem.

No problem I think; I don't have enough working bits for both groups
so I'll only use the disks in group 0 - the leftmost two columns of
DASD. I remove all the disks and jumpers from group 1 and the SSA
adaptor from group 1 - and replug the SSA cables appropriately. I
check it out with diskette boot ISSACFG; all is well; I have a
functioning string of 8 good disks.

Then I bring up the SE; I perform a POR; I start the internal disk
subsytem configurator tool. It shows all 8 drives in group 0 working
(blue squares) and all group 1 blank (white squares) - just as I
expected. Unexpectedly it *still* won't create an LSS; the message
about a faulty disk being present is gone but instead I get "The HDDs
are not plugged in the order as required for this frame. The LSS
configuration data could not be built or upgraded. Message ID: 0x8104"

Any suggestions? I don't see how the plugging order *could* be any
different; all slots in group 0 are plugged with working valid drives.
No jumpers are used.

Specific questions:

1. Is what I'm trying to do valid? i.e. run the machine with only 8
internal disks installed in group 0 - and have all the group 1 disks
and SSA adapter removed and their spaces covered with blanking plates?
The manual implies this should be possible. Or does *every* slot have
to populated with a working disk or jumper and both SSA adapters
installed - even if the SSA *loop* is only configured to use the group
0 adapter and disks? Refer to
http://www-01.ibm.com/support/docview.wss?uid=isg202df2e6254dd7e3c852568b000761b0f&aid=1
- pages 7-2 to 7-7. I'm trying to implement figure 7-1 since I don't
have enough working devices for figure 7-2 which was the original
configuration.

2. Or am I doing it wrong? Should the order of actions be: Bring up
the SE *then* use ISSACFG to create a RAID 5 array with hot spare
using the 8 drives BEFORE performing a POR (turning control of the
devices over to the PCI-STI bridge) THEN use the internal disk
subsytem configurator tool to create an LSS from an already-created
array?

3. Does anyone have any spare 7060 18GB SSA drives or jumpers lying in
some dark closet?! I'm going to need some sooner or later anyway!

4. Does anyone have a spare 7060 DAT tape drive lying around? Both of
mine appear to be flaky... and I'm going to need that sooner or later
too!

5. If I abandon internal DASD completely for now and decide to use
only emulated DASD on the SE array (which works perfectly) can I
replace the 9GB SE array disks with 18GB units? I know I would have to
reformat them to 512 byte blocks first and reinstall the SE from CDROM
- but would it work? I could create a much bigger G: partition  for a
useful amount of emulated DASD that way.

6. I've heard tell of people who decided to throw away the SE array
completely and instead boot the SE from an IDE disk connected to the
IDE port on the SE SBC. Obviously that would require tweaking of the
drivers etc. on the SE installation. Any comments or links to
documentation on what exactly people did to make that work if the
story is true?


Thanks

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

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

Re: rsync anyone?

[Paul Gilmartin]

On Mon, 28 Dec 2015 14:08:37 -0600, Kirk Wolf wrote:
>
>I'm not sure if an ssh invocation of pax like this works in all cases.
>Certainly z/OS to non-z/OS it would not work since, by default, ssh exec
>sessions are translated EBCDIC/ASCII and vice versa in the z/OS OpenSSH
>implementations.   I would have to check, but this seems unlikely to be
>binary-clean zOS->zOS.   We've argued this before, right?
> 
I don't know that we have much to argue about as long as we agree that EBCDIC
creates problems in a predominantly ASCII world.

And in the z/OS -- non-z/OS instance, I deal with the confrontation by adding
a suitably crafted iconv in a pipe on the z/OS side.

And (only) z/OS pax has elaborate facilities for ASCII<->EBCDIC on the
directory side, but not on the archive side.

The bad news is that IBM REJected my SR when I reported that when pax
converted a file tagged IBM-1047;NL to UTF-8, it converted the NLs to LFs
but the tag became UTF-8;NL.  Should have been UTF-8;LF.

>The good news is that with this APAR:
>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.foto100/soc4q15.htm
>
A christmas present.  Is it under control of the individual user, or only the 
administrator:

>z/OS V2R2 OpenSSH can now customize which kinds of channels are converted,
>using the "ChannelConvert" option and omitting "exec" from the list.
>Assuming that you use portable PAX/USTART file formats, you could use this
>to send filesystems z/OS<->non-z/OS.
> 
"exec"?

-- gil

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

Re: OpenSSH has had bugs in the news. (Was rsync anyone?)

[Kirk Wolf]

Here's the CVE:  *CVE-2015-5600*
http://seclists.org/oss-sec/2015/q3/173

z/OS OpenSSH doesn't support keyboard-interative authentication, so this
particular brute force attack on passwords would not apply anyway.

I'll also point out a couple of things:

1) All popular security software has defects and vulnerabilities.
 OpenSSH (which does NOT use SSL/TLS) is generally much better than
alternatives like OpenSSL or other popular SSL/TLS implementations.  (e.g.
"Heartbleed", "Poodle", "FREAK", etc)

2) IBM monitors CVEs against OpenSSH and releases PTFs to address them



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Dec 28, 2015 at 2:42 PM, Hansen, Dave L - Eagan, MN <
00d83826d62b-dmarc-requ...@listserv.ua.edu> wrote:

>
> http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kirk Wolf
> Sent: Monday, December 28, 2015 1:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: rsync anyone?
>
> >
> > ... However, OpenSSH has had security issues IIRC. ...
>
>
> What security issues are those?
>
> --
> 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: EXTERNAL: Re: rsync anyone?

[Eosze, Jonathan L.]

I ported rsync-2.5.5 a few years ago:

Below and attached is the diff from the original rsync-2.5.5.tar.gz.

I also created /usr/local/bin/rsync.sh since we put rsync in a non-standard 
location:

#!/bin/sh

# This is a script to help provide a wrapper around rsync for usability reasons

/usr/local/bin/rsync -e ssh --rsync-path=/usr/local/bin/rsync "$@"
exit $?

# example:
# rsync.sh -av --delete --dry-run zxmvs01@z001:/area/host/lsm/products/ 
/area/host/lsm/products
# rsync.sh -a --delete --stats --progress --one-file-system /u// 
/u/plc5611/tmp/


diff -cr rsync-2.5.5/Makefile.in rsync-2.5.5-new/Makefile.in
*** rsync-2.5.5/Makefile.inMon Mar 25 05:36:56 2002
--- rsync-2.5.5-new/Makefile.in Wed May 15 11:32:50 2002
***
*** 24,35 
  .SUFFIXES: .c .o
  
  LIBOBJ=lib/fnmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o \
!   lib/permstring.o \
!   @LIBOBJS@
  ZLIBOBJ=zlib/deflate.o zlib/infblock.o zlib/infcodes.o zlib/inffast.o \
zlib/inflate.o zlib/inftrees.o zlib/infutil.o zlib/trees.o \
zlib/zutil.o zlib/adler32.o 
! OBJS1=rsync.o generator.o receiver.o cleanup.o sender.o exclude.o util.o 
main.o checksum.o match.o syscall.o log.o backup.o
  OBJS2=options.o flist.o io.o compat.o hlink.o token.o uidlist.o socket.o 
fileio.o batch.o \
clientname.o
  DAEMON_OBJ = params.o loadparm.o clientserver.o access.o connection.o 
authenticate.o
--- 24,34 
  .SUFFIXES: .c .o
  
  LIBOBJ=lib/fnmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o \
!lib/permstring.o @LIBOBJS@
  ZLIBOBJ=zlib/deflate.o zlib/infblock.o zlib/infcodes.o zlib/inffast.o \
zlib/inflate.o zlib/inftrees.o zlib/infutil.o zlib/trees.o \
zlib/zutil.o zlib/adler32.o 
! OBJS1=rsync.o generator.o receiver.o cleanup.o sender.o exclude.o util.o 
main.o checksum.o match.o syscall.o log.o backup.o cpconv.o
  OBJS2=options.o flist.o io.o compat.o hlink.o token.o uidlist.o socket.o 
fileio.o batch.o \
clientname.o
  DAEMON_OBJ = params.o loadparm.o clientserver.o access.o connection.o 
authenticate.o
***
*** 45,51 
  # note that the -I. is needed to handle config.h when using VPATH
  .c.o:
  @OBJ_SAVE@
!   $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< @CC_SHOBJ_FLAG@
  @OBJ_RESTORE@
  
  all: rsync
--- 45,51 
  # note that the -I. is needed to handle config.h when using VPATH
  .c.o:
  @OBJ_SAVE@
!   $(CC) -I. -I$(srcdir) $(CFLAGS) @CC_SHOBJ_FLAG@ -c $<
  @OBJ_RESTORE@
  
  all: rsync
diff -cr rsync-2.5.5/lib/getaddrinfo.c rsync-2.5.5-new/lib/getaddrinfo.c
*** rsync-2.5.5/lib/getaddrinfo.c  Fri Dec 14 06:33:12 2001
--- rsync-2.5.5-new/lib/getaddrinfo.c   Tue May 14 14:12:24 2002
***
*** 259,266 
--- 259,278 
/* error check for hints */
if (hints->ai_addrlen || hints->ai_canonname ||
hints->ai_addr || hints->ai_next)
+ #if defined(__MVS__)
+   /* hints seem to be unknown to OS390 Open Edition, use 
EAI_MAX 
+ */
+   ERR(EAI_MAX); /* xxx */
+ #else
ERR(EAI_BADHINTS); /* xxx */
+ #endif
+ #if defined(__MVS__)
+   /* when compiling on OS390 Open Edition AI_MASK appears to be */
+   /* undefined, include expansion literally here */
+   if (hints->ai_flags & ~(AI_PASSIVE | AI_CANONNAME | 
AI_NUMERICHOST))
+ #else
if (hints->ai_flags & ~AI_MASK)
+ #endif
ERR(EAI_BADFLAGS);
switch (hints->ai_family) {
case PF_UNSPEC:
***
*** 294,306 
--- 306,330 
case SOCK_DGRAM:
if (pai->ai_protocol != IPPROTO_UDP &&
pai->ai_protocol != ANY)
+ #if defined(__MVS__)
+   /* hints seem to be unknown to OS390 Open 
Edition, use 
+ EAI_MAX */
+   ERR(EAI_MAX);   /*xxx*/
+ #else
ERR(EAI_BADHINTS);  /*xxx*/
+ #endif
pai->ai_protocol = IPPROTO_UDP;
break;
case SOCK_STREAM:
if (pai->ai_protocol != IPPROTO_TCP &&
pai->ai_protocol != ANY)
+ #if defined(__MVS__)
+   /* hints seem to be unknown to OS390 Open 
Edition, use 
+ EAI_MAX */
+   ERR(EAI_MAX);   /*xxx*/
+ #else
ERR(EAI_BADHINTS);  /*xxx*/
+ #endif
pai->ai_protocol = IPPROTO_TCP;
break;
default:
***
*** 350,356 
--- 374,386 
pai->ai_socktype = SOCK

OpenSSH has had bugs in the news. (Was rsync anyone?)

[Hansen, Dave L - Eagan, MN]

http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Monday, December 28, 2015 1:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: rsync anyone?

>
> ... However, OpenSSH has had security issues IIRC. ...


What security issues are those?

--
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: rsync anyone?

[Kirk Wolf]

Gil,

I'm not sure if an ssh invocation of pax like this works in all cases.
Certainly z/OS to non-z/OS it would not work since, by default, ssh exec
sessions are translated EBCDIC/ASCII and vice versa in the z/OS OpenSSH
implementations.   I would have to check, but this seems unlikely to be
binary-clean zOS->zOS.   We've argued this before, right?

The good news is that with this APAR:
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.foto100/soc4q15.htm

z/OS V2R2 OpenSSH can now customize which kinds of channels are converted,
using the "ChannelConvert" option and omitting "exec" from the list.
Assuming that you use portable PAX/USTART file formats, you could use this
to send filesystems z/OS<->non-z/OS.

This feature would be a great way to run rsync on z/OS once someone ports
it :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> This is still a little tricky to set up on the server side, but there
are workable techniques.   Like:

# sshd_config
Port 22
Port 

# zos_sshd_config
Match LocalPort  
   ChannelConvert shell# exec channels are binary into port 


On Mon, Dec 28, 2015 at 1:35 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 28 Dec 2015 18:12:05 +, Skeldum, William wrote:
>
> >The pax command is a good choice because it can copy all files,
> directories, and symbolic links in a directory using a single command
> without overlaying any existing files.   For example:
> >cd /Service/ZOS113/var
> >pax -rvwk -pe * /var
> >
> For rsync-like behavior, one often wants to overwrite older files and
> preserve newer.
> For this, "-u" may be a better choice than "-k".
>
> ... and your command moves files only within an LPAR.  Across LPARs,
> you need something such as:
>
> ssh other-LPAR "pax -w bin" |  # (Yes, the dreaded "ssh".)
> pax -rvu
>
> -- 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: rsync anyone?

[Skeldum, William]

Gil,
Thanks for the correction.  I was thinking if he was doing a one-time move he 
could mount a filesystem on the originating LPAR, do the pax command, dismount, 
and then mount again on the receiving LPAR.  Cumbersome, but works for a one 
time move.
If it is going to be an ongoing process then I'm sure Dave would desire a 
better solution.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 28, 2015 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: rsync anyone?

On Mon, 28 Dec 2015 18:12:05 +, Skeldum, William wrote:

>The pax command is a good choice because it can copy all files, directories, 
>and symbolic links in a directory using a single command without overlaying 
>any existing files.   For example:
>cd /Service/ZOS113/var
>pax -rvwk -pe * /var
>
For rsync-like behavior, one often wants to overwrite older files and preserve 
newer.
For this, "-u" may be a better choice than "-k".

... and your command moves files only within an LPAR.  Across LPARs, you need 
something such as:

ssh other-LPAR "pax -w bin" |  # (Yes, the dreaded "ssh".)
pax -rvu

-- gil



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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: rsync anyone?

[Paul Gilmartin]

On Mon, 28 Dec 2015 18:12:05 +, Skeldum, William wrote:

>The pax command is a good choice because it can copy all files, directories, 
>and symbolic links in a directory using a single command without overlaying 
>any existing files.   For example:
>cd /Service/ZOS113/var
>pax -rvwk -pe * /var
> 
For rsync-like behavior, one often wants to overwrite older files and preserve 
newer.
For this, "-u" may be a better choice than "-k".

... and your command moves files only within an LPAR.  Across LPARs,
you need something such as:

ssh other-LPAR "pax -w bin" |  # (Yes, the dreaded "ssh".)
pax -rvu

-- gil



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

Re: rsync anyone?

[Kirk Wolf]

>
> ... However, OpenSSH has had security issues IIRC. ...


What security issues are those?

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

Re: Is there a source for detailed, instruction-level performance info?

[Jim Mulder]

> An example: which of these code sequences do you suppose runs faster?
> 
>  la rX,0(rI,rBase)   rX -> array[i]
>  lg rY,0(,rX)rY = array[i]
>  agsi 0(rX),1++array[i]
> * Now do something with rY
> 
> vs:
>  lg rY,0(rI,rBase)   rY = array[i]
>  la rX,1(,rY)rX = rY + 1
>  stg rX,0(rI,rBase)  effect is ++array[i]
> * Now do something with rY
> 
> The first is substantially faster. I would have GUESSED that the 
> second would be faster, since I need the value in rY anyway. (I'm in
> 64-bit mode, so using "LOAD ADDRESS for the increment is safe...)

  "Substantially faster" is probably a cache effect.  Assuming a cache 
miss on array[i], in sequence 2, the LG will miss and install
the cache line shared, and then the STG will need to do an upgrade to
exclusive.  The AGSI in sequence 1 will miss and install the cache line
exclusive, avoiding the upgrade to exclusive.   Adding a PFD 2,0(rI,rBase)
before the LG in sequence 2 may make these sequences perform similarly.

 Also, in sequence 1, changing lg rY(0(,Rx) to 
lg rY,0(rI,rBase)  may avoid some Address Generation Interlock 
effects (although various machines have various AGI bypasses for various
instructions).  And it may just transfer some of the AGI effect from the 
LG down to the AGSI. 
 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY



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

AW: rsync anyone?

[Michael Knigge]

Dave,

a long time ago I looked at the source code of rsync and it is no trivial task 
to port it to an ebcdic platform (at least it was). A colleague of me was so 
frustrated too that he wrote a command line tool and a daemon that can be used 
to sync directories using the "rsync algorithm", but uses an own protocol.

https://github.com/tobiasbaum/jsync

Maybe you want to throw an eye on it.


Bye,
Michael



Mit freundlichen Grüßen

Michael Knigge
Software Engineer

SET GmbH
Lister Straße 15
30163 Hannover

phone: +49 511 39780-23
fax: +49 511 39780-65

www.set.de
michael.kni...@set.de

Handelsregister: HRB52778 Amtsgericht Hannover
Geschäftsführer: Till Dammermann, Dr. Bernd Huber

Weitere Informationen finden Sie auf unserer Homepage...

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Hansen, Dave L - Eagan, MN
Gesendet: Montag, 28. Dezember 2015 18:58
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: rsync anyone?

Hi,  I have been working with IBM to identify how to move a USS directory that 
has files and subdirectories to a different LPAR.  They said Ported Tools and 
the scp command.  However, OpenSSH has had security issues IIRC.  The other 
thing they mentioned was to port rsync over to z/OS.  I also have directions on 
how to voice this as a requirement to USS development using the RFE process.

Q).  Does anyone have a better way to move a directory that has files and 
subdirectories to a different LPAR?  Or do you just keep installing the same 
code for each instance?

Q).  Is anyone requesting rsync for z/OS via RFE or working on a port for 
rsync?  We do not have shared DASD and need something.


  Thank you,  Dave

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

OSA-ICC HMC panels do not work

[R.S.]

I have problems with OSA-ICC configuration panels on HMC 2.13.0
Source file cannot be validated deu to "Unknown error", panel options 
also do not work.


Has anyone experienced such problems?

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: rsync anyone?

[Skeldum, William]

The pax command is a good choice because it can copy all files, directories, 
and symbolic links in a directory using a single command without overlaying any 
existing files.   For example:
cd /Service/ZOS113/var
pax -rvwk -pe * /var
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hansen, Dave L - Eagan, MN
Sent: Monday, December 28, 2015 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: rsync anyone?

Hi,  I have been working with IBM to identify how to move a USS directory that 
has files and subdirectories to a different LPAR.  They said Ported Tools and 
the scp command.  However, OpenSSH has had security issues IIRC.  The other 
thing they mentioned was to port rsync over to z/OS.  I also have directions on 
how to voice this as a requirement to USS development using the RFE process.

Q).  Does anyone have a better way to move a directory that has files and 
subdirectories to a different LPAR?  Or do you just keep installing the same 
code for each instance?

Q).  Is anyone requesting rsync for z/OS via RFE or working on a port for 
rsync?  We do not have shared DASD and need something.


  Thank you,  Dave

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

rsync anyone?

[Hansen, Dave L - Eagan, MN]

Hi,  I have been working with IBM to identify how to move a USS directory that 
has files and subdirectories to a different LPAR.  They said Ported Tools and 
the scp command.  However, OpenSSH has had security issues IIRC.  The other 
thing they mentioned was to port rsync over to z/OS.  I also have directions on 
how to voice this as a requirement to USS development using the RFE process.

Q).  Does anyone have a better way to move a directory that has files and 
subdirectories to a different LPAR?  Or do you just keep installing the same 
code for each instance?

Q).  Is anyone requesting rsync for z/OS via RFE or working on a port for 
rsync?  We do not have shared DASD and need something.


  Thank you,  Dave

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

Re: Is there a source for detailed, instruction-level performance info?

[Shmuel Metz (Seymour J.)]

In <3361710c8fdd49d9a5ba76a61a993...@su806104.ad.ing.net>, on
12/28/2015
   at 06:15 AM, "Windt, W.K.F. van der (Fred)"
 said:

>And on newer machines (with the general-instructions-extension) you
>can simply do:

>  ASI COUNTER,1

>I assume it is faster than the sequence of three instructions but
>have not verified that.

I would be very much surprised if it were not faster. Also, it makes
the code clearer.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Is there a source for detailed, instruction-level performance info?

[Jerry Callen]

Back from Christmas break to a lot of responses - thanks to all. Summarizing 
the responses thus far:

* Select and/or tune your algorithm first.

Check.

* Tuning for a specific machine is a bad idea because you'll have to retune for 
every new machine.

Check. This code is sufficiently critical that it's worth doing 
platform-specific tuning. Otherwise I wouldn't be coding in assembler anyway. 
And it's small enough to be manageable.

* The compilers are very good and can probably do better than you can.

Usually, I agree. On this small kernel, though, I'm already beating xlc and (by 
a lesser margin) gcc. Looking at the code they generate has been enlightening; 
gcc is especially aggressive on loop unrolling, and that's on my list of  
things to try.

* Modern machines are too complex to enable detailed timing formulae to be 
published.

I'm not really after detailed timing. I'm looking for implementation details of 
the same sort used by compiler writers to guide selection of instruction 
sequences, where the guiding principle is, "How can I avoid pipeline stalls?" 
As I noted, several SHARE presentations contain SOME of this information, which 
I've already benefited from, but I'm looking for more.

* Just write some timing loops and figure it out yourself.

I've been doing that, using mostly the algorithm itself plus small timing 
experiments (which can be deceiving since they aren't in the context of the 
rest of the algorithm). I've already managed to squeeze out about a 15% 
improvement over my initial code.

An example: which of these code sequences do you suppose runs faster?

 la rX,0(rI,rBase)   rX -> array[i]
 lg rY,0(,rX)rY = array[i]
 agsi 0(rX),1++array[i]
* Now do something with rY

vs:
 lg rY,0(rI,rBase)   rY = array[i]
 la rX,1(,rY)rX = rY + 1
 stg rX,0(rI,rBase)  effect is ++array[i]
* Now do something with rY

The first is substantially faster. I would have GUESSED that the second would 
be faster, since I need the value in rY anyway. (I'm in 64-bit mode, so using 
"LOAD ADDRESS for the increment is safe...)

* Suggestions regarding branch prediction.

Spot on, and I already did that, too. Luckily branch prediction is one of the 
few performance characteristics that's actually semi-architectural (see the 
description of "BRANCH PREDICTION PRELOAD" in the Principles of Operation). 
Consider these two code sequences:

loop ds 0h
*Compute a value in r1
 cgrjne r2,r1,loop   continue if not done
vs:

loop ds 0h
*Compute a value in r1
 cgrje r2,r1,loopexitexit if done
 j loop
loopexit ds 0h

The second sequence is MUCH faster - though I haven't yet tried using "BRANCH 
PREDICTION PRELOAD" to alter the default prediction.

* Cache issues

This kernel unfortunately has little (data) cache locality; it's inherent in 
the problem. What I HAVE found is that using "PREFETCH DATA" and specifying 
store intent before the first access DOES help a bit. I haven't fiddled with 
"NEXT INSTRUCTION ACCESS INTENT" yet; that seems like a potentially enormous 
rathole. Using MVCL isn't an option; my data elements are small, aligned 
multiples of doublewords, and I determined very early on that a load/store loop 
way outperforms both MVCL and MVC.

On the I-cache side: the kernel is very small (a few dozen instructions) and 
chugs along for a good long time once it's called, so it's undoubtedly in 
cache. Following David Bond's suggestion to align the tops of loops on 16-byte 
boundaries helped a bit.

* The usual IBM-MAIN drift, reminiscences of old machines/code/operating 
systems/management practices/etc.

Check. :-)

I'm still hoping that someone will reveal the existence of a document intended 
for compiler writers...

-- Jerry

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

Re: Is there a source for detailed, instruction-level performance info?

[Bernd Oppolzer]

As Tom has noted, the most dramatic performance enhancements typically
come from a change in strategy or algorithm used.  In my experience you
get better results by looking for ways to accomplish the end result by
having the program do fewer actions rather than concentrating on
micro-optimzing the individual actions.



Very true. As others have pointed out, very often the problem is 
sequential search

of tables considered to be small which are large in real situations.

My example is the DB2 CAF interface module DSNALI;
there is a loop that checks if a certain module has already been loaded by
sequentially looking up the CDE list. And this is done on every single 
DB2 action,
for example a fetch of a DB2 row. This works in a batch environment 
where the

number of modules is low. Now we had at a customers site a situation where
DSNALI was used in an environment where there where some 5000 modules
in the CDE list. The CPU amount in the DSNALI loop added up to more than 
5 %
of the overall CPU, although this was a region with heavy math load; 
DSNALI should

normally be invisible.

We talked with IBM on this, but IBM didn't fix it - and we were not 
allowed to fix it
at the customer's site (it's IBM software). The solution in the end was: 
we changed

all those processes to RRSAF, that is: DSNRLI; DSNRLI had no such problem.

Kind regards

Bernd



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