date:20130117

Re: ICSF Symmetric Key being sent to a non-zOS system

2013-01-17 Thread R.S.

W dniu 2013-01-17 21:22, Mark Jacobs pisze:

I've been reading the ICSF Applications Programmers guide and I
understand the process on how to transport ICSF keys to another zOS
system using importer/exporter keys, but I have no idea on how it would
work on a non-zOS platform.

Can anyone point me to some doc, or share their process if they've
already done it?

The least secure method, but the easiest si to sent the key in clear
form, unencrypted. That requires SSM=YES.
IOf you don't like clear keys then you should protect it by encrypting
the key using ...the other key. In ICSF it is usually the oter key
called transport key. Of course the other party (receiver) has to use
the same symmetric transport key to decrypt the "message".
The problem is how to get the same transport key in both systems. You
can send such key using other key for transport...

There are following solutions:
a) you really send first key in clear form.
b) you enter the key in both machines - the key is not sent, but rather
read from the sheet of paper by human entering it.
c) you can use assymetric cryptography to exchange the keys. The safest
way, probably he most complicated.

Now you know methods, but there is still problem with compatibility. The
other system have to understand the data sent from ICSF. Having smae
algorithms and keylenghts on both sides is prerequisite.

--
Radoslaw Skorupka
Lodz, Poland

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

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

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

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread R.S.

W dniu 2013-01-17 22:45, Steve Conway pisze:

Within your JES2PARM, you can specify by JOBCLASS whether to allow command
processing or not. I think JES2 gets first whack at saying "No", followed
by RACF (if JES2 thinks it's OK).

Well... so?

JOBCLASS can allow (ask operator) or deny all the commands, regardless
of command type and user who issued it. Not funny. Tha't why OPERCMDS is
created - to make distinction between MVS.DISPLAY and MVS.QUIESCE as
well as JOHN and FRANK.

JOBCLASS is free of choice in vanilla system, so any user can use any
class. It can be limited using exits, such exit could check ...in RACF.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Tasks ENQ'ing exclusive on resource not getting control in FIFO order

2013-01-17 Thread Hunkeler Peter (KIUP 4)

>Have you checked to see if the system that ends up winning the ENQ is 
>the same as the one which was running the job that just ended and did 
>the DEQ? It seems to me that the DEQing system has the best chance of 
>winning any race condition since it is the first to know of the DEQ 
>and thus the first to be able to grab the ENQ lock.

Yes, we saw symptoms like that, too, but if GRS contention resolution
is defined to be FIFO, then there is no race condition one system can
win.

I wanted to confirm I'm not missing something that changed in GRS
processing, before opening a PMR. Jim Mulder confirmed that it still
had to be FIFO. We now have to find out why we saw different behavior.

--
Peter Hunkeler

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

Re: silicon photonics - faster than copper

2013-01-17 Thread R.S.

W dniu 2013-01-17 18:31, Martin, Larry D pisze:

But light doesn't create heat; thus more circuits in a smaller
space..

1. Light could create heat, but I strongly believe this is not the case
in such application due to powers which could be used. The problem
occurs in long distance links (undersea cables for example) or outside
of IT.

2. I would worry about transmitters. Transmitters do create heat.

3. There are also receivers. While heating of receivers is not nightmare
for engineers, they do create a hit also.

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

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
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.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.

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

Re: silicon photonics - faster than copper

2013-01-17 Thread R.S.

W dniu 2013-01-17 18:23, retired mainframer pisze:

While photonic components (switches, etc) may be faster than the current
semi-conductor ones, can the wiring really be a factor. Don't both
electricity and light move at c?

Neither light nor electricity move at c.

Speed of light depends on the media. c is for vacuum. For fiber optic it
is c/RI RI - refractive index, approx. 1.46
So for the calculations people tend to use speed of light (still in the
FO) as 200 000 000 m/s.

Now, speed of electricity is higher it's approx. 3/4 c. However I can't
remember explanation for the number.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Tasks ENQ'ing exclusive on resource not getting control in FIFO order

2013-01-17 Thread Robert A. Rosenberg

Have you checked to see if the system that ends up winning the ENQ is 
the same as the one which was running the job that just ended and did 
the DEQ? It seems to me that the DEQing system has the best chance of 
winning any race condition since it is the first to know of the DEQ 
and thus the first to be able to grab the ENQ lock.





At 14:46 -0600 on 01/17/2013, Peter Hunkeler wrote about Tasks 
ENQ'ing exclusive on resource not getting control in :


It was my understanding that tasks enqueueing on a 
resource are getting control in FIFO order, if contention existed. 
Today, we had a situation where this was not true.


Environment is as follows:

- 4 system parallel sysplex, z/OS V1.13, GRS STAR mode.
- a dozen or so jobs running the same program are active across all 
4 systems at a time. More job being submitted as jobs end (more or 
less).
- the programs are serializing using EXCLUSIVE ENQ on a resource, 
scope systems


As expected, one job is running, all others are waiting to get the 
resource assigned.
But suddenly, we the recognized that jobs on two systems never got 
running. They have been waiting for the resource for hours, while 
newer jobs got control one after the other. So resource assignment 
is clearly not FIFO. We then saw (in EJES) that once a job ended, 
all waiting jobs are active for a very short time, then one job 
continues to run while all other are waiting again.


I have RTFM, and still think ENQ is FIFO. I have not found anything 
related to GRS STAR mode that contradicts.


I have not followed GRS new lately. What am I missing?

--
Peter Hunkeler

--
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: Running the RB chain of an inactive TCB

2013-01-17 Thread Shmuel Metz (Seymour J.)

In <50f87d72.5020...@phoenixsoftware.com>, on 01/17/2013
   at 02:38 PM, Edward Jaffe  said:

>When begs the question: if local lock is not enough, what
>serialization should  be used? ;)

Dispatcher lock plus testing that the TCB is not dispatched?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: silicon photonics - faster than copper

2013-01-17 Thread Shmuel Metz (Seymour J.)

In
,
on 01/17/2013
   at 12:31 PM, "Martin, Larry D"  said:

>But light doesn't create heat;

Are you a betting man?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: silicon photonics - faster than copper

2013-01-17 Thread Shmuel Metz (Seymour J.)

In <4301C80A9ADC4F1AA5460361D8A785E0@barryf93b83d71>, on 01/17/2013
   at 09:23 AM, retired mainframer  said:

>While photonic components (switches, etc) may be faster than the
>current semi-conductor ones, can the wiring really be a factor. 
>Don't both electricity and light move at c?

No; electrons have a non-zero rest mass. However, an electromagnetic
field moves at c, so the Devil is in the details.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: SMS COMMAND VIA BATCH

2013-01-17 Thread Shmuel Metz (Seymour J.)

In <05dc01cdf4c8$fea86de0$fbf949a0$@mindspring.com>, on 01/17/2013
   at 08:40 AM, Lizette Koehler  said:

>It might work under OPER in TSO.

OPER is by design very limited; I'd suggest CONSOLE if you're
authorized for it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Searching for storage (DASD) alternatives

2013-01-17 Thread Shmuel Metz (Seymour J.)

In
,
on 01/16/2013
   at 01:15 PM, John McKown  said:

>Yea. and the only supported thing that I can think of which requires
>ECKD is BPAM for PDS. Oh, and NIP for SYS1.NUCLEUS mainly I believe.

IEAIPL00.

FWIW, TSS/360 used page-formatted volumes, including VPAM.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Searching for storage (DASD) alternatives

2013-01-17 Thread Shmuel Metz (Seymour J.)

In , on 01/16/2013
   at 01:57 PM, Anne & Lynn Wheeler  said:

>beatt...@uk.ibm.com (Malcolm Beattie) writes:
>> z/VSE has supported FCP SCSI for a good while now (since 3.1).

>a lot easier for any mainframe system that originally provided FBA
>support

The original code base precedes FBA. Once they added FBA most of the
work was done for FCP SCSI.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Break a dataset into new record boundaries?

2013-01-17 Thread Shmuel Metz (Seymour J.)

In <1358346823.60155.yahoomail...@web120503.mail.ne1.yahoo.com>, on
01/16/2013
   at 06:33 AM, "Ze'ev Atlas"  said:

>I would do Perl too, but what if you are limited to Rexx and EXECIO 

Then I'd grit my teeth and use parse to split the data. In either case
the real problem is what heuristic to use to decide whether the match
really is the beginning of a record.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Passing of Chris Mason reported

2013-01-17 Thread Shmuel Metz (Seymour J.)

In
,
on 01/15/2013
   at 10:41 PM, John Gilmore  said:

>Shmuel wrote:

>| De mortui

>which is perhaps a botched reference to the Latin tag

>De mortuis nil nisi bonum [dicendum est].

That is the sort of errant pedantry up with which I shall not put.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Break a dataset into new record boundaries?

2013-01-17 Thread Shmuel Metz (Seymour J.)

In <1358352865.70255.yahoomail...@web120503.mail.ne1.yahoo.com>, on
01/16/2013
   at 08:14 AM, "Ze'ev Atlas"  said:

>Don't misunderstand me, I love Rexx... just would want it to have
>better IO and regular expressions (in z/OS - on other platforms 
>Rexx already has this capability, though in POSIX sematics).

>To that end, I've ported PCRE to z/OS

That should be useful, although it would still be nice to have a
current Perl; 4.8.7 is pretty long in the tooth.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed

2013-01-17 Thread Anthony Fletcher

Too embarrassing!

The return code was 20 and the reason code was 40.

40 means that the PGM was not found anywhere in the search set of data
sets.

Someone had removed the essential data set from the LINKLIST without
telling anyone else.

Of course it would have been much easier if the application had shown the
reason code.


regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   Lizette Koehler 
To: IBM-MAIN@listserv.ua.edu,
Date:   18/01/2013 14:42
Subject:Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
Sent by:IBM Mainframe Discussion List 



So what was the answer?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Anthony Fletcher
> Sent: Thursday, January 17, 2013 5:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
>
> Thanks to all responders. The ISPVCALL one was the easiest and led
straight to the
> answer I needed.
>
>
> regards,
> Anthony Fletcher - NZ MIITP
> Team Lead NZ SMM
> (AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)
>
> IBM Strategic Outsourcing Delivery
> Server Systems Operations
> Server Management Mainframe
>
> Mainframe Software Program Manager  NZ
> z/OS Technical Lead A/NZ
>
> Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN
*869298142,
> mobile +64 21 464 864, Fax +64 4 576 5808.
> Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com
>
>  "The biggest threat to effective communication is the belief that it has
occurred"
>  "Winners make commitments, Losers make promises"
>
>
>
> From:  Lizette Koehler 
> To:IBM-MAIN@listserv.ua.edu,
> Date:  17/01/2013 17:30
> Subject:   Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
> Sent by:   IBM Mainframe Discussion List 
> 
>
>
>
> First, if you have not done so, you can join the ISPF Newsgroup for these
types of
> issues.  https://listserv.nd.edu/cgi-bin/wa?A0=ispf-l
>
>
> Second, I would run ISPF TEST and set breakpoints on your process.  The
ISPF
> manuals have some decent descriptions of the ISPF TEST facility.
>
> Other is to issue TSO ISPVCALL which will set up a trace facility.
> Run your process.
> Then issue TSO ISPVCALL which will then unload the trace file.  Then go
through the
> output and find your RC20
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> Behalf
> > Of Anthony Fletcher
> > Sent: Wednesday, January 16, 2013 7:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
> >
> > I have some code (that I didn't write) that is coming back with RC 20
> when issuing a
> > command like
> >
> > SELECT PGM(xxx) PARM(yyy)
> >
> > I need some clues as to what it may be objecting to. I have checked
> > all
> the obvious
> > things like IKJTSO00 entries, APF entries, RACF PROGAM class etc, but
> > no
> luck, so I
> > need some ideas as to find out what ISPF is really complaining about.
> >
> > Anyone got any ideas?

--
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: ICSF Symmetric Key being sent to a non-zOS system

2013-01-17 Thread Walt Farrell

On Thu, 17 Jan 2013 12:39:11 -0800, Phil Smith  wrote:

>Mark Jacobs wrote:
>>I've been reading the ICSF Applications Programmers guide and I understand 
>>the process on how to transport ICSF keys to another zOS system using 
>>importer/exporter keys, but I have no idea on how it would work on a non-zOS 
>>platform.
>
>>Can anyone point me to some doc, or share their process if they've already 
>>done it?
>
>FYI, there's no such thing as an "ICSF key". There are keys of various sorts 
>that ICSF manages, but they aren't ICSF-ized per se. I guess if they're 
>wrapped (encrypted) in a Crypto Express, they could be sort of thought of as 
>being bound to ICSF, but they still are really just 56 or 64 or 128 or 192 or 
>256 or however many bits of key material.
>
>So...having said that, what do you mean by "how it would work on a non-z/OS 
>platform"? How WHAT would work? An AES key is an AES key: if you have an AES 
>algorithm and a key, you can encrypt data, and you'll get the same result on 
>any platform (assuming you're using the same AES mode, etc.).
>
>I feel like I'm taking you to task here, and I don't mean to be - just trying 
>to understand what your real question is!

I read it as, "how would I extract a key from ICSF and send it to a non-z/OS 
system?"

-- 
Walt

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

Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed

2013-01-17 Thread Lizette Koehler

So what was the answer?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Anthony Fletcher
> Sent: Thursday, January 17, 2013 5:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
> 
> Thanks to all responders. The ISPVCALL one was the easiest and led
straight to the
> answer I needed.
> 
> 
> regards,
> Anthony Fletcher - NZ MIITP
> Team Lead NZ SMM
> (AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)
> 
> IBM Strategic Outsourcing Delivery
> Server Systems Operations
> Server Management Mainframe
> 
> Mainframe Software Program Manager  NZ
> z/OS Technical Lead A/NZ
> 
> Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN
*869298142,
> mobile +64 21 464 864, Fax +64 4 576 5808.
> Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com
> 
>  "The biggest threat to effective communication is the belief that it has
occurred"
>  "Winners make commitments, Losers make promises"
> 
> 
> 
> From: Lizette Koehler 
> To:   IBM-MAIN@listserv.ua.edu,
> Date: 17/01/2013 17:30
> Subject:  Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
> Sent by:  IBM Mainframe Discussion List 
> 
> 
> 
> First, if you have not done so, you can join the ISPF Newsgroup for these
types of
> issues.  https://listserv.nd.edu/cgi-bin/wa?A0=ispf-l
> 
> 
> Second, I would run ISPF TEST and set breakpoints on your process.  The
ISPF
> manuals have some decent descriptions of the ISPF TEST facility.
> 
> Other is to issue TSO ISPVCALL which will set up a trace facility.
> Run your process.
> Then issue TSO ISPVCALL which will then unload the trace file.  Then go
through the
> output and find your RC20
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> Behalf
> > Of Anthony Fletcher
> > Sent: Wednesday, January 16, 2013 7:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
> >
> > I have some code (that I didn't write) that is coming back with RC 20
> when issuing a
> > command like
> >
> > SELECT PGM(xxx) PARM(yyy)
> >
> > I need some clues as to what it may be objecting to. I have checked
> > all
> the obvious
> > things like IKJTSO00 entries, APF entries, RACF PROGAM class etc, but
> > no
> luck, so I
> > need some ideas as to find out what ISPF is really complaining about.
> >
> > Anyone got any ideas?

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

Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed

2013-01-17 Thread Anthony Fletcher

Thanks to all responders. The ISPVCALL one was the easiest and led straight
to the answer I needed.


regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   Lizette Koehler 
To: IBM-MAIN@listserv.ua.edu,
Date:   17/01/2013 17:30
Subject:Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
Sent by:IBM Mainframe Discussion List 



First, if you have not done so, you can join the ISPF Newsgroup for these
types of issues.  https://listserv.nd.edu/cgi-bin/wa?A0=ispf-l


Second, I would run ISPF TEST and set breakpoints on your process.  The
ISPF manuals have some decent descriptions of the ISPF TEST facility.

Other is to issue TSO ISPVCALL which will set up a trace facility.
Run your process.
Then issue TSO ISPVCALL which will then unload the trace file.  Then go
through the output and find your RC20

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Anthony Fletcher
> Sent: Wednesday, January 16, 2013 7:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
>
> I have some code (that I didn't write) that is coming back with RC 20
when issuing a
> command like
>
> SELECT PGM(xxx) PARM(yyy)
>
> I need some clues as to what it may be objecting to. I have checked all
the obvious
> things like IKJTSO00 entries, APF entries, RACF PROGAM class etc, but no
luck, so I
> need some ideas as to find out what ISPF is really complaining about.
>
> Anyone got any ideas?
>
> --
> 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: Running the RB chain of an inactive TCB

2013-01-17 Thread Jim Mulder

> >  From the serialization section of SYS1.MACLIB(IHARB):
> > If the task is not running and the local lock is held, the RB 
> chain will not change.
> > 
> >  From APAR PQ81630:
> > PQ76702 introduced code for MVSTCB TCB statistics. DFHDSMT calls
> > DFHDSAUT for these statistics in routine CREATE_SNAPSHOT.
> > DFHDSAUT will loop in routine TCB_SCAN due to not serializing
> > the RB chain. A MVS local lock is not enough to serialize the
> > RB chain.
> 
> When begs the question: if local lock is not enough, what 
> serialization should 
> be used? ;)
> 
> More than likely the RB chain of a dispatchable TCB can be 100% 
> safely traversed 
> only while running in that TCB.
 
  That is correct.

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

Re: Running the RB chain of an inactive TCB

2013-01-17 Thread Edward Jaffe


On 1/17/2013 11:12 AM, Mark Henderson wrote:

Can someone explain to me the apparent contradiction in the following two 
pieces of information ?

 From the serialization section of SYS1.MACLIB(IHARB):
If the task is not running and the local lock is held, the RB chain will not 
change.
  
 From APAR PQ81630:

PQ76702 introduced code for MVSTCB TCB statistics. DFHDSMT calls
DFHDSAUT for these statistics in routine CREATE_SNAPSHOT.
DFHDSAUT will loop in routine TCB_SCAN due to not serializing
the RB chain. A MVS local lock is not enough to serialize the
RB chain.


When begs the question: if local lock is not enough, what serialization should 
be used? ;)


More than likely the RB chain of a dispatchable TCB can be 100% safely traversed 
only while running in that TCB.


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

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

Re: Tasks ENQ'ing exclusive on resource not getting control in FIFO order

2013-01-17 Thread Jim Mulder

IBM Mainframe Discussion List  wrote on 
01/17/2013 04:42:33 PM:


> It sounds as if the relative CPU speed and/or hypervisor dispatching
> of LPARs may be involved in any given LPAR's getting the resource. 
> If after GRS sends a signal to all enqueing systems that the 
> resource is available it then waits for a response from said 
> systems, it may be that GRS will give the resource to whichever 
> system responded first and is ignoring the order in which the 
> processors did the original ENQs.  Perhaps a timestamp needs to be 
> associated with each ENQ request and the global resource allocator 
> made sensitive to the timestamp.   Or maybe the documentation needs 
> to be updated to reflect the different way that SCOPE=SYSTEMS ENQ 
> works in GRS from SCOPE=SYSTEM with no GRS involved.
> 
> The relative processor speed certainly has been known to affect 
> which of several sharing processors will next get access to a shared
> DASD volume using the RESERVE/RELEASE hardware function.
> 
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane ? Franklin, TN 37069-2526 ? USA
> t: +1.617.614.4503 ?  e: bfairch...@rocketsoftware.com ? w: 
> www.rocketsoftware.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Peter Hunkeler
> Sent: Thursday, January 17, 2013 2:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Tasks ENQ'ing exclusive on resource not getting control in FIFO 
order
> 
> It was my understanding that tasks enqueueing on a resource are 
> getting control in FIFO order, if contention existed. Today, we had 
> a situation where this was not true.
> 
> Environment is as follows:
> 
> - 4 system parallel sysplex, z/OS V1.13, GRS STAR mode.
> - a dozen or so jobs running the same program are active across all 
> 4 systems at a time. More job being submitted as jobs end (more or 
less).
> - the programs are serializing using EXCLUSIVE ENQ on a resource, 
> scope systems
> 
> As expected, one job is running, all others are waiting to get the 
> resource assigned.
> But suddenly, we the recognized that jobs on two systems never got 
> running. They have been waiting for the resource for hours, while 
> newer jobs got control one after the other. So resource assignment 
> is clearly not FIFO. We then saw (in EJES) that once a job ended, 
> all waiting jobs are active for a very short time, then one job 
> continues to run while all other are waiting again.
> 
> I have RTFM, and still think ENQ is FIFO. I have not found anything 
> related to GRS STAR mode that contradicts.
> 
> I have not followed GRS new lately. What am I missing?
> 
> --
> Peter Hunkeler

  GRS resource contention is intended to be processed FIFO, regardless
of Ring mode vs. Star mode. 

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread Jonathan Goossen

Or you can have something like OPSMVS intercept the WTOR and reply No.

Thank you and have a Terrific day!

Jonathan Goossen, DTM
ACT Mainframe Storage Group
Personal: 651-361-4541
Department Support Line: 651-361-
For help with communication and leadership skills checkout Woodwinds 
Toastmasters.



IBM Mainframe Discussion List  wrote on 
01/17/2013 03:45:24 PM:

> From: Steve Conway 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 01/17/2013 03:45 PM
> Subject: Re: SMS COMMAND VIA BATCH
> Sent by: IBM Mainframe Discussion List 
> 
> Within your JES2PARM, you can specify by JOBCLASS whether to allow 
command 
> processing or not.  I think JES2 gets first whack at saying "No", 
followed 
> by RACF (if JES2 thinks it's OK).
> 
> 
> Cheers,,,Steve
> 
> Steven F. Conway, CISSP
> LA Systems
> z/OS Systems Support
> Phone: 703.295.1926
> steve_con...@ao.uscourts.gov
> 
> 
> 
> From:   "R.S." 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   01/17/2013 04:34 PM
> Subject:Re: SMS COMMAND VIA BATCH
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> W dniu 2013-01-17 17:06, Ed Gould pisze:
> > Lizette:
> >
> > AND that is only if the JES2 init parms are set up that way. Which of
> > course is a big NONO (security wise).
> >
> 
> Big what-what? AFAIK all commands from job are under OPERCMDS class.
> 
> 
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie 
jeste 
> adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
> przekazania adresatowi, informujemy, e jej rozpowszechnianie, 
kopiowanie, 
> rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
> zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
> prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
> usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and 
is 
> intended solely for business use of the addressee. This e-mail may only 
be 
> received by the addressee and may not be disclosed to any third parties. 

> If you are not the intended addressee of this e-mail or the employee 
> authorised to forward it to the addressee, be advised that any 
> dissemination, copying, distribution or any other similar activity is 
> legally prohibited and may be punishable. If you received this e-mail by 

> mistake please advise the sender immediately by using the reply facility 

> in your e-mail software and delete permanently this e-mail including any 

> copies of it either printed or saved to hard drive. 
> 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 
00, 
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego 
> Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 
> 526-021-50-88. 
> Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w 
> caoci wpacony) wynosi 168.555.904 zotych.
> 
> 
> --
> 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


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

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread Steve Conway

Within your JES2PARM, you can specify by JOBCLASS whether to allow command 
processing or not.  I think JES2 gets first whack at saying "No", followed 
by RACF (if JES2 thinks it's OK).


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   "R.S." 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   01/17/2013 04:34 PM
Subject:Re: SMS COMMAND VIA BATCH
Sent by:IBM Mainframe Discussion List 



W dniu 2013-01-17 17:06, Ed Gould pisze:
> Lizette:
>
> AND that is only if the JES2 init parms are set up that way. Which of
> course is a big NONO (security wise).
>

Big what-what? AFAIK all commands from job are under OPERCMDS class.



-- 
Radoslaw Skorupka
Lodz, Poland






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

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

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


--
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: Tasks ENQ'ing exclusive on resource not getting control in FIFO order

2013-01-17 Thread Bill Fairchild

It sounds as if the relative CPU speed and/or hypervisor dispatching of LPARs 
may be involved in any given LPAR's getting the resource.  If after GRS sends a 
signal to all enqueing systems that the resource is available it then waits for 
a response from said systems, it may be that GRS will give the resource to 
whichever system responded first and is ignoring the order in which the 
processors did the original ENQs.  Perhaps a timestamp needs to be associated 
with each ENQ request and the global resource allocator made sensitive to the 
timestamp.   Or maybe the documentation needs to be updated to reflect the 
different way that SCOPE=SYSTEMS ENQ works in GRS from SCOPE=SYSTEM with no GRS 
involved.

The relative processor speed certainly has been known to affect which of 
several sharing processors will next get access to a shared DASD volume using 
the RESERVE/RELEASE hardware function.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA
t: +1.617.614.4503 •  e: bfairch...@rocketsoftware.com • w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, January 17, 2013 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tasks ENQ'ing exclusive on resource not getting control in FIFO order

It was my understanding that tasks enqueueing on a resource are getting control 
in FIFO order, if contention existed. Today, we had a situation where this was 
not true.

Environment is as follows:

- 4 system parallel sysplex, z/OS V1.13, GRS STAR mode.
- a dozen or so jobs running the same program are active across all 4 systems 
at a time. More job being submitted as jobs end (more or less).
- the programs are serializing using EXCLUSIVE ENQ on a resource, scope systems

As expected, one job is running, all others are waiting to get the resource 
assigned.
But suddenly, we the recognized that jobs on two systems never got running. 
They have been waiting for the resource for hours, while newer jobs got control 
one after the other. So resource assignment is clearly not FIFO. We then saw 
(in EJES) that once a job ended, all waiting jobs are active for a very short 
time, then one job continues to run while all other are waiting again.

I have RTFM, and still think ENQ is FIFO. I have not found anything related to 
GRS STAR mode that contradicts.

I have not followed GRS new lately. What am I missing?

--
Peter Hunkeler

--
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: SMS COMMAND VIA BATCH

2013-01-17 Thread R.S.

W dniu 2013-01-17 17:06, Ed Gould pisze:

Lizette:

AND that is only if the JES2 init parms are set up that way. Which of
course is a big NONO (security wise).

Big what-what? AFAIK all commands from job are under OPERCMDS class.

--
Radoslaw Skorupka
Lodz, Poland

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

Tasks ENQ'ing exclusive on resource not getting control in FIFO order

2013-01-17 Thread Peter Hunkeler

It was my understanding that tasks enqueueing on a resource are getting control 
in FIFO order, if contention existed. Today, we had a situation where this was 
not true.

Environment is as follows:

- 4 system parallel sysplex, z/OS V1.13, GRS STAR mode.
- a dozen or so jobs running the same program are active across all 4 systems 
at a time. More job being submitted as jobs end (more or less).
- the programs are serializing using EXCLUSIVE ENQ on a resource, scope systems

As expected, one job is running, all others are waiting to get the resource 
assigned.
But suddenly, we the recognized that jobs on two systems never got running. 
They have been waiting for the resource for hours, while newer jobs got control 
one after the other. So resource assignment is clearly not FIFO. We then saw 
(in EJES) that once a job ended, all waiting jobs are active for a very short 
time, then one job continues to run while all other are waiting again.

I have RTFM, and still think ENQ is FIFO. I have not found anything related to 
GRS STAR mode that contradicts.

I have not followed GRS new lately. What am I missing?

--
Peter Hunkeler

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

Re: ICSF Symmetric Key being sent to a non-zOS system

2013-01-17 Thread Phil Smith

Mark Jacobs wrote:
>I've been reading the ICSF Applications Programmers guide and I understand the 
>process on how to transport ICSF keys to another zOS system using 
>importer/exporter keys, but I have no idea on how it would work on a non-zOS 
>platform.

>Can anyone point me to some doc, or share their process if they've already 
>done it?

FYI, there's no such thing as an "ICSF key". There are keys of various sorts 
that ICSF manages, but they aren't ICSF-ized per se. I guess if they're wrapped 
(encrypted) in a Crypto Express, they could be sort of thought of as being 
bound to ICSF, but they still are really just 56 or 64 or 128 or 192 or 256 or 
however many bits of key material.

So...having said that, what do you mean by "how it would work on a non-z/OS 
platform"? How WHAT would work? An AES key is an AES key: if you have an AES 
algorithm and a key, you can encrypt data, and you'll get the same result on 
any platform (assuming you're using the same AES mode, etc.).

I feel like I'm taking you to task here, and I don't mean to be - just trying 
to understand what your real question is!

Cheers,
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)

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

Re: S0C4-4

2013-01-17 Thread Jim Mulder

IBM Mainframe Discussion List  wrote on 
01/17/2013 02:33:23 PM:

> From: Richard Verville 
> To: IBM-MAIN@listserv.ua.edu, 
> Date: 01/17/2013 03:00 PM
> Subject: S0C4-4
> Sent by: IBM Mainframe Discussion List 
> 
> REFRPROT is what is causing my S0C4. I wonder why this is not 
> happening with TS 3.2, the program has the same characteristics 
> (refr,rent etc...) as the one in TS 4.2. Is there a parm on the SVC 
> 08(load) that would change the REFR attribute (or make it ignore it). 
Richard

  REFRPROT protects the full 4K pages of REFR modules.  Possibly
the size of the module increased in TS 4.2 so that the area being
modified now falls within a full 4K page.

  But a semantic point about causality:  REFRPROT is not causing
your 0C4.  YOU are causing your 0C4 by storing into a page
which the program (by specifying REFR) and the installation 
(by specifying REFRPROT) have requested to be protected.
If the program intends that you should modify it,
then it should not be linked with REFR.  If the program does not
intend that you should modify it, then you should not 
modify it.  If you are modifying a program which is not
provided by you, and whose provider does not intend that you 
should modify it, then when you modify it, you may be 
voiding any warranty from the provider of the program. 
Is that disclosed to all users of your program? 



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

ICSF Symmetric Key being sent to a non-zOS system

2013-01-17 Thread Mark Jacobs

I've been reading the ICSF Applications Programmers guide and I 
understand the process on how to transport ICSF keys to another zOS 
system using importer/exporter keys, but I have no idea on how it would 
work on a non-zOS platform.


Can anyone point me to some doc, or share their process if they've 
already done it?


--
Mark Jacobs
Time Customer Service
Tampa, FL


The quiet ones are the ones that change the universe...
The loud ones only take the credit.

Londo Mollari - Babylon 5

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

Re: Running the RB chain of an inactive TCB

2013-01-17 Thread Tony Harminc

On 17 January 2013 14:12, Mark Henderson  wrote:
> Can someone explain to me the apparent contradiction in the following two 
> pieces of information ?
>
> From the serialization section of SYS1.MACLIB(IHARB):
> If the task is not running and the local lock is held, the RB chain will not 
> change.
>
> From APAR PQ81630:
> PQ76702 introduced code for MVSTCB TCB statistics. DFHDSMT calls
> DFHDSAUT for these statistics in routine CREATE_SNAPSHOT.
> DFHDSAUT will loop in routine TCB_SCAN due to not serializing
> the RB chain. A MVS local lock is not enough to serialize the
> RB chain.

Perhaps you're not seeing the "and" in the first quote?

Tony H.

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

S0C4-4

2013-01-17 Thread Richard Verville

REFRPROT is what is causing my S0C4. I wonder why this is not happening with TS 
3.2, the program has the same characteristics (refr,rent etc...) as the one in 
TS 4.2. Is there a parm on the SVC 08(load) that would change the REFR 
attribute (or make it ignore it). Richard

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Tony Harminc

On 17 January 2013 12:31, Martin, Larry D  wrote:
> But light doesn't create heat; thus more circuits in a smaller 
> space..

You've never sat out in the sun, I take it...

Tony H.

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

Re: DFHSM CDS size versus multi-cluster

2013-01-17 Thread O'Brien, David W. (NIH/CIT) [C]

Lizette,

What is the freespace(nn,nn) parameter in your CDS VSAM define?

I suspect you are running with something like 50,50 based on your comment. If 
you are 96% full with 62% freespace that tells me that a section of your CDS is 
experiencing a lot of activity and will drive the file to 100%. Probably at the 
most inopportune time.

Splits for a HSM CDS should not be a concern. It's not like anyone is waiting 
with bated breath for a migrate or backup to finish.

Like any other VSAM KSDS, the HSM CDSs need to be re-organized from time to 
time.

Thank You,
Dave O'Brien
NIH Contractor

From: Lizette Koehler [stars...@mindspring.com]
Sent: Thursday, January 17, 2013 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM CDS size versus multi-cluster

I think if you issue the command F dfhsm,Q CDS you may find in the ARC0148I
messages that there are two pieces of information to explain if your file
needs to be reorg'd

First is the number you get is %Full.  However there is a second number
%Freespace.

What I have seen in my shop is we are running 96% full.  However we have 62%
freespace.  Which to me does not indicate a need to reorg.

According to IBM and Share presentations, the xCDS files should not be
reorg'd.  That when you reorg an xCDS HSM has to starting splitting the
files again which will slow down the process for a little bit.  Once enough
splits occur so there is room to insert records, it is fine.

So the questions are
1) Is the xCDS so big it needs a reorg?
2) Do I need to resize the xCDS dataset?

Once those are answered, you can figure out when to take an outage on HSM.

The other option is to change from VSAM to VSAM RLS structure for your xCDS
datasets.  You may also wish to review if the Journal dataset should be
changed as well.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of af dc
> Sent: Thursday, January 17, 2013 5:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM CDS size versus multi-cluster
>
> Hello,
> I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
> 6500 CYLS with no SEC space.
> VSAM characteristics are:
> SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
> UNORDERED   TEMP-EXP NOREUSE   NONSPANNED
>
> INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
> EXTENDEDEXT-ADDR
>
> In a short time I'll have to create a new BCDS, so, in your opinion what's
advisable to
> have (performance aspect, backup considerations?, etc)??
>  1) a bigger BCDS or
>  2) multi cluster
>
> Note:
> - DFHSM cdss are shared among 3 lpars
>
> Any hint is welcome?
> Many thx, Antonio Cecilio.
>
> --
> 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: SMS COMMAND VIA BATCH

2013-01-17 Thread retired mainframer

I believe ISMF shows the status in the SCDS while the D command shows the
status in the ACDS.  VARY commands update the ACDS but you need to manually
update the SCDS if you want the change to be reflected in the next ACTIVATE.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of John Dawes
:>: Sent: Thursday, January 17, 2013 9:54 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: SMS COMMAND VIA BATCH
:>:
:>: Boris,
:>:
:>: I tried out your suggestion and it ran well.  When I run the command to
:>: query the status of the storage group D SMS,SG(CICSSG01),LISTVOL it
:>: shows that the VOLUME is D.
:>: However, when I check via ISMF it shows that it is in ENABLE status (col
:>: 25).  I cannot understand which status is right or why there is a
:>: discrepancy between the two.

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

Running the RB chain of an inactive TCB

2013-01-17 Thread Mark Henderson

Can someone explain to me the apparent contradiction in the following two 
pieces of information ? 

From the serialization section of SYS1.MACLIB(IHARB):
If the task is not running and the local lock is held, the RB chain will not 
change. 
 
From APAR PQ81630:
PQ76702 introduced code for MVSTCB TCB statistics. DFHDSMT calls
DFHDSAUT for these statistics in routine CREATE_SNAPSHOT.
DFHDSAUT will loop in routine TCB_SCAN due to not serializing
the RB chain. A MVS local lock is not enough to serialize the
RB chain.

Thanks in advance, Mark.

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

Download the Redbook: Batch Modernization on z/OS

2013-01-17 Thread Ed Gould


http://www.redbooks.ibm.com/redbooks/pdfs/sg247779.pdf



Mainframe computers play a central role in the daily operations of  
many of the world's largest corporations, and batch processing is a  
fundamental part of the workloads that run on the mainframe. A large  
portion of the workload on IBM® z/OS® systems is processed in batch  
mode.
Although several IBM Redbooks® publications discuss application  
modernization on the IBM z/OS platform, this book specifically  
addresses batch processing in detail.


Many different technologies are available in a batch environment on z/ 
OS systems. This book demonstrates these technologies and shows how  
the z/OS system offers a sophisticated environment for batch. In this  
practical book, we discuss a variety of themes that are of importance  
for batch workloads on z/OS systems and offer examples that you can  
try on your own system. The book also includes a chapter on future  
developments in batch processing. 
--

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

Bounds Checking [Was Re: Java Security?]

2013-01-17 Thread Tom Ross

>>If I remember rightly Pascal does bounds checking. Pascal was one of the=20
>>languages I did at college - and the highest-level one. A bit of a shock=20
>>to me to discover - in an IBM Systems Engineer training homework=20
>>assignment - that COBOL didn't. (This was in 1986.) The result was me=20

>What about SSRANGE? Wasn't there an equivalent for FCOBOL as well as=20
>VS/COBOL?

There was SSRANGE available in 1986, but in VS COBOL II Release 1, which was
not quite ready for prime-time.  VS COBOL II Release 3 was the first VS COBOL II
that gained wide acceptance and it shipped in 1988.  In 1986 most people were
still using OS/VS COBOL, which had no help for bounds checking on subscripts.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: DFHSM CDS size versus multi-cluster

2013-01-17 Thread Ed Gould


David:

I was assigned the job (many years ago) to speed up the process (we  
did it weekly) with some tinkering of JCL  parameters I think (If I  
recall correctly) we got it down to 20 minutes (to tape). It wasn't  
hard.


Ed

On Jan 17, 2013, at 7:37 AM, O'Brien, David W. (NIH/CIT) [C] wrote:

To each his own but wouldn't an Export/Import be more efficient.  
There's no additional file to define, no jcl to change or files to  
rename.


Besides the sample jcl is provided in sys1.samplib(ARCSTRST).  
HSMPRESS is located at the end of the member.


-Original Message-
From: Staller, Allan [mailto:allan.stal...@kbmg.com]
Sent: Thursday, January 17, 2013 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM CDS size versus multi-cluster

Probably needs to be re-orged. Define a "new cluster" shut down HSM 
(all LPARS) and repro. You will probably be amazed at how small the  
re-orged dataset will be.


That being said, my  DFHSM CDS's are defined as VSAM extended  
format dataset in a "do nothing" SMS management class and storage  
group.

Concurrent copy will greatly improve the speed of CDS backups.
Works great.

HTH,


I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's  
size is

6500 CYLS with no SEC space.
VSAM characteristics are:
SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
UNORDERED   TEMP-EXP NOREUSE   NONSPANNED

INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
EXTENDEDEXT-ADDR

In a short time I'll have to create a new BCDS, so, in your opinion  
what's advisable to have (performance aspect, backup  
considerations?, etc)??

 1) a bigger BCDS or
 2) multi cluster

Note:
- DFHSM cdss are shared among 3 lpars


--
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: SMS COMMAND VIA BATCH

2013-01-17 Thread John Dawes

Boris,
 
I tried out your suggestion and it ran well.  When I run the command to query 
the status of the storage group D SMS,SG(CICSSG01),LISTVOL it shows that the 
VOLUME is D.
However, when I check via ISMF it shows that it is in ENABLE status (col 25).  
I cannot understand which status is right or why there is a discrepancy between 
the two.



From: Boris Lenz 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, 17 January 2013 11:23 AM
Subject: Re: SMS COMMAND VIA BATCH

John,

your command wasn't found because VARY is an MVS command, not a TSO command, 
and IKJEFT01 is TSO.

If, as others pointed out, the // COMMAND suggestion doesn't work due to 
authorization issues or timing issues, you may want to try it in TSO batch 
again, using the CONSOLE command (for which you're authorized maybe).

Something like this:

//your-jobcard JOB ...                                              
//STEP01    EXEC  PGM=IEBUPDTE,PARM=NEW                              
//SYSPRINT  DD  DUMMY                                                
//SYSUT2    DD  DISP=(,PASS),SPACE=(TRK,(1,1)),                      
//          RECFM=FB,LRECL=80,DSORG=PO,DSNTYPE=LIBRARY              
//SYSIN    DD  DATA,DLM='¬¬'                                        
./ ADD NAME=MVSCMD                                                  
/* rexx */                                                          
/* issues MVS commands */                                            
arg dd                                                              
call ReadInput                                                      
if result ^= 0 then exit result                                      
call CountCmds                                                      
say "# of MVS commands to issue: "result                            
cartpfx = userid                                                    
cartcnt = 0                                                          
address tso                                                          
do k = 1 to inplines.0                                              
"CONSOLE ACTIVATE NAME("userid"Z)"                                  
'CONSPROF SOLDISP(NO) UNSOLDISP(NO) SOLNUM(1024) UNSOLNUM(1024)'    
conscmd = inplines.k                                                
'CONSOLE SYSCMD('conscmd') CART('conscart')'                        
gc = getmsg('R.','SOL',conscart,,5)                                
if gc = 4 then gc = getmsg('R.','EITHER',conscart,,5)              
if gc = 0 then do                                                  
    say "        Issuing command #"k"..."                          
    say "        "conscmd                                          
    do i = 1 to r.0                                                  
      conscmdn = r.mdbgtimh ""r.i                                  
      say conscmdn                                                  
    end                                                              
if gc > 0 then say 'Unable to retrieve message - GETMSG RC:' gc    
end                                                                
'CONSPROF SOLDISP(YES) UNSOLDISP(YES) SOLNUM(1000) UNSOLNUM(1000)'  
'CONSOLE DEACTIVATE'                                                
end                                                                  
exit                                                                
/**/                                                                
CountCmds: procedure expose inplines.                                
  j = 0                                                              
  do i = 1 to inplines.0                                            
    if (left(inplines.i,2) ^= "&&") then j=j+1                      
  end                                                                
return j                                                            
/**/                                                                
ReadInput: procedure expose dd inplines.                            
maxcc = 0                                                            
  address mvs "EXECIO * DISKR "dd" (STEM INPLINES. FINIS"            
  if rc ^= 0 then do                                                
    say "RXLENZ01 ERROR READING INPUT FROM DD "dd                    
    maxcc = 16                                                      
  end                                                                
  if inplines.0 = 0 then do                                          
    say "RXLENZ02 NO INPUT PROVIDED IN DD "dd                        
    maxcc = 16                                                      
  end                                                                
return maxcc                                                        
/**/                                                                
¬¬                                                      
//*                                                      
//STEP02

Re: silicon photonics - faster than copper

2013-01-17 Thread Pew, Curtis G

On Jan 17, 2013, at 11:23 AM, retired mainframer  
wrote:

> Don't both
> electricity and light move at c?

In a vacuum, light moves at c. In a fiber optic cable, you divide c by the 
index of refraction. That's usually in the range of 1.5, so the light is 
traveling about (2/3)c.

The speed of electrical signals is a bit more complicated. It's been almost 30 
years since I took electromagnetism so I'm not going to try to explain it; I'm 
sure I'd get it wrong. It will be less than c too, though.

-- 
Curtis Pew (c@its.utexas.edu)
ITS Systems Core
The University of Texas at Austin

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

Re: Mocha TN3270 on Android now available

2013-01-17 Thread Shane Ginnane

On Thu, 17 Jan 2013 10:40:11 +0100, R.S.  wrote:

>V2hpbGUgcG9pbnRpbmcgZGV2aWNlIGNvdWxkIGFjY2VwdGVkIHdpdGggc29tZSByZXNlcnZlLCBJ
>IGFic29sdXRlbHkgCmRvbid0IGFueSBkZXZpY2Ugd2l0aCAic3Ryb2tlZCIgaW50ZXJmYWNlLiBL
>ZXlib2FyZCBpcyBhIG11c3QsIGEgY2FibGUgCmlzIGEgbXVzdCBhbHNvLCBwcmVmZXJyYWJseSBj
>b2F4aWFsLgo7LSkKCi0tIApSYWRvc2xhdyBTa29ydXBrYQpMb2R6LCBQb2xhbmQKCgoKCgoKLS0N
>ClRyZRoaIHRlaiB3aWFkb21vGmNpIG1vGmUgemF3aWVyYRogaW5mb3JtYWNqZSBwcmF3bmllIGNo
>cm9uaW9uZSBCYW5rdSBwcnplem5hY3pvbmUgd3kaGmN6bmllIGRvIHUaeXRrdSBzGnUaYm93ZWdv
>IGFkcmVzYXRhLiBPZGJpb3JjGiBtbxplIGJ5GiBqZWR5bmllIGplaiBhZHJlc2F0IHogd3kaGmN6
>ZW5pZW0gZG9zdBpwdSBvc/NiIHRyemVjaWNoLiBKZRplbGkgbmllIGplc3RlGiBhZHJlc2F0ZW0g
>bmluaWVqc3plaiB3aWFkb21vGmNpIGx1YiBwcmFjb3duaWtpZW0gdXBvd2EabmlvbnltIGRvIGpl
>aiBwcnpla2F6YW5pYSBhZHJlc2F0b3dpLCBpbmZvcm11amVteSwgGmUgamVqIHJvenBvd3N6ZWNo
>bmlhbmllLCBrb3Bpb3dhbmllLCByb3pwcm93YWR6YW5pZSBsdWIgaW5uZSBkemlhGmFuaWUgbyBw
>b2RvYm55bSBjaGFyYWt0ZXJ6ZSBqZXN0IHByYXduaWUgemFicm9uaW9uZSBpIG1vGmUgYnkaIGth
>cmFsbmUuIEplGmVsaSBvdHJ6eW1hGmUaIHQaIHdpYWRvbW8aGiBvbXkaa293bywgcHJvc2lteSBu
>aWV6dxpvY3puaWUgemF3aWFkb21pGiBuYWRhd2MaIHd5c3kaYWoaYyBvZHBvd2llZBogb3JheiB0
>cndhbGUgdXN1bhoaIHQaIHdpYWRvbW8aGiB3GhpjemFqGmMgdyB0byB3c3plbGtpZSBqZWoga29w
>aWUgd3lkcnVrb3dhbmUgbHViIHphcGlzYW5lIG5hIGR5c2t1Lg0KDQpUaGlzIGUtbWFpbCBtYXkg
>Y29udGFpbiBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gb2YgdGhlIEJhbmsgYW5kIGlz
>IGludGVuZGVkIHNvbGVseSBmb3IgYnVzaW5lc3MgdXNlIG9mIHRoZSBhZGRyZXNzZWUuIFRoaXMg
>ZS1tYWlsIG1heSBvbmx5IGJlIHJlY2VpdmVkIGJ5IHRoZSBhZGRyZXNzZWUgYW5kIG1heSBub3Qg
>YmUgZGlzY2xvc2VkIHRvIGFueSB0aGlyZCBwYXJ0aWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
>ZW5kZWQgYWRkcmVzc2VlIG9mIHRoaXMgZS1tYWlsIG9yIHRoZSBlbXBsb3llZSBhdXRob3Jpc2Vk
>IHRvIGZvcndhcmQgaXQgdG8gdGhlIGFkZHJlc3NlZSwgYmUgYWR2aXNlZCB0aGF0IGFueSBkaXNz
>ZW1pbmF0aW9uLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55IG90aGVyIHNpbWlsYXIgYWN0
>aXZpdHkgaXMgbGVnYWxseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgcHVuaXNoYWJsZS4gSWYgeW91
>IHJlY2VpdmVkIHRoaXMgZS1tYWlsIGJ5IG1pc3Rha2UgcGxlYXNlIGFkdmlzZSB0aGUgc2VuZGVy
>IGltbWVkaWF0ZWx5IGJ5IHVzaW5nIHRoZSByZXBseSBmYWNpbGl0eSBpbiB5b3VyIGUtbWFpbCBz
>b2Z0d2FyZSBhbmQgZGVsZXRlIHBlcm1hbmVudGx5IHRoaXMgZS1tYWlsIGluY2x1ZGluZyBhbnkg
>Y29waWVzIG9mIGl0IGVpdGhlciBwcmludGVkIG9yIHNhdmVkIHRvIGhhcmQgZHJpdmUuIA0KDQpC
>UkUgQmFuayBTQSwgMDAtOTUwIFdhcnN6YXdhLCB1bC4gU2VuYXRvcnNrYSAxOCwgdGVsLiArNDgg
>KDIyKSA4MjkgMDAgMDAsIGZheCArNDggKDIyKSA4MjkgMDAgMzMsIHd3dy5icmViYW5rLnBsLCBl
>LW1haWw6IGluZm9AYnJlYmFuay5wbA0KUxpkIFJlam9ub3d5IGRsYSBtLiBzdC4gV2Fyc3phd3kg
>WElJIFd5ZHppYRogR29zcG9kYXJjenkgS3Jham93ZWdvIFJlamVzdHJ1IFMaZG93ZWdvLCBuciBy
>ZWplc3RydSBwcnplZHNpGmJpb3Jj83cgS1JTIDAwMDAwMjUyMzcsIE5JUDogNTI2LTAyMS01MC04
>OC4gDQpXZWQadWcgc3RhbnUgbmEgZHppZRogMDEuMDEuMjAxMyByLiBrYXBpdGEaIHphaxphZG93
>eSBCUkUgQmFua3UgU0EgKHcgY2EabxpjaSB3cBphY29ueSkgd3lub3NpIDE2OC41NTUuOTA0IHoa
>b3R5Y2guCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
>LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGb3IgSUJNLU1BSU4gc3Vic2NyaWJlIC8gc2lnbm9m
>ZiAvIGFyY2hpdmUgYWNjZXNzIGluc3RydWN0aW9ucywNCnNlbmQgZW1haWwgdG8gbGlzdHNlcnZA
>bGlzdHNlcnYudWEuZWR1IHdpdGggdGhlIG1lc3NhZ2U6IElORk8gSUJNLU1BSU4NCg==

What he ^^ said.
Ah, for the days when we could leave work at work - so much for the promised 
advances in technology giving us a better quality of life 

Shane ...

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Tom Marchant

On Thu, 17 Jan 2013 09:23:37 -0800, retired mainframer wrote:

>While photonic components (switches, etc) may be faster than the current
>semi-conductor ones, can the wiring really be a factor.  Don't both
>electricity and light move at c?

No.  Electrical signals propagate at about half the speed of light.
IIRC, inductance and capacitance play a role  too, so the exact 
speed depends upon the materials used.

-- 
Tom Marchant

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Paul Gilmartin

On Thu, 17 Jan 2013 12:31:58 -0500, Martin, Larry D wrote:

>But light doesn't create heat; thus more circuits in a smaller 
>space..
>
Drat!  Dashing everyone's hopes of solar energy.

-- gil

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Paul Gilmartin

On Thu, 17 Jan 2013 09:23:37 -0800, retired mainframer wrote:

>While photonic components (switches, etc) may be faster than the current
>semi-conductor ones, can the wiring really be a factor.  Don't both
>electricity and light move at c?
> 
Depends on the medium.  In diamond, light moves at c/2.417.  Electricity
in a wire moves (paradoxically) at the speed of light in the insulation,
perhaps 0.7 c. (Roughly; and all frequency dependent.  Makes it hard to
keep the bits together.)

-- gil

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Martin, Larry D

But light doesn't create heat; thus more circuits in a smaller 
space..

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Thursday, January 17, 2013 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: silicon photonics - faster than copper

While photonic components (switches, etc) may be faster than the current 
semi-conductor ones, can the wiring really be a factor.  Don't both electricity 
and light move at c?

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of John McKown
:>: Sent: Thursday, January 17, 2013 4:25 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: OT: silicon photonics - faster than copper
:>:
:>: http://www.computerworld.com.au/article/446722/intel_prepares_use_lasers
:>: _light_shuffle_data_between_computers/
:>: 
:>: Intel is taking the first steps to implement thin fiber optics that
:>: will use lasers and light as a faster way to move data inside
:>: computers, replacing the older and slower electrical wiring technology
:>: found in most computers today.
:>: 

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

This E-mail and any of its attachments may contain Prince George’s
County Government or Prince George's County 7th Judicial Circuit
Court proprietary information or Protected Health Information,
which is privileged and confidential.  This E-mail is intended
solely for the use of the individual or entity to which it is
addressed.  If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited by federal law
and may expose you to civil and/or criminal penalties. If you have
received this E-mail in error, please notify the sender immediately
and permanently delete the original and any copy of this E-mail and
any printout.

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

Re: silicon photonics - faster than copper

2013-01-17 Thread Tony B. AOL Mozilla

ISTM that the weaponry used by the Starship Enterprise was termed 
"photon torpedoes."  Quite effective in their day (whoa, "their day" 
hasn't occurred yet!




On 1/17/2013 11:23 AM, retired mainframer wrote:

While photonic components (switches, etc) may be faster than the current
semi-conductor ones, can the wiring really be a factor.  Don't both
electricity and light move at c?

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of John McKown
:>: Sent: Thursday, January 17, 2013 4:25 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: OT: silicon photonics - faster than copper
:>:
:>: http://www.computerworld.com.au/article/446722/intel_prepares_use_lasers
:>: _light_shuffle_data_between_computers/
:>: 
:>: Intel is taking the first steps to implement thin fiber optics that
:>: will use lasers and light as a faster way to move data inside
:>: computers, replacing the older and slower electrical wiring technology
:>: found in most computers today.
:>: 

--
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: silicon photonics - faster than copper

2013-01-17 Thread retired mainframer

While photonic components (switches, etc) may be faster than the current
semi-conductor ones, can the wiring really be a factor.  Don't both
electricity and light move at c?

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of John McKown
:>: Sent: Thursday, January 17, 2013 4:25 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: OT: silicon photonics - faster than copper
:>:
:>: http://www.computerworld.com.au/article/446722/intel_prepares_use_lasers
:>: _light_shuffle_data_between_computers/
:>: 
:>: Intel is taking the first steps to implement thin fiber optics that
:>: will use lasers and light as a faster way to move data inside
:>: computers, replacing the older and slower electrical wiring technology
:>: found in most computers today.
:>: 

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

Re: Mocha TN3270 on Android now available

2013-01-17 Thread Jim McAlpine

Is there a Cisco IPSEC client available for Android ?

Jim McAlpine

On Wed, Jan 16, 2013 at 10:58 PM, Edward Jaffe
wrote:

>  Original Message 
> Subject:Mocha TN3270 on Android now available
> Date:   Sat, 12 Jan 2013 17:56:49 -0500
> From:   Tony Thigpen 
> Reply-To:   VSE Discussion List 
> To: vmes...@listserv.uark.edu ,
> vs...@lehigh.edu 
>
>
>
> For two years I have been waiting for a TN3270 client for my droid. One
> guy released something about 6 months ago, but the user interface was
> poor. About once every 6 months, I emailed Mocha to see if they were
> doing anything, but every time they replied "we don't see a market,
> maybe you should consider an iPhone".
>
> Well, today, I did my 'ever so often' scan for TN3270 on Droid and this
> time I got a hit from where else but Mocha!
> http://mochasoft.dk/android_**3270.htm
> I have installed the trial version on my phone and it actually looks
> good (based on 5 minutes of playing).
>
> It may need a little refinement (like named connections) but at least we
> have something.
>
> I guess there is a Santa Claus.
>
> --
> Tony Thigpen
>
> __**_
> VSE-L mailing list
> vs...@lists.lehigh.edu
> https://lists.lehigh.edu/**mailman/listinfo/vse-l
>
> --**--**--
> 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: SMS COMMAND VIA BATCH

2013-01-17 Thread Darth Keller

Have you ever looked at using Naviquest to issue your SMS commands?   You 
can generate the JCL through the ISMF panels.

ISMF; 
ENHANCED ACS MANAGEMENT; 
BATCH TESTING/CONFIGURATION MANAGEMENT SELECTION MENU;
CONFIGURATION CHANGES BATCH SAMPLES SELECTION MENU;
Change Storage Group Volume Status 
Comment from the generated JCL:  SAMPLE JCL TO ADD NEW VOLUMES AND 
THEIR STATUS


An example from my JCL library: 
Note:  MY_ID would be where I specify my TSO userID; 
SGPAL in this example is the storage group name. 
SCDS name is pretty much self-documented.


//ADDVOL1 EXEC ACBJBAOB, 
//PLIB1='SYS1.DGTPLIB', 
//TABL2=MY_ID.TEST.ISPTABL 
//SYSUDUMP DD  SYSOUT=* 
//TEMPFILE  DD  DSN=&&VOLADDS,DISP=(NEW,KEEP), 
//  SPACE=(CYL,(15,15)),LRECL=300,RECFM=F,BLKSIZE=300 
//SYSTSIN  DD * 
PROFILE PREFIX(MY_ID) 
ISPSTART CMD(ACBQBAI9) + 
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 
/* 
//VOLADD  DD  * 
UPDHLVLSCDS() 
SCDSNAME('SMS.SCDS01.SCDS') VOL(PALF00) SG(SGPAL) STATUSALL(DISNEW) 
SCDSNAME('SMS.SCDS01.SCDS') VOL(PALF01) SG(SGPAL) STATUSALL(DISNEW) 
/* 
//VOLALT  DD  * 
/* 
//VOLDEL  DD * 
 /* 
 //ADDVOL2 EXEC ACBJBAOB, 
 //PLIB1='SYS1.DGTPLIB', 
 //TABL2=MY_ID.TEST.ISPTABL 
 //SYSUDUMP DD  SYSOUT=* 
 //SYSTSIN  DD DSN=&&VOLADDS,DISP=(OLD,DELETE) 
 //***   



I am trying to execute the following command via batch however I was 
unsuccessful : COMMAND VARY NOT FOUND
 
Could anybody suggest how I can correct my problem:
 
/* 
//STEP001 EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=* 
//SYSTSPRT DD SYSOUT=* 
//SYSTSIN  DD *
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW
/* 
//  

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

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

Re: Mocha TN3270 on Android now available

2013-01-17 Thread R.S.

W dniu 2013-01-17 17:02, Grinsell, Don pisze:

You can still get real coax in Poland? I'm jealous.

I still use coax. :-)
Really, my consoles are still connected to 3174's.
I created alternative (ICC) and waiting several years for 3174 failure.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: SMP Apply Question

2013-01-17 Thread Mary Anne Matyaz

Matt, 
I think about the best you can do is LIST SYSMODS FORFMID(HSMA135,HSMA136) (or 
whichever FMIDs you want) and exclude them manually. 
There was a SHARE requirement many years ago asking for this function, but at 
the time it was rejected because IBM didn't think they could provide it in the 
timeframe. It might be worth another try. 

Mary Anne 

On Thu, 17 Jan 2013 10:46:28 -0500, Dazzo, Matt  wrote:

>I have a shared global zone between lpars with targets for each lpar. I am 
>applying RSU maint, one lpar has osmf on it and one does not. What I would 
>like to do is on one lpar is exclude applying the ptf's for the fmids 
>pertaining to osmf but apply all the other ptf's in the RSU package I pulled 
>down.  I have looked in the smp commands guide on the apply command and saw 
>that the you can't EXCLUDE by FMID? Any suggestions on excluding ptf's for 
>certain FMID's?
>
>Thanks Matt

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread Boris Lenz

John,

your command wasn't found because VARY is an MVS command, not a TSO command, 
and IKJEFT01 is TSO.

If, as others pointed out, the // COMMAND suggestion doesn't work due to 
authorization issues or timing issues, you may want to try it in TSO batch 
again, using the CONSOLE command (for which you're authorized maybe).

Something like this:

//your-jobcard JOB ...   
//STEP01EXEC  PGM=IEBUPDTE,PARM=NEW  
//SYSPRINT  DD  DUMMY
//SYSUT2DD  DISP=(,PASS),SPACE=(TRK,(1,1)),  
//  RECFM=FB,LRECL=80,DSORG=PO,DSNTYPE=LIBRARY   
//SYSIN DD  DATA,DLM='¬¬'
./ ADD NAME=MVSCMD   
/* rexx */   
/* issues MVS commands */
arg dd   
call ReadInput   
if result ^= 0 then exit result  
call CountCmds   
say "# of MVS commands to issue: "result 
cartpfx = userid 
cartcnt = 0  
address tso  
do k = 1 to inplines.0   
 "CONSOLE ACTIVATE NAME("userid"Z)"  
 'CONSPROF SOLDISP(NO) UNSOLDISP(NO) SOLNUM(1024) UNSOLNUM(1024)'
 conscmd = inplines.k
 'CONSOLE SYSCMD('conscmd') CART('conscart')'
 gc = getmsg('R.','SOL',conscart,,5) 
 if gc = 4 then gc = getmsg('R.','EITHER',conscart,,5)   
 if gc = 0 then do   
say " Issuing command #"k"..."   
say " "conscmd   
do i = 1 to r.0  
   conscmdn = r.mdbgtimh ""r.i   
   say conscmdn  
end  
 if gc > 0 then say 'Unable to retrieve message - GETMSG RC:' gc 
 end 
 'CONSPROF SOLDISP(YES) UNSOLDISP(YES) SOLNUM(1000) UNSOLNUM(1000)'  
 'CONSOLE DEACTIVATE'
end  
exit 
/**/ 
CountCmds: procedure expose inplines.
  j = 0  
  do i = 1 to inplines.0 
if (left(inplines.i,2) ^= "&&") then j=j+1   
  end
return j 
/**/ 
ReadInput: procedure expose dd inplines. 
maxcc = 0
  address mvs "EXECIO * DISKR "dd" (STEM INPLINES. FINIS"
  if rc ^= 0 then do 
say "RXLENZ01 ERROR READING INPUT FROM DD "dd
maxcc = 16   
  end
  if inplines.0 = 0 then do  
say "RXLENZ02 NO INPUT PROVIDED IN DD "dd
maxcc = 16   
  end
return maxcc 
/**/ 
¬¬   
//*  
//STEP02EXEC  PGM=IKJEFT01,PARM='%MVSCMD MVSCMDS'
//SYSEXEC   DD  DSN=*.STEP01.SYSUT2,DISP=(OLD,DELETE)
//SYSTSPRT  DD  SYSOUT=* 
//SYSTSIN   DD  DUMMY
//MVSCMDS   DD * 
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW 
//


Regards,
Boris

--
For IBM-MAIN s

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread David Devine

An alternative way to skin this particular cat would be to use batch sdsf.

//JS0015   EXEC PGM=SDSF   
//ISFOUT   DD   SYSOUT=*   
//ISFINDD   *  
/RO *ALL,D SMS,SG(STANDARD),LISTVOL
/* 

The command string is limited to 42 chars so not great, but has the benefit in 
that if you can issue commands via sdsf you can use this.

Dave

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread John Dawes

One question,  When I run the job don't I need the EXEC  PGM=x in order to 
issue the command ?  I checked the manual for an example but it just displays 
the actual COMMAND.
 Examples of the COMMAND StatementExample 1The following shows an example 
COMMAND statement with the START command.// COMMAND ’S VTAM’ start VTAMExample 
2The following is an example of a command that is continued with the command
operand in apostrophes.// COMMAND ’SEND ’’This message will be sent to user 
SCOTTC
// when this job is converted’’,USER=(SCOTTC)’



From: Steve Thompson 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, 17 January 2013 10:50 AM
Subject: Re: SMS COMMAND VIA BATCH

From:  Lizette Koehler
Date:  01/17/2013 09:42 AM


Well, if you must do JCL, then you need to use the JCL statement for 
COMMAND
not IKJEFT01.  Vary does not work under it.

It might work under OPER in TSO.

But, I find, //  COMMAND,VARY

COMMAND Statement

z/OS V1R12.0 MVS JCL Reference
SA22-7597-14


Lizette's directive is a good one. You can also do the following:

//  VARY .

But in all of these, you will need to ensure that you have Security 
authority to issue commands via JCL.

This authority can be effected in a few ways.

Regards,
Steve Thompson

--
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: SMS COMMAND VIA BATCH

2013-01-17 Thread Ed Gould


Lizette:

AND that is only if the JES2 init parms are set up that way. Which of  
course is a big NONO (security wise).


Ed


On Jan 17, 2013, at 9:40 AM, Lizette Koehler wrote:

Well, if you must do JCL, then you need to use the JCL statement  
for COMMAND

not IKJEFT01.  Vary does not work under it.

It might work under OPER in TSO.

But, I find, //  COMMAND,VARY

COMMAND Statement

z/OS V1R12.0 MVS JCL Reference
SA22-7597-14

Purpose

Use the COMMAND statement to specify an MVS™ or JES command that  
the system

issues when the submitted JCL is converted.

The COMMAND statement is the preferred way within the job control  
language
to specify commands, rather than using the JCL command statement,  
which is
described in JCL Command Statement. That is because the COMMAND  
statement is
in standard JCL statement format, is parsed and processed using  
code common

to the other JCL statements, and if necessary may be continued across
multiple card images, that is, is not limited to 80 characters.  
Note that
some MVS subsystems, including TSO, JES2, and JES3, offer  
additional ways to
enter system commands outside JCL, which may be preferable under  
certain

circumstances.


Acceptable

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On

Behalf

Of John Dawes
Sent: Thursday, January 17, 2013 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS COMMAND VIA BATCH

G'Day,

I am trying to execute the following command via batch however I was

unsuccessful :

COMMAND VARY NOT FOUND

Could anybody suggest how I can correct my problem:

/*
//STEP001 EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW
/*
//

Thanks in advance.



--
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: SMS COMMAND VIA BATCH

2013-01-17 Thread Pew, Curtis G

On Jan 17, 2013, at 9:40 AM, Lizette Koehler  wrote:

> Use the COMMAND statement to specify an MVST or JES command that the system
> issues when the submitted JCL is converted.

It's important to note that the command is issued when the JCL is converted, 
usually shortly after the job is submitted, and not when the job is executing. 
This may not be what you want; for example, you may wish the command to be 
issued after step A but before step B.

-- 
Curtis Pew (c@its.utexas.edu)
ITS Systems Core
The University of Texas at Austin

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

Re: Mocha TN3270 on Android now available

2013-01-17 Thread Grinsell, Don

You can still get real coax in Poland?  I'm jealous.

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"Man can climb to the highest summits, but he cannot dwell there long."
~ George Bernard Shaw (1856-1950)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, 17 January 2013 02:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mocha TN3270 on Android now available

While pointing device could accepted with some reserve, I absolutely don't any 
device with "stroked" interface. Keyboard is a must, a cable is a must also, 
preferrably coaxial.
;-)

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

SMP Apply Question

2013-01-17 Thread Dazzo, Matt

I have a shared global zone between lpars with targets for each lpar. I am 
applying RSU maint, one lpar has osmf on it and one does not. What I would like 
to do is on one lpar is exclude applying the ptf's for the fmids pertaining to 
osmf but apply all the other ptf's in the RSU package I pulled down.  I have 
looked in the smp commands guide on the apply command and saw that the you 
can't EXCLUDE by FMID? Any suggestions on excluding ptf's for certain FMID's?

Thanks Matt



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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread Steve Thompson

From:   Lizette Koehler
Date:   01/17/2013 09:42 AM

Well, if you must do JCL, then you need to use the JCL statement for 
COMMAND
not IKJEFT01.  Vary does not work under it.

It might work under OPER in TSO.

But, I find, //  COMMAND,VARY

COMMAND Statement

z/OS V1R12.0 MVS JCL Reference
SA22-7597-14

Lizette's directive is a good one. You can also do the following:

//  VARY .

But in all of these, you will need to ensure that you have Security 
authority to issue commands via JCL.

This authority can be effected in a few ways.

Regards,
Steve Thompson

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

Re: Sterling-ConnectDirect

2013-01-17 Thread Juergen Keller

thats in our NETMAP as we still have SNA-Nodes (most LU6.2)
 
===
SELECT NETWORK MAP 
===
   
Node Name   : nodeVTAM Applid   : appl
Max Parsess : 6   Def Ses Class : 1
Session Type: SNA Environment   :  
API Applids : NDMUSRA  NDMUSRB  NDMUSRC  NDMUSRD  NDMUSRE  
  NDMUSRF  NDMUSRG  NDMUSRH  NDMUSRI  NDMUSRJ  
  NDMUSRK  NDMUSRL  NDMUSRM  NDMUSRN  NDMUSRO  
  NDMUSRP  NDMUSRQ  NDMUSRR  NDMUSRS  NDMUSRT  
  NDMUSRU  NDMUSRV  NDMUSRW  NDMUSRX  NDMUSRY  
  NDMUSRZ  
Node Status : INTERNAL, SEND, RECEIVE  
  Session Snode Max : 255  

SNA was unchanged when adding TCP. TCP was 'addon'

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

Re: SMS COMMAND VIA BATCH

2013-01-17 Thread Lizette Koehler

Well, if you must do JCL, then you need to use the JCL statement for COMMAND
not IKJEFT01.  Vary does not work under it.

It might work under OPER in TSO.

But, I find, //  COMMAND,VARY

COMMAND Statement

z/OS V1R12.0 MVS JCL Reference
SA22-7597-14

Purpose

Use the COMMAND statement to specify an MVS or JES command that the system
issues when the submitted JCL is converted.

The COMMAND statement is the preferred way within the job control language
to specify commands, rather than using the JCL command statement, which is
described in JCL Command Statement. That is because the COMMAND statement is
in standard JCL statement format, is parsed and processed using code common
to the other JCL statements, and if necessary may be continued across
multiple card images, that is, is not limited to 80 characters. Note that
some MVS subsystems, including TSO, JES2, and JES3, offer additional ways to
enter system commands outside JCL, which may be preferable under certain
circumstances.


Acceptable

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of John Dawes
> Sent: Thursday, January 17, 2013 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS COMMAND VIA BATCH
> 
> G'Day,
> 
> I am trying to execute the following command via batch however I was
unsuccessful :
> COMMAND VARY NOT FOUND
> 
> Could anybody suggest how I can correct my problem:
> 
> /*
> //STEP001 EXEC PGM=IKJEFT01
> //SYSPRINT DD SYSOUT=*
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN  DD *
> VARY SMS,VOLUME(SMC1G5),DISABLE,NEW
> /*
> //
> 
> Thanks in advance.
> 

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

SMS COMMAND VIA BATCH

2013-01-17 Thread John Dawes

G'Day,
 
I am trying to execute the following command via batch however I was 
unsuccessful : COMMAND VARY NOT FOUND
 
Could anybody suggest how I can correct my problem:
 
/* 
//STEP001 EXEC PGM=IKJEFT01    
//SYSPRINT DD SYSOUT=* 
//SYSTSPRT DD SYSOUT=* 
//SYSTSIN  DD *    
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW    
/* 
//  
 
Thanks in advance.  

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

Re: Sterling-ConnectDirect

2013-01-17 Thread Ron Wells

is what I have <<


... and something more from the INIT-deck
   TCP = OES  /* OES  - USE IBM OPEN EDITION SOCKETS   */
  TCP.LISTEN=(ANYADDR, 1364)  /* SINGLE IPV4 LISTEN   */ 
  TCP.API.LISTEN=(ANYADDR , 1363) 
 TCP.TIMER = 120  /* WAIT TIME FOR DATA READ   */
 TCP.FMH.TIMER = 00:03:00 /* WAIT TIME FOR FMH READ*/
TCP.RUNTASK.TIMER = 00:05:00 /* WAIT TIME - SNODE RUNTASK TO COMP  */

>> maybe ??

noticed the Node names I usedboth sidesare also defined as VTAM 
node names

Node Name   : NDMPRD  VTAM Applid   : NDMPRD2 
Max Parsess : 14  Def Ses Class : 2 
Session Type: SNA Environment   : 
API Applids : NDMPRDI0 NDMPRDI1 NDMPRDI2 NDMPRDI3 NDMPRDI4 
  NDMPRDI5 NDMPRDI6 NDMPRDI7 NDMPRDI8 NDMPRDI9 
Node Status : INTERNAL, SEND, RECEIVE 
  Session Snode Max : 255 

Do these have to be defines with Diff. names as ADJ definitions???







From:   Juergen Keller 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   01/17/2013 08:49 AM
Subject:Re: Sterling-ConnectDirect
Sent by:IBM Mainframe Discussion List 



hello Ron,

unfortunately my C:D-colleague is on holiday but I will try to answer your 
question

That's what he has defines in NETMAP:

/*  THE FOLLOWING IS TCP/IP DEFAULT ENTRY AND MUST NOT BE  */
/*  REMOVED IF TCP/IP IS TO BE USED (TCP=IBM OR TCP=SNS IN THE */
/*  INITPARMS).*/
  ADJACENT.NODE = ((TCP.IP.DEFAULT, , , TCP)) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  PARSESS=(10 1) - 
  ENVIRONMENT=OS390 - 
) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  ENVIRONMENT=WINDOWS - 
) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  PARSESS=(10 1)  - 
  ENVIRONMENT=UNIX - 
) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP,) - 
  PARSESS=(2 1) - 
  ENVIRONMENT=OS400 - 
) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) - 
   ALTERNATE.COMMINFO=(ALT.TYPE=TCP,ALT.ADDR=ip-addr) -
ENVIRONMENT=NT - 
  ) 

and the JCL ...

//NDM EXEC PGM=DMINIT, 
//PARM='&NDMPREF..PARMLIB(&PARMMEM)',
//*   REGION=16M, 
//REGION=0M, 
//TIME=1440 
//*   TIME=1 
//INCLUDE MEMBER=TCPDATA 

TCPDATA

//SYSTCPD  DD DISP=SHR,DSN=

which contains ... (I think you already have one ...)

TCPIPJOBNAME TCPIP 
HOSTNAME  xxx 
DATASETPREFIX  
DOMAINORIGIN  
NSINTERADDR ip-addr 
RESOLVERTIMEOUT 1 

I hope that helps

regards Juergen

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: Sterling-ConnectDirect

2013-01-17 Thread Juergen Keller

... and something more from the INIT-deck
   TCP = OES  /* OES  - USE IBM OPEN EDITION SOCKETS   */
  TCP.LISTEN=(ANYADDR, 1364)  /* SINGLE IPV4 LISTEN   */ 
  TCP.API.LISTEN=(ANYADDR , 1363)
 TCP.TIMER = 120  /* WAIT TIME FOR DATA READ   */
 TCP.FMH.TIMER = 00:03:00 /* WAIT TIME FOR FMH READ*/
TCP.RUNTASK.TIMER = 00:05:00 /* WAIT TIME - SNODE RUNTASK TO COMP  */

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

Re: MGCRE problem

2013-01-17 Thread Ward, Mike S

Never mind I figured it out.

UNKNIDS and INTIDS


Thanks
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Thursday, January 17, 2013 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MGCRE problem

Hello all,

We are testing on a z/OS V1.13 system. I have a program that I wrote that uses 
the MGCRE service in order to execute internal commands. The program works the 
command is executed and the command and its output is placed into the hardcopy 
log. The problem I am having is that on the V1.11 and prior the command and its 
output displayed on the master console as well as the hardcopy log. Now the 
command and its output do not display on the master console only on the 
hardcopy log. I reviewed the consol00 member and the parameters, but I do not 
see anything in the init and tuning guide for console that might fix this 
problem. I also reviewed the mgcre macro for any additional parameters.

Am I missing something simple, or do the internal commands issued by MGCRE no 
longer display on the master console?


Any help appreciated and thanks in advance.

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: Sterling-ConnectDirect

2013-01-17 Thread Juergen Keller

hello Ron,

unfortunately my C:D-colleague is on holiday but I will try to answer your 
question

That's what he has defines in NETMAP:

/*  THE FOLLOWING IS TCP/IP DEFAULT ENTRY AND MUST NOT BE  */
/*  REMOVED IF TCP/IP IS TO BE USED (TCP=IBM OR TCP=SNS IN THE */
/*  INITPARMS).*/
  ADJACENT.NODE = ((TCP.IP.DEFAULT, , , TCP))

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  PARSESS=(10 1) -   
  ENVIRONMENT=OS390 -
)

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  ENVIRONMENT=WINDOWS - 
)   

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
  PARSESS=(10 1)  -  
  ENVIRONMENT=UNIX - 
)

  ADJACENT.NODE=( (node,1364,ip-addr,TCP,) - 
  PARSESS=(2 1) - 
  ENVIRONMENT=OS400 - 
) 

  ADJACENT.NODE=( (node,1364,ip-addr,TCP) -
   ALTERNATE.COMMINFO=(ALT.TYPE=TCP,ALT.ADDR=ip-addr) -
ENVIRONMENT=NT -   
  )

and the JCL ...

//NDM EXEC PGM=DMINIT,   
//PARM='&NDMPREF..PARMLIB(&PARMMEM)',
//*   REGION=16M,
//REGION=0M, 
//TIME=1440  
//*   TIME=1 
//INCLUDE MEMBER=TCPDATA 

TCPDATA

//SYSTCPD  DD DISP=SHR,DSN=

which contains ... (I think you already have one ...)

TCPIPJOBNAME TCPIP  
HOSTNAME  xxx
DATASETPREFIX 
DOMAINORIGIN 
NSINTERADDR ip-addr
RESOLVERTIMEOUT 1   

I hope that helps

regards Juergen

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

Re: DFHSM CDS size versus multi-cluster

2013-01-17 Thread Lizette Koehler

I think if you issue the command F dfhsm,Q CDS you may find in the ARC0148I
messages that there are two pieces of information to explain if your file
needs to be reorg'd

First is the number you get is %Full.  However there is a second number
%Freespace.

What I have seen in my shop is we are running 96% full.  However we have 62%
freespace.  Which to me does not indicate a need to reorg.

According to IBM and Share presentations, the xCDS files should not be
reorg'd.  That when you reorg an xCDS HSM has to starting splitting the
files again which will slow down the process for a little bit.  Once enough
splits occur so there is room to insert records, it is fine.

So the questions are
1) Is the xCDS so big it needs a reorg?
2) Do I need to resize the xCDS dataset?

Once those are answered, you can figure out when to take an outage on HSM.

The other option is to change from VSAM to VSAM RLS structure for your xCDS
datasets.  You may also wish to review if the Journal dataset should be
changed as well.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of af dc
> Sent: Thursday, January 17, 2013 5:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM CDS size versus multi-cluster
> 
> Hello,
> I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
> 6500 CYLS with no SEC space.
> VSAM characteristics are:
> SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
> UNORDERED   TEMP-EXP NOREUSE   NONSPANNED
> 
> INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
> EXTENDEDEXT-ADDR
> 
> In a short time I'll have to create a new BCDS, so, in your opinion what's
advisable to
> have (performance aspect, backup considerations?, etc)??
>  1) a bigger BCDS or
>  2) multi cluster
> 
> Note:
> - DFHSM cdss are shared among 3 lpars
> 
> Any hint is welcome?
> Many thx, Antonio Cecilio.
> 
> --
> 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

Sterling-ConnectDirect

2013-01-17 Thread Ron Wells

Any one may have a sample for a Netmap setup...VTAM(I already have) but 
setting up for a TCPIP connection..

Looking for examples..

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

MGCRE problem

2013-01-17 Thread Ward, Mike S

Hello all,

We are testing on a z/OS V1.13 system. I have a program that I wrote that uses 
the MGCRE service in order to execute internal commands. The program works the 
command is executed and the command and its output is placed into the hardcopy 
log. The problem I am having is that on the V1.11 and prior the command and its 
output displayed on the master console as well as the hardcopy log. Now the 
command and its output do not display on the master console only on the 
hardcopy log. I reviewed the consol00 member and the parameters, but I do not 
see anything in the init and tuning guide for console that might fix this 
problem. I also reviewed the mgcre macro for any additional parameters.

Am I missing something simple, or do the internal commands issued by MGCRE no 
longer display on the master console?


Any help appreciated and thanks in advance.

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: DFHSM CDS size versus multi-cluster

2013-01-17 Thread O'Brien, David W. (NIH/CIT) [C]

To each his own but wouldn't an Export/Import be more efficient. There's no 
additional file to define, no jcl to change or files to rename. 

Besides the sample jcl is provided in sys1.samplib(ARCSTRST). HSMPRESS is 
located at the end of the member.  

-Original Message-
From: Staller, Allan [mailto:allan.stal...@kbmg.com] 
Sent: Thursday, January 17, 2013 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM CDS size versus multi-cluster

Probably needs to be re-orged. Define a "new cluster" shut down HSM(all LPARS) 
and repro. You will probably be amazed at how small the re-orged dataset will 
be.

That being said, my  DFHSM CDS's are defined as VSAM extended format dataset in 
a "do nothing" SMS management class and storage group.
Concurrent copy will greatly improve the speed of CDS backups.
Works great.

HTH,

I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
6500 CYLS with no SEC space.
VSAM characteristics are:
SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
UNORDERED   TEMP-EXP NOREUSE   NONSPANNED

INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
EXTENDEDEXT-ADDR

In a short time I'll have to create a new BCDS, so, in your opinion what's 
advisable to have (performance aspect, backup considerations?, etc)??
 1) a bigger BCDS or
 2) multi cluster

Note:
- DFHSM cdss are shared among 3 lpars

--
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: DFHSM CDS size versus multi-cluster

2013-01-17 Thread Staller, Allan

Probably needs to be re-orged. Define a "new cluster" shut down HSM(all LPARS) 
and repro. You will probably be amazed at how small the re-orged dataset will 
be.

That being said, my  DFHSM CDS's are defined as VSAM extended format dataset in 
a "do nothing" SMS management class and storage group.
Concurrent copy will greatly improve the speed of CDS backups.
Works great.

HTH,


I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
6500 CYLS with no SEC space.
VSAM characteristics are:
SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
UNORDERED   TEMP-EXP NOREUSE   NONSPANNED

INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
EXTENDEDEXT-ADDR

In a short time I'll have to create a new BCDS, so, in your opinion what's 
advisable to have (performance aspect, backup considerations?, etc)??
 1) a bigger BCDS or
 2) multi cluster

Note:
- DFHSM cdss are shared among 3 lpars


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

Re: DFHSM CDS size versus multi-cluster

2013-01-17 Thread O'Brien, David W. (NIH/CIT) [C]

Is the 85% full before or after you re-organized the file?

-Original Message-
From: af dc [mailto:acbi...@gmail.com] 
Sent: Thursday, January 17, 2013 7:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM CDS size versus multi-cluster

Hello,
I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
6500 CYLS with no SEC space.
VSAM characteristics are:
SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
UNORDERED   TEMP-EXP NOREUSE   NONSPANNED

INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
EXTENDEDEXT-ADDR

In a short time I'll have to create a new BCDS, so, in your opinion what's 
advisable to have (performance aspect, backup considerations?, etc)??
 1) a bigger BCDS or
 2) multi cluster

Note:
- DFHSM cdss are shared among 3 lpars

Any hint is welcome?
Many thx, Antonio Cecilio.

--
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: Deleting a nonexisting volser from hsm

2013-01-17 Thread David Devine

Hello Michael,
Are you still having the problem? i've been having a tinker and may have a 
workaround.

Restore & rename the control datasets from the cds backup to your own 
qualifiers and then browse with tso superc 3.15  (you may be able to browse the 
cds's directly with file-aid or equivalents; don't have them here so can only 
use superc 3.15 and cannot do so online) 

Then scan the bcds (or mcds) for the volser and there should be a dataset on 
the same line. (possibly multiple lines) 
If you are absolutely sure the tape is gone, issue bdeletes or hdeletes as 
appropriate. 
A scan of the ocds will show up all the T entrys for the tape and just issue 
fixcds T xx-vvv- deletes for each of them if there are any still there 
, you may have already sorted these.

A further scan should show you all clear.

Regards
 Dave 


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

OT: silicon photonics - faster than copper

2013-01-17 Thread John McKown

http://www.computerworld.com.au/article/446722/intel_prepares_use_lasers_light_shuffle_data_between_computers/

Intel is taking the first steps to implement thin fiber optics that
will use lasers and light as a faster way to move data inside
computers, replacing the older and slower electrical wiring technology
found in most computers today.


-- 
Maranatha! <><
John McKown

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

DFHSM CDS size versus multi-cluster

2013-01-17 Thread af dc

Hello,
I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is
6500 CYLS with no SEC space.
VSAM characteristics are:
SHROPTNS(3,3)   RECOVERY UNIQUE   NOERASE
UNORDERED   TEMP-EXP NOREUSE   NONSPANNED

INDEXED   NOWRITECHK NOIMBED   NOREPLICAT
EXTENDEDEXT-ADDR

In a short time I'll have to create a new BCDS, so, in your opinion what's
advisable to have (performance aspect, backup considerations?, etc)??
 1) a bigger BCDS or
 2) multi cluster

Note:
- DFHSM cdss are shared among 3 lpars

Any hint is welcome?
Many thx, Antonio Cecilio.

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

Re: Break a dataset into new record boundaries?

2013-01-17 Thread Massimo Biancucci

There were a couple of issues about finding a multiple delimiter.
 
So the new rexx will produce empty records too (means record with the delimiter 
only) and could manage a delimiter as a file termination (last empty record) or 
file start.
 
Sorry for flooding the list with such a long answer.
 
Regards.
 
Input:
* Top of Data **
$$A...+1+2+3+4+5    
+6+$B...+1+2+3..    
..+4+5+6+7$C...+1...    
.+2+3+4+$D+2    
+3$E...+1+2+3+4$F$G.    
...+1$H...$$I...+1$L...+2+3..$$$    
 Bottom of Data 
 
Output:
* Top of Data **
$   
$A...+1+2+3+4+5+6+  
$B...+1+2+3+4+5+6+7 
$C...+1+2+3+4+  
$D+2+3  
$E...+1+2+3+4   
$F  
$G+1    
$H...   
$   
$I...+1 
$L...+2+3.. 
$   
$   
$   
 Bottom of Data 
 
Rexx:
 
/* REXX */  
PARSE ARG BLOCK_READ .  
BLOCCO = 0  
BLOCCW = 0  
LETTI = 0   
DROP LISTA. 
L = 0   
DELIM = "$" 
INP_STR = ""    
OUT_STR = ""    
    
"EXECIO 0 DISKR FILE1"  
"EXECIO 0 DISKW FILE2"  
    
"EXECIO" BLOCK_READ "DISKR FILE1(STEM INPUT."   
    
DO WHILE(INPUT.0 > 0)   
  BLOCCO = BLOCCO + 1   
  SAY "LETTO BLOCCO:" BLOCCO "DI" INPUT.0 "RECORDS" 
  IF BLOCCO = 1 &,  
 LEFT(INPUT.1,1) <> DELIM THEN DO   
    SAY "FIRST RECORD DOES NOT START WITH '"DELIM"'"    
    EXIT(99)    
  END   
  CALL ELABORA  
  "EXECIO" BLOCK_READ "DISKR FILE1(STEM INPUT." 
END 
    
IF INP_STR > "" THEN DO 
  L = L + 1 
  LISTA.L = INP_STR 
END 
    
IF L > 0 THEN DO    
  BLOCCW = BLOCCW + 1   
  "EXECIO" L "DISKW FILE2(STEM LISTA."  
  SAY "SC

Re: Mocha TN3270 on Android now available

2013-01-17 Thread R.S.

While pointing device could accepted with some reserve, I absolutely
don't any device with "stroked" interface. Keyboard is a must, a cable
is a must also, preferrably coaxial.

;-)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Sharing TS7700 across sms plex

2013-01-17 Thread Mary Anne Matyaz

He means SC35-0427.  
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOWNLOAD/dgt2o370.pdf?DN=SC35-0427-10&DT=20110601095613
 

Mary Anne

On Wed, 16 Jan 2013 20:58:52 -0600, Victor Zhang  
wrote:

>I can't locate SG35-0427, can you tell me where to find it?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

79 matches

Mail list logo