from:"R.S."

Re: Printing DASD type

2012-06-12 Thread R.S.

W dniu 2012-06-13 07:14, mf db pisze:

Hello All,

We know pretty well that Mod - 3 , Mod - 9 . Mod - 27 has a Cylinder
of 3K , 9K and 27k, but in a environment where we have mixture of all these
type it becomes hard to know by each Volume serial. Are there any ways to
scan only the Volumes corresponding to MOD 3 or MOD 9 ?

Any suggestions or advises are much appreciated.

Suggestion: you SHOULD know each volume, its capacity, volser, etc. You
can use sophisticated tools, or simple regular spreadsheet.
If you need, you can use naming convention for that, i.e. third letter
of the volser tells you the model, - 1,2,3,9,A (=27) ,B (=54) ,C (=your
custom size).

If you want to know number of cylinders for existing device, then use DS
QD command.

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

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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

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

Re: How many cost a cpu second?

2012-06-12 Thread R.S.

W dniu 2012-06-12 23:13, Salva Carrasco pisze:

Apart from the syntax error "How many" vs. "How much", My question is not
having much success.

In other terms:
If I have a STC consuming 25,000 cpus / secs per month, and I spend two days
optimizing it to reduce to 15,000.
Am I gaining money or loosing time ?

It DEPENDS.

If your STC consumes "free" CPU cycles, then you lost time. If your STC
consumes *AND MUST* consume CPU cycle during rush hours, and cannot be
dispatched on other hours, then you saved some cycles from the peak,
which COULD mean real savings.

Disclaimer: I'm not biased. I'm not interested in neighter your
gratification, nor company savings. My opinion. If you need some
justification, why you should get bonus, just tell us, we imagine
something ;-)

BTW: BTDT. I did it many times. I did many optimisations, which saved
"countable" amounts of money and almist never get gratified for that.
What a pity!

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Weird thought on misuse of a GDG.

2012-06-11 Thread R.S.

W dniu 2012-06-11 21:58, Roberts, John J pisze:

But in today's world, without SCRATCH in the definition, the oldest
GDG does not get scratched. It gets "rolled off" the GDG base and
becomes a "normal" cataloged dataset entry. So it stays in the
catalog, and can be referenced by absolute name. I wonder if this
would ever be of some use to anyone.

What happens when you hit GV00? Does it wrap to GV00 or
G0001V00? If so, you could be attempting to catalog a name that
already exists. Not a problem for most generation datasets, but I
would guess that someone would trip over this someday. Especially if
z/OS lasts another 50 years ;-)

There is no need to wait 50 years, usually it takes 30 minutes during
... JCL course. I've taught so many groups where there was at least one
guy who wanted to check it. ;-)

BTW: Much more cumbersome may be "can I submit JOB A from JOB A,
recurrently?"

BTW2: In real world datasets, even generated more than daily is
ENOUGH. 255 is not of course.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: FYI LinkedIn passwords hacked

2012-06-10 Thread R.S.

W dniu 2012-06-10 22:37, Andy Wood pisze:

On Fri, 8 Jun 2012 22:48:50 +0200, R.S.
wrote:

[snipped]

I am quite prepared to accept that mainframe workers would know that
it is not a good idea to reuse passwords in that way.

However, that was not my point when I said that "we" might learn
something from this.

Some aspects of the incident were clearly not so "obvious" - the fact
that you had to explain what a rainbow table is proves that.

You also explained how RACF encrypts passwords, but actually an
installation can choose to encrypt passwords some other way, via the
ICHDEX01 exit. I'm not saying that this is a good or bad thing, but
it exists, and may be used. Would you want an exit like that to be
implemented by somebody who never heard of a rainbow table?

Yes, I was less accurate than RACF manuals, maybe due to size
limitations of the messages sent ti the listserv ;-)

And no, I wouldn't want anything from the person which does the thing he
has no idea about. And this is the case - a person who wants to store
passwords, provide changes to very delicate part of security system and
has no idea how to do it.

Also, no, I see no reason to use this exit.

And yes, there is always an opportunity to learn something form any
event/information you get. However some of the informations are
mainframe related and some are not.
Again, I'm not going to fight for it, but I'm also not going to say that
linkedin is on topic, because it's not.

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Failed Disk Data Exposure

2012-06-09 Thread R.S.

W dniu 2012-06-08 23:15, Grinsell, Don pisze:

Here's a Friday topic: With modern disk arrays, e.g. DS8000, what is
the real exposure of meaningful residual data being recovered from a
single drive out of the array. I can't seem to find anything
definitive other than a lot of "data may be recoverable" statements
from vendors selling secure erase services. Just curious if anybody
has any hard data to demonstrate an exposure or not.

1. Any disk from array do *contain data*. In case of RAID1 it's obvious,
in case of RAID5 or RAID6 there are still some data on it.
Is it hard to read it? There are EBCDIC conversion issues, 3390
emulations etc. etc. Usually it's very hard, but not impossible. Last,
but not least: this is political issue. If someone read any string of
characters, for example SMITH, then it's your fault, newspapers shout
about security breach, etc. Nevermind that nobody knows who is SMITH and
any further detail about him (her).

2. How to manage it.
First, you have to remember that failed disk can be really FAILED. Not
working. In such case any security erase software will not help. BTW:
such software is available os DASD box feature (all big manufacturers do
offer it). So, in some cases you cannot use a software.
2.1. You can pay your vendor for failed disks. Regular service contract
assumes that failed disks are replaced and taken off by serviceman. You
can pay and keep failed disk.
2.2. You can sign "NDA contract" (it's free of charge) that failed disks
are kept in secure locations and no one would try to recover any data.
In simple words DASD vendor promises you some security. Is it enough?
It's matter of your company rules.

Ad 2.1. Method used by Google (presented on Youtube) is nice, impressive
but overkill. For example step one is not necessare when you intend to
totally shred disk in step two. You can also buy degausser (severla
hundreds $ AFAIK) or pay some company for degaussing as a service (in
your premises - disks do not leave secure area).
BTW: Some company in Poland patented a method - they dissolve whole
disks in some acid mixture. Quite impressive and overkill IMHO.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Need a PC tape drive to read 3490, 3490E

2012-06-08 Thread R.S.

W dniu 2012-06-08 21:06, Mike Baldwin pisze:
[...]

There are also Fujitsu, IBM 3490F (which I think is really Overland),
If you mean 3490E-Fxx, then yes, it;s Overland drive, attached (using
SCSI) to a PC. The PC is small Siemens server running Sinix (Siemens
flavor of Unix). The PC has ESCON cards for host attachment and SCSI for
drive attachment.

My opinion: piece of sh*t. Older 3490E-Cxx drives are more reliable and
less susceptible to failures. Tested on +25k carts and dozen of drives.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: FYI LinkedIn passwords hacked

2012-06-08 Thread R.S.

W dniu 2012-06-08 22:02, Clark Morris pisze:

On 7 Jun 2012 14:28:43 -0700, in bit.listserv.ibm-main you wrote:

[...]

Yet some smug mainframe workers could learn something from this. Such as,
storing hashed but unsalted passwords is not such a good idea (and, yes, I have
seen that done on a mainframe).

Would you mind explaining further what unsalted passwords are?

BIG ASSUMPTION: Passwords are kept in the database as hashes.
Keeping passwords in that way is popular, but it is ONE of the methods.

So, a user provides new password, the password is hashed (i.e. using SHA
function) and the hash is stored. The result: you can compare hash from
databse with hash of password-provided-during-logon. You cannot retrieve
the password from database, because ther is no reverse function for SHA.
BINGO. "Good people" did create hashes of every word and even
combination of words and numbers. It's called rainbow tables.
So, when you have user database stolen, you don't need to guess the
password using brute force method. You can use rainbow tables. Time to
crack the password is reduced significantly.
What to do? You can add some random (!) bytes (this is the salt) to the
password and then compute the hash. And of course store the salt in
opentext form. It causes the hacker cannot use rainbow tables (passwords
are SALTED), so time to crack the password is elongated significantly.

BTW: RACF does NOT use the method above. Passwords are encrypted using
DES algorithm, more detail: userid (which is not secret) is encrypted
and the key is the password (after some "normalization"). Effect: there
is not known reverse function, so brute force is the only method for
password cracking. Unfortunately it is worse than using password+random
bytes, because allowed character set for passwords is quite narrow.

Regarding linkedin: it is still unrelated to mainframes. It is related
to any user+password system. And OBVIOUSLY you shouldn't use the same
password for top-secret system and some free of charge (and FREE OF
RESPONSIBILITY) Internet community portal. And this should be obvious
for ANY folk working in IT, and should be know to anynone using
Internet. I heard that many people use Internet and some of them are not
mainframers, more - some of them are not IT folks.

That's why I sustain it's off topic.

--
Radoslaw Skorupka
Lodz, Poland

P.S. This is not the only off-topic post here, so I'm not going to fight
for "on-topic transparency". From the other hand didn't change my mind
about it.

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

Re: How many cost a cpu second?

2012-06-08 Thread R.S.

W dniu 2012-06-08 13:32, Salva Carrasco pisze:

Well, I know the simple way is:

TCO/nCPU/365/24/3600

But, i do not have the TCO. So, i would like to get an average. I know that
there is a lot of factor in the play:

- LPAR vs single image
- MSU, MIPs, etc..
- Software licences
- ELAs
- Hardware amortization
- etc...

So, anybody can make a Fermi estimate to say me how much does a cpu second cost
?

This is political question, so you can use any formula you want (your
managers do), put any values you imagine and get any results.

IMHO most mainframes are scaled to provide enough performance during
peak hours, not to provide enough average (during day, week) power.

Of course this is relevant for # of MIPS only.

My €0.02
--
Radoslaw Skorupka
Lodz, Poland

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

Re: FYI LinkedIn passwords hacked

2012-06-07 Thread R.S.


Having password or not is not matter of topic of IBM-MAIN.
There are really a lot of things which do have passwords and are 
absolutely unrelated to mainframes.
We are here to discuss mainframe issues, not password problems on 
popular portal(s).


However in case of security breach on IBM.com systems I would be happy 
to know it, because it's related to my job and to mainframe activities 
at all (i.e. software orders, SCRT report submission, CoD, etc.).


--
Radoslaw Skorupka
Lodz, Poland


W dniu 2012-06-07 16:23, Hal Merritt pisze:

Hammers, football games, and panties don't usualy have passwords. LinkedIn 
isn't as pervasive as Yahoo, but does serve a higher value clientel, at least 
in the US.

Major portals such as Yahoo, Google+, Hotmail, etc all do and I would say that 
getting the word out about a major breech is a service to the community and a 
slap to the bad guys.

Think about it: let's say you cop a million passwords, but before you can 
exploit them, most all are changed. So, what was the point? A lot of hard word 
for just a few presumably inactive passwords.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Thursday, June 07, 2012 6:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FYI LinKEdln passwords hacked

W dniu 2012-06-06 23:31, Ed Gould pisze:

LinkedIn Users: Change Password Now
Attackers appear to have obtained--and may have already decrypted--at
least 6.5 million LinkedIn passwords.


How is it related to IBM mainframes?
Hint: Maybe some mainframers do use this portal, but mainframers also use VISA 
cards, hammers, watch football, wear panties (or not), etc.










--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: FYI LinKEdln passwords hacked

2012-06-07 Thread R.S.

W dniu 2012-06-06 23:31, Ed Gould pisze:

LinkedIn Users: Change Password Now
Attackers appear to have obtained--and may have already decrypted--at
least 6.5 million LinkedIn passwords.

How is it related to IBM mainframes?
Hint: Maybe some mainframers do use this portal, but mainframers also
use VISA cards, hammers, watch football, wear panties (or not), etc.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: What is a PC Call?

2012-06-01 Thread R.S.

W dniu 2012-06-01 00:43, Mike Schwab pisze:

Just because they added something to the hardware, does not mean they
are ready to add it to the operating system.

When z/VM 6 came out, it required a z10 to run on, because they
changed the software to use hardware introduced with that processort.
Which means they need to support z/VM 5 on older processors until they
upgrade or exceed the reasonable hardware lifetime.

When z/OS 2.1 comes out, it will drop support for z/900 and z/990
processors so they can use hardware feature only available on newer
hardware. You can still run z/OS 1.13 on older processor but not take
advantage of the newer hardware.

(my €0.02)
It is also possible to use new hardware features OPTIONALLY.
So, if HW >= z10 then exploit_new_features else use_legacy_code.

Good example of such approach was z/OS 1.1 - 1.5
It could run on 64-bit machine as well as on 31-bit machines.
IMHO the difference between 9672 G5 and z/900 was significantly bigger
than difference between z/990 and z9 (z/OS V2) or z9 and z10 (z/VM V6).

--
Radoslaw Skorupka
Lodz, Poland

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

Re: JES2 default OUTCLASS

2012-05-30 Thread R.S.

W dniu 2012-05-30 16:21, Mark Zelden pisze:
[...]

Note what I wrote about "the source" earlier.

I had to re-read it. I'm sorry for my abstractedness.

For record purposes:
(simple version)
Default MSGCLASS for jobs is taken from JOBCLASS(TSU) definition
(MSGCLASS parameter).

(longer version)
For job submitted by TSO user a TSO segment (UADS) is taken, more
precisely MSGCLASS subparameter. In case of lack of this parameter
JOBCLASS(TSU) definition is taken.

(special cases)
I changed dynamically TSU definition, MSGCLASS(K) -> X
After that (and "fresh" logon) the output disappears (user with
NOMSGLCASS in TSO segment).
For the user which did not re-logon (logged on before TSU change),
output is still available and it's in old (K) outclass.

For the user with TSO(MSGCLASS(X)) the class (X) is assigned.

Mark, thank you for your help and for your patience!

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: SMP/E and UNIX (JAVA?) (solved)

2012-05-30 Thread R.S.

W dniu 2012-05-30 16:06, Paul Gilmartin pisze:

On Tue, 29 May 2012 22:50:05 +0200, R.S. wrote:

Solution: add SMPJHOME DD to SMPE job.
I'm curious why IBM did not add a DDDEF for that...

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimrfr42/4.20

4.20 SMPJHOME
...
No default location is assumed by SMP/E for SMPJHOME.
...
Notes:

1. SMPJHOME can be specified using a DD statement or a DDDEF entry.

Do you mean that sample UCLIN for the product should include a
customizable sample/default SMPJHOME DDDEF?

A reasonable UNIX distribution (in contrast to z/OS USS) would
provide a (customizable) symlink to the current Java libraries
in (e.g.) /usr/lpp/java/...

Well, I found 'jar' program in 9 different locations, including
WebSphere - the product I applied the PTF to. I compared size of the
files - it looks I have 9 identical jar's.

Why ServerPac is not customized to use any of them?

Why there is not HOLD ACTION in the PTF to take care about SMPJHOME?

Why APPLY CHECK does not check presence/lack of ot?

Why SMP/E does not use PATH variable?

--
Radoslaw Skorupka
Lodz, Poland

P.S. Something tell me that I will have to solve the same problem few
years later. And obviously I'll forget the solution. And IBM won't fix it.

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

Re: IBM software module names

2012-05-30 Thread R.S.

W dniu 2012-05-30 13:44, Jim McAlpine pisze:

Is there a list of the 3 letter software prefixes anywhere eg ICE for
DFSORT.

Yes.

The list is (partially) listed in MVS System Messages, SA22-7634,
chapter 1.3 Message Directory:

CBR │ Object access method (OAM)│ z/OS MVS System Messages,│
│ │ │ Vol 4 (CBD-DMO), SA22-7634 │
├─┼───┼──┤
│ CEA │ Common Event Adapter │ z/OS MVS System Messages,│
│ │ │ Vol 4 (CBD-DMO), SA22-7634 │
├─┼───┼──┤
│ CEE │ Language Environmentę │ z/OS Language Environment│
│ │ │ Debugging Guide, GA22-7560 │
├─┼───┼──┤
│ CHS │ MVSSERV messages for the user │ z/OS TSO/E Messages, │
│ │ and system programmer │ SA22-7786│
├─┼───┼──┤
│ CIM │ Managed System Infrastructure │ z/OS MVS System Messages,│
│ │ for Setup (msys for Setup)│ Vol 4 (CBD-DMO), SA22-7634

--
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.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.

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

Re: JES2 default OUTCLASS

2012-05-29 Thread R.S.

W dniu 2012-05-29 17:47, Mark Zelden pisze:

On Tue, 29 May 2012 16:27:00 +0200, R.S. wrote:

For STC and TSU there is explicit parameter for OUTCLASS.
For JOBs there's no such parameter.

Q: what output class is chosen as default for jobs? Where is it coded?

There is no OUTCLASS parm for JOBCLASS(STC) nor JOBCLASS(TSU) either.
There is MSGCLASS for STC/TSU, which defaults to "A".

There is no default MSGCLASS for batch job classes. If you submit a job
without MSGCLASS, it depends on the source of the submission. From TSO/ISPF, it
would be the JOBCLASS(TSU) MSGCLASS. If for example you used IEBGENER
to submit to the INTRDR via SYSOUT=(n,INTRDR), the default MSGCLASS
would be "n".

Yes, the parameter for JOBCLASS(STC or TSU) is MSGCLASS.
Regarding to defaults - the following scenario:
A job submitted fromISPF via SUB command.
No MSGCLASS in the job. All DD SYSOUT=*. Also no CLASS parameter.

In that case default CLASS is used - and I found the default in JES2PARM.
Also some default OUTCLASS (MSGCLASS? sorry for eventual misnaming) is
used for JES* datasets and SYSOUT's. In my case this is K, but I cannot
find any entry in the JES2PARM saying "use K outclass".

And my curiosity eats me... ;-)

Supplemental information: the system uses almost 'vanilla' JES2PARM
delivered with ServerPac. Default CLASS is A:

INTRDR ... CLASS=A,
Default OUTCLASS is K - why?

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: JES2 default OUTCLASS

2012-05-29 Thread R.S.

(re-send)
W dniu 2012-05-29 17:47, Mark Zelden pisze:

On Tue, 29 May 2012 16:27:00 +0200, R.S. wrote:

For STC and TSU there is explicit parameter for OUTCLASS.
For JOBs there's no such parameter.

Q: what output class is chosen as default for jobs? Where is it coded?

There is no OUTCLASS parm for JOBCLASS(STC) nor JOBCLASS(TSU) either.
There is MSGCLASS for STC/TSU, which defaults to "A".

Supplemental information: the system uses almost 'vanilla' JES2PARM
delivered with ServerPac. Default CLASS is A:
INTRDR ... CLASS=A,
Default OUTCLASS is K - why?

Regards
--
Radoslaw Skorupka
Lodz, Poland

P.S. I re-send this message since it didn't reached listserver. I'm
sorry for duplicate if such occur.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: SMP/E and UNIX (JAVA?) (solved)

2012-05-29 Thread R.S.

W dniu 2012-05-29 22:39, R.S. pisze:

The following scenario: single PTF APPLY.
APPLY CHECK ends with RC=0

APPLY end with RC=8
reason: jar command not found. (see details below)
I edited /etc/profile, so PATH variable do containg entry for jar.
I tested it using shell (jar -? command) and BPXBATCH PARM='SH jar-?'

However SMPE APPLY does not see the PATH.

Q: is there any customization required/available to tell SMPE where to
find jar program?

BPXBATCH output from the SMPE job quotation:
jar: /usr/lpp/IHSA... 73: FSUM7351 not found

Solution: add SMPJHOME DD to SMPE job.
I'm curious why IBM did not add a DDDEF for that...

--
Radoslaw Skorupka
Lodz, Poland

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

SMP/E and UNIX (JAVA?)

2012-05-29 Thread R.S.

The following scenario: single PTF APPLY.
APPLY CHECK ends with RC=0

However SMPE APPLY does not see the PATH.

Q: is there any customization required/available to tell SMPE where to
find jar program?

BPXBATCH output from the SMPE job quotation:
jar: /usr/lpp/IHSA... 73: FSUM7351 not found

--
Radoslaw Skorupka
Lodz, Poland

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

JES2 default OUTCLASS

2012-05-29 Thread R.S.

For STC and TSU there is explicit parameter for OUTCLASS.
For JOBs there's no such parameter.

Q: what output class is chosen as default for jobs? Where is it coded?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Spool offload

2012-05-28 Thread R.S.

W dniu 2012-05-28 18:03, Skip Robinson pisze:

OK, I'll bite. Which parameters cannot be changed dynamically? I think you
mentioned in another thread about having to resolve name conflicts. There
ways to juggle things around via multiple incremental changes to achieve
the desired result. I have systems last cold started in 1995.

What IBM writes in JES2PARM:
/*
/*
/* NOTE: Changing ANY of the following parameters will prevent a
/*JES2 Warmstart; they can ONLY be changed on a COLDSTART
/*
/*
/*
/* CKPTDEF DSNAME=
/* JOBDEFJOBNUM=
/* NJEDEFOWNNODE=
/* OUTDEFJOENUM=
/* SPOOLDEF BUFSIZE=, DSNAME=, RECINCR=, SPOOLNUM=, TGNUM=,
/*TRKCELL=, VOLUME=
/* TPDEF RMTNUM=
/*

I know I can change the parameters (some of them , at least)
dynamically, by a command.

In my case I changed JOBNUM, JOENUM (and some others).

Changing it dynamically causes some discrepancy between JES2PARM and
reality, and can be confusing across IPLs.
In my case there was no problem with IPL, and even spool content was in
"nice to have" category, so the cold start wasn't big issue.

Disclaimer: I'm not JES2 specialist, so I'd be happy to hear that I
could do it in other, smarter way.

Regards
--
Radoslaw Skorupka
Lodz, Poland

P.S. Thank you Mark and Skip for your help! I appreciate it.

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

Re: Spool offload

2012-05-28 Thread R.S.

W dniu 2012-05-28 17:10, Mark Zelden pisze:
[...]

I assume you are asking if they are correct prior to starting the offload. If
so,
it looks okay. If not, then of course you need to start offload1.

Good assumption!
My explanations weren't good enough. :-)

Are you sure you disk output is big enough to hold everything? If you have
tape output available, you can use that and avoid a potential space
abend.

Yes, I'm sure, the spool is small, it's not production system.

Just out of curiosity, why do you need to cold start?

Change some parameters in JES2PARM.

--
Radoslaw Skorupka
Lodz, Poland

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

Spool offload

2012-05-28 Thread R.S.

I'm going to cold start JES2. I would like to preserve my spool content 
by using spool offload.


I changed parameters of OFF* devices to the following values:

OFFLOAD1  DSN=SYS1.OFFLOAD,STATUS=DRAINED,ARCHIVE=ONE,
  CRTIME=RESET,LABEL=SL,PROTECT=NO,RETPD=0,
  TRACE=NO,UNIT=(3390,1),VALIDATE=YES,VOLS=255
Changes: RETPD=0 and unit=3390, dataset preallocated


OFF1.JT  STATUS=STARTABLE,CLASS=,CREATOR=,DISP=KEEP,
 HOLD=,JOBNAME=,LIMIT=(0,*),NOTIFY=NO,
 RANGE=(J1,99),ROUTECDE=(),START=YES,
 SCHENV=,SRVCLASS=,SYSAFF=(NONE),VOLUME=(,,,),
 WS=(/)
OFF1.ST  STATUS=STARTABLE,CREATOR=,DISP=KEEP,
 OUTDISP=(WRITE,KEEP),HOLD=,JOBNAME=,NOTIFY=NO,
 RANGE=(J1,99),ROUTECDE=(),START=YES,
 VOLUME=(,,,),WS=(/),BURST=,FCB=,FLASH=,
 FORMS=(,,,),LIMIT=(0,*),PLIM=(0,*),
 PRMODE(),QUEUE=,UCS=,WRITER=
Changes: WS changed to "everything", DISP=KEEP (does not delete or 
change existing entries).



Q: did I miss something?

--
Radoslaw Skorupka
Lodz, Poland






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

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee 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
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.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.


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

How to leave ISPF

2012-05-25 Thread R.S.

When one leaves ISPF usually there is a panel "Specify Disposition of
Log Data Set". Usually the answer is 2 - delete.

Q: how is it possible to exit ISPF by choosing some option (X - Exit)
and NOT see the panel? I saw it many moons ago.

BTW: I don't ask how to logoff TSO immediately after leaving ISPF. This
is another issue.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: 24/7/365 appropriateness was Re: IBMLink outages in 2012

2012-05-23 Thread R.S.

IMHO everyone here perfectly understand common (and intended) meaning of 
24/7/365. While is formally inaccurate, it's still clear.


The rest is as worth to discuss as USS=Unix System Services.

Maybe there is "official IBM meaning* of 24/7/365 or "the only proper 
description of continuous availability" ? 


My €0.02
--
Radoslaw Skorupka
Lodz, Poland





W dniu 2012-05-23 16:20, Bill Fairchild pisze:

And the general public, many Dilbertian managers, and even some of us 
professional nitpickers, think that a job running 1 hour instead of 10 is 900% 
faster, and that 1 is 10 times smaller than 10.  2+2 no longer = 5; now it 
equals chartreuse.

Fortunately architects and engineers know how to use mathematically accurate 
and precise terminology when describing the bridges they design and build, or 
we would have a lot more cars falling off of collapsing bridges.

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@bama.ua.edu] On Behalf Of 
Clark Morris
Sent: Wednesday, May 23, 2012 6:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: 24/7/365 appropriateness was Re: IBMLink outages in 2012

On 22 May 2012 20:04:42 -0700, in bit.listserv.ibm-main you wrote:


In, on 05/21/2012
   at 03:51 PM, Clark Morris  said:


I'm the last to see my own errors.  Hopefully it was obvious I meant
24/7/365


That's no better. Either 24/7/52 or 24/365 would be approximately
correct.



On a logical basis I agree with you but has the 24/7/365 shortcut for 
continuous availability become so pervasive that it is the shorthand way for 
saying it and is it the way that the general public as opposed to us 
professional nitpickers best understands it?

Clark Morris

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

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




--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: IBM's first tape drive turns 60 (makes you feel old!)

2012-05-22 Thread R.S.

BTW: I heard about 1-inch tapes. Is it true? Did such wide tapes exist?
Current cartridges are 1/2 inch wide. The article says that 729 was also
1/2 inch.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-05-22 12:55, Don Higgins pisze:

All

It reminds me of when I saw my first tape sort running on what I think were IBM
729 drives at Florida Power around 1970. I knew I had to learn how that
worked. And now there is an open source sort merge utility included with z390.
It is written in structured mainframe macro assembler and runs on Windows,
Linux, and Apple OSX using J2SE 6.0+ host. But it is just no fun to watch
anymore as it uses hard drive work areas!

Don Higgins
d...@higgins.net
www.z390.org

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

Re: OWNER() in DEF CLUSTER

2012-05-21 Thread R.S.

W dniu 2012-05-21 22:41, Mark Zelden pisze:

On Mon, 21 May 2012 22:29:47 +0200, R.S. wrote:

I just found a job with DEFINE CLUSTER ...OWNER(...) parameter.

Just curious:
What is the meaning of the owner field in VSAM ?

To identify the owner. :-)Didn't you RTFM?

Seriously, it is an optional "comment" field.

This is what I knew, but after I saw some job with DEF...OWNER and some
comments describing when to change the field I felt I've been missing
something.
It's fine to get confirmation that everything is in order, Copernicus
was right and OWNER is not relevant. ;-)

Thank you Mark!

--
Radoslaw Skorupka
Lodz, Poland

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

OWNER() in DEF CLUSTER

2012-05-21 Thread R.S.

I just found a job with DEFINE CLUSTER ...OWNER(...) parameter.

Just curious:
What is the meaning of the owner field in VSAM ?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: PSP Bucket for 2107DEVICE (DS8300)

2012-05-21 Thread R.S.

W dniu 2012-05-21 11:21, Moussadak Mostafa pisze:

hello to all,

We plan to migrate from ESS800 disk-bay to a new DS8300. we are currently in a
zOS1.7 on z10BC.

I took a test in HCD, the Device Type 2107 is here !

Your HCD is aware of this device type. In fact 2107 is quite old, older
than *your* DS8xxx model.

Are we obliged to apply the PSP Bucket to have support of the DEVICE 2107
(DS8300) or is it already included under zOS?

There is o obligation at all - you decide about your system and you are
responsible for the results.
I would use the bucket. In "perfect" case all the PTFs required you
already have. In more realistic, but still optimistic case your won't
crash when you omit all missing PTFs. In other realistic case you can
expect troubles without the PTFs.

Conclusion: review PSP bucket and apply missing PTFs (maybe not all of
them).

--
Radoslaw Skorupka
Lodz, Poland

Thank you very much for your answers.

Regards/Cordialement.

**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.gbp.ma
**

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

Re: Early IPL problems

2012-05-19 Thread R.S.

I prefer to have system solution, which would allow me to view/manage 
TEXT FILE. It's far more convenient than using video camera.

And in fact I miss the facility.
BTW: I haven't investigated it: I have some 3270 emulator which allow to 
view few previous screens - sometimes usable for ISPF activities.

However this facility does not work for NIP text stream.
--
Radoslaw Skorupka
Lodz, Poland





W dniu 2012-05-18 21:11, McKown, John pisze:

I use the HMC and the "Operating System Messages" ICON. I don't have any 
NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going.

If you do have a 3270 type console, why not record the console on your cell 
phone camera? It is a bit small. So, get a tablet. Might take two people. One 
to do the IPL, the other to keep the console in focus.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe
Sent: Friday, May 18, 2012 1:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Early IPL problems

On 5/18/2012 11:22 AM, Mark Zelden wrote:

No, the complaint is that on emulated consoles attached via

Tn3270 (2074,

OSA-ICC and I assume Visira which I've never worked with)

any messages

that come out on the console along with the wait disappear

immediately

due to the RESET that happens along with the wait.


Sounds like z/OS sysprogs need to ask their employers to pay
for Evelyn Wood
speed-reading classes. ;-)

Seriously, I remember OS/2 had a similar issue. Before you
could write down the
information about a catastrophic trap, it would restart and
blow away the
screen. There was a special CONFIG.SYS parameter you had to
code to prevent it
from automatically restarting itself. Oh what fun...

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

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




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




--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bam

Change SYSPLEX name

2012-05-18 Thread R.S.

I forgot to customize sysplex name during ServerPac installation.
Now I want to fix it.
I found it's coded in couple datasets only (and LOADxx).

Q1. Is there any other place where I should change the sysplex name?

Q2. How to do it? The only idea I know is to delete and re-create all
the CDS datasets *and* to re-create CDS content.

Any clue?
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Preventive z/OS maintenance, was: EPSPT vs. FIXCAT

2012-05-17 Thread R.S.

Jürgen

In my humble opinion every piece of software installed should serviced,
so I sustain the idea of aplying all PTFs.

Disclaimers (exceptions):
- One can have some software installed, but not used.
- I'm not talking about PTFs in error, etc.
- "Up to date" does not necessarily mean "from yesterday", service can
be "seasoned" (cured? matured?).

Regards
--
Radoslaw Skorupka
Lodz, Poland

P.S. I'd like to hear more about this, you have my e-mail address.

W dniu 2012-05-17 17:38, Jürgen Kehr pisze:

Hi Radoslaw,

in your note you mentioned the idea to apply all (installable) PTFs.
This idea leads me to the reason for opening this topic. I'm involved in
an IBM project for preventive maintenance packages named CPMz. One major
idea behind this project is "to apply as few PTFs as possible, but as
many PTFs as needed". In order to determine which PTFs are really needed
in a specific environment, besides other subjects we include FIXCAT
data. At that point one of our customers asked me where to find the CICS
FIXCAT data. Because there is no specific category, I thought that there
are no such FIXCATs for CICS, but now I know from the answers here where
to find them.

BTW: For this offering CPMz we although have a customer in Poland, if
you like to hear more about this topic, you may give me a personal note.

Am 17.05.2012 14:59, schrieb R.S.:

W dniu 2012-05-17 14:29, Kurt Quackenbush pisze:
[...]

Stupid question:
Applying service usually require IPL, which is some inconvenience even
in Sysplex environment (for sure it is in monoplex).
PTF usually require to review some actions, dependencies, etc. -
everything with HOLDSYS().
With some exceptions applying service is not single little PTF, it;s
not daily activity. It's rather some session - mass update, infrequent.

So, it's reaaly good opportunity to apply all the PTFs, especially
those from RSU.

So the question is: Why doesn't one receive "full pack" of service?
ShopzSeries allows to use SMPE reports to order only missing PTFs and
only to the products installed.

Isn't it good idea to have all the components up to date?
--
Radoslaw Skorupka
Lodz, Poland

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

Re: EPSPT vs. FIXCAT

2012-05-17 Thread R.S.

W dniu 2012-05-17 14:29, Kurt Quackenbush pisze:

thanks, that is the information I wasn't aware of, the fact that for
CICS there isn't a special category like for IMS or DB2 and that these
PTFs are all together in this generic category.So all PTFs from the
former PSP extract files are now in any category either in a specific or
in such a generic category?

I don't know the exact algorithms used to build the former PSP extract
files, so I cannot guarantee ALL of those PTFs are represented by FIXCAT
HOLDDATA. However, I do know that any PTF that appears in the Service
Recommendation section of *any* PSP bucket (z/OS, DB2, IMS, CICS, etc.)
will be represented in HOLDDATA with the fix category
IBM.ProductInstall-RequiredService.

[...]

Stupid question:
Applying service usually require IPL, which is some inconvenience even
in Sysplex environment (for sure it is in monoplex).
PTF usually require to review some actions, dependencies, etc. -
everything with HOLDSYS().
With some exceptions applying service is not single little PTF, it;s not
daily activity. It's rather some session - mass update, infrequent.

So, it's reaaly good opportunity to apply all the PTFs, especially those
from RSU.

So the question is: Why doesn't one receive "full pack" of service?
ShopzSeries allows to use SMPE reports to order only missing PTFs and
only to the products installed.

Isn't it good idea to have all the components up to date?
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing (now: SCRT)

2012-05-16 Thread R.S.

W dniu 2012-05-16 13:42, Elardus Engelbrecht pisze:

[1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking
something ...

But you can split the job stream. I moved DD * content to separate
members and DO NOT change them. Also the JCL itself is (almost) not
changed. The only change is to replace object code.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing (now: SCRT)

2012-05-16 Thread R.S.

W dniu 2012-05-16 12:42, Elardus Engelbrecht pisze:
[...]

I changed sysid to meet SCRT requirements, otherwise SCRT cannot
prepare correct report for the LPAR running this system.

Yuck! Could you be kind to elaborate on this required change? I'm
also using this SCRT toy every month.

SCRT does require all systems to have uniques SYSID. This requirement is
described in SCRT manual.

SCRT is REALLY BAD product, I know several cases where it gives false
results even if you fulfill all the requirement.

SCRT does like: unique SYSIDs, *stable* SYSIDS (not changed during the
reporting period).
SCRT does not like: changing SYSIDs, SMF records out of the scope (i.e.
from previous month) - I mean "valid" records PLUS older ones.
SCRT hates: non-unique SYSIDs, or SMF70 with no SMF89 or vice versa - I
mean scenario: you IPL system for 15 minutes, then you shut it down.
It's unusual, but IMHO legal to start z/OS for short period of time.

BTW: the requirement of uniques SYSIDs is simply STUPID. There is
identifier which is really unique: LPAR name. From the other hand there
are cases when you could need imple PiT copy, a CLONE of you z/OS
system. You can clone everything except the SYSID. Reason: SCRT.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing (solution???)

2012-05-16 Thread R.S.

http://www-01.ibm.com/support/docview.wss?uid=isg1OA39170

It's quite fresh.

BTW: very interesting problem for lawyers:
I changed sysid to meet SCRT requirements, otherwise SCRT cannot prepare
correct report for the LPAR running this system.

I can say I cannot change sysid due to error in IBM code.
Catch 22?

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-05-16 11:14, R.S. pisze:

W dniu 2012-05-15 20:33, Mark Zelden pisze:

What's wrong???

User error? :-) Did you change the SYSID or anything like that?
When you use the LOG command do you see an ISPF short message
error?

Try "SYSID ?" and see what it says.
Then SYSID with no operands.

1. SYSID

SYSID *was changed* recently.

The command SYSID ? shows:

JES SYSIDS=(NEW1),OLD1

and in the command line there appears text SYSID NEW1

Remarks:
Expected output from SYSID ? is JES SYSIDS=(NEW1) (tested on other systems)
I issued SYSID NEW1 - no effect
I issued SYSID OLD1 - and could not enter LOG (no msg)
I issued SYSID WRNG - and could not enter LOG (no msg)
MAS panel shows:
OLD1 DRAINED,P
NEW1 ACTIVE
(system is not sysplexed, PLEXCFG=MONOPLEX)

2. SYSLOG - OPERLOG
My "log default" is SYSLOG, previously I had "OPERLOG only if Operlog is
active on your system".
I enter syslog by typing LOG or LOG S.
WHen I type LOG O I get the following message:
ISF036I NO RECORDS TO DISPLAY

3. LOG content
Real syslog content is accessible under ST, entry SYSLOG +MASTER+
LOG panel always show last few messages from last "live" - it contains
information since previous IPL to SHUTDOWN. No current information.

--
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.2012 r. kapita zakadowy BRE
Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

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

Re: z114/z196 LPAR Activation List

2012-05-16 Thread R.S.

W dniu 2012-05-16 02:19, Kent Ramsay pisze:

Hi,

A customer recently installed a z114. When a Power-on Reset is done,
the LPAR's specified in the Partition Activation List are not
activated. This facility was working on the replaced z9. Has anyone
seen a similar occurrence? Thanks.

I had similar problems when:
a) no memory was available for the LPARS. In the activation profiles
there were more memory assigned than available.

b) LPAR id duplicate (I'm not sure about it).
c) Crypto Usage Domain duplicate.

In every case I conclued problem nature from the messages.
What messages do you see?
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing

2012-05-16 Thread R.S.

W dniu 2012-05-15 20:33, Mark Zelden pisze:

What's wrong???

User error? :-)Did you change the SYSID or anything like that?
When you use the LOG command do you see an ISPF short message
error?

Try "SYSID ?" and see what it says.
Then SYSID with no operands.

1. SYSID

SYSID *was changed* recently.

The command SYSID ? shows:

JES SYSIDS=(NEW1),OLD1

and in the command line there appears text SYSID NEW1

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing

2012-05-15 Thread R.S.


W dniu 2012-05-15 19:25, Mark Zelden pisze:

On Tue, 15 May 2012 19:02:57 +0200, R.S.  wrote:



Don't know why it broke, but have you tried this?

V SYSLOG,HARDCPY



Yes, no effect



Try   W START   (WRITELOG START)


I tried, no effect.

I just re-ipled system, with no effect, but found something interesting:
SD.LOG is dead. It shows $PJES2 and other things related to last system 
shutdown. No current IEA101A.


However I typed SD.ST and selected the following entry:
SYSLOG   STC00187 +MASTER+

and found current *living* log there!!!
By 'living' I mean when I issue some command the output is displayed in 
the log.


What's wrong???




Supplemental informations:

Output from D C,HC
 CONSOLES MATCHING COMMAND: D C,HC
 MSG:CURR=0LIM=2500 RPLY:CURR=0LIM=20SYS=CPAC PFK=00
 HARDCOPY  LOG=(SYSLOG)  CMDLEVEL=CMDS
   ROUT=(ALL)
 LOG BUFFERS IN USE: 0   LOG BUFFER LIMIT: 2000


My CONSOLxx (fragment):
INIT MLIM(2500)
 LOGLIM(2000)
 RLIM(20)
 UEXIT(N)
 MPF(NO)
 MMS(NO)
 PFK(00)
 CNGRP(NO)
 CMDDELIM(;)
 /*commented  APPLID, GENERIC */
HARDCOPY DEVNUM(SYSLOG)
 ROUTCODE(ALL)
 CMDLEVEL(CMDS)
 HCFORMAT(CENTURY)
DEFAULT
 LOGON(OPTIONAL)
 HOLDMODE(NO)
 RMAX(999)
/*  */
CONSOLE DEVNUM(0400) UNIT(3270-X) NAME(CNLODZ)
AUTH(MASTER)   USE(FC)
ROUTCODE(ALL)  LEVEL(ALL)   CON(N)
SEG(01)DEL(RD)  RNUM(10)
RTME(1/2)  MFORM(J,T)   AREA(NONE)
PFKTAB(TABL01) RBUF(15) LOGON(REQUIRED)
MONITOR(JOBNAMES-T)

--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: z/os v1r13 RACF problem

2012-05-15 Thread R.S.

W dniu 2012-05-15 19:03, Crabtree, Anne D pisze:

Security Server is enabled in IFAPRD00.

What is DSNT? I don't recognize that. The onepac system is stand alone not a
sysplex. The datasets are cataloged fine and both 1.11 and 1.13 reference that
catalog. They are not in MSTJCLxx member in my 1.11 system and it works fine.
There's just something I've missed and it's driving me crazy!

ICHRDSNT contains RACF db names.
However, AFAIK if you have wrong dsnames, you will be asked for RACF db
name.

I would suggest to ask the question on RACF-L group.
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Syslog missing

2012-05-15 Thread R.S.

W dniu 2012-05-15 18:47, Mark Zelden pisze:

On Tue, 15 May 2012 18:39:08 +0200, R.S. wrote:

The following scenario:
z/OS 1.13 during ServerPac installation process.
The system is IPLed for second or third time, almost nothing is customized.
I just noticed that syslog is dead.
Example: I enter SDSF, LOG and issue /D A,L - the results are not
recorded in the log (last entry in the log is few days old).
The output can be seen in ULOG.

When the command is issued on MCS console, it's also unavailable in the
syslog

Don't know why it broke, but have you tried this?

V SYSLOG,HARDCPY

Yes, no effect

Could your CONSOLxx member have a syntax problem? Does it
contain HARDCOPY DEVNUM(SYSLOG)? If you have
OPERLOG enabled, does that work?

Well, I believe the member is OK, but I don't know how to check whether
correct member was used during IPL or there were no error messeges
during the member processing. I culd check in in ...the syslog.

However my MCS console comes definitely from correct member.
BTW: from the member:
HARDCOPY DEVNUM(SYSLOG)
ROUTCODE(ALL)
CMDLEVEL(CMDS)
HCFORMAT(CENTURY)

R.S.

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

Syslog missing

2012-05-15 Thread R.S.

The output can be seen in ULOG.

When the command is issued on MCS console, it's also unavailable in the
syslog

Any clue?

BTW:
Few customizations I'm aware of: sysname is still CPAC, but SMF id is
changed, TCPIP is customized to conform our network addressing, IEFACTRT
installed.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: z/os v1r13 RACF problem

2012-05-15 Thread R.S.

W dniu 2012-05-15 18:14, Crabtree, Anne D pisze:

Trying to bring up z/os v1r13 for first time on my onepac system and I keep
getting error message ICH571A Error building program control tables followed by
ICH501I saying RACF is not active. I performed a system upgrade when
installing and my 1.11 onepac system comes up fine with these RACF datasets. I
have to have missed something !!
That being said, I have checked the following:

My IEFSSNxx member has:
SUBSYS SUBNAME(RACF)
INITRTN(IRRSSI00)
INITPARM(';,X')

The RACF proc is in CPAC.PROCLIB and looks ok.
IRRSSI00 module is in SYS1.LINKLIB.
I get messages that the installation router table and the class descriptor
table were processed.
I'm also getting this error (but I think it's just because RACF didn't start
and is not the problem):

ICH584i ICHEINTY next error against profile irrplex_in class gxfacili on the database with
master dataset "my dataset name" on "my volume" rc=001C reas=

Any suggestions?

Small one:
RACF address space and RACF subsystem is NOT RACF ITSELF.
This is some "add-on" to the RACF. You can have RACF working without the
subsystem and started task.

Wild guess: Is RACF enabled in IFAPRDxx?
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Is having an OMVS segment on a userid with RACF SPECIAL an issue?

2012-05-14 Thread R.S.

IMHO the are two secure choices:

1. NOOMVS for SPECIAL

2. UID(0) for SPECIAL. Yes, 0. The trick is UID(0) is shared, so there
is one to many relationship. So, hijacking UID(0) does NOT mean
hijacking SPECIAL user. There is a parameter in BPXPRMxx called
SUPERUSER(username). This is the user which would be hijacked for
UID(0)! Obviously you should care not to give this user any
extraordinary attributes. BTW: default username is BPXROOT.

Last, but not least: take care to prevent hijacking. IMHO it's feasible
to configure system in that manner.

My €0.02
--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-05-14 21:22, Bruce Wheatley pisze:

I seem to recall that in the past adding an OMVS segment to a userid with RACF SPECIAL was
considered a "no-no." Something to do with the posiibility of the userid being
"hijacked" thereby allowing access to its SPECIAL attribute.

Is this still a concern (was it ever?) and if so are there ways to prevent such
"hijacking"?

TIA

(Posted on both RACF& IBM-Main lists)

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

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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

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

Re: Codepages and locales

2012-05-14 Thread R.S.

W dniu 2012-05-14 17:35, Phil Smith pisze:

The C manual on etoa() says, "The conversion is performed using the codeset page
associated with the current locale."

So what does that mean in the real world, if 037 is the "real" codepage (and what's a "codeset
page", if not a codepage?!) used by z/OS itself? Can changing the "locale" change the code(set
)page?

I've done some searching on this, but not found the right book - I keep finding
product books that talk about how to set it *for that product*, which of course
isn't what I'm looking for.

Wild guess: you can set current locale in the program.

BTW: how to start using polish characters in "pure z/OS" (TSO, ISPF,
JCL): do ...nothing on the host side, just configure your 3270 emulator
to use CP870.

BTW1a: very few emulators do it correctly

BTW2: How to configure SDSF to display polish characters: use TRTAB
CODPAG(CP00870) in ISFPRMxx.

BTW3: How to configure DFS/SMB to use polish characters (with Windows
client). Use CP870 *and* CP1250 (polish codepage on Windows).
BTW3a: there are *several* polish codepages, I'm aware of more than 10,
3-4 of them are in wide usage (CP852, CP1250, ISO8859-2, Mazovia).

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Reducing Common Area below 16M line

2012-05-14 Thread R.S.

W dniu 2012-05-14 17:13, Paul Gilmartin pisze:

Oops! I was unfamiliar with the terminology. I'll restate:
How much storage do LPA and ELPA respectively occupy in a
typical-to-large shop?

Do you think it depends on shop size?
I would bet it depends on installed product portfolio and product
requirements.

BTW: I *love* to teach about LPA ;-)
LPA consist of fixed LPA, modified LPA and pageable LPA
LPA consist of LPA and ELPA
LPA consist of fixed LPA and fixed ELPA,...

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Codepages and locales

2012-05-12 Thread R.S.

W dniu 2012-05-10 23:52, Phil Smith pisze:

How many z/OS shops actually run with a different locale (codepage)?

I mean both globally for the entire system as well as within one or more
databases.

I'm assuming the second set is much larger than the first; it's the first I'm
really interested in.

z/OS itself does not use any codepage, including US one.
*SOME* z/OS components, subsystems and and applications use codepages
and for those we usually use non-US ones.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: ### of GDG Entries

2012-05-10 Thread R.S.

W dniu 2012-05-10 22:12, Donnelly, John pisze:

We have a business application that creates literally 100s of GDGs a day;
please don't ask.
Is there any way to create or pretend to create a GDG base greater than 255...

g
NO. THE LIMIT IS 255.
However...
a) you can live with rolled off generations. You will see all the
generations you created (up to ) and max. 255 of them can be
referenced as relative - that means HLQ.GDGNAME(-200) vs
HLQ.GDGNAME.G0200V00.

b) (I think nobody mentioned it!). You can use your batch scheduler
facilities. Mostsuch products do offer an alternative to old stinking
GDG. For example, in ControlM you can use HLQ.SOMENAME.D%%ODATE - which
could mean HLQ.SOMENAME.D120510.

HTH
--
Radoslaw Skorupka
Lodz, Poland

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

Re: It's feeding time in Jurassic Park . . .

2012-05-08 Thread R.S.

"Microsoft Windows" sounds very generic.
zBX can run only ONE version of Windows: 64-bit edition of 2008
Enterprise (or so). g
If your application require 32-bit edition, or other version - then you
...can still use blade, for example IBM HX5 outside of zBX.
You'd loose legendary Enssemble capabilities, you won't be able to
manage it from HMC (what management? Why would you need it???) and the
most secure piece of 10G Ethernet (you can set up your own in a similar
manner).

--
Radoslaw Skorupka
Lodz, Poland

P.S. I'm not zBX enemy. I'm not biased - I don't sell neither Dell
blades, nor zBX. I only say "the king is naked" (hope you know The
Emperor's New Clothes by Andersen).

W dniu 2012-05-09 06:54, Timothy Sipples pisze:

George Henke writes:

Also, we have CITRIX.
Can that be moved the the zBx?

Sure. It's the same IBM HX5 blade running the same Microsoft Windows
operating system.

Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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

Re: It's feeding time in Jurassic Park . . .

2012-05-07 Thread R.S.

W dniu 2012-05-07 23:19, George Henke pisze:

Radoslaw,

ty for your interesting and helpful comments.

But, I was hoping that the whole was more than just the sum of the parts,
what with the zBx hipervisor and the speed and security of hipersockets.

Our 100 or more mid-range servers are layered and seeded with a vast array
of internal firewalls, switches, routers, IDPs/IDSes, load balancers all of
which I was hoping could be potentially eliminated by zBx along with the
server standup time and the organic labor to support it.

The unwieldly complexity of this conglomeration makes just opening a new
OSA path very labor-intensive, fraught with unforeseen obstacles.

I dare to disagree.
Windows or Linux will have all the advantages and disadvantages on both
"regular" blade and zBX blade.
I think (no offence intended), that part of the advantages you mentioned
are fictitious.

1. LAN security. Assuming your server room is a safe place there is not
problem to establish secure LAN without zBX facilities. More: none of
the facilities is exclusive to zBX, all of them are available outside.
2. Firewalls, etc. Assuming some of your servers need to be in DMZ you
still need a firewall between those servers and your internal LAN. zBX
network will not replace it.
3. Complexity. No difference between "regular" blades and zBX. Yes, you
can have mess in distributed systems area, but you can have also mess in
zBX or even z/OS realm.

4. Labor. As above, no difference between regular blades and zBX.
5. Speed of hipersockets. zBX data network is regular 10G Ethernet. What
is the advantage over 10G Ethernet available outside zBX?
6. Power save. It wasn't mentioned here, but it can be found in sales
pitches. Another piece of bullsh*t, especially when compared with
regular blades.

Last, but not least: you have 100 or more severs? You are happy guy. So
simple environment... I'm serious...

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Confused on DFSORT SORTWK

2012-05-07 Thread R.S.

W dniu 2012-05-07 18:59, Skip Robinson pisze:

Bingo. We've had VIO=YES forever. We're revisiting our entire ICEMAC
usermod ASAP. Thanks!

I'd suggest to get rid of the usermod at all.
Nowadays DFSORT can be customized using PARMLIB members.
It's also an opportunity to rethink all the non-default settings. ;-)

HTH
--
Radoslaw Skorupka
Lodz, Poland

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

Re: It's feeding time in Jurassic Park . . .

2012-05-07 Thread R.S.

Several dozens aswered, so it's my turn ;-)

1. Yes.

2. No.
From application point of view think about zBX as regular blade cabinet
connected to the mainframe. You simply connect to mainframe a bunch of
Intel-based (and other) servers using Ethernet/IP.
My not so humbly opinion: zBX is regular bunch of blades plus management
network (for what?) + some management (for what?) plus a lot of sales
pitch and black magic.
Conclusion: "sysplex" capabilities of zBX are almost the same as regular
PC connected to the mainframe. Means: it depend on the application.

3. Solaris is kind of Unix. Linux is also kind of Unix, but with no
certification. You have to port your applications. Usually vendors do
offer their applications of various platforms, so maybe it's a matter of
quite simple reinstallation + backup/restore.
You could have similar problems to solve when moving from HP-UX to
Solaris, or from AIX to zLinux.

4. Yes, you have to recompile binary "machine" code. Java is another issue.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-05-04 20:01, George Henke pisze:

and the dinosaurs are very hungry.

I need to migrate 50 Solaris servers to zLinux under z/VM on a z114 and
about the same number of Windows servers to zBx.

Does anyone have experience with this, some ideas?

Need a migration path.

Some questions:

Can z114 be upgraded to include zBx or must I upgrade to a z196 for that?
Can zBx be SYSPLEXed between 2 CECs?
If not, how do I eliminate the SPF, how do I do failover for the blade
servers?
How do I convert Solaris to zLInux under z/VM? Solaris is not supported by
zBx.
Must I recompile the applications running under Solaris to run them under
zLinux?

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

Re: ServerPac RACF* jobs (rant)

2012-04-30 Thread R.S.

W dniu 2012-04-30 23:35, John Eells pisze:
[...]

If the jobs will not run against a new, empty RACF database (that is,
essentially used to create a brand new test system, on which security
definitions will be extended soon afterward), then in my opinion you
should open a PMR. If you just don't like the way they work and want
them to improve, you should open a requirement instead.

John,
Indeed, the job run against new empty RACF db would partially fail.
However it's NOT the most important problem. It should be improved
seriously.
No, I'm not going to submit neither PMR nor enhancement requirement. IBM
bureaucracy is really good inhibitor. Last, but not least: I DON'T
BELIEVE IN EFFICIENCY OF SUCH ACTION. BTDT.

I just wanted to share my opinion about ServerPac jobs, definitely
justified topic on this forum.

--
Radoslaw Skorupka
Lodz, Poland

P.S. Sometimes we submit PMRs and sometimes it works for very obvious
errors. At least two H/W (microcode) APARs fixed and one S/W come to my
mind.

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

ServerPac rant continued (this time not RACF)

2012-04-30 Thread R.S.

Another fining: CSFSETMK job using CSFEUTIL program.
The purpose of the job is to initialize ICSF CKDS using specified pass
phrase. The problem is it DOESN'T work on z/990 and newer machines.
No, there is no clue in the job about it. Just assumption you are
working on z/900 or z/800. ;-)

I'm curious whether the job will be part of z/OS v2 installation process
(no support for machines which would support the job).

--
Radoslaw Skorupka
Lodz, Poland

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.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.

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

Re: Early IPL problems

2012-04-29 Thread R.S.

It's not strictly related to the OP question, but it is very important 
issue when talking about IPL problems. We pay much attention to avoid 
duplicate&online volsers.


BTW: in our case duplicates come from clones performed using PiT copy, 
it's not matter of naming convention.


--
Radoslaw Skorupka
Lodz, Poland


W dniu 2012-04-29 03:15, Skip Robinson pisze:

As Radoslaw says, IPL failures in production are so rare and so varied
that categorizing them is a an exercise in thrashing. Except for one
cause: duplicate volume serial numbers. The fact that duplicates are the
result of user error does not lessen the blow. In the case of only a
handful of duplicates, the operator can reply a few times and move on. But
we've had cases of dozens or scores of duplicates. NIP provides no
mechanism for handling a flood of duplicates even though the cause may be
obvious, such as volumes copied from one subsystem to another without the
original volumes having yet been CLIPped to unique spares. Or an IODF has
mistakenly connected an LPAR to a DASD subsystem it should not have access
to. Whatever the cause, restarting the IPL is useless as the same
duplicates will be prompted for again and again until they are eliminated.


Take this simple case, Duplicate pairs:

4001 - 8001
4002 - 8002
4003 - 8003
...

The pattern is transparent. The only real question is whether 4xxx is
'current' or 8xxx is. There is currently no way tell NIP that, say, 8xxx
is the range we want to keep online, while the corresponding 4xxx units
should remain offline.

Side irritant: why on earth do we have to tell NIP which volume we do
*not* want online? How would that game plan play on a network quiz show?

Back to the point. Although this stuation does not happen often, it can
take ages to unravel. And best of luck if there's no running system
available to undo the duplicates.

.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   "R.S."
To: IBM-MAIN@bama.ua.edu
Date:   04/28/2012 12:47 AM
Subject:Re: Early IPL problems
Sent by:IBM Mainframe Discussion List



W dniu 2012-04-27 23:03, John McDowell pisze:

I'm trying to get a feel for problems that occur in the early stages of

z/OS system start up (e.g. IPL/NIP).  Generally problems in these stages
result in a non-restartable wait state, for example wait state x'0B1'
(e.g. LOADxx or IODF problem).


Questions:
1.  FREQUENCY: How often do they occur ?
2.  DURATION: How long does it take to resolve them (e.g. minutes,

hours, etc.) ?

3.  IMPACT: What are the consequences (e.g. missed SLAs, etc.) ?
4.  CAUSE: What are the underlying sources (e.g. hardware, software,

etc.) ?

5.  RECOVERY: How do you recover from them ?


1. Rarely. IPL is performed rarely. In my case I haven't noticed such
problem *on production systems* for years. Such problems do happen
during tests, like new system, PTFs applied (and IPLTEXT not refreshed),
new CPC, new LPAR, DR test, etc.
BTW: I *hate* looking at last 3 digits, then previous digits... ;-)
Since the numbers are available on HMC, it would be nice to have button
Explain which could (under the covers) open the book and perform the
analysis for me.

2. The time depends on two-three elements:
a) time to open the book. It can be few seconds when I'm on my PC (HMC
accessed remotely), it can be minutes when I do it on real HMC and I
have to use another PC for documentation access.
b) time to write down the digits, extract wait state code and reason code.
c) (optional) sometimes I need to check whether description is accurate
or maybe fix something (like LOAD member). I usually logon to TSO on
another system and view/modify the things. It could take 5 min.

3. Lost time, some stress. From business point of view it doesn't affect
my SLA.

4. IODF in multiple extents, OS config with bad offline/online device
set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx,
not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC.

5. See 2.




Regards



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

Re: ServerPac RACF* jobs (rant)

2012-04-29 Thread R.S.

What I didn't say before is LACK OF KNOWLEDGE of persons who write those
member. It's "bad day", or "senior moment" (junior moment?), it's lack
of knowledge. I think this is main reason why it's so bad.

BTW: There is no chance to submit all the commands in the job without
any error. Even on vanilla RACF db. Some definitions are simply
conflicting.

It's worth to note, those jobs are IMHO the *MOST TIME CONSUMING PART OF
INSTALLATION PROCESS*.

Regards
--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-27 20:42, Gibney, Dave pisze:

I'll bite. Hi, Walt, What makes you think IBM might listen to this now that you
are not there? These jobs have always been a mess.

Last time I ranted, I suggested that serverpac provide an unload (or unload
records of the required profiles that could be used with DBSYNC (A very useful
tool, thank you so much) to more closely approximate the updates needed to a
customer specific RACF DB.
I think Russ, or someone took the idea under advisement.

Dave Gibney
Information Technology Services
Washington State University

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

Re: Early IPL problems

2012-04-28 Thread R.S.

W dniu 2012-04-27 23:03, John McDowell pisze:

I'm trying to get a feel for problems that occur in the early stages of z/OS
system start up (e.g. IPL/NIP). Generally problems in these stages result in a
non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF
problem).

Questions:
1. FREQUENCY: How often do they occur ?
2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.)
?
3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ?
4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ?
5. RECOVERY: How do you recover from them ?

1. Rarely. IPL is performed rarely. In my case I haven't noticed such
problem *on production systems* for years. Such problems do happen
during tests, like new system, PTFs applied (and IPLTEXT not refreshed),
new CPC, new LPAR, DR test, etc.

BTW: I *hate* looking at last 3 digits, then previous digits... ;-)
Since the numbers are available on HMC, it would be nice to have button
Explain which could (under the covers) open the book and perform the
analysis for me.

2. The time depends on two-three elements:
a) time to open the book. It can be few seconds when I'm on my PC (HMC
accessed remotely), it can be minutes when I do it on real HMC and I
have to use another PC for documentation access.

b) time to write down the digits, extract wait state code and reason code.
c) (optional) sometimes I need to check whether description is accurate
or maybe fix something (like LOAD member). I usually logon to TSO on
another system and view/modify the things. It could take 5 min.

3. Lost time, some stress. From business point of view it doesn't affect
my SLA.

4. IODF in multiple extents, OS config with bad offline/online device
set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx,
not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC.

5. See 2.

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: ServerPac RACF* jobs (rant)

2012-04-27 Thread R.S.

One more example, I just found (I couldn't resist)
SETROPTS +
RACLIST +
(SERVAUTH)+
CLASSACT +
(SERVAUTH)
SETROPTS +
RACLIST +
(SERVAUTH)+
REFRESH

Hint: SERVAUTH is CLASSACTivated two times before the above.

BTW: FACILITY is activated at least 5 times, not to mention RACLIST
(without refresh).

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-27 17:57, R.S. pisze:

RACFDRV and RACFTGT jobs are part of ServerPac installation process.
I have the following observation: the jobs are longer and longer and
MUCH MORE STUPID.
Example:

RACDCERT +
ID(WSCRU1) +
CONNECT ( +
RING(WASKeyring.BBNBASE.Signers) +
LABEL('WebSphereCA') +
CERTAUTH)
SETROPTS +
RACLIST(FACILITY) +
REFRESH

Quiz: why the FACILITY profiles are refreshed after every RACDCERT command?

Why there are several CLASSACT(class) commands for the same class?
Why there is RACLIST(class) REFRESH directly after CLASSACT(class)?
Unix UIDs are hard-assigned, but previously other UID values were used!
No clue whether I can use any unique number, or this number has to be
preserved.

BTW: I corrected (you can call it: edited) RACFDRV. Original size: 1500
lines, size after corrections: 137 lines (including comments), almost no
line left untouched.
Now I'm editing RACFTGT. 4300+ lines, I edited maybe 50%, 1600 lines left.

I think this should be seriously improved.

Time for my pills

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

Re: Test

2012-04-27 Thread R.S.

David,

Observation:
Your encoding is ISO-8859-1, Mark's email is coded in Windows-1252.
Maybe this is related to the problem

Regards
--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-27 17:13, David Betten pisze:

Sorry about this post. Trying to determine why my posts are coming out
garbled.

Dave Betten

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

ServerPac RACF* jobs (rant)

2012-04-27 Thread R.S.

RACFDRV and RACFTGT jobs are part of ServerPac installation process.
I have the following observation: the jobs are longer and longer and
MUCH MORE STUPID.

Example:

RACDCERT +
ID(WSCRU1) +
CONNECT ( +
RING(WASKeyring.BBNBASE.Signers) +
LABEL('WebSphereCA') +
CERTAUTH)
SETROPTS +
RACLIST(FACILITY) +
REFRESH

Quiz: why the FACILITY profiles are refreshed after every RACDCERT command?

BTW: I corrected (you can call it: edited) RACFDRV. Original size: 1500
lines, size after corrections: 137 lines (including comments), almost no
line left untouched.

Now I'm editing RACFTGT. 4300+ lines, I edited maybe 50%, 1600 lines left.

I think this should be seriously improved.

Time for my pills
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Confused on DFSORT SORTWK

2012-04-27 Thread R.S.

OPTION DYNALLOC=(3390,25)
The above means 25 work datasets.

BTW: IMHO you should omit FILSZ. DFSORT is able to obtain file size for
most cases.

To David Betten: your emails looks like encrypted. We cannot read it.

Regards
--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-27 16:27, Mark Pace pisze:

That corrected the error of running out space. However I thought it would
be a good idea to try DYNALLOC and be done with programers needing SORTWK
DD.
But change the JCL to
OPTION DYNALLOC=3390,FILSZ=E550

Causes it to fail almost immediately with SMS not allocating any space.

ICE083A D RESOURCES WERE UNAVAILABLE FOR DYNAMIC ALLOCATION OF WORK DATA
SETS (970C)
ICE753I 0 FWK=(0,0) SWK=(0,0) TWK=(0,0) RWK=(0,0) TOTAL=(0,0)
BLK=56664
ICE248I 0 ATTEMPTED TO ALLOCATE 80250MB OF DISK WORK SPACE ON 4 WORK DATA
SETS
ICE249I 0 SUCCESSFULLY ALLOCATED 0MB OF DISK WORK SPACE ON 0 WORK DATA
SETS

IGD17272I VOLUME SELECTION HAS FAILED FOR INSUFFICIENT SPACE FOR
DATA SET SYS12118.T101515.RA000.DMULLIS1.R0107017
JOBNAME (DMULLIS1) STEPNAME (RMFSORT )
PROGNAME (SORT) DDNAME (SORTWK04)
*REQUESTED SPACE QUANTITY = 20544130 KB *
STORCLAS (TEMPS) MGMTCLAS () DATACLAS ()
STORGRPS (TMPSG1 )

This is HUGE space request and I can't find where I tell DFSORT how to
change the requested size.

Maybe I'll leave well enough alone since I was able to make it work with
the SORTWK DDs

On Fri, Apr 27, 2012 at 9:33 AM, Mark Pace wrote:

Well part of the problem is an embarrassment. A couple of the volumes I
formatted incorrectly and were not SMS managed. :(
Trying again with all Temp volumes reformatted properly.

On Fri, Apr 27, 2012 at 9:15 AM, Shane Ginnanewrote:

On Fri, 27 Apr 2012 07:03:08 -0600, Steve Comstock wrote:

Well that cleared that up! Now I understand. :-)

Yep - always pays to get the definitive answer in plain English ... d'oh

Shane ...

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

--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Confused on DFSORT SORTWK

2012-04-27 Thread R.S.


Did you try to get rid of SORTWKxx DDs and use OPTION DYNALLOC ?

--
Radoslaw Skorupka
Lodz, Poland





W dniu 2012-04-27 14:43, Mark Pace pisze:

Trying to sort a fairly large RMF data file. 20,000 + cylinders.
I keep running out of SORTWK space.  I have 9 3390-9 volumes in my SMS
temporary storage pool. But I just noticed that no matter how many SORTWKxx
DDs I add it only allocates file on the first 5 temp storage volumes.
Anyone have an idea how I make DFSORT use more volumes?

//SORTWK01 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK02 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK03 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK04 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK05 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK06 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK07 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK08 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK09 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))
//SORTWK10 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(3335,3335))

ICE046A E SORT CAPACITY EXCEEDED - RECORD COUNT 2459859

B37-04,IFG0554A,DMULLIS1,RMFSORT,SORTWK01,BA11,TMP001,04210011,SYS12118.T083055.RA000.DMULLIS1.R0106329
B37-04,IFG0554A,DMULLIS1,RMFSORT,SORTWK05,BA12,TMP002,04210011,SYS12118.T083055.RA000.DMULLIS1.R0106333
B37-04,IFG0554A,DMULLIS1,RMFSORT,SORTWK08,BA13,TMP003,04210011,SYS12118.T083055.RA000.DMULLIS1.R0106336
B37-04,IFG0554A,DMULLIS1,RMFSORT,SORTWK04,BA14,TMP004,04210011,SYS12118.T083055.RA000.DMULLIS1.R0106332
B37-04,IFG0554A,DMULLIS1,RMFSORT,SORTWK02,BA15,TMP005,04210011,SYS12118.T083055.RA000.DMULLIS1.R0106330




--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: Have you ever done this using FTP?

2012-04-27 Thread R.S.

W dniu 2012-04-27 14:36, Bob Shannon pisze:

TRSMAIN is still available AFAIK.

TRSMAIN is an alias of AMATERSE.

Yes, but...
Definitely NOT for older system which do not have AMATERSE.
And for those systems you can still download older version.
BTW: http://techsupport.services.ibm.com/390/trsmain.html

AMATERSE is enhanced to support LARGE PS.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Have you ever done this using FTP?

2012-04-27 Thread R.S.

W dniu 2012-04-27 14:16, McKown, John pisze:

-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler
Sent: Thursday, April 26, 2012 5:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Have you ever done this using FTP?

I typically either use TRSMAIN, TSO XMIT, or DFDSS to dump
the PDS to a seq file, then do the FTP.

I think TRSMAIN can actually have the PDS as input and
produce the seq file as output.

Lizette

TRSMAIN has been replaced by AMATERSE. TRSMAIN was something like the old "field 
developed program". AMATERSE is now a standard z/OS utility. But all that has 
changed, as best as I can tell, is the name.

1. There are small functional enhancements in AMATERSE.
2. TRSMAIN is still available AFAIK. The reason could be to help users 
of old system versions.

--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

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

Re: SV: Mainframe Skills Scarce? (z/OS Mainframe & CA Product training ...)

2012-04-27 Thread R.S.

W dniu 2012-04-27 10:35, Thomas Berg pisze:
[...]

If true, why are so many skilled mainframe professionals --

particularly

sysprogs -- looking for work? IJS...

It is reasonable. Let's take job situation in Poland: unemployment is
over 10%, many (hundreds thousands) migrated to UK and other EU counries
and we hire people from Ukraine, Belarus and still looking for more.

In case of mainframe specialists the following reasons could explain the
situation:
- Less skilled specialists occupy the positions

- More skilled ones are to expensive

They aren't. It's just that the hiring bosses think so because they are
fixated at the view that non-management personals should be payed much less
than management personals.
In a rational world there wouldn't at the same time have people saying that
it's hard to get skilled mainframe personal and have many skilled mainframe
sysprogs looking for work (and not getting any).

If you really need, e g, a skilled sysprog it's no problem to get one: just put
some more money on the pay - and do a decent research to get the right person.
But CIOs today isn't interested as they are constantly looking at the next step
in their careers.

Let me rephrase it: It is TYPICAL IN OUR WORLD.
Is our world reasonable?
Well... I think it's completely unreasonable that poor soccer player
earns much more than prime minister or university professor. It's
unreasonable to pay fortune for Madonna's brassiere. It's unreasonable
that, for example some celebrity's divorce is a news of the day, and
blue laser is completely ignored. However it's typical, so it's NORMAL.

And it's (unfortunately) normal, that managers prefer young candidates.
It's bad, stupid, illegal, but normal.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Mainframe Skills Scarce? (z/OS Mainframe & CA Product training ...)

2012-04-26 Thread R.S.

W dniu 2012-04-27 07:38, Edward Jaffe pisze:

On 4/26/2012 9:09 PM, Scott McFall wrote:

MAINFRAME SKILLS ARE BECOMING SCARCE!particularly Systems
Programmers.

I hear this paradoxical conjecture all the time.

If true, why are so many skilled mainframe professionals -- particularly
sysprogs -- looking for work? IJS...

In case of mainframe specialists the following reasons could explain the
situation:

- Less skilled specialists occupy the positions
- More skilled ones are to expensive
- Unemployed specialists are not so skilled as they claim. Especially
there are some other skills important, usually called soft skills.

- Unemployed specialists are both expensive and not so skilled ;-)
- Cheaper specialists from other countries took the jobs, in US or
outside. That includes Poland - I'm aware of few teams maintaining
datacenters in US, Canada or western Europe.
- You have to high unemployment benefits and overall social advantages
causing your specialist to lazy to really looking for the job. That
includes readiness to relocate, to take worse job, to take different
job, etc.
- Unemployed specialist earned so much money in the past so they really
don't need to work. They are rich people. ;-)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: XRC (z/OS Global Mirroring)

2012-04-24 Thread R.S.

W dniu 2012-04-24 20:30, Patti McLeskey pisze:

I'm looking for anyone who has successfully used z/OS Global
Mirroring to replicate on non-IBM storage. Does it work?

Yes, it does. You have to have proper license for that. XRC is licensed
feature of DASD array.

What vendor DASD do you use?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: A z/OS Redbook Corrected - just about!

2012-04-24 Thread R.S.

It's boring. Another example for USS meaning Unix system services, not 
Unformatted system services. Yes, IBMer do use USS for Unix SS, 
regardless it is "official" or not official. And yes we can discuss what 
the acronym is and what is IBM authority to authorize the acronyms since 
it part of the English language. AFAIK English language is not a product 
of IBM, so I can freely use USS for USS Pampanito (I visited it in San 
Francisco) without IBM approvement.


And yes there are two or three IBM-MAIN members (I call them 
fundamentalists) who fight for the only usage of USS acronym. The rest, 
about 4,500 f*ck the idea of the only meaning of saint USS_Acronym. They 
don't care. They udnerstand that many acronyms are overloaded and the 
meaning of the acronym should be explained explicitly or should be 
obvious from the context.


So, my idea is to consequently ignore emails from USS fundamentalists 
and not to discuss about USS meaning. It is nonsense to discuss with 1 
(up to three) persons about USS acronym meaning. This is NOT the purpose 
of the group. Let's back to discussion about mainframes, z/OS, USS (UNIX 
System Services), USS (Unformatted System Services), VTAM, SNA, TCPIP, 
SMS, RACF, CSI, CSI (guess why I used it TWICE), HCD, etc. etc.

This is not forum about one persons idee fixe or fobia.

--
Radoslaw Skorupka
Lodz, Poland




W dniu 2012-04-24 21:17, Mark Zelden pisze:


There are? I see only one:

USS
See unformatted system service.




And this very recent APAR describes a problem with a zFS loop in
renaming processing after a BPX1REN ( rename, rename() ) syscall from
Unformatted System Service.   No wonder it caused a loop!


   APAR Identifier .. OA38688  Last Changed  12/04/13
   ZFS LOOP IN RENAME PROCESSING


   Symptom .. LP LOOP  Status ... CLOSED  PER
   Severity ... 2  Date Closed . 12/04/13
   Component .. 5696EFS00  Duplicate of 
   Reported Release . 3B0  Fixed Release  999
   Component Name ZFS ZSERIES FIL  Special Notice   HIPER
   Current Target Date ..12/06/29  Flags
   SCP ...   FUNCTIONLOSS
   Platform 

   Status Detail: APARCLOSURE - APAR is being closed.

   PE PTF List:

   PTF List:
   Release 3B0   : PTF not available yet
   Release 3B0   : Relief is available in the form of: AA38688
   Release 3D0   : PTF not available yet
   Release 3D0   : Relief is available in the form of: BA38688


   Parent APAR:
   Child APAR list:


   ERROR DESCRIPTION:
   A loop in zFS rename processing ( ZFSRENAM ) occurred after a
   BPX1REN ( rename, rename() ) syscall from USS.
   The token structure on the rename consists of the source
   directory vnode and the source vnode and the new token structure
   of the target directory vnode and the target vnode. The trace
   has shown the source directory vnode being the same as the
   target vnode which is incorrect and drove the loop.


   LOCAL FIX:
   None


   PROBLEM SUMMARY:
   
   * USERS AFFECTED: zFS Release 11 and zFS Release 13*
   * zFS FMID:HZFS3B0 and FMID:HZFS3D0*
   
   * PROBLEM DESCRIPTION: A loop in zFS rename processing *
   *  ZFSRENAM  occurred after a  *
   *  BPX1REN syscall from USS was made.  *
   
   * RECOMMENDATION: APPLY PTF*
   
   The vnodes for the operation are passed as input to zFS by the
   USS. The sdevp should not be the same as tdevp.


   PROBLEM CONCLUSION:
   A validity check of the input vnodes was added. In addition,
   code was added to ctkc_Lock4Vnodes to exit the loop if we are
   in recovery.


   TEMPORARY FIX:
   *
   * HIPER *
   *


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




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

Re: Striped file information

2012-04-24 Thread R.S.

W dniu 2012-04-24 22:07, Bill Ashton pisze:

Hi folks!

I have a 2.3GB file that is allocated to a STRIPED Dataclass.

Is there any way to see the particulars on each stripe - where it is, how
big it is, etc.? There is no problem, it is more of a curiosity for me. I
would like to know how performance of STRIPED files compares to a standard
allocation across the same number of volumes. I would like to play with
BUFNO and allocations to see how to best create and use this PS file.

1. LISTCAT ENT(dataset) ALL. You'll see more details about VSAM, less
about PS.
2. See STORCLASS definition - IMHO the stripes have to be equal, so you
can imagine the remaining parameters.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: DES, ICSF, and AES

2012-04-24 Thread R.S.

W dniu 2012-04-24 20:24, Ward, Mike S pisze:

Hello all is it possible to simultaneously have a DES master and an
AES master key at the same time or are they mutually exclusive?

What does it mean "to have keys" ?

In ICSF you can set master key for DES and AES algorithms independently.
Of course regular user has no ide about it - he's just using hi own keys
(the keys he is authorized to use) and he has no idea about master key.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Origins of numeric assignation of z196 & z114

2012-04-17 Thread R.S.

W dniu 2012-04-17 18:53, Elardus Engelbrecht pisze:
[...]

Sh, kiddies are reading this and we greybeards must behave.
;-D

Kiddies here? Are you KIDDING?

This is mainframe list! Avg member still remember Ford T premiere

--
Radoslaw Skorupka
Lodz, Poland

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

Re: SMS QUESTION

2012-04-17 Thread R.S.

My guess: you tried to define dataset > 4GB limit (*).

RC 140 RSN 110 say about it. To Allan: I would suggest to use regular
IBM documentation and regular BookManager search utility ;-)

I'm serious: 3 clicks and you have the answer.

I don't know what is the reason of the problem, but it can be difference
in DC definitions (do not confuse with ACS routines).

(*) Remarks:
1. There are other reasons for 140-110, 4GB limit is only one of them.
2. 4GB limit is a little bit tricky: this is limit of RBA, but total
size in tracks x track size can be slightly bigger than 4GB. The real
allocation limit is:

2^32 / CISZ -> integer number of CI's
number of CI's / CI/CA -> integer number of CA's
(in both case you truncate the value, i.e. 1023,2837 -> 1023)
number of CA's * ca size in track = maximum size of VSAM non-EA.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-17 18:13, willie bunter pisze:

I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster
recovery. The SMS rules - ACS or DC, MC ,SC& SG - are the same as in our
production system. However I could not understand the reason for this problem. As
a work around I defined the MCDS to use 4,000
cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS
which is also VSAM EXTENDED worked fine.

Below is the output of the failing job.

DEFINE CLUSTER -
(NAME(SYS2.MCDS) -
VOLUMES(HSM001) -
CYLINDERS(8000) -
RECORDSIZE(435 2040) FREESPACE(0 0) -
INDEXED KEYS(44 0) SHAREOPTIONS(3 3) -
SPEED BUFFERSPACE(530432) -
UNIQUE NOWRITECHECK) -
DATA -
(NAME(SYS2.MCDS.DATA) -
CONTROLINTERVALSIZE(12288)) -
INDEX -
(NAME(SYS2.MCDS.INDEX) -
CONTROLINTERVALSIZE(2048))
0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET
SYS2.MCDS
RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV
IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
RETURN CODE 140 REASON CODE 110
THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU
SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT
SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025
IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
SYS2.MCDS
0IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS
IDC3009I IGG0CLEV-110
1IDCAMS SYSTEM SERVICES TIME:
19:20:1304/02/12 PAGE 2
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

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

Re: Origins of numeric assignation of z196 & z114

2012-04-17 Thread R.S.

W dniu 2012-04-17 16:30, Mike Schwab pisze:

On Tue, Apr 17, 2012 at 5:50 AM, Jan MOEYERSONS
wrote:

On Mon, 16 Apr 2012 16:41:51 +0200, R.S. wrote:

BTW: I really can't understand "marketing names" like z196, TS1140, or
DS8000. Why don't they use names like Jaguar (ok, it's partially used),
MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

A rose, by any other name...

Bet he does not like BMW model names either.

No, I don't like. ;-) But you are talking about model NUMBER, not name.
The name - let's take Rolls-Royce, Audi, Mercedes, sounds IMHO better
than z196. z196 plays the role of NAME, not model number. The m/t is
2817. What is Quattro? It's a model of Audi. What is Silver Spirit? It's
a model of R-R. What's 2817 it m/t of z196...
Believe me: my car do have Product Number, I'm pretty sure it's user
unfriendly and hard to remember, ...but I don't care. We use *names*,
like Toyota Corolla, VW Golf, Ford Mondeo.
I have never heard someone saying: I'm using Ford product 2817-M15 known
as z196...

BTW: Let's leave it. My primary goal was to explain the meaning of 196
and 114 and I did it. The rest is my humble opinion. I wish I would
start Cindy or logon to Jennifer... ;-)

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: SV: Origins of numeric assignation of z196 & z114

2012-04-16 Thread R.S.

W dniu 2012-04-16 16:54, Thomas Berg pisze:

-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
R.S.
Skickat: den 16 april 2012 16:42
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: Origins of numeric assignation of z196& z114

W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze:

I have seeked but found nothing about this, why the new servers have

been

named z196& z114 and not Z11 EC& Z11 BC?

Why not z11? I don't know.
Why 196 and 114? I heard about it:
1xx means FIRST generation (of what? naming convention?)
96 means number of processors inside. Note, you can buy "only" 80 of
them, but it really contains 96 processors, inlcuidng SAPs and spares.
14 is for M10 model (4 are for spares and SAPs).

BTW: I really can't understand "marketing names" like z196, TS1140, or
DS8000. Why don't they use names like Jaguar (ok, it's partially used),
MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

Last, bit not least: Athlon, or Pentium sounds much better than CMOS
11S.

--
Radoslaw Skorupka
Lodz, Poland

I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :)

Hera? What are you talking about???
Here sounds like a mother. What sounds more attractive: Hera or Jennifer
Lopez? Or maybe you like z/OS-BX-81673&333 ???

Well, "sexy name" do have different meanings, very different...

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Origins of numeric assignation of z196 & z114

2012-04-16 Thread R.S.

W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze:

I have seeked but found nothing about this, why the new servers have been
named z196& z114 and not Z11 EC& Z11 BC?

14 is for M10 model (4 are for spares and SAPs).

BTW: I really can't understand "marketing names" like z196, TS1140, or
DS8000. Why don't they use names like Jaguar (ok, it's partially used),
MAGSTAR, T-REX, MtBlanc or Cindy Crawford?

Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Modernizing the BCP code ?

2012-04-14 Thread R.S.

Good idea, wrong address. Walt is retired.
However the idea is really good. There many cases where IBM should
prepare some sample exits (*). Even (as usually) in "as is" mode of
responsibility.

(*) I didn't say there are no sample exits from IBM. I said we lack some
other exits.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-14 17:26, Scott Ford pisze:

Walt,
That's great that you indicate they can be in Metal C, but I haven't seen any
examples from IBM in there manuals. Also, it would be desirable to say 'yes'
you can or 'no' you can't, it would help customers and us developers, IMHO.
Examples are a great source for learning and helpful pointers.

Regards

Scott Ford
Senior Systems Engineer
www.identityforge.com

On Apr 13, 2012, at 11:11 PM, Walt Farrell wrote:

On Fri, 13 Apr 2012 15:05:57 -0400, Scott Ford wrote:

Reading through this thread, quickly, it very obvious that certain exits must
be in Assembler.
So your kind of a captive audience. I am speaking of security type products. I
have beem experimenting in C , not being a C
heavy, it would be nice and desirable to do them in C . But sure if IBM
supports ICHPWX01 in C ...

Are there really system exits that -must be- in Assembler? Wouldn't Metal C
work instead? (Yes, you might need to provide some control block mappings
yourself, of course, but that really doesn't mean the language can't be used;
just that it may be a bit inconvenient, depending on what you want to look at.)

(And by the way, I'm pretty sure that Metal C would work for ICHPWX01 (RACF new
password exit). You can even use System REXX if you want.)

--
Walt

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

Re: Modernizing the BCP code ?

2012-04-12 Thread R.S.

W dniu 2012-04-12 22:44, Tom Marchant pisze:
[...]

Just to remain: z/990 introduced CSS concept,
60 LPARs, 1024 channels,

30 LPARs and 512 channels on the z990. CSS and
greater than 256 channels was quite a significant
architectural change, IMO

60 LPARs and 1024 channels. And SPANNED channels. I mean GA2. It was
available in z/990.

The same with STP - it was available in z/990, but not in "day 0".
The same like FICON 8S (PCIe cards) in z196.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Modernizing the BCP code ?

2012-04-12 Thread R.S.

W dniu 2012-04-12 20:47, Tom Marchant pisze:

On Thu, 12 Apr 2012 19:25:34 +0200, R.S. wrote:

As far as I know, z9 wasn't so revolutionary generation.

z9 introduced these facilities:
• DAT-enhancement facility 2
• ETF2-enhancement facility
• ETF3-enhancement facility
• Extended-immediate facility
• HFP-unnormalized-extensions facility
• Message-security-assist extension 1
• Modified-CCW-indirect-data-addressing facility
• PER-3 facility
• Server-time-protocol facility
• Store-clock-fast facility
• Store-facility-list-extended facility:
• TOD-clock-steering facility

Extended-Immediate is nice. I wonder if the clock
facilities are the reason for the level set.

So what? How does it compare to 50+ new instructions in z10?

A big change was introduced with z/990 and later with z10.

z20, yes. z990, not so much. And a big change with z996.

You're talking about z30, z8 and USS?
Just to remain: z/990 introduced CSS concept, 60 LPARs, 1024 channels,
CCF->CPACF(+Crypto cards), STP, PCHIDs, >16 CPs, new specialized CPs.
Was it small change? I don't think so.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Modernizing the BCP code ?

2012-04-12 Thread R.S.

W dniu 2012-04-12 20:25, Bob Shannon pisze:

Yes, but z/VM 5.4 is still supported and marketed.

zVM 5.4 was withdrawn from marketing December 12, 2011. It goes out of service
September 20, 2013.

I knew I should check it again before sending ;-)
My fault.
BTW: Sept 2013 is not tomorrow.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Modernizing the BCP code ?

2012-04-12 Thread R.S.

W dniu 2012-04-12 19:31, Bob Shannon pisze:

So, I suspect it was political decision whether to support z/990
and z9.

I think supporting the older processors this long was a marketing
decision. Sooner or later they had to drop off and now they have. zVM
V6 requires a z10 processor or higher, so it's somewhat surprising
that z9s are still supported by z/OS 2.1.

Yes, but z/VM 5.4 is still supported and marketed. I understand it as
technical requirements caused that new version require new hardware, but
customer can still order and use older version if he has older hardware.

Of course it only speculation.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Modernizing the BCP code ?

2012-04-12 Thread R.S.

W dniu 2012-04-12 18:52, McKown, John pisze:

Apparently pre-z9 processors will not be able to IPL z/OS version 2
at all. I would guess a hard wait at IPL/NIP time.

I'm curious: how much politics influenced on that decision?

As far as I know, z9 wasn't so revolutionary generation.
A big change was introduced with z/990 and later with z10.

So, I suspect it was political decision whether to support z/990 and z9.
And someone sad no to z/990 and yes to z9.

My €0.02
--
Radoslaw Skorupka
Lodz, Poland

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

Re: z/OS every two years (Official announcment)

2012-04-12 Thread R.S.

W dniu 2012-04-12 17:20, McKown, John pisze:

We pdf files on a Windows share. The only problem with this is in a
D.R. situation, because that share is deemed "non critical" and not
restored during a test. Which is why I need BookManager. At our DR
provider, the PC's used to connect to z/OS are not Internet capable.
And, as I've said, our Windows documentation disk is not available.
So I might be a good idea for me, like you, to copy the pdfs to a
z/OS UNIX subdirectory and make them available via the HTTP server.

Well, Windows disk *can be available*. Just make a copy on every Windows
disk you have in your company. I mean it: every admin laptop should
contain the copy of your library.
Lack of Internet do happen i.e. due to security restrictions (BTDT),
concurrent failure of every laptop cannot happen unless in Armageddon
mode ;-)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: SSL FTPing via crypto processor

2012-04-12 Thread R.S.

W dniu 2012-04-12 12:23, Tsai Laurence pisze:

Dear listers,
as the subject , a couple of questions to be clarified .
from z10+ , with z/OS V1.11+
1) I know z/OS FTP client support SSL/TLS , But no idea whether the
transferred data encrypted via HW crypto (CPACF) ?
2) If yes , what kind of key , symemtric key ? asymmestric key ?
3) is it signifcant CPU overhead comparing with none SSL ftping ?

1) CPACF can be used when present. It's not used for every single crypto
function.
2) SSL/TLS is a mix of encryption methods. During the handshake process
assymetric algorithms are used, then some symmetric key is exchanged and
main session (=> vast majority of data) is encrypted using symmetric
cryptography.

3. It depends. :-)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: z/OS every two years (Official announcment)

2012-04-12 Thread R.S.


I will fight for BOO format.
Where to demonstrate? Any riot?

Really outraged
--
Radoslaw Skorupka
Lodz, Poland





W dniu 2012-04-12 16:05, Sevetson, Phil pisze:

Bookreader? Really??
Guys, there's this thing they call the Internet, where you can get good documentation 
from what IBM calls their "website." ... PDF and Info Center (I much prefer the 
former, frankly)... fully searchable...

--Phil Sevetson, recovering Bookmanager addict

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Jan MOEYERSONS
Sent: Thursday, April 12, 2012 6:50 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS every two years (Official announcment)

On Wed, 11 Apr 2012 17:14:43 +0200, R.S.  wrote:


Documentation in Bookreader format will no longer be available!
That's horrible!


Indeed, it is.

Should we not make it a requirement (Share or otherwise) to have documentation 
in Bookreader format?

Cheers,

Jantje.

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

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




--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: z/OS every two years (Official announcment)

2012-04-11 Thread R.S.

Documentation in Bookreader format will no longer be available!
That's horrible!

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Questions regarding SMS compacted dataset

2012-04-10 Thread R.S.

In each case when you copy dataset from DASD to TAPE ar vice versa, the
data "in transit" are uncompressed. Compression/lack of compression on
source/target doesn't matter.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-04-10 17:00, Victor Zhang pisze:

Chris,
Thanks for the reply.
Using dss is to back extended files to tape/virtual tape.

Your answer said the data read will be expanded. So even by setting compact as
N, the amount of data written to tape/virtual tape will be same, right?

My another question is:
If I set compact=N for storage class, so data sets will not be
compressed/compacted.

If I use same utility to copy it to tape/virtual tape, will there any
difference for the data stream writing to tape?

I already noticed a difference:
By enabling compact option in storage class, I have very low compression ratio
for data written to tape/virtual tape, do you have any idea?

Regards
Victor

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

Re: LU0, SNA, TCPIP issue

2012-04-06 Thread R.S.

W dniu 2012-04-06 21:54, Staller, Allan pisze:

Lots of ways to go here.
Upgrade CICS to use LU2. CICS also (IIRC) speaks TCP "directly".
TN3270/TN3270E
Some emulator client on PC (Rumba, VISTA, PCOMM)

The goal is to get rid of HIS and not to make any revolution. It also
means to stay with LU0 (application "understand" LU0).

BTW:The client application is NOT 3270 emulator, it is "our own" GUI
based client, which talks to the windows server application which in
turn talks to mainframe (via HIS).
I think it would be enough to change last layer of the application which
talks to HIS and simply set up telnet server on host side.

--
Radoslaw Skorupka
Lodz, Poland

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

LU0, SNA, TCPIP issue

2012-04-06 Thread R.S.

Scenario:

CICS application-LU0 SNA (OSA Eth)HIS-Windows APP Server-WinClients

In other words there is a CICS based application, which is cuurently
accessed via LU0 "terminals". The application server (windows based) is
connected to the host via HIS, formerly known as MS SNA Server. So, from
the network point of view Windows machine is connected to the mainframe
using SNA protocol.

We want to get rid of the HIS.

So, we would like to use LU0 and TCP/IP communication.

Note: we're aware of Enterprise Extender, but our goal is to get rid of
HIS.

As far as now I just set up dedicated (for LU0) telnet server with his
own port.

Any ideas, comments, prompts are welcome.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Malicious Software Protection

2012-04-03 Thread R.S.

W dniu 2012-04-03 13:22, Elardus Engelbrecht pisze:
[...]

[1] - Bypass APF, bypass RACF, ignoring change managament processes,
use bribery, do copies from your sandbox into your production, use
FTP, capture data with keystroke logger + screen scrapers, etc.

Don't put into one basket so different things.
Obviously methods using bribery, dishonest (malicious) system
administrator, or misconfiguration caused by i.e. uneducated or lazy
admins - all those methods DO WORK on z/OS. The methods do work on every
platform. See K.Mitnick book - he claims he hacked people, not systems.

However none of attacks using any of the above (my list!) can be named a
virus. None of them exist because the system have the holes.

I would worry about method like Winnuke attack, or email with malicious
attachment, or execution non-authorized code.

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: ICSF - will "deactivate"op Lpar 'A' affect other lpars? and does it remain "deactivated"across IPLs?

2012-04-03 Thread R.S.

W dniu 2012-04-03 08:54, Francis van Zutphen pisze:

You can easily control which services are used and which are not.
ICSF calls RACF, see CSF* classes.

BTW: Why do you afraid? What's the risk you want to avoid? Just
curious.

-- Hello Radoslaw,

I had already set on the RACF audit bit for the CSF* classes and have
successfully execute some ICSF API's and received audit records in
the CSFSERV class...this works fine.

However I am also conducting tests with CA-XCOM (FTP) and switched on
the ICSF interface in the XCOM config file, see XCOM documentation
attachment, however this time I do not get any hits in the CSFSERV
class. I expect to see some hits on the RACF profiles that cover ICSF
CSNBSYE/CSNBSYD (CPACF) callable services.

Well. Two things to check:
1. Is the software using CPACF or CEX? That's significant difference.
Crypto cards (CEX2C, CEX3C) are designed for "high security" - secure
key cryptography. The cards are *SLOW*, especially for enc/decryption
small blocks of data. However you can also have CPACF which is fast (up
to 1000 times faster AFAIK), but it is clear key cryptography (or latest
enhancement - "masked" key).
To use CPACF you can use (possibly different) ICSF services or even
assembler (without ICSF at all).

I would create CL(CSFSERV) ** profile with AUDIT(ALL(READ)) and watch
the SMF80.

HTH
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Malicious Software Protection

2012-04-02 Thread R.S.

W dniu 2012-04-02 18:35, Chris Craddock pisze:

On Apr 2, 2012, at 10:46 AM, "R.S."
wrote:

The same with unauthorized code - maybe the system is not
bulletproof, but we have no documented case of such flaw.

Sorry, but you are totally wrong there.

You totally misinterpret my words.

Absence of publicized cases does not imply absence of cases.

Agreed. Did I write something opposite?

These matters are generally NOT publicized in order to avoid
encouraging copycats

...or there is another explanation: lack of such issues. (I did not say
anything more!)
It's worth to mention there are some flaws documented, in all cases I
know there is a solution for system administrator, a way to fix the hole.

- particularly in the financial sector.

The same reasons can be used in Windows or Unix (&Linux) world. But we
know many cases documented. What's the reason?
Why we don't know any virus for z/OS? Is the security by obscurity so
effective?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Malicious Software Protection

2012-04-02 Thread R.S.

W dniu 2012-04-02 03:37, Steve Comstock pisze:

On 4/1/2012 8:35 AM, Shmuel Metz (Seymour J.) wrote:

In, on 03/31/2012
at 09:57 PM, Clark Morris said:

Java on the server side is effectively executable code.

Yes, Java, Javascript and PDF are code, but a web browser does not
give code to a web server. OTOH, a web server can give code to a web
browser, and a browser running under z/OS would have the same
vulnerabilities as a browser on any other platform.

Hmmm. Do you know of any browsers that run under z/OS?

This is the "problem" with z/OS vulnerabilities. The vulnerabilities do
happen, but nobody heard about virus using any of them.

Oh, maybe someone *heard*, but there is no documented virus, is it?

The same with unauthorized code - maybe the system is not bulletproof,
but we have no documented case of such flaw.

--
Radoslaw Skorupka
Lodz, Poland

P.S. I can be wrong, I would gladly get corrected by reading documented
cases as I descibed above.

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

Re: Two "why" about the hardware

2012-04-01 Thread R.S.


OK, but "any" channel number does not change when using switch.
BTW: CU-host connection is limited to 8 channels.

--
Radoslaw Skorupka
Lodz, Poland


W dniu 2012-04-02 02:50, Mike Schwab pisze:

Because that is how the paths are counted.  A particular I/O command
could come in on any Ficon channel, and leave on any FIcon channel.

On Sun, Apr 1, 2012 at 3:50 PM, R.S.  wrote:

Why do you multiply the connection? And why the number of logical paths
should affect connectivity? Number of logical paths is almost always related
to CU electronics and  it is independent of switch used - it is the same
with and without  switch or switches. Radoslaw Skorupka Lodz, Poland W dniu
2012-04-01 21:40, Mike Schwab pisze:>  One complication is the
multiplication of paths 256 is the limit.>  And whatever delay that occurs
in each switch.>  (zSeries)16Ficon(McData)16Ficon(DS8000) is 16*16=256
paths.>  (zSeries)4Ficon(Mcdata)8Ficon(McData)8Ficon(DS8000) is 4 * 8 * 8 =
256 paths.>
(zSeries)4Ficon(Mcdata)4Ficon(McData)4Ficon(McData)4Ficon(DS8000) is 4>  * 4
* 4 * 4 = 256 paths.>
(zSeries)2Ficon(Mcdata)2Ficon(McData)2Ficon(McData)2Ficon(Mcdata)2Ficon(McData)2Ficon(McData)2Ficon(McData)2Ficon(DS8000)

is 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2= 256 paths.



--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: Two "why" about the hardware

2012-04-01 Thread R.S.


???
Why do you multiply the connection?
And why the number of logical paths should affect connectivity?
Number of logical paths is almost always related to CU electronics and 
it is independent of switch used - it is the same with and without 
switch or switches.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 2012-04-01 21:40, Mike Schwab pisze:

One complication is the multiplication of paths 256 is the limit.
And whatever delay that occurs in each switch.

(zSeries)16Ficon(McData)16Ficon(DS8000) is 16*16=256 paths.

(zSeries)4Ficon(Mcdata)8Ficon(McData)8Ficon(DS8000) is 4 * 8 * 8 = 256 paths.

(zSeries)4Ficon(Mcdata)4Ficon(McData)4Ficon(McData)4Ficon(DS8000) is 4
* 4 * 4 * 4 = 256 paths.

(zSeries)2Ficon(Mcdata)2Ficon(McData)2Ficon(McData)2Ficon(Mcdata)2Ficon(McData)2Ficon(McData)2Ficon(McData)2Ficon(DS8000)
is 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2= 256 paths.

On Sun, Apr 1, 2012 at 9:49 AM, Yi Ming  wrote:

1 level of cascading (2 directors) is supported (i think IBM simply hasn't got 
round to certifying multi-level cascades rather than it not working)
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/webindex/FQ116133



--
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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

Re: Initialize Tape Options

2012-04-01 Thread R.S.

W dniu 2012-04-01 08:35, Jake anderson pisze:

Hello List,

Good Morning !

Apart from IEHINIT, are there any freeware or any available utility to
initialize the 3590 tape ? This is just a general question out of curiosity
:).

My environment :

Z/os : 1.8
CA1 has its own utility, RMM has EDGINERS utility, probably other TMSes
have their own utility as well. IMHO the most important enhancement of
those utilities is cooperation with TMS database, not the initialisation
itself.

Q: what do you want to do? What's wrong with IEHINITT?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: New z/OS 1.13 Health Checks - Friday Rant

2012-03-31 Thread R.S.

W dniu 2012-03-30 16:24, Mark Brooks pisze:

Hi,
The XCF signalling services are available in all sysplex
environments, including monoplex. The rationale that motivates the
defining of transport classes applies to them all.

What for?
The classes are for traffic on sysplex links, are they?
No links, no need for traffic priorities.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: TSO userid character sets

2012-03-31 Thread R.S.

W dniu 2012-03-31 21:52, Phil Smith pisze:

Resending as plaintext with the Cyrillic characters removed since a friend
tells me the encoding got hosed when reading on GMail.

Does z/OS support userids with non-Roman characters? E.g., Cyrillic? I’m talking
about the userid itself, e.g., instead of YEVGENY.

I'm sorry I just re-read your message again.
You mean userids. NO, no such characters are allowed in the userid.

The only allowable characters are: A-Z, 0-9, #$@, first cannot be
numeric. 1-7 length.

No place for cyryllic or other national characters.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: TSO userid character sets

2012-03-31 Thread R.S.

W dniu 2012-03-31 21:52, Phil Smith pisze:

Resending as plaintext with the Cyrillic characters removed since a friend
tells me the encoding got hosed when reading on GMail.

Does z/OS support userids with non-Roman characters? E.g., Cyrillic? I’m talking
about the userid itself, e.g., instead of YEVGENY.

Yes, it does.
All you have to do is to set up 3270 emulator. Choose CP1025 and don't
forget to use proper keyboard.

I'm not sure about ISPF settings - is there any terminal type dedicated
for Russia? However you can work on default setting, all you can loose
is ability to change UC LC and SORT (etc.) in ISPF editor

BTW: I saw both your emails. First is unreadable for me. I reviewed
message source for both - they differ significantly.

--
Radoslaw Skorupka
Lodz, Poland

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

Two "why" about the hardware

2012-03-31 Thread R.S.

1. A coupling link ISC-3 is available from z/900 to z196, however IBM
claims it's impossible to connect two machines (*). WHY? Is it technical
or political (marketing) reson?

AFAIK it more restrictive: z10 will not connect to z/900 and z196 will
not connect to z/990.

2. FICON cascaded switching and two hops - that mean connection from
host to CU via more than 2 directors.

Q1. What is the reson of such restriction?
Q2. Has anobody tried to do it? Does it seems to work? What symptoms
(messages, error codes) can be observed?

BTW: What is CCIN 2BD2?

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: ICSF - will "deactivate"op Lpar 'A' affect other lpars? and does it remain "deactivated"across IPLs?

2012-03-30 Thread R.S.

You can easily control which services are used and which are not. ICSF
calls RACF, see CSF* classes.

BTW: Why do you afraid? What's the risk you want to avoid?
Just curious.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-30 18:04, Francis van Zutphen pisze:

Hi Mark, On second thoughts, I will leace ICSF running, other wise the API's
to CPACF will not work..I know that we use hashing...

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

Re: ICSF - will "deactivate"op Lpar 'A' affect other lpars? and does it remain "deactivated"across IPLs?

2012-03-30 Thread R.S.

W dniu 2012-03-30 16:17, Mark Jacobs pisze:

Yes, If you stop ICSF you won't be able to execute the ICSF API's that
interface with the cryptographic cards.

To complement: ICSF is the only *supported* way to access Crypto cards
*from z/OS*.

Remarks:
- you can access Crypto cards from Linux on zMachine.
- you can write your own program which does ICSF job, although the
interface is not documented. Of course you can safely omit this possibility.

BTW: Crypto card in OFFLINE state can be varied online from ICSF.

--
Radoslaw Skorupka
Lodz, Poland

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2741 matches

Mail list logo