date:20130314

On Thu, 14 Mar 2013 07:13:11 -0500, Kirk Wolf wrote:

I was thinking that another path might be to write a shell script in REXX
and use the Unix syscalls.  But the one you really need, mktime(), isn't
listed in the Using REXX with Unix System Services.  Pity, that would
have been quite doable.
 
mktime() is LE-dependent, and the apparent wizard behind Rexx-USS has
an aversion to LE.  There are reasons for this, perhaps good.

I'd do it in C since we have the compiler.

What are the syntactic bounds on the TZ environment variable?  Could
one subtract 24 hours from the offset and use the date(1) command?
Nope.  By experiment, z/OS POSIXly enforces a 24-hour syntactic limit.
OS X and Linux are not so fastidious.

-- gil

Unix was not designed to stop its users from doing stupid things,
as that would also stop them from doing clever things. – Doug Gwyn

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

Re: CATALOG QUESTION

2013-03-14 Thread Tom Marchant

On Thu, 14 Mar 2013 05:34:55 -0700, willie bunter wrote:

I am trying to find out who or what is using a usercat. 
I issued the /F CATALOG,ALLOCATED and it shows that it is allocated.

Is there something or command I can issue to see who or what is using the 
catalog?

GRS can tell you who has it.  Most likely, it is the Catalog Address Space.

You can use F CATALOG,UNALLOCATE... to get CAS to release it.
CAS will allocate it again when it is needed.

-- 
Tom Marchant

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

AW: USS date command, subtract one day

2013-03-14 Thread Uwe Oswald

Thx perfect, thats exactly what I need. But I'm afraid this doesn’t work for 
the first of a month for example 20130401 will then be 20130400 or I'm wrong?

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Rafal Hanzel ZETO Katowice
Gesendet: Donnerstag, 14. März 2013 13:23
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: USS date command, subtract one day

Maybe something like that, will help you:
echo `date +%Y%m%d` - 1 | bc

---
Pozdrawiam/Best regards,

Rafal Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych Tel. +48 32 
3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl Tel. kom. +48 
501677656 Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z 
o.o.
40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy Krajowego 
Rejestru Sądowego, KRS 051477 Kapitał zakładowy: 264500 zł NIP 
634-013-11-06 http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna trafić 
bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, rozpowszechnianie, 
bądź kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej 
informacji prosimy o poinformowanie nadawcy i usunięcie jej z komputera.

W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):
 Hi,

 I dont know if this is the right forum but I hope someone could help 
 anyway. I want to subtract one day from the actual date with one USS 
 unix command.

 The actual date I get via date +%Y%m%d (for example 20130314), but 
 date +%Y%m%d-1 or ...yesterday don’t work. I have tried everything 
 without success. Does anybody have a tip for me? It must be achieved 
 within one command not more.

 Thx
 Uwe

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

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

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

Re: USS date command, subtract one day

2013-03-14 Thread Elardus Engelbrecht

Steve Comstock wrote:
If you're coding in C, Assembler, COBOL, or PL/I, you can use the Language 
Environment date functions, which can do what you want pretty simply.

It is pretty easy indeed. I have done that in REXX and COBOL to test out 
date/time functions before and after we converted to use both Local and 
Greenwich Time Zone for time control compatibility with other machines.

For  Assembler, I just used TIME ,ZONE=LT or UTZ.

   call CEELOCT to get today's date in Lilian format
   subtract 1
   call CEEDATE to convert to a formatted date in a wide
variety of options
this does account for leap years and such.

Indeed, otherwise you will see an APAR pretty quick. ;-)

It's not a shell command, but you could write a very short program that 
returns the output from the CEEDATE call and then just invoke the program from 
a shell script.

Excellent approach for the OP to consider.

Groete / Greetings
Elardus Engelbrecht

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

Re: CATALOG QUESTION

2013-03-14 Thread willie bunter

Tom,

Thanks for the tip.  Thanks to all readers who responded to my post.

From: Tom Marchant m42tom-ibmm...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, March 14, 2013 9:24:58 AM
Subject: Re: CATALOG QUESTION

On Thu, 14 Mar 2013 05:34:55 -0700, willie bunter wrote:

I am trying to find out who or what is using a usercat. 
I issued the /F CATALOG,ALLOCATED and it shows that it is allocated.

Is there something or command I can issue to see who or what is using the 
catalog?

GRS can tell you who has it.  Most likely, it is the Catalog Address Space.

You can use F CATALOG,UNALLOCATE... to get CAS to release it.
CAS will allocate it again when it is needed.

-- 
Tom Marchant

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

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

Re: SMS QUESTION

2013-03-14 Thread John Dawes

David,
 
I checked.  There are no volumes in QUINEW status.   There is no overflow pool 
defined for this storage group.  I will heed your suggestion about having the 
overflow volumes.  This will be a great help.
 
Thanks again.



From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, 14 March 2013 9:16 AM
Subject: Re: SMS QUESTION

John,

Are there any volumes with status Quinew in the pool you're having a problem 
with?
Do you have a 'spill' pool defined?

If you Quinew one or more volumes, you'll find that over time these will have a 
greater amount of freespace than the rest of the pool thereby allowing 
allocations that won't fit elsewhere in the pool. You could expedite the 
process by clearing the now quinew'd volume using DSS or HSM. 

-Original Message-
From: John Dawes [mailto:jhn_da...@yahoo.com.au] 
Sent: Wednesday, March 13, 2013 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS QUESTION

As you aptly put it 'Just because someone else is stupid, that's no reason for 
you to be' which prompted my first post.  I was curious as to why the High 
Threshold was low.  Thanks to all of you my understanding has greatly increased.
 
Cheers.



From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, 13 March 2013 11:10 AM
Subject: Re: SMS QUESTION

I was once told by a colleague, 'Just because someone else is stupid, that's no 
reason for you to be'.

A low 'High Threshold' will trigger migration during Interval Migration. As Ron 
pointed out it also prevents SMS from working as designed.
A very low 'Low Threshold' will ensure that as much as possible will be 
migrated during Primary Space Mgt.

Beyond that I'll not comment further.

-Original Message-
From: John Dawes [mailto:jhn_da...@yahoo.com.au]
Sent: Wednesday, March 13, 2013 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS QUESTION

I stumbled on to this by accident.  The person who had set up the Storage Group 
wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to 
prevent space abends because the users who create dsns on this pool are not 
authorized to create multi-volume dsns.




From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, 13 March 2013 9:15 AM
Subject: Re: SMS QUESTION

That is correct, although by setting the high threshold so low, you prevent SMS 
from determining target volumes by activity.

What did you hope to accomplish with a high threshold setting of 20%? 

-Original Message-
From: John Dawes [mailto:jhn_da...@yahoo.com.au]
Sent: Wednesday, March 13, 2013 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS QUESTION

Just that I understand correctly if the the High Threshold is set to 20% SMS 
does not PREVENT allocations above the High Threshold i.e. the dsn will still 
be allocated if the space is available.  SMS will not fail the allocation 
request.  Right?
 
Thanks.



From: Ron Hawkins ronjhawk...@sbcglobal.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, 12 March 2013 6:51 PM
Subject: Re: SMS QUESTION

David,

Yes, your understanding is the same as mine. The primary eligible device list 
contains volumes that will not exceed the max threshold if the primary space is 
allocated there. This is sorted on performance criteria. The secondary eligible 
device list has volumes with enough free space to satisfy the primary space 
request, and my recollection is that this is in free space order.

If allocation is not satisfied in the primary list it will fall through to the 
secondary list. With a high threshold of 20%, most allocation will likely be 
influenced by space, rather than activity.

If you suspect that fragmentation is the problem then have you checked if you 
have Space Constraint relief set to YES in the DATACLAS used by the data set, 
or if the % reduction is aggressive enough to counter the fragmentation. 
Another strategy would be to reduce to space request to something smaller, 
let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated 
across multiple volumes - UNIT=(,5).

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of O'Brien, David W. (NIH/CIT) [C]
 Sent: Tuesday, March 12, 2013 11:01 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: [IBM-MAIN] SMS QUESTION
 
 No, volumes which are above the threshold but have available space are 
 put into a secondary allocation list. Those volumes under the high 
 threshold
are
 in a primary allocation list. SMS then searches for a volume which 
 will
satisfy
 the allocation. At least that's the way it was explained to me by IBM 
 at
the
 Share meeting in Baltimore some years ago.
 
 The OP has 51 volumes with available space which are either

Re: Query for Destination z article -- mainframes back to the future

On Wed, 13 Mar 2013 09:47:06 -0400, Gabe Goldberg wrote:

I'm writing about Back to the Future for mainframers -- historic (but
sometimes forgotten) mainframe lessons needed by and best-to-be learned
by new mainframers (but everyone, really).

Don't underestimate the future.

The Y2K crisis might have been mitigated if more designers
had said, Hey, pretty soon we're going to need 4-digit years.
Let's provide them now.  I made such a suggestion for a product
we were working on in 1987.  It was brushed off as premature.

And much of the anguish of 24-bit to 31-bit address conversion
might have been avoided if designers had thought to reserve
the top 8 bits of addresses instead of using them for flags.
Instead, many OS interfaces remain 24-bit constrained.

How many programmers are still using 31-bit branch instructions
rather than 64 because z/OS doesn't support execution above
the bar?  This year.

-- gil

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

Re: IBM Mainframe (1980's) on You tube

2013-03-14 Thread Todd Arnold

IBM had three channel-attached crypto units for the mainframes.

1977 – IBM 3845 DES encryption unit

1979 – IBM 3848 DES encryption unit - faster than the 3845, and added Triple-DES
   (yes, IBM already had Triple-DES in its products in 1979!)

1989 – IBM Transaction Security System (TSS) which included the 4753.  The 4753 
was the first product to offer the CCA architecture, and it is the ancestor of 
all of the other crypto processors such as the Crypto Express cards.

Todd Arnold

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread zMan

On Thu, Mar 14, 2013 at 10:25 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 Don't underestimate the future.

 The Y2K crisis might have been mitigated if more designers
 had said, Hey, pretty soon we're going to need 4-digit years.
 Let's provide them now.  I made such a suggestion for a product
 we were working on in 1987.  It was brushed off as premature.

 And much of the anguish of 24-bit to 31-bit address conversion
 might have been avoided if designers had thought to reserve
 the top 8 bits of addresses instead of using them for flags.
 Instead, many OS interfaces remain 24-bit constrained.

 How many programmers are still using 31-bit branch instructions
 rather than 64 because z/OS doesn't support execution above
 the bar?  This year.


Indeed -- look at CCWs: if they'd put the flags in the reserved byte
instead, we'd only have needed one format! (Well, until there's 64-bit I/O,
anyway).
-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: Query for Destination z article -- mainframes back to the future

Ah yes, the not-so-good pre-UPS days when even a  fraction-of-a-second 
power interruption could take down an entire DP center.  I recall the 
utility workers describing at least one roasted squirrel event and even 
one roasted large-bird event that affected our transformer's HV feed, 
although more of the problems were weather-related or human-related.  
One amazing thing was that in the 1980's our utility power was much more 
stable, rarely above three or four disruptive glitches a year.  By 2000, 
noticeable utility power glitches which reached our site had risen to 
several a month and often were uncorrelated with local weather, but 
fortunately by then the center was UPS-protected.


UPS-protecting all mainframe system hardware did significantly reduce 
number of hardware failures we experienced.  Even if you have an 
environment where an abnormal shutdown and restart of the DP center is 
is tolerable, an 8-hour or longer down time waiting on parts might not 
be.  These days, running a mainframe system without adequate UPS 
protection should be considered false economy.

Joel C Ewing

On 03/14/2013 07:50 AM, John McKown wrote:

I think that squirrel event refers to a number of times that the IBM-MAIN
listserv went down due to a suicidal squirrel throwing itself onto a
transformer, causing a massive power surge, which cause a catastrophic
event in the computer center.


On Thu, Mar 14, 2013 at 7:45 AM, zMan zedgarhoo...@gmail.com wrote:


On Thu, Mar 14, 2013 at 12:05 AM, Ed Finnell efinnel...@aol.com wrote:


Bon jour! We actually prosecuted a group of students who had managed to
overlay the weekly backup tapes with garbage and hoped for a 'squirrel
event'.
  They came perilously close...


I don't mind looking dumb: what's a squirrel event? Sounds like something
Macy's would advertise...
--
zMan -- I've got a mainframe and I'm not afraid to use it






--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Tom Marchant

On Thu, 14 Mar 2013 09:25:49 -0500, Paul Gilmartin wrote:

How many programmers are still using 31-bit branch instructions
rather than 64 because z/OS doesn't support execution above
the bar?  This year.

AFAIK there are no differences in the branch instructions for 
64-bit addresses.  Perhaps you mean that there are AMODE 31 
programs that do not clear the high halves of the registers?

-- 
Tom Marchant

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

Re: Secure Encryption Keys vs Protected Keys

2013-03-14 Thread Todd Arnold

I just discovered this discussion group, and I thought I'd add a little bit of 
information to the discussion.  I am a lead architect in development of the IBM 
crypto coprocessors (Crypto Express, etc), and in design of the CCA 
architecture and its verbs.  I also happen to have been deeply involved in 
design of the protected key support.

So here are a few random things that might make it clearer.  Many of you have 
made educated guesses, many of which are right, but I wanted to simply state 
the facts from the viewpoint of someone who should hopefully know them.  :-)

As described elsewhere, use of protected keys DOES require the Crypto Express 
coprocessor.  The key starts as a secure key (wrapped by the CEX master key).  
The CPACF firmware sends this to the CEX, where it is decrypted using a special 
instruction that is not available to normal application programs.  The 
resulting cleartext key is sent directly from the CEX to CPACF and can never 
appear anywhere in the system that application programs or the O/S can ever see 
it.  Thus, it stays in hardware in the mainframe.  This is what makes it much 
more secure than anything the application program, O/S, RACF, etc. could do - 
nothing can get to the cleartext key, even though it is in the machine.  

CPACF generates a fresh wrapping key when it starts, and uses that to wrap the 
cleartext keys that come back from the CEX.  Since that wrapping key will 
change when CPACF starts up next time, the CPACF-wrapped keys are no good for 
long term use - they have to be re-decrypted and re-wrapped by CPACF the next 
time the system starts.

Once the key has been unwrapped by the CEX and sent back to CPACF, the CEX is 
no longer involved in the protected key operations.  The CPACF-wrapped 
protected key gets sent to the CPACF when you need to use it, and the CPACF 
unwraps it and performs the desired operation.  Thus, the protected key 
operations are extremely fast, but they are slightly slower than clear key 
CPACF operations since there is an extra step of unwrapping the key.  
Obviously, if you encrypt a huge block of data, this extra unwrap operation 
will not have nearly as much impact as if you encrypt a tiny block, since it's 
only done once for the block in either case.

In regard to synchronous vs. asynchronous...  This is really from the 
perspective of the host CPU.  A synchronous operation is one like any regular 
CPU instruction (add, move, etc.).  The CPU executes a machine instruction, and 
at the end of that instruction the result is available.  For an asynchronous 
operation, on the other hand, the CPU executes an instruction that sends a 
request off for execution somewhere else (hence the name coprocessor), and 
that CPU instruction is done when the request has been sent.  Some time later, 
the coprocessor notifies the CPU that the request has been completed and the 
CPU goes and gets it.  This asynchronous method is the way the CEX's work.  
Requests are posted to queues and the CEX's read from those queues, process the 
work, and return results to the queue.

The choice of using protected key CPACF or the CEX is really one dependent on 
what your application has to do.  The protected key CPACF is VERY fast and 
really is very secure - the only way an attacker could find the value of your 
key is to attack your mainframe at the hardware level.  Nothing they can do in 
software or with any utilities or management tools will let them attack it.  On 
the other hand, there are several things that would make you use the CEX 
instead, and they are important.  The first one is that the CEX provides a huge 
and varied set of functions, while the protected key CPACF can only do simple 
encryption and MAC operations with the keys.  The second one is that the 
protected key CPACF cannot do any kind of enforced key typing or key usage 
control.  For example, you can't specify a key that can only be used for MAC, 
or one that can only be used to protect financial PINs, or...  CCA on the CEX 
has a rich set of key management and key typing features that do that.  
Finally, if you are doing any kind of bank card or payments processing, or some 
other operations, there are standards that make it mandatory that you use an 
HSM like the CEX cards.  Even though protected key CPACF is very secure, it 
does not meet the rules stated in those standards.

Todd Arnold
Senior Technical Staff Member (STSM)
IBM Cryptographic Coprocessor Development
(arno...@us.ibm.com)

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

Re: What is the justification for not using Trusted Key Entry (TKE) workstation?

2013-03-14 Thread Todd Arnold

TKE is definitely more secure than the TSO panels.  Furthermore, standards that 
are mandatory for some applications (particularly banking) make the TSO 
approach unacceptable.  Those standards say that you are not allowed to have 
any cleartext key parts pass through any unprotected general-purpose computer.  
Since the hardware and software in your general purpose computer is much less 
secure than the HSM (crypto card) that you are installing keys into, that 
computer is an easier attack target.  The assumption is that smart and capable 
attackers will capture the key parts as they travel through your mainframe, 
where they are unprotected, and thus they will not have to find a way to attack 
the secure HSM itself.  In many cases, even the terminal you use to enter the 
key parts can be easy to attack - for example, keystroke loggers.

TKE solves this by using very secure cryptographic protocols for all 
communications over any unprotected medium.  For example, there is strong 
authentication of the TKE user, and then key parts are strongly encrypted all 
the way from the crypto module in the TKE workstation to the HSM itself in the 
mainframe.  There is no point where it can be attacked.  At the TKE 
workstation, if you use the optional smart card support, the key parts are 
entered on the keypad of the smart card reader which is secure, unlike the 
keyboard on a PC.  Note that TKE performs cryptography using its own crypto 
card (with a special version of the CCA firmware) - something that obviously 
isn't in an HMC.  While I understand why some people think the HMC might be a 
good place for key loading functions, it does not have the necessary security - 
for example the embedded crypto card that prevents any cleartext or otherwise 
sensitive data from passing through the HMC computer or across the network it's 
connected to.  Furthermore, many people want their key management machine 
locked in a controlled room, while their HMC would not be restricted to the 
people who need to do key management functions.

The question is really what level of security is appropriate (or required) in 
your particular application.  There is no question that TKE is much more 
secure, but for many people the TSO panels are perfectly acceptable.

Todd Arnold
Senior Technical Staff Member (STSM)
IBM Cryptographic Coprocessor Development
(arno...@us.ibm.com)

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

Re: Query for Destination z article -- mainframes back to the future

paulgboul...@aim.com (Paul Gilmartin) writes:
 Don't underestimate the future.

 The Y2K crisis might have been mitigated if more designers
 had said, Hey, pretty soon we're going to need 4-digit years.
 Let's provide them now.  I made such a suggestion for a product
 we were working on in 1987.  It was brushed off as premature.

 And much of the anguish of 24-bit to 31-bit address conversion
 might have been avoided if designers had thought to reserve
 the top 8 bits of addresses instead of using them for flags.
 Instead, many OS interfaces remain 24-bit constrained.

 How many programmers are still using 31-bit branch instructions
 rather than 64 because z/OS doesn't support execution above
 the bar?  This year.

there was a CENTURY discussion on the internal network early to mid-80s
... discussing the looming y2k problem. I've previously reposted
somebody's post to the CENTURY discussion about similar/related issues
at NASA:
http://www.garlic.com/~lynn/99.html#email841207
in this old Y2K thread
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve 
Y2K)

other past refs:
http://www.garlic.com/~lynn/2001n.html#74 The demise of compaq
http://www.garlic.com/~lynn/2009n.html#53 Long parms...again
http://www.garlic.com/~lynn/2010i.html#65 Of interest to the Independent 
Contractors on the list
http://www.garlic.com/~lynn/2010m.html#47 OT:  Found an old IBM Year 2000 manual
http://www.garlic.com/~lynn/2010o.html#41 60 Minutes News Report:Unemployed for 
over 99 weeks!

misc. references to the internal network (larger than the
arpanet/internet from just about the beginning until sometime late
'85 or early '86)

other Y2K trivia ... one of the too-big-to-fail financial institutions
had outsourced much of their Y2K remediation to the lowest bidder ...
in this case a software company located it in the Brighton Beach area of
Brooklyn. It wasn't until it was long over that they found out it was a
front for an ethnic criminal organization (interesting hacks were found
in various places that would trigger unlogged wire transfers to various
places around the world).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

DS6800 problem (?)

2013-03-14 Thread Miklos Szigetvari


Hi

In some previous message I have described that , we are moving now from 
the zDASD storage system to DS6800.
We have a relative large number of volumes (140) , so we decided to 
move via DFSDD COPY
all the volumes to the proper new addresses. It worked for every volume, 
except the z/OS 1.13 system volumes (Z1DT11 and Z1DT12), worked also for 
the z/OS 1.12 system volumes

We got output track format errors, and nobody can say the reason till now:
- if I change the output (target) the error moves to the new volume, but 
the message complains about the output volume

- if I COPY logically by dataset , I got errors for
  sys1.linklib
  cee.sceerun
  sys1.shasmig
  csf.scsfmod0
As last attempt I copied again this datasets by IEBCOPY, and try to IPL, 
and the new system is working

(or at last I think so) .

I lost my confidence on me , DS6800  zDASD and the IBM support , but 
maybe somebody have seen something like this.


--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail:miklos.szigetv...@isis-papyrus.com
Info:i...@isis-papyrus.com  Hotline: +43-2236-27551-111
Visit our brand new extended Website atwww.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

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

Re: DS6800 problem (?)

2013-03-14 Thread David Devine

Hi Miklos,
Some quick questions:-
(a) did you have purge coded in the sysin of your dfdss copy decks?
(b) did you copy the ipl volumes when their system was down ? (via another 
lpar)   
(c) did you copy the source volume to a target with exactly the same cylinder 
count?
(d) you mention message complains about the output volume can you copy that 
in so we can see specifically?

Dave
***
 Hi

In some previous message I have described that , we are moving now from 
the zDASD storage system to DS6800.
We have a relative large number of volumes (140) , so we decided to 
move via DFSDD COPY
all the volumes to the proper new addresses. It worked for every volume, 
except the z/OS 1.13 system volumes (Z1DT11 and Z1DT12), worked also for 
the z/OS 1.12 system volumes
We got output track format errors, and nobody can say the reason till now:
- if I change the output (target) the error moves to the new volume, but 
the message complains about the output volume
- if I COPY logically by dataset , I got errors for
   sys1.linklib
   cee.sceerun
   sys1.shasmig
   csf.scsfmod0
 As last attempt I copied again this datasets by IEBCOPY, and try to IPL, 
 and the new system is working
 (or at last I think so) .

I lost my confidence on me , DS6800  zDASD and the IBM support , but 
maybe somebody have seen something like this.

-- 
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Gerhard Adam

The Y2K crisis might have been mitigated if more designers
had said, Hey, pretty soon we're going to need 4-digit years.
Let's provide them now.  

In fairness, there wasn't a Y2K crisis as much as it was Y2K procrastination. 
 Everyone was aware of this problem from the mid-70's on, but there was always 
an excuse as to why it was premature, or not necessary, or how the system would 
be replaced by then, etc. etc. etc.  It was not a designer or programmer 
problem.

And much of the anguish of 24-bit to 31-bit address conversion
might have been avoided if designers had thought to reserve
the top 8 bits of addresses instead of using them for flags.
Instead, many OS interfaces remain 24-bit constrained.

Again, it's an easy argument to make when one is wallowing in terabytes of 
memory.  Not so much when an application may have had 80K [or less] to run in. 
After all, it's amazing what one can see in hindsight.  Yet, I seriously doubt 
that anyone would look at 64-bit addressing and say ... let's go to 128 bit, 
because we'll need it at some point in the future.  Who would be willing to 
reserve more storage, modify architecture, and infrastructure for such a 
contingency?

How many programmers are still using 31-bit branch instructions
rather than 64 because z/OS doesn't support execution above
the bar?  This year.

There is no 31-bit versus 64-bit branch instruction.  All addresses are 
interpreted based on the addressing mode and Branch Relative instructions don't 
use a base.  

Adam

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

Re: AW: USS date command, subtract one day

Correct.  So if you really want something that will work for all dates, 
including first of month, first of month in March on leap and nonleap 
year, first of year, etc.  you need something else.


I'm not enough of a UNIX authority to know if this is standard for all 
implementations of the UNIX date command and can't test in z/OS 
environment, but a search for relative dates and Linux found a 
--date parameter for the date command.  At least on Fedora Linux the 
date command already appears to have relative date calculation built in.

Currently (2013-03-14) on Fedora the command
date  --date=14 days ago
 returns Thu Feb 28 09:52:21 CST 2013
and
date --date=379 days ago
returns Wed Feb 29 09:57:26 CST 2012

If date under z/OZ UNIX supports the same parameters, then
date +%Y%m%d --date=1 day ago
which today on Fedora returns 20130313  may be the form you need.

   JC Ewing

On 03/14/2013 08:32 AM, Uwe Oswald wrote:

Thx perfect, thats exactly what I need. But I'm afraid this doesn’t work for 
the first of a month for example 20130401 will then be 20130400 or I'm wrong?

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Rafal Hanzel ZETO Katowice
Gesendet: Donnerstag, 14. März 2013 13:23
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: USS date command, subtract one day

Maybe something like that, will help you:
echo `date +%Y%m%d` - 1 | bc

---
Pozdrawiam/Best regards,

Rafal Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych Tel. +48 32 
3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl Tel. kom. +48 
501677656 Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z 
o.o.
40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy Krajowego 
Rejestru Sądowego, KRS 051477 Kapitał zakładowy: 264500 zł NIP 
634-013-11-06 http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna trafić 
bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, rozpowszechnianie, 
bądź kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej 
informacji prosimy o poinformowanie nadawcy i usunięcie jej z komputera.

W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):

Hi,

I dont know if this is the right forum but I hope someone could help
anyway. I want to subtract one day from the actual date with one USS
unix command.

The actual date I get via date +%Y%m%d (for example 20130314), but
date +%Y%m%d-1 or ...yesterday don’t work. I have tried everything
without success. Does anybody have a tip for me? It must be achieved
within one command not more.

Thx
Uwe







--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Speed up DASD copy

2013-03-14 Thread David Devine

Hello,
further to this query and the oddity of Optimize being tolerated for dfdss full 
copy but not documented, i emailed one of the guys who present's the What's 
new in dss share sessions asking for clarifcation and they were kind 
enough to send on to R  D who gave the response.

Here's the reply.

Hi David,

Thank you for your questions.  You are correct, Optimize is only valid for 
dump.  Optimize for copy was prototyped 20+ years ago, but was never intended 
to be shipped as part of the product.  I understand you do see some performance 
gains when running your copy commands, but the code is not fully developed.  We 
will take an APAR and are considering two approaches: 
1.  ignore the OPTIMIZE keyword for the COPY command.  This means that 
existing jobs that specify OPTIMIZE on COPY that run today would continue to 
run, however, they will be forced to OPTIMIZE(1). 
2.  cause a syntax error when OPTIMIZE is specified on the COPY command.  
This means existing jobs that specify OPTIMIZE on COPY that run today would now 
fail.

We would appreciate any comments you have on whether we should take one 
approach over the other.  Also, if you would like to see OPTIMIZE for COPY 
fully supported I would ask you open a marketing requirement.  A requirement 
will help get that work prioritized amongst other requirements.

Thank you again,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ

Nice people to talk to.

In the short term, i think the first apar option is probably desirable rather 
the second as they need to cater for the fact its unsupported and mitigate for 
any unforseen consequences of its usage, but longer term, getting it fully 
deployed  supported on copy, if only for Copy Full would be the way to go, 
so i'd say opening a marketing requirement would be the preferred approach.

An invitation hard to refuse.
The more requests they get the more likely it is to happen so anyone attending 
the next few shares could bring it up too.  

Dave
 

***
Miklos,

Others may want to correct me, but from what I've observed OPT(4) is only used 
for the DUMP command.

COPY will accept OPT(4), but all you seem to get is  OPT(3).

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Miklos Szigetvari
 Sent: Thursday, March 07, 2013 4:34 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: [IBM-MAIN] Speed up DASD copy
 
   Hi
 
 The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
 10 minutes to abut 7 minutes.
 The  real copy will go from ESCON channels to FICON .
 We have to do this only once, as BusTech gave up the support for zDASD .
 
 Thank you


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

Re: AW: USS date command, subtract one day

2013-03-14 Thread Mark Zelden

If you do it in REXX, as already mentioned, the DATE builtin function can 
convert 
between most formats (not all).   It's has that ability since OS/390 2.4.   If 
you
don't like that you can use the RDATE or RDATEF (called as a function)
from my web site or CBT file 434. 

It has it's own base date based on 1/1/1900 that I use in programs
for subtracting or adding days. 

http://www.mzelden.com/mvsfiles/rdate.txt

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Speed up DASD copy

2013-03-14 Thread Miklos Szigetvari


Thank you Dave.
Disturb me a little the code is not fully developed sentence, but we 
are now over the big copy(140 volumes with 3 errors) .

Thank you again .

On 14.03.2013 17:32, David Devine wrote:

Hello,
further to this query and the oddity of Optimize being tolerated for dfdss full copy but not 
documented, i emailed one of the guys who present's the What's new in dss 
share sessions asking for clarifcation and they were kind enough to send on to R  D who 
gave the response.

Here's the reply.

Hi David,

Thank you for your questions.  You are correct, Optimize is only valid for 
dump.  Optimize for copy was prototyped 20+ years ago, but was never intended 
to be shipped as part of the product.  I understand you do see some performance 
gains when running your copy commands, but the code is not fully developed.  We 
will take an APAR and are considering two approaches:
1.  ignore the OPTIMIZE keyword for the COPY command.  This means that 
existing jobs that specify OPTIMIZE on COPY that run today would continue to 
run, however, they will be forced to OPTIMIZE(1).
2.  cause a syntax error when OPTIMIZE is specified on the COPY command.  
This means existing jobs that specify OPTIMIZE on COPY that run today would now 
fail.

We would appreciate any comments you have on whether we should take one 
approach over the other.  Also, if you would like to see OPTIMIZE for COPY 
fully supported I would ask you open a marketing requirement.  A requirement 
will help get that work prioritized amongst other requirements.

Thank you again,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ

Nice people to talk to.

In the short term, i think the first apar option is probably desirable rather the second as 
they need to cater for the fact its unsupported and mitigate for any unforseen consequences 
of its usage, but longer term, getting it fully deployed  supported on copy, if only for 
Copy Full would be the way to go, so i'd say opening a marketing requirement 
would be the preferred approach.

An invitation hard to refuse.
The more requests they get the more likely it is to happen so anyone attending the next 
few shares could bring it up too.

Dave
  


***

Miklos,
Others may want to correct me, but from what I've observed OPT(4) is only used 
for the DUMP command.
COPY will accept OPT(4), but all you seem to get is  OPT(3).
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Miklos Szigetvari
Sent: Thursday, March 07, 2013 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Speed up DASD copy

   Hi

The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
10 minutes to abut 7 minutes.
The  real copy will go from ESCON channels to FICON .
We have to do this only once, as BusTech gave up the support for zDASD .

Thank you
   


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





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

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

Re: AW: USS date command, subtract one day

On Thu, 14 Mar 2013 11:15:20 -0500, Joel C. Ewing wrote:

If date under z/OZ UNIX supports the same parameters, then
date +%Y%m%d --date=1 day ago
which today on Fedora returns 20130313  may be the form you need.
  
I believe that any option introduced by two hyphens is a GNUism; not POSIX;
not available on z/OS.

-- gil

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

Re: AW: USS date command, subtract one day

2013-03-14 Thread Sri h Kolusu

If you are planning to perform the date arithmetic on z/OS then DFSORT has 
many Date arithmetic functions that can add/subtract days, months and 
years from any given date. 

If you just want the current date-1 when you can use DATE1-1 

//STEP0100 EXEC PGM=SORT 
//SYSOUT DD SYSOUT=* 
//SORTIN DD * 
ABC 
//SORTOUT DD SYSOUT=* 
//SYSIN DD * 
  OPTION COPY 
  INREC OVERLAY=(10:DATE1-1) 
//* 

The output from this 

ABC  20130313 

But if you want add/sub days from any given date, then you can use the 
following DFSORT Job

//STEP0100 EXEC PGM=SORT 
//SYSOUT DD SYSOUT=* 
//SORTIN DD * 
20101215 
20110110 
20110225 
//SORTOUT DD SYSOUT=* 
//SYSIN DD * 
  OPTION COPY 
  INREC OVERLAY=(15:1,8,Y4T,ADDDAYS,+15,TOGREG=Y4T(-), 
 30:1,8,Y4T,SUBDAYS,+23,TOGREG=Y4T(-)) 
//*

The output is 

20101215  2010-12-30 2010-11-22
20110110  2011-01-25 2010-12-18
20110225  2011-03-12 2011-02-02  


For complete details of date arithmetic functions and other new functions 
see User Guide for DFSORT PTFs UK90025 and UK90026 paper (sortugph.pdf) 
at:

http://www.ibm.com/support/docview.wss?rs=114uid=isg3T7000242

Thanks,
Sri Hari Kolusu
DFSORT Development
IBM Corporation
Email: skol...@us.ibm.com
Phone: 408-463-2403 Tie Line 543-2403

IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 
03/14/2013 09:38:02 AM:

 From: Mark Zelden m...@mzelden.com
 To: IBM-MAIN@listserv.ua.edu, 
 Date: 03/14/2013 09:38 AM
 Subject: Re: AW: USS date command, subtract one day
 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
 
 If you do it in REXX, as already mentioned, the DATE builtin 
 function can convert 
 between most formats (not all).   It's has that ability since OS/390
 2.4.   If you
 don't like that you can use the RDATE or RDATEF (called as a function)
 from my web site or CBT file 434. 
 
 It has it's own base date based on 1/1/1900 that I use in programs
 for subtracting or adding days. 
 
 http://www.mzelden.com/mvsfiles/rdate.txt
 
 --
 Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS 
 mailto:m...@mzelden.com 
 Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
 Systems Programming expert at http://expertanswercenter.techtarget.com/
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

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

Re: AW: USS date command, subtract one day

On Thu, 14 Mar 2013 11:38:02 -0500, Mark Zelden wrote:

If you do it in REXX, as already mentioned, the DATE builtin function can 
convert 
between most formats (not all).   It's has that ability since OS/390 2.4.   If 
you
don't like that you can use the RDATE or RDATEF (called as a function)
from my web site or CBT file 434. 

It has it's own base date based on 1/1/1900 that I use in programs
for subtracting or adding days. 

http://www.mzelden.com/mvsfiles/rdate.txt
 
A more interesting (but perhaps less useful) problem is to find the
date and time 12 hours ago.  It could still be done in Rexx --
convert everything to seconds; add the offset in seconds;
convert back with congruence arithmetic.  It's a delightful
feature of Rexx that its congruence operators don't demand
integer operands.

Ah, if only Rexx were timezone savvy.

What's one month before March 31?

-- gil

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

AW: AW: USS date command, subtract one day

2013-03-14 Thread Uwe Oswald

Thank you for all your hints and tips but I need just one command without an 
additional script or similar since I need this for different customers. All 
that I want is just create a file with some content and give that file 
yesterdays date. In each other Unix version not a problem at all, but USS 
seems to be different. The date...--date syntax is invalid in USS. As I said 
in my first post, I tried nearly everything I believe.

HELP :-)

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Joel C. Ewing
Gesendet: Donnerstag, 14. März 2013 17:15
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: AW: USS date command, subtract one day

Correct.  So if you really want something that will work for all dates, 
including first of month, first of month in March on leap and nonleap year, 
first of year, etc.  you need something else.

I'm not enough of a UNIX authority to know if this is standard for all 
implementations of the UNIX date command and can't test in z/OS environment, 
but a search for relative dates and Linux found a --date parameter for 
the date command.  At least on Fedora Linux the date command already appears 
to have relative date calculation built in.
Currently (2013-03-14) on Fedora the command date  --date=14 days ago
  returns Thu Feb 28 09:52:21 CST 2013
and
date --date=379 days ago
returns Wed Feb 29 09:57:26 CST 2012

If date under z/OZ UNIX supports the same parameters, then date +%Y%m%d 
--date=1 day ago
which today on Fedora returns 20130313  may be the form you need.

JC Ewing

On 03/14/2013 08:32 AM, Uwe Oswald wrote:
 Thx perfect, thats exactly what I need. But I'm afraid this doesn’t work for 
 the first of a month for example 20130401 will then be 20130400 or I'm wrong?

 -Ursprüngliche Nachricht-
 Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 Im Auftrag von Rafal Hanzel ZETO Katowice
 Gesendet: Donnerstag, 14. März 2013 13:23
 An: IBM-MAIN@LISTSERV.UA.EDU
 Betreff: Re: USS date command, subtract one day

 Maybe something like that, will help you:
 echo `date +%Y%m%d` - 1 | bc

 ---
 Pozdrawiam/Best regards,

 Rafal Hanzel
 Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych Tel. +48 
 32 3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl Tel. kom. +48 
 501677656 Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z 
 o.o.
 40-158 Katowice, ul. Owocowa 1
 Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy 
 Krajowego Rejestru Sądowego, KRS 051477 Kapitał zakładowy: 264500 
 zł NIP 634-013-11-06 http://www.zetokatowice.pl

 Jesteśmy uczestnikiem Programu
 RZETELNA Firma
 Sprawdź naszą rzetelność na
 http://www.rzetelnafirma.pl/8FGKEVFH

 Treść tej informacji może być poufna, w związku z czym powinna trafić 
 bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, rozpowszechnianie, 
 bądź kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej 
 informacji prosimy o poinformowanie nadawcy i usunięcie jej z komputera.

 W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):
 Hi,

 I dont know if this is the right forum but I hope someone could help 
 anyway. I want to subtract one day from the actual date with one 
 USS unix command.

 The actual date I get via date +%Y%m%d (for example 20130314), but 
 date +%Y%m%d-1 or ...yesterday don’t work. I have tried 
 everything without success. Does anybody have a tip for me? It must 
 be achieved within one command not more.

 Thx
 Uwe





-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Ed Finnell

Yup, think Darren even posted it(after we came back up). Also had a Gray  
rat snake event trying to get to the squirrels. Can't complain too much. The  
last one finally pushed the funding for full UPS backup to the top of the  
queue.
Where it had been for 19 years!
 
 
In a message dated 3/14/2013 8:15:15 A.M. Central Daylight Time,  
darth.kel...@assurant.com writes:

we had a  squirrel event -   one of the crafty 
little devils actually  managed to crawl into a power  transformer

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

Re: DS6800 problem (?)


On 03/14/2013 10:36 AM, Miklos Szigetvari wrote:

Hi

In some previous message I have described that , we are moving now 
from the zDASD storage system to DS6800.
We have a relative large number of volumes (140) , so we decided to 
move via DFSDD COPY
all the volumes to the proper new addresses. It worked for every 
volume, except the z/OS 1.13 system volumes (Z1DT11 and Z1DT12), 
worked also for the z/OS 1.12 system volumes
We got output track format errors, and nobody can say the reason till 
now:
- if I change the output (target) the error moves to the new volume, 
but the message complains about the output volume

- if I COPY logically by dataset , I got errors for
  sys1.linklib
  cee.sceerun
  sys1.shasmig
  csf.scsfmod0
As last attempt I copied again this datasets by IEBCOPY, and try to 
IPL, and the new system is working

(or at last I think so) .

I lost my confidence on me , DS6800  zDASD and the IBM support , but 
maybe somebody have seen something like this.


I have never used zDASD, but the Internet descriptions of zDASD sounds 
like your data integrity would be totally dependent on the integrity of 
the Open Systems Disks used for the physical storage. Perhaps you 
actually have corrupted tracks in the problem datasets. It's possible 
that zDASD might have some different exposures for strangeness if 
writes are in flight at the time of a z/OS abend or power failure.  Back 
in the days of real 3990's and non-emulated DASD, after some crashes 
it was not uncommon to get an unreadable track when in-flight data 
failed to get properly written.  Or you might even be seeing some 
failure in the underlying physical storage used by zDASD if that storage 
was not configured as RAID5 or mirrored storage.


If IEBCOPY appears to work but other forms of copy do not, that almost 
suggests the libraries in question might have corrupted tracks but the 
corrupted tracks might not be part of any active member in the library.  
If the track is corrupted in some way that the track read succeeds 
without error but the count, key, or data fields are bad, DFDSS might 
not check for all possibilities, especially if with IBM DASD such a 
failure would have been detected at the I/O or DASD hardware level and 
never make it to DFDSS. Because of the internal error detection and 
error correction in IBM DASD subsystems, I have never seen an undetected 
read failure on IBM DASD, but perhaps that can happen with some zDASD 
configurations. If an impossible track data inconsistency was not seen 
until the attempt to write the track on the target drive failed, that 
might explain why the failure seems to point to the target drive even 
though the failure seems to be independent of the target drive chosen.


Since IEBCOPY processes the dataset by blocks and can re-arrange data 
across track boundaries, if zDASD has any possibility of undetected read 
failures, then there is also a possibility that if IEBCOPY were somehow 
fed a bad block from an undetected read failure it might also be able to 
store a corrupted block on the target successfully where a track image 
copy would fail.  If that scenario could happen, you couldn't rule out 
the possibility of having some corrupted members in the copied dataset.  
If any problems are in members that are seldom used, it might take a 
long time for it to produce a failure on the copied system.  If I had 
any independent backups of those datasets, I would be strongly tempted 
to make some restored copies under another name and see if there is any 
way to prove there aren't any unexplained inconsistencies.


Perhaps someone else will have better ideas on ways to validate the 
datasets in question.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: AW: USS date command, subtract one day

2013-03-14 Thread zMan

On Thu, Mar 14, 2013 at 1:04 PM, Uwe Oswald
uwe.osw...@zit-consulting.comwrote:

 Thank you for all your hints and tips but I need just one command without
 an additional script or similar since I need this for different customers.


I'd never tell someone You don't want to do it that way, do it THIS way,
but I don't understand how a script is different from one command?
-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: AW: AW: USS date command, subtract one day

Is there support for man date under z/OS UNIX? Paul indicated that
the double-hypen parms are non-POSIX and therefore not supported under
z/OS; but man date under Fedora also shows -d as an alternative for
--date=, so for example under Fedora it's also possible to use

date +%Y%m%d -d1 day ago
or
date +%Y%m%d -dyesterday
Maybe that form is supported?

P.S. I interpreted your original post as saying you had tried
date +%Y%m%d yesterday
where apparently you had intended to imply
date +%Y%m%d --date=yesterday
JC Ewing

On 03/14/2013 12:04 PM, Uwe Oswald wrote:

Thank you for all your hints and tips but I need just one command without an additional script or
similar since I need this for different customers. All that I want is just create a file with some
content and give that file yesterdays date. In each other Unix version not a problem at
all, but USS seems to be different. The date...--date syntax is invalid in USS. As I
said in my first post, I tried nearly everything I believe.

HELP :-)

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Joel C. Ewing
Gesendet: Donnerstag, 14. März 2013 17:15
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: AW: USS date command, subtract one day

Correct. So if you really want something that will work for all dates,
including first of month, first of month in March on leap and nonleap year,
first of year, etc. you need something else.

I'm not enough of a UNIX authority to know if this is standard for all implementations of the UNIX date command and
can't test in z/OS environment, but a search for relative dates and Linux found a
--date parameter for the date command. At least on Fedora Linux the date command already
appears to have relative date calculation built in.
Currently (2013-03-14) on Fedora the command date --date=14 days ago
returns Thu Feb 28 09:52:21 CST 2013
and
date --date=379 days ago
returns Wed Feb 29 09:57:26 CST 2012

If date under z/OZ UNIX supports the same parameters, then date +%Y%m%d --date=1
day ago
which today on Fedora returns 20130313 may be the form you need.

JC Ewing

On 03/14/2013 08:32 AM, Uwe Oswald wrote:

Thx perfect, thats exactly what I need. But I'm afraid this doesn’t work for
the first of a month for example 20130401 will then be 20130400 or I'm wrong?

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
Im Auftrag von Rafal Hanzel ZETO Katowice
Gesendet: Donnerstag, 14. März 2013 13:23
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: USS date command, subtract one day

Maybe something like that, will help you:
echo `date +%Y%m%d` - 1 | bc

---
Pozdrawiam/Best regards,

Rafal Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych Tel. +48 32
3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl Tel. kom. +48
501677656 Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z
o.o.
40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy
Krajowego Rejestru Sądowego, KRS 051477 Kapitał zakładowy: 264500
zł NIP 634-013-11-06 http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna trafić
bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, rozpowszechnianie,
bądź kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej
informacji prosimy o poinformowanie nadawcy i usunięcie jej z komputera.

W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):

Hi,

I dont know if this is the right forum but I hope someone could help
anyway. I want to subtract one day from the actual date with one
USS unix command.

The actual date I get via date +%Y%m%d (for example 20130314), but
date +%Y%m%d-1 or ...yesterday don’t work. I have tried
everything without success. Does anybody have a tip for me? It must
be achieved within one command not more.

Thx
Uwe

--
Joel C. Ewing,Bentonville, AR jcew...@acm.org

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

z890 into the Plex (Compliance w/z10 CF and z9 and up members?)

2013-03-14 Thread Patrick Falcone

Argh...I can't find this. I'm sure it's out there, somewhere. If someone has a 
link I'd be grateful.
 
 
 
Is there a hardware compliance restriction with bringing a z890 into a plex 
w/z10 CF @ CF16 with z9 and up members?
 
 
 
 
 

TIA...




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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Ed Gould


Gil,

Just remember in the olden days that bytes cost money (either in  
storage or in memory).
I actually had to work on a software set of programs (system) that  
stripped the sign off of all dates and money they were assumed to be  
positive).


Ed

On Mar 14, 2013, at 9:25 AM, Paul Gilmartin wrote:


On Wed, 13 Mar 2013 09:47:06 -0400, Gabe Goldberg wrote:

I'm writing about Back to the Future for mainframers -- historic  
(but
sometimes forgotten) mainframe lessons needed by and best-to-be  
learned

by new mainframers (but everyone, really).


Don't underestimate the future.

The Y2K crisis might have been mitigated if more designers
had said, Hey, pretty soon we're going to need 4-digit years.
Let's provide them now.  I made such a suggestion for a product
we were working on in 1987.  It was brushed off as premature.

And much of the anguish of 24-bit to 31-bit address conversion
might have been avoided if designers had thought to reserve
the top 8 bits of addresses instead of using them for flags.
Instead, many OS interfaces remain 24-bit constrained.

How many programmers are still using 31-bit branch instructions
rather than 64 because z/OS doesn't support execution above
the bar?  This year.

-- gil

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


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

Re: z890 into the Plex (Compliance w/z10 CF and z9 and up members?)

2013-03-14 Thread Jerry Whitteridge

I have a z890 in a plex with z10 and z9 - forget off hand my CFCC code
level.

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Patrick Falcone
Sent: Thursday, March 14, 2013 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z890 into the Plex (Compliance w/z10 CF and z9 and up members?)

Argh...I can't find this. I'm sure it's out there, somewhere. If someone
has a link I'd be grateful.
 
 
 
Is there a hardware compliance restriction with bringing a z890 into a
plex w/z10 CF @ CF16 with z9 and up members?
 
 
 
 
 

TIA...




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



Email Firewall made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

Re: AW: AW: USS date command, subtract one day

I finally RTFM (z/OS UNIX System Services Command Reference) which 
documents that at least up to z/OS 1.13 the only documented options for 
date  are -c -u and  +format, and -c and -u  are synonyms, 
versus 7 distinct options for the date command, plus -- counterpart 
options, in Fedora.  Unless there are undocumented features, this would 
appear to be another of those many cases where the tools under z/OS UNIX 
simply don't have all the features one finds in non-z/OS UNIX 
environments.  I knew there were good reasons I preferred writing REXX 
rather than shell scripts on z/OS.


If I weren't retired, at a minimum I'd put date option -d 
implementation in as a SHARE requirement.  You really don't want people 
doing kludgey circumventions in scripts to perform their own relative 
date adjustments. Y2K re-mediation demonstrated there are just too many 
ways to do it incorrectly.

JC Ewing

On 03/14/2013 01:46 PM, Joel C. Ewing wrote:
Is there support for man date under z/OS UNIX?  Paul indicated that 
the double-hypen parms are non-POSIX and therefore not supported under 
z/OS; but man date under Fedora also shows -d as an alternative 
for --date=, so for example under Fedora it's also possible to use

date +%Y%m%d  -d1 day ago
 or
date +%Y%m%d  -dyesterday
Maybe that form is supported?

P.S.  I interpreted your original post as saying you had tried
date +%Y%m%d  yesterday
where apparently you had intended to imply
date +%Y%m%d --date=yesterday
JC Ewing

On 03/14/2013 12:04 PM, Uwe Oswald wrote:
Thank you for all your hints and tips but I need just one command 
without an additional script or similar since I need this for 
different customers. All that I want is just create a file with some 
content and give that file yesterdays date. In each other Unix 
version not a problem at all, but USS seems to be different. The 
date...--date syntax is invalid in USS. As I said in my first post, 
I tried nearly everything I believe.


HELP :-)

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
Im Auftrag von Joel C. Ewing

Gesendet: Donnerstag, 14. März 2013 17:15
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: AW: USS date command, subtract one day

Correct.  So if you really want something that will work for all 
dates, including first of month, first of month in March on leap and 
nonleap year, first of year, etc.  you need something else.


I'm not enough of a UNIX authority to know if this is standard for 
all implementations of the UNIX date command and can't test in z/OS 
environment, but a search for relative dates and Linux found a 
--date parameter for the date command.  At least on Fedora Linux 
the date command already appears to have relative date calculation 
built in.

Currently (2013-03-14) on Fedora the command date  --date=14 days ago
   returns Thu Feb 28 09:52:21 CST 2013
and
date --date=379 days ago
returns Wed Feb 29 09:57:26 CST 2012

If date under z/OZ UNIX supports the same parameters, then date 
+%Y%m%d --date=1 day ago

which today on Fedora returns 20130313  may be the form you need.

 JC Ewing

On 03/14/2013 08:32 AM, Uwe Oswald wrote:
Thx perfect, thats exactly what I need. But I'm afraid this doesn’t 
work for the first of a month for example 20130401 will then be 
20130400 or I'm wrong?


-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
Im Auftrag von Rafal Hanzel ZETO Katowice
Gesendet: Donnerstag, 14. März 2013 13:23
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: USS date command, subtract one day

Maybe something like that, will help you:
echo `date +%Y%m%d` - 1 | bc

---
Pozdrawiam/Best regards,

Rafal Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych 
Tel. +48 32 3589246, Fax +48 32 3589277, email: 
hanz...@zetokatowice.pl Tel. kom. +48 501677656 Zakład 
Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z o.o.

40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy
Krajowego Rejestru Sądowego, KRS 051477 Kapitał zakładowy: 264500
zł NIP 634-013-11-06 http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna 
trafić bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, 
rozpowszechnianie, bądź kopiowanie jest zabronione. W przypadku 
omyłkowego otrzymania niniejszej informacji prosimy o poinformowanie 
nadawcy i usunięcie jej z komputera.


W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):

Hi,

I dont know if this is the right forum but I hope someone could help
anyway. I want to subtract one day from the actual date with one
USS unix command.

The actual date I get via date +%Y%m%d (for example 20130314), but
date +%Y%m%d-1 or ...yesterday don’t work. I have tried
everything without success. Does anybody have a tip for me? It must

Re: USS date command, subtract one day

2013-03-14 Thread Rafal Hanzel ZETO Katowice


Yes, You're right.

In this situation you need pretty simple script or something like this: 
long single command tested on my linux


if [ `date +%d` -ne 01 ]; then echo `date +%Y%m%d` - 1 | bc; elif [ 
`date +%m` -ne 01 ]; then echo $(echo $(date +%Y) $(echo $(date +%m) ) 
$(cal $(echo $(date +%m) -1 | bc)  $(date +%Y) | tr -d '\n' | tr -d ' 
' | tail -c 2) | tr -d ' ') - 100 | bc; else echo $(echo $(date +%Y) 12  
$(cal 12  $(echo $(date +%Y) -1 |bc  ) | tr -d '\n' | tr -d ' ' | tail 
-c 2) | tr -d ' ') - 1 | bc; fi



I can't try this in USS now, but I hope it works

---
Pozdrawiam/Best regards,

Rafal Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych
Tel. +48 32 3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl
Tel. kom. +48 501677656
Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z o.o.
40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy 
Krajowego Rejestru Sądowego, KRS 051477

Kapitał zakładowy: 264500 zł
NIP 634-013-11-06
http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna trafić 
bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, 
rozpowszechnianie, bądź kopiowanie jest zabronione. W przypadku 
omyłkowego otrzymania niniejszej informacji prosimy o poinformowanie 
nadawcy i usunięcie jej z komputera.


W dniu 14.03.2013 14:32, Uwe Oswald napisał(a):

Thx perfect, thats exactly what I need. But I'm afraid this doesn’t
work for the first of a month for example 20130401 will then be
20130400 or I'm wrong?

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
Im Auftrag von Rafal Hanzel ZETO Katowice
Gesendet: Donnerstag, 14. März 2013 13:23
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: USS date command, subtract one day

Maybe something like that, will help you:
echo `date +%Y%m%d` - 1 | bc

---
Pozdrawiam/Best regards,

Rafal Hanzel




W dniu 14.03.2013 12:54, Uwe Oswald napisał(a):

Hi,

I dont know if this is the right forum but I hope someone could help
anyway. I want to subtract one day from the actual date with one 
USS

unix command.

The actual date I get via date +%Y%m%d (for example 20130314), but
date +%Y%m%d-1 or ...yesterday don’t work. I have tried 
everything

without success. Does anybody have a tip for me? It must be achieved
within one command not more.

Thx
Uwe



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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Ed Gould


Joel:

I worked a DC in downtown Chicago in the 70's and 80's and we were  
supposedly 24X7 shop. We had power problems+ and we could not afford  
a UPS in fact at the time we would have needed a HUGE UPS to get us  
through power outages. I guess these were intermittent rather than  
lengthy. Our biggest thorn in out side was a solid state paging  
device as when it lost power you had to re-init it and re define the  
PLPA page data set. Vsam at the time was a PITA as you couldn't  
delete the pagespace unless it was already there so we ended up with  
5 or 10 page data sets cataloged on the volume that was empty. (and  
no noscratch was ignored most of the time).
Since we only used it for PLPA we had to IPL delete/define PLPA and  
update parmlib and then re ipl with CLPA this became a weekly  
occurrence until the big boss got tired of the extra outages and got  
rid of solid state device (sorry do not remember the vendor).


I think we were all happy to see the monster go.

Ed

On Mar 14, 2013, at 9:55 AM, Joel C. Ewing wrote:

Ah yes, the not-so-good pre-UPS days when even a  fraction-of-a- 
second power interruption could take down an entire DP center.  I  
recall the utility workers describing at least one roasted squirrel  
event and even one roasted large-bird event that affected our  
transformer's HV feed, although more of the problems were weather- 
related or human-related.  One amazing thing was that in the 1980's  
our utility power was much more stable, rarely above three or four  
disruptive glitches a year.  By 2000, noticeable utility power  
glitches which reached our site had risen to several a month and  
often were uncorrelated with local weather, but fortunately by then  
the center was UPS-protected.


UPS-protecting all mainframe system hardware did significantly  
reduce number of hardware failures we experienced.  Even if you  
have an environment where an abnormal shutdown and restart of the  
DP center is is tolerable, an 8-hour or longer down time waiting on  
parts might not be.  These days, running a mainframe system without  
adequate UPS protection should be considered false economy.

Joel C Ewing

On 03/14/2013 07:50 AM, John McKown wrote:
I think that squirrel event refers to a number of times that the  
IBM-MAIN

listserv went down due to a suicidal squirrel throwing itself onto a
transformer, causing a massive power surge, which cause a  
catastrophic

event in the computer center.


On Thu, Mar 14, 2013 at 7:45 AM, zMan zedgarhoo...@gmail.com wrote:

On Thu, Mar 14, 2013 at 12:05 AM, Ed Finnell efinnel...@aol.com  
wrote:


Bon jour! We actually prosecuted a group of students who had  
managed to
overlay the weekly backup tapes with garbage and hoped for a  
'squirrel

event'.
  They came perilously close...

I don't mind looking dumb: what's a squirrel event? Sounds like  
something

Macy's would advertise...
--
zMan -- I've got a mainframe and I'm not afraid to use it






--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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


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

Re: USS date command, subtract one day

2013-03-14 Thread Kirk Wolf

See the little c program below that displays dates after applying your
favorite offset.
mktime() and strftime() do all of the heavy lifting.

example:

* dateoff -d -1 -h -1 %Y/%m/%d %H:%M:%S
   *
2013/03/13 14:20:33

 (display the local time less a day and an hour)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


#define _LARGE_TIME_API
#define _XOPEN_SOURCE_EXTENDED 1
#include stdlib.h
#include stdio.h
#include time.h

/*
   dateoff - display current date/time after applying optional offsets

   to build:  cc -o dateoff dateoff.c

   Kirk Wolf - 2013/03/14
   License:  public domain
*/
void usage() {
   fprintf(stderr, usage: dateoff [-y|m|d|h|n|s] [-]offset] format\n);
}
#define RC_SYNTAX_ERROR 1
#define RC_SYSCALL_ERROR 2

int main(int argc, char**argv)  {
   int days_off = 0;
   int years_off = 0;
   int months_off = 0;
   int hours_off = 0;
   int minutes_off = 0;
   int seconds_off = 0;

   char* format;
   time64_t timeval;
   struct tm* bdt;
   char formatted[100];
   extern char* optarg;
   int opt;

   if (argc  2) {
  usage();
  return RC_SYNTAX_ERROR;
   }

   format = argv[--argc];  /* last argument is a strftime() format string */
   while ((opt = getopt(argc, argv, :y:m:d:h:n:s:)) != -1) {
  switch(opt) {
 case 'y':
years_off = atoi(optarg);
break;
 case 'm':
months_off = atoi(optarg);
break;
 case 'd':
days_off = atoi(optarg);
break;
 case 'h':
hours_off = atoi(optarg);
break;
 case 'n':
minutes_off = atoi(optarg);
break;
 case 's':
seconds_off = atoi(optarg);
break;
 case ':':
fprintf(stderr, Missing argument for option: %c\n, optopt);
usage();
exit(RC_SYNTAX_ERROR);
 default:
fprintf(stderr, Unknown option: %c\n, optopt);
usage();
exit(RC_SYNTAX_ERROR);
  }
   }

   if (time64(timeval)  0) {
  perror(time64);
  return RC_SYSCALL_ERROR;
   }
   if (!(bdt = localtime64(timeval))) {
  perror(localtime64);
  return RC_SYSCALL_ERROR;
   }
   bdt-tm_mday += days_off;
   bdt-tm_year += years_off;
   bdt-tm_mon  += months_off;
   bdt-tm_hour += hours_off;
   bdt-tm_min  += minutes_off;
   bdt-tm_sec  += seconds_off;

   timeval = mktime64(bdt);
   if (timeval  0) {
  perror(mktime64);
  return RC_SYSCALL_ERROR;
   }
   if (!strftime(formatted, sizeof(formatted)-1, format, bdt) ) {
  perror(strftime);
  return RC_SYSCALL_ERROR;
   }
   printf(%s\n,formatted);
   return 0;
}

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Jim Mulder

 How many programmers are still using 31-bit branch instructions
 rather than 64 because z/OS doesn't support execution above
 the bar?  This year.

  z/OS 1.13 does support execution above the bar
(with significant restrictions on how to get code
loaded there, and very few services which document 
support for being invoked from there). 


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Jim Mulder

 Indeed -- look at CCWs: if they'd put the flags in the reserved byte
 instead, we'd only have needed one format! (Well, until there's 64-bit 
I/O,
 anyway).
 
  64-bit I/O has been supported since the beginning of z/Architecture
via 64-bit IDAWs, and subsequently via MIDAWs. 

 Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Query for Destination z article -- mainframes back to the future

On Thu, 14 Mar 2013 16:43:31 -0400, Jim Mulder d10j...@us.ibm.com wrote:

  z/OS 1.13 does support execution above the bar
(with significant restrictions on how to get code
loaded there, and very few services which document
support for being invoked from there).
 
Why does that use of support remind me of the Sword of Damocles?

-- gil

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Phil Smith III

Ed Gould wrote:

Just remember in the olden days that bytes cost money (either in storage or
in memory).

I actually had to work on a software set of programs (system) that stripped
the sign off of all dates and money they were assumed to be positive).

 

Right, S/360 memory was a buck a byte (at some point in its life). Much
bigger bucks than today, too! So that led to the mode of thinking that said
We can use 2-byte years (and even single-byte, in some cases--yuck). I
expect that every Real Programmer who ever coded such a thing felt a twinge,
however; most probably said, I'll be retired by then.

 

I was somewhat surprised that it took so long for Y2K to rise to the top,
with 30-year mortgages and such forward-looking things being far from
uncommon. But I guess those systems all got fixed one at a time as their
windows passed 2000, without enough awareness that anyone said Hey, we need
to fix this globally, now that storage (both memory and DASD) is cheap!

 

Another argument suggests that leaving the problem to the end was good
management: as the crisis neared, tools and skills were developed, plus
some applications had gone by the wayside that might have been fixed for
naught. So maybe it wasn't ignorance or willful neglect, but rather
deliberate. 

 

(Of course, how many companies have management that smart? [Oops, did I type
that out loud?])

-- 

...phsiii

 


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

Re: Query for Destination z article -- mainframes back to the future

edgould1...@comcast.net (Ed Gould) writes:
 I worked a DC in downtown Chicago in the 70's and 80's and we were
 supposedly 24X7 shop. We had power problems+ and we could not afford a
 UPS in fact at the time we would have needed a HUGE UPS to get us
 through power outages. I guess these were intermittent rather than
 lengthy. Our biggest thorn in out side was a solid state paging device
 as when it lost power you had to re-init it and re define the PLPA
 page data set. Vsam at the time was a PITA as you couldn't delete the
 pagespace unless it was already there so we ended up with 5 or 10 page
 data sets cataloged on the volume that was empty. (and no noscratch
 was ignored most of the time).
 Since we only used it for PLPA we had to IPL delete/define PLPA and
 update parmlib and then re ipl with CLPA this became a weekly
 occurrence until the big boss got tired of the extra outages and got
 rid of solid state device (sorry do not remember the vendor).

re:
http://www.garlic.com/~lynn/2013c.html#90 Query for Destination z article -- 
mainframes back to the future

recent post about providing online 7x24 service starting in the 60s,
some of the hacks that were done to get the cpu meter to stop when
activity was otherwise idle (back in the days when mainframes were
rented and monthly lease was based on cpu meter reading):
http://www.garlic.com/~lynn/2013c.html#91 What Makes an Architecture Bizarre?

recent post about trying to get mutliple exposure support (multiple
device addresses per real device ... aka like on 2305 fixed-head disk
that came with 8 logical device addresses) for 3350 with fixed-head
option ... so I could overlap data transfer from the fixed head area
while disk arm was moving for non-fixed head area
http://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What 
Makes an Architecture Bizarre?

I got shotdown by Jupiter project in POK ... which was planning on
shipping a solid state device ... and thot that I might be
competition. They were never able to announce ... since customers
started buying all the memory chips that IBM could turn out as processor
memory (and memory chips in processors had higher profit than same
memory chips in solid state device).

Internally they then started providing IBM 1655 solid state paging
devices (initially 2305 simulation) ... 1655s were really from another
vendor ... that had developed a way to use memory chips that had failed
standard processor memory tests ... in solid state paging devices. Power
outages were no problem since had procedure that would come up and
automatigically reclaim these devices w/o requiring manual intervention
or re-ipl.

misc. past posts mentioning the (internal) 1655:
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About 
DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs
http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events?
http://www.garlic.com/~lynn/2007u.html#4 Remembering the CDC 6600
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2009m.html#54 August 7, 1944: today is the 65th 
Anniversary of the Birth of   the  Computer
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#55 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#82 [OT] What is the protocal for GMT 
offset in SMTP (e-mail) header time-stamp?
http://www.garlic.com/~lynn/2010h.html#78 Software that breaks

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Ed Jaffe


On 3/14/2013 1:47 PM, Jim Mulder wrote:


   64-bit I/O has been supported since the beginning of z/Architecture
via 64-bit IDAWs, and subsequently via MIDAWs.


And, now via TIDAWs!

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

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Jim Mulder

 64-bit I/O has been supported since the beginning of z/Architecture
  via 64-bit IDAWs, and subsequently via MIDAWs.
 
 And, now via TIDAWs!

  If/when I get around to exploiting zHPF in standalone dump,
I will be quicker to remember TIDAWs. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread John Gilmore

Jim,

You will need to remember FCXs too!

John Gilmore, Ashland, MA 01721 - USA

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

Re: Query for Destination z article -- mainframes back to the future

2013-03-14 Thread Martin Packer

Interesting you mention Jupiter Project...

... In the late 1980's as a young SE I supported one of the Jupiter 
Council customers in their roll out of what something called Jupiter 
turned into: DFSMS.

I'm wondering if your mentioned SSD was another part of a grander plan - 
incorporating storage management and hardware.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Anne  Lynn Wheeler l...@garlic.com
To: IBM-MAIN@listserv.ua.edu, 
Date:   03/14/2013 08:58 PM
Subject:Re: Query for Destination z article -- mainframes back to 
the future
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu



edgould1...@comcast.net (Ed Gould) writes:
 I worked a DC in downtown Chicago in the 70's and 80's and we were
 supposedly 24X7 shop. We had power problems+ and we could not afford a
 UPS in fact at the time we would have needed a HUGE UPS to get us
 through power outages. I guess these were intermittent rather than
 lengthy. Our biggest thorn in out side was a solid state paging device
 as when it lost power you had to re-init it and re define the PLPA
 page data set. Vsam at the time was a PITA as you couldn't delete the
 pagespace unless it was already there so we ended up with 5 or 10 page
 data sets cataloged on the volume that was empty. (and no noscratch
 was ignored most of the time).
 Since we only used it for PLPA we had to IPL delete/define PLPA and
 update parmlib and then re ipl with CLPA this became a weekly
 occurrence until the big boss got tired of the extra outages and got
 rid of solid state device (sorry do not remember the vendor).

re:
http://www.garlic.com/~lynn/2013c.html#90 Query for Destination z article 
-- mainframes back to the future

recent post about providing online 7x24 service starting in the 60s,
some of the hacks that were done to get the cpu meter to stop when
activity was otherwise idle (back in the days when mainframes were
rented and monthly lease was based on cpu meter reading):
http://www.garlic.com/~lynn/2013c.html#91 What Makes an Architecture 
Bizarre?

recent post about trying to get mutliple exposure support (multiple
device addresses per real device ... aka like on 2305 fixed-head disk
that came with 8 logical device addresses) for 3350 with fixed-head
option ... so I could overlap data transfer from the fixed head area
while disk arm was moving for non-fixed head area
http://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was 
What Makes an Architecture Bizarre?

I got shotdown by Jupiter project in POK ... which was planning on
shipping a solid state device ... and thot that I might be
competition. They were never able to announce ... since customers
started buying all the memory chips that IBM could turn out as processor
memory (and memory chips in processors had higher profit than same
memory chips in solid state device).

Internally they then started providing IBM 1655 solid state paging
devices (initially 2305 simulation) ... 1655s were really from another
vendor ... that had developed a way to use memory chips that had failed
standard processor memory tests ... in solid state paging devices. Power
outages were no problem since had procedure that would come up and
automatigically reclaim these devices w/o requiring manual intervention
or re-ipl.

misc. past posts mentioning the (internal) 1655:
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification 
please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use 
instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was 
Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was 
Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is 
an MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something 
About DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse 
than disks ?

Re: IBM Mainframe (1980's) on You tube

arno...@us.ibm.com (Todd Arnold) writes:
IBM had three channel-attached crypto units for the mainframes.

1977 – IBM 3845 DES encryption unit

1979 – IBM 3848 DES encryption unit - faster than the 3845, and added
Triple-DES
(yes, IBM already had Triple-DES in its products in 1979!)

1989 – IBM Transaction Security System (TSS) which included the 4753.
The 4753 was the first product to offer the CCA architecture, and it
is the ancestor of all of the other crypto processors such as the
Crypto Express cards.

in part to be used with IBM ATM machines
http://en.wikipedia.org/wiki/IBM_3624

in conjunction with PIN processing and authorizing financial
transactions
http://en.wikipedia.org/wiki/Personal_identification_number

3624 pin processing had a weakness that could be exploited by an
attacker if they had access to the banks computers

discussed in more detail here (also referencing ibm 4758)
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-560.pdf

disclaimer ... even tho I was in research at the time, I also had
offices and labs in the Los Gatos lab ... mentioned in the 3624 wiki
reference ... which also references one of my old postings from 2004.

recent ibm reference
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.csfb300/pinkeys.htm

in the mid-80s, I was involved in doing another kind of twist on DES
... and the product crypto group (responsible for those IBM mainframe
DES units) complained that I had seriously weakened DES ... however,
after spending 3months in debate ... finally convinced them it was
significantly stronger than standard DES (instead of weaker) ... it was
hollow victory ... finding out that (at the time) there were 3-kinds of
crypto: 1) the kind they don't care about, 2) the kind you can't do, 3)
the kind you can only do for them (aka I was told I could build as many
boards as I wanted ... but there was only one customer that they could
be sold to).

I was doing this HSDT effort ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt

and spending armleg on T1 full-duplex DES crypto units (about
300kbyte/sec aggregate). I wanted a board that could do sustained
channel speed DES crypto (ten times faster), being able to even change
key on every packet (traditional DES chips tended to have high latency
on key change) and cost less than $100.

old email mentioning that software standard DES ran at 150kbytes/sec on
3081 processor ... aka both 3081k processors would be required to
support full-duplex T1 (150kbytes/sec concurrent in each direction)
http://www.garlic.com/~lynn/2006n.html#email841115

--
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: DS6800 problem (?)

2013-03-14 Thread Miklos Szigetvari


On 14.03.2013 19:21, Joel C. Ewing wrote:

On 03/14/2013 10:36 AM, Miklos Szigetvari wrote:

Hi

In some previous message I have described that , we are moving now 
from the zDASD storage system to DS6800.
We have a relative large number of volumes (140) , so we decided to 
move via DFSDD COPY
all the volumes to the proper new addresses. It worked for every 
volume, except the z/OS 1.13 system volumes (Z1DT11 and Z1DT12), 
worked also for the z/OS 1.12 system volumes
We got output track format errors, and nobody can say the reason till 
now:
- if I change the output (target) the error moves to the new volume, 
but the message complains about the output volume

- if I COPY logically by dataset , I got errors for
  sys1.linklib
  cee.sceerun
  sys1.shasmig
  csf.scsfmod0
As last attempt I copied again this datasets by IEBCOPY, and try to 
IPL, and the new system is working

(or at last I think so) .

I lost my confidence on me , DS6800  zDASD and the IBM support , but 
maybe somebody have seen something like this.


I have never used zDASD, but the Internet descriptions of zDASD sounds 
like your data integrity would be totally dependent on the integrity 
of the Open Systems Disks used for the physical storage. Perhaps you 
actually have corrupted tracks in the problem datasets. It's possible 
that zDASD might have some different exposures for strangeness if 
writes are in flight at the time of a z/OS abend or power failure.  
Back in the days of real 3990's and non-emulated DASD, after some 
crashes it was not uncommon to get an unreadable track when in-flight 
data failed to get properly written.  Or you might even be seeing some 
failure in the underlying physical storage used by zDASD if that 
storage was not configured as RAID5 or mirrored storage.


If IEBCOPY appears to work but other forms of copy do not, that almost 
suggests the libraries in question might have corrupted tracks but the 
corrupted tracks might not be part of any active member in the 
library.  If the track is corrupted in some way that the track read 
succeeds without error but the count, key, or data fields are bad, 
DFDSS might not check for all possibilities, especially if with IBM 
DASD such a failure would have been detected at the I/O or DASD 
hardware level and never make it to DFDSS. Because of the internal 
error detection and error correction in IBM DASD subsystems, I have 
never seen an undetected read failure on IBM DASD, but perhaps that 
can happen with some zDASD configurations. If an impossible track 
data inconsistency was not seen until the attempt to write the track 
on the target drive failed, that might explain why the failure seems 
to point to the target drive even though the failure seems to be 
independent of the target drive chosen.


Since IEBCOPY processes the dataset by blocks and can re-arrange data 
across track boundaries, if zDASD has any possibility of undetected 
read failures, then there is also a possibility that if IEBCOPY were 
somehow fed a bad block from an undetected read failure it might also 
be able to store a corrupted block on the target successfully where a 
track image copy would fail.  If that scenario could happen, you 
couldn't rule out the possibility of having some corrupted members in 
the copied dataset.  If any problems are in members that are seldom 
used, it might take a long time for it to produce a failure on the 
copied system.  If I had any independent backups of those datasets, I 
would be strongly tempted to make some restored copies under another 
name and see if there is any way to prove there aren't any 
unexplained inconsistencies.


Perhaps someone else will have better ideas on ways to validate the 
datasets in question.




Thank you very much, it is a very good feeling , that some of the list 
members take the time, and think over my problem ad give very useful 
advices.
With the inactive tracks, it would be a very good explanation, and 
would suggest that the error is on the old zDASD side and the new 
DS6800 is working properly. I'm now mixed up a little, but as far as I 
remember, the first thing we tested was a DFDSS COPY , the same 
volumes,  from  zDASD to zDASD and it worked. I will  check this again .

Thank you again .

--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.

Re: DS6800 problem (?)

2013-03-14 Thread Mike Schwab

On Thu, Mar 14, 2013 at 6:39 PM, Miklos Szigetvari
miklos.szigetv...@isis-papyrus.com wrote:

 Thank you very much, it is a very good feeling , that some of the list
 members take the time, and think over my problem ad give very useful
 advices.
 With the inactive tracks, it would be a very good explanation, and would
 suggest that the error is on the old zDASD side and the new DS6800 is
 working properly. I'm now mixed up a little, but as far as I remember, the
 first thing we tested was a DFDSS COPY , the same volumes,  from  zDASD to
 zDASD and it worked. I will  check this again .
 Thank you again .

 --
 Kind regards, / Mit freundlichen Grüßen

One thing that TDMF complained about was wrong cylinder numbers in the
CCHHR header.  This was from volumes that VM had created minidisks on,
using the cylinder number within the mini-disk, then reused for z/OS
and some tracks were never written to and still had the VM CCHHR
records on that track.


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

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

Re: Query for Destination z article -- mainframes back to the future