RLS SMSVSAM and PLEX wide IPL

[Lizette Koehler]

We upgraded the CPU this weekend, and SMSVSAM would not come up.

We got the IGW611a and IGW609A messages

After a bit of investigation, I did the V SMS,SHCDS(xxx),NEW putting back
the Prim/Sec/Spare files.

There were no issues with the definition and the only changes were
un-cabling/re-cabling the DASD from the old CPU to the new CPU and IPLing
with new CF datasets.

I am curious if when there is a PLEX wide IPL (All Lpars down at the same
time then IPL one at a time up) if there is some way to prevent the loss of
the SHCDS data set names?

Any thoughts?

My hunts through the manuals and internet is not providing much detail on
PLEX wide IPLs and SHCDS datasets

Thanks.

Lizette Koehler

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

Re: RLS SMSVSAM and PLEX wide IPL

[Vernooij, CP - SPLXM]

What do you mean with 'new CF datasets'? New, empty Couple Datasets?
That could explain why information is lost. CDSs can be migrated, while
retaining the contents.

A Sysplex wide IPL should not loose data, it can be beneficial to solve
some problems, that cannot be solved with individual IPLs of the Sysplex
LPARs.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Sunday, March 03, 2013 09:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RLS SMSVSAM and PLEX wide IPL

We upgraded the CPU this weekend, and SMSVSAM would not come up.

We got the IGW611a and IGW609A messages

After a bit of investigation, I did the V SMS,SHCDS(xxx),NEW putting
back the Prim/Sec/Spare files.

There were no issues with the definition and the only changes were
un-cabling/re-cabling the DASD from the old CPU to the new CPU and
IPLing with new CF datasets.

I am curious if when there is a PLEX wide IPL (All Lpars down at the
same time then IPL one at a time up) if there is some way to prevent the
loss of the SHCDS data set names?

Any thoughts?

My hunts through the manuals and internet is not providing much detail
on PLEX wide IPLs and SHCDS datasets

Thanks.

Lizette Koehler

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

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

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



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

Re: Paul Gilmartin

[John Gilmore]

I think that there are [at least] two usefully separated issues here.

I looked yesterday at a macro definition I wrote 16 years ago that I
still use but had not updated in the interval.  As a part of its
bullet-proofing it conditionally removes some framing single quotes
from input values in the old, long-winded way instead of using the
HLASM's comparatively new DEQUOTE bif.  I fixed it to use DEQUOTE in
three places,  and that was appropriate, but it would be unreasonable
to expect IBM to undertake to  retrofit all of its macros to use
DEQUOTE wherever it could be used to advantage.

I come now to Tony Harminc's example:


But SETRP generates a NOPR with an expression (related to the SDWA, I think)
obviously intended (and I think commented) to fail if the length is
not 0. However HLASM doesn't think the expression is a likely register
value - a legal one, certainly - but still worth a warning if you have
registers EQUated with the GR or GR32 or GR64 option.


It is very different.  Register equates are ubiquitous.  What we thus
have in this example is no or inadequate testing, and that is not
defensible.  None of us expects IBM code to be error-free.  None of us
writes such code.   We do expect that IBM code will have been tested,
in effect that such errors as we find in it will be subtle and not
crudely obvious ones; and in this expectation we are now often
disappointed.


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

Me? (was: SAVE macro, I think)

[Paul Gilmartin]

On Sun, 3 Mar 2013 08:51:34 -0500, John Gilmore wrote:
>
>...   We do expect that IBM code will have been tested,
>in effect that such errors as we find in it will be subtle and not
>crudely obvious ones; and in this expectation we are now often
>disappointed.
> 
A sort of critical mass is approaching.  Long ago, I rarely
encountered errors in IBM code.  More recently, in attempts
to distill my code down to the minimum that exposes a
defect, I often encounter an untested boundary condition,
and yet another defect.  At critical mass, this process can
be expected not to terminate.

And I have known IBM support to reply to my minimal test
case similarly to, "Why do you need this program to work?
It appears to do nothing useful."

-- gil

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

Re: Me? (was: SAVE macro, I think)

[zMan]

On Sun, Mar 3, 2013 at 9:54 AM, Paul Gilmartin  wrote:

> And I have known IBM support to reply to my minimal test
> case similarly to, "Why do you need this program to work?
> It appears to do nothing useful."
>

Seriously? At that point, I'd probably send them a 10,000-line module and
say "Here, try this..."

Sheesh. That sounds like the IBM of old, when they'd do anything to avoid
fixing bugs (I remember once saying "'ALL' means 'ALL', damnit!" to a Level
2 rep, who was arguing that the documentation didn't mean that something
applied to all cases, even though it said it did...).
-- 
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: REFRPROT History Question

[Paul Gilmartin]

On Mar 2, 2013, at 20:04, Charles Mills wrote:

> I recall distinctly the hardware having fetch protection but there being no 
> apparent OS support for it.
>  
That matches my old recollection of an Old Timer's recounting
his astonishment at having read a dump in which a Protection
Exception appeared to have been taken on a fetch instruction.

I believe (with no good evidence) that it was controlled by
a bit in the page key.  It may have been model-dependent.
A matching PSW key always allowed read-write access; a
different PSW key might have either no access or read-only
access depending on the bit's setting.

Truly the Bad Old Days, when there was no privacy enforced
between jobs.  And IBM OS technology has always trailed the
hardware technology.  To wit, nowadays, the absence in z/OS
of complete support for 64-bit virtual.  (The less said of
COBOL the better; it's not part of the OS.)

Jim Mulder's explanation is most plausible; at some point
there may have been understandable reluctance to load user
code in key 0, only partly because there would have been no
way to guarantee confidentiality of such code.

-- gil

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

Re: REFRPROT History Question

[Ted MacNEIL]

>To  wit, nowadays, the absence in z/OS
of complete support for 64-bit virtual.  (The less said of COBOL the better; 
it's not part of the OS.)

Nice blinders-on statement!
COBOL may be one of the ugliest languages around, but it's also (still, I 
believe) the most heavily used!

Why not cater to your largest user base?

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: Me? (was: SAVE macro, I think)

[Shmuel Metz (Seymour J.)]

In <0551413286133992.wa.paulgboulderaim@listserv.ua.edu>, on
03/03/2013
   at 08:54 AM, Paul Gilmartin  said:

>And I have known IBM support to reply to my minimal test case
>similarly to, "Why do you need this program to work? It appears to 
>do nothing useful."

You'll get more with a kind word and an escalation than you'll ever
get with just a kind word. (JD)

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Me? (was: SAVE macro, I think)

[John Gilmore]

The late John Cocke observed that

" . . . an error example should have  the minimal length and
complexity required to exhibit that error".

There is no appeal from this judgment.  Dissent from it is
disqualifying, unseriösische.

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

Newer HLASM functions (was ...)

[Peter Relson]

(Sorry, I couldn't keep doing that to Paul, so I changed the subject)

>Newer IBM macros rely on some newer (for
>various values of newer) assembler functions. 

But I'd guess that not one of them relies on a function that is a 
diagnostic function. Yes, macros for a z/OS release might indeed rely on 
the HLASM that accompanies that release.

Most of the cases that I think we are talking about are diagnostic 
functions that can be turned on and off (such as by ACONTROL). The 
existence of "old" macros is one reason why the assembler team tends to 
make options of these not "all or nothing" but rather enable-able and 
disable-able. It is certainly very reasonable to enable a function for 
"your code", disable it for some macro, then re-enable it.

The SETRP example is one where SETRP was of course doing this long before 
HLASM created its option.
For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES 
option so that if you must use the HLASM optional function, you can do so.

As to coding your own expansions: feel free. But don't expect any sympathy 
or support (since doing so is not supported). You'd better get it right. 
Fortunately z/OS is not windoze so you can pretty much rely on the object 
code from your hand-coded source continuing to work from release to 
release (a migration action for a release should accompany a necessary 
change.)

Peter Relson
z/OS Core Technology Design

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

Re: Me? (was: SAVE macro, I think)

[Scott Ford]

I can tell your not irish

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Mar 3, 2013, at 10:05 AM, "Shmuel Metz (Seymour J.)" 
 wrote:

> In <0551413286133992.wa.paulgboulderaim@listserv.ua.edu>, on
> 03/03/2013
>   at 08:54 AM, Paul Gilmartin  said:
> 
>> And I have known IBM support to reply to my minimal test case
>> similarly to, "Why do you need this program to work? It appears to 
>> do nothing useful."
> 
> You'll get more with a kind word and an escalation than you'll ever
> get with just a kind word. (JD)
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Newer HLASM functions (was ...)

[Ed Jaffe]

On 3/3/2013 8:19 AM, Peter Relson wrote:

For what it's worth, IHASDWA was enhanced in z/OS 1.11 with a GR32=NO|YES
option so that if you must use the HLASM optional function, you can do so.


We will change every IHASDWA in every software product we have to code 
GR32=YES. THANKS for the great info!


--
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: Paul Gilmartin

[Walt Farrell]

On Sun, 3 Mar 2013 08:51:34 -0500, John Gilmore  wrote:

>I come now to Tony Harminc's example:
>
>
>But SETRP generates a NOPR with an expression (related to the SDWA, I think)
>obviously intended (and I think commented) to fail if the length is
>not 0. However HLASM doesn't think the expression is a likely register
>value - a legal one, certainly - but still worth a warning if you have
>registers EQUated with the GR or GR32 or GR64 option.
>
>
>It is very different.  Register equates are ubiquitous.  What we thus
>have in this example is no or inadequate testing, and that is not
>defensible.  None of us expects IBM code to be error-free.  None of us
>writes such code.   We do expect that IBM code will have been tested,
>in effect that such errors as we find in it will be subtle and not
>crudely obvious ones; and in this expectation we are now often
>disappointed.

I'll have to disagree with you, John. What we have there is (I believe) an old 
macro, using techniques that work perfectly well, unless someone uses an HLASM 
option that did not exist when the macro was written.

If IBM has not needed to change the macro since HLASM created that option, then 
there has been no need to test the macro. Even if IBM has had to change the 
macro, there is nothing that would require IBM's testers to try it with all 
possible HLASM options and combinations of options.

Note that I'm not saying the macro is as good as it could be. And I'm not 
saying that IBM shouldn't improve it.  But claiming inadequate testing, or 
claiming that the macro definitively has an error, seems inappropriate to me.

-- 
Walt (who is, of course, no longer an IBMer but once was)

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

Re: REFRPROT History Question

[Anne & Lynn Wheeler]

paulgboul...@aim.com (Paul Gilmartin) writes:
> That matches my old recollection of an Old Timer's recounting
> his astonishment at having read a dump in which a Protection
> Exception appeared to have been taken on a fetch instruction.
>
> I believe (with no good evidence) that it was controlled by
> a bit in the page key.  It may have been model-dependent.
> A matching PSW key always allowed read-write access; a
> different PSW key might have either no access or read-only
> access depending on the bit's setting.
>
> Truly the Bad Old Days, when there was no privacy enforced
> between jobs.  And IBM OS technology has always trailed the
> hardware technology.  To wit, nowadays, the absence in z/OS
> of complete support for 64-bit virtual.  (The less said of
> COBOL the better; it's not part of the OS.)
>
> Jim Mulder's explanation is most plausible; at some point
> there may have been understandable reluctance to load user
> code in key 0, only partly because there would have been no
> way to guarantee confidentiality of such code.

cp67 had used games with storage protect key to provide integrity for
cms shared pages (i.e. the same physical page appearing in multiple
different virtual address spaces). It was a real ugly hack because cp67
had to fudge both the psw key that cms ran in as well as the storage
keys (so no cms virtual machine could modify shared pages taking out
other virtual machines).

in the move to vm370, part of the original 370 architecture was segment
protection (bit in the segment table entry) and cms was reorganized so
that it shared pages were in 4k page, 64kbyte segments (370 had 2kbyte &
4kbyte page options as well as 64kbyte and 1mbyte segment options).

however, 370/165 was starting to schedule slip with retofitting virtual
memory hardware to the machine ... and in escalation meetings, it was
decided to drop several features from 370 virtual memory ... including
segment protect. As a result, all the other models that had already
implemented full 370 virtual memory had to go back and remove the
dropped features ... and any software written to use the dropped
features had to be redone. This included the support for cms shared
segments and returning to the ugly cp67 hack for protecting shared
pages.

during the FS period (when company was shutting down 370 work), I
continued to work on 370 ... moving a bunch of cp67 enhancements to
vm370 base and doing lot more stuff like page-mapped filesystem
(avoiding lots of the performance shortcomings of the tss/360 and paged
mapped stuff being worked on for FS) as well as significantly extended
shared segment capability. some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

with the death of FS, there was mad rush to get stuff back into the 370
product pipelines (the dearth of products during the FS period is also
credited with giving the clone processor companies market foothold).
some past posts
http://www.garlic.com/~lynn/submain.html#futuresys

This resulted in decision to release bits & pieces of stuff that i was
distributing in csc/vm to internal datacenters (one of my hobbies was
production systems for internal datacenters). A variation was some of
the expanded shared segment stuff that I had done.

Somebody had come up with hack for vm370 version 3 that eliminated the
storage key hack ... allowing VMA microcode assist to be used with CMS
(LPSW VMA microcode didn't have the rules for the storage key hack).  An
executing cms virtual machine could now modify shared pages ... so to
fence the effect ... on every task switch, all shared pages were scanned
to see if they had been modified, if they had, they were unshared, and
unmodified shared page was fetched from disk. The story was with single
shared 16page segment, the overhead of scanning 16 pages for
modification on every task switch was less than the performance gain
from being able to use VMA with CMS.

The problem was that the inclusion of some of my shared segment
enhancements ... also in version 3 ... increased the number of shared
pages to be scanned on every task switch, invalidating the trade-off of
better performance with VMA. I repeatedly pointed this out ... but
eventually they came back and said that they couldn't drop the VMA use
for CMS (reverting back to the cp67 storage key hack) ... because
salesmen had pre-announced the VMA CMS use to 370/168 vm370 customers
who had ordered VMA and paid substantial amount of money. The company
couldn't go back and tell those customers that it had all been a mistake
(and what they had paid for 370/168 VMA was waste of money).

misc. past posts mentioning paged-map work
http://www.garlic.com/~lynn/submain.html#mmap

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,

Re: REFRPROT History Question

[DASDBILL2]

Saying that COBOL is not part of the OS is not the same as saying it is not 
heavily used.  Regardless of its ugliness or beauty, any given compoenent is 
either part of the OS or not.  And I also believe that COBOL is not. . 


Bill Fairchild 
Franklin, TN 

“Political language is designed to make lies sound truthful and murder 
acceptable, and to give the appearance of solidity to pure wind.” [George 
Orwell] 

- Original Message -
From: "Ted MacNEIL"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, March 3, 2013 9:41:00 AM 
Subject: Re: REFRPROT History Question 

>To  wit, nowadays, the absence in z/OS 
of complete support for 64-bit virtual.  (The less said of COBOL the better; 
it's not part of the OS.) 

Nice blinders-on statement! 
COBOL may be one of the ugliest languages around, but it's also (still, I 
believe) the most heavily used! 

Why not cater to your largest user base? 

- 
Ted MacNEIL 
eamacn...@yahoo.ca 
Twitter: @TedMacNEIL 

-- 
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: Paul Gilmartin

[John Gilmore]

Walt,

I am not sure that we can resolve this difference of opinion.

As you know from the character of my posts over the years, I am not
anti-IBM; and  neither do I want to hold it to impossibly high
standards.

IBM code has always contained some errors.  How not?   In the past,
however, these errors were  subtler.  One could often feel real
sympathy for the programmer who had made one of them (and imagine
having made it oneself).  Now, however, I often see macros that just
do not assemble correctly; and I have been led, reluctantly but
inexorably, to the conclusion that they have not been tested
adequately or that they were not retested at all after being altered
in a notionally trivial way.

I wish things were otherwise.

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: Paul Gilmartin

[John McKown]

Which adds to the need, IMO, for customers to have access to the PL/AS
compiler. Or for IBM to write a PL/AS structure to C struct transformer.
Not that it would help me, what with my lack of a C license.

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

Not I (was: SAVE macro, I think.)

[Paul Gilmartin]

On Sun, 3 Mar 2013 12:55:27 -0500, John Gilmore wrote:
>
>...  Now, however, I often see macros that just
>do not assemble correctly; and I have been led, reluctantly but
>inexorably, to the conclusion that they have not been tested
>adequately or that they were not retested at all after being altered
>in a notionally trivial way.
> 
(somewhat echoing and expanding on John M.)

It's the predictable consequence of requiring end users to use a
different language, including OS interfaces, from that used
internally.  IBM's posture that withholding PL/S provided a
competitive advantage should have been vitiated; mooted by
the advent of unbuldling, priced OS software, and OCO.  It
flouts the maxim attributed to Linus, "With enough testers all
bugs are shallow."

Imagine where UNIX would be nowadays if C had been sequestered
for vendor internal use only, and customers left to program in
assembler with second-rate OS interface declarations.

-- gil

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

Re: REFRPROT History Question

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2013c.html#31 REFRPROT History Question

Note this is part of old exchange of trying to get page protect for 3033
... included in same hardware hits for MVSA microcode assist

Date: 02/27/80 08:37:42
From: wheeler
 
re: yesterday's protect bit discussion.  -- It does make a difference
whether the proctect bit is in the page table entry or segment table
entry (page table entry bit , I think may have originated MVS 811
hardware to provide them selective storage protection in addition to
don't p*** on page zero for system protection). I was spending too
much time thinking about the hardware implementation. Segment table
entry protect bit provides selective protection for some users and the
possibility of no protection for others, i.e. some virtual machines
have R/W shared segments (DWSS) and others only have R/O
access. Segment table protect bit is also defined in the original 370
architecture.

.. Lynn W., K03/281, San Jose Res., 408-256-1783 (8-276)

referenced note:

MY VERSION OF HARDWARE PAGE PROTECTION: WHEN UNDERTAKING AP
DESIGN, SHARED PAGE PROBLEM WAS OBVIOUS.  FIRST, I WAS TOLD BY POK
MANAGEMENT () THAT CMS MUST UTILIZE VMA MICROCODE.  THIS WAS
BECAUSE IBM WAS SELLING VMA TO 168 CUSTOMERS, AMONG OTHER REASONS.  SO
WE TRIED FOR PAGE PROTECTION.  ARCHITECTURE SAID O.K.  MVS SAID IT
WOULD MAKE A NICE RAS TOOL, BUT THEY REALLY DID NOT CARE, AND DID NOT
GET INVOLVED IN NEGOTIATIONS.  WE DID NOT GET PAGE PROTECTION BECAUSE
OF 168 MANUFACTURING.  OUR EC WOULD HAVE HIT SEVERAL OF THE SAME CARDS
AS MVSA (THEN IN THE WORKS).  168 PEOPLE INSISTED ON COMBINING PAGE
PROTECT WITH MVSA TO REDUCE MANUFACTURING AND RECORD KEEPING
COMPLEXITY.  BUSINESS PEOPLE THEN SAID VM CUSTOMERS WOULD HAVE TO
SHARE MVSA COSTS, SINCE IT WOULD BE PART OF PAGE PROTECT PACKAGE.  AT
THIS POINT VM BUSINESS CASE COLLAPSED AND WE GAVE UP THE FIGHT.

THE ONLY APPARENT ALTERNATIVE WAS TO ADOPT YOUR 'FACETIOUS' SUGGESTION
TO DUPLICATE ALL SHARED SEGMENTS.  WHAT SHOULD WE HAVE DONE??  

.

ABOUT CHANGES TO VMA SHARED PAGE SCAN, xxx, , AND I
CERTAINLY ATTEMPTED TO OPTIMIZE BOTH SOFTWARE AND MICROCODE.  THE
MICROCODE DID NOT ALLOW FOR RELOCATABLE SHARED SEGMENTS SINCE WE DID
NOT UNDERSTAND THE DESIRABILITY OF DOING SO.  I SEE THIS AS PRIMARILY
YOUR FAULT.  SINCE YOU ENVISIONED THIS REQUIREMENT, YOU SHOULD HAVE
EXPLAINED IT TO US.  I CERTAINLY WOULD HAVE LISTENED.

... snip 

"xx, yy, zzz" are to protect some of the guilty.

DWSS was internal support for the original relational database
implementation, system/r
http://www.garlic.com/~lynn/submain.html#systemr

and getting DWSS included in protect as shipping system/r as sql/ds
(in period when favorite son operations were pre-occupied with getting
out EAGLE as the new strategic database ... it wasn't until EAGLE
crash&burn that attention was turned to possibly doing version of
systemr/sqlds as DB2).

In a shared segment with same page table used by all virtual address
spaces, a protection bit in the page table entry would apply to all
address spaces. There was a unique segment table entry for every
address space ... so with segment protect bit, it was possible to have
some address spaces with the protect bit on and other address spaces
with protect bit off.

Part of my full paged-mapped memory and shared segment support (small
subset shipped in vm370 release 3) was any shared segment could occur at
any virtual address in any virtual address space (even concurrently at
different virtual addresses).  The issue was limited to 16mbyte, 64kbyte
shared segments was limited to 256 ... take out some system overhead and
requirement for some shared systems being multiple shared segments
... possibly limited the number of unique shared systems around one
hundred or so (across the whole system if unique system-wide virtual
address was required for each shared application image). Relocating
shared segments eliminated requirement for unique system-wide virtual
address for each shared application. Then a specific CMS was limited to
hundred or so concurrent shared applications (but in any combination
... rather than having the limitation system-wide). misc. pasts memory
mapped posts
http://www.garlic.com/~lynn/submain.html#mmap

lots of old posts discussing problems that I had creating location free
code (i.e. image on disk could be loaded at any virtual address w/o
having to change it ... and the same image could occur simultaneously in
multiple different address spaces at potentially different addresses)
http://www.garlic.com/~lynn/submain.html#adcon

this showed up because lots of CMS applications were done using os/360
compilers which generated relocatable address constants ... which had to
be swizzled after loading  fixing them to specific address. I
basically had to undo all relocatable address constants in order to
create location free code.

as an aside, lots of stuff I've done over the years, people have
repeatedly claim

Re: DFSORT Weirdness

[Jim Mulder]

> Yes Jim, that pretty much sums it up. We essentially plugged in a 
> new disk drive and suddenly DFSORT didn't work the way it used to. 
> Despite everything everyone says, something else is influencing 
> DFSORT's decisions on how much storage to use and where it's going 
> to get it. We do know that if we reconfigure our page datasets to be
> of uniform size, we get different results (different amount of 
> memory being used, different amount of memory objects being used for
> work) even if the total amount of slots doesn't change. I cannot 
> believe that the speed of the drives and the availability of DASD 
> Fast Write, Cache Fast Write, and even PAVs aren't playing some part. 

  I have reviewed your PMR,  and I would suggest that most effective
way to continue the investigation would be to work with DFSORT support 
via your PMR by providing the SORTDIAG data they have requested,
from both the original page data set configuration and the
the new page data set configuration. 

  The RMF data provided in your PMR suggests that your old
page data set configuration provided 4218MB of local space,
and your new page data set provided 9140MB of local space.
This change could have a direct effect on word 2 of the 
results returned by STGTEST, which in turn has a direct effect
on the DFSORT storage decisions. This remains by far the most
likely explanation for the change in DFSORT behavior.

 The STGTEST Sysevent does not know anything about things
like "the speed of the drives and the availability of DASD 
Fast Write, Cache Fast Write, and even PAVs", so those things
cannot directly the results returned by STGTEST.  To the extent
that those things might reduce the elapsed time needed for
other jobs and processes in the system, they could possibly
affect real and aux storage occupancy for other things in your
workload, and this could indirectly affect the things that 
STGTEST does look at (like available real storage, UIC buckets,
available aux storage), and thus indirectly affect the results
of STGTEST.  But those would be second order effects, while
the total amount of available local aux space is a first order effect.
 
  With regard to your assertion that  "We do know that if we
reconfigure our page datasets to be
of uniform size, we get different results (different amount of 
memory being used, different amount of memory objects being used for
work) even if the total amount of slots doesn't change.", I have
not seen any data in your PMR to support that assertion.
STGTEST does not know anything about the sizes of individual 
page data sets, so that cannot figure directly into its results.
While the size distribution could affect paging performance
(not paging capacity) and thus indirectly storage occupancy,
that would again be a second order effect. 
 
  
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: DFSORT Weirdness

[Martin Packer]

One thing that's worth pointing out - and is relevant to DFSORT and memory 
in general but possibly not this situation in particular - is that Flash 
Express capacity is not regarded as free or otherwise for the purposes of 
STGTEST SYSEVENT.

This is, to me, a significant benefit of Flash Express for the "DFSORT 
chases online address spaces into Aux" category of behaviour - and one I 
mentioned in
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker/entry/flash_saviour_of_the_universe?lang=en
 
just last week. I checked with z/OS Development specifically on how 
STGTEST SYSEVENT treated Flash Express.

Hoping this is useful to some of you, 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:   Jim Mulder 
To: IBM-MAIN@listserv.ua.edu, 
Date:   03/03/2013 09:19 PM
Subject:Re: DFSORT Weirdness
Sent by:IBM Mainframe Discussion List 



> Yes Jim, that pretty much sums it up. We essentially plugged in a 
> new disk drive and suddenly DFSORT didn't work the way it used to. 
> Despite everything everyone says, something else is influencing 
> DFSORT's decisions on how much storage to use and where it's going 
> to get it. We do know that if we reconfigure our page datasets to be
> of uniform size, we get different results (different amount of 
> memory being used, different amount of memory objects being used for
> work) even if the total amount of slots doesn't change. I cannot 
> believe that the speed of the drives and the availability of DASD 
> Fast Write, Cache Fast Write, and even PAVs aren't playing some part. 

  I have reviewed your PMR,  and I would suggest that most effective
way to continue the investigation would be to work with DFSORT support 
via your PMR by providing the SORTDIAG data they have requested,
from both the original page data set configuration and the
the new page data set configuration. 

  The RMF data provided in your PMR suggests that your old
page data set configuration provided 4218MB of local space,
and your new page data set provided 9140MB of local space.
This change could have a direct effect on word 2 of the 
results returned by STGTEST, which in turn has a direct effect
on the DFSORT storage decisions. This remains by far the most
likely explanation for the change in DFSORT behavior.

 The STGTEST Sysevent does not know anything about things
like "the speed of the drives and the availability of DASD 
Fast Write, Cache Fast Write, and even PAVs", so those things
cannot directly the results returned by STGTEST.  To the extent
that those things might reduce the elapsed time needed for
other jobs and processes in the system, they could possibly
affect real and aux storage occupancy for other things in your
workload, and this could indirectly affect the things that 
STGTEST does look at (like available real storage, UIC buckets,
available aux storage), and thus indirectly affect the results
of STGTEST.  But those would be second order effects, while
the total amount of available local aux space is a first order effect.
 
  With regard to your assertion that  "We do know that if we
reconfigure our page datasets to be
of uniform size, we get different results (different amount of 
memory being used, different amount of memory objects being used for
work) even if the total amount of slots doesn't change.", I have
not seen any data in your PMR to support that assertion.
STGTEST does not know anything about the sizes of individual 
page data sets, so that cannot figure directly into its results.
While the size distribution could affect paging performance
(not paging capacity) and thus indirectly storage occupancy,
that would again be a second order effect. 
 
 
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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: Not I (was: SAVE macro, I think.)

[Jim Mulder]

> It's the predictable consequence of requiring end users to use a
> different language, including OS interfaces, from that used
> internally.  IBM's posture that withholding PL/S provided a
> competitive advantage should have been vitiated; mooted by
> the advent of unbuldling, priced OS software, and OCO.  It
> flouts the maxim attributed to Linus, "With enough testers all
> bugs are shallow."
> 
> Imagine where UNIX would be nowadays if C had been sequestered
> for vendor internal use only, and customers left to program in
> assembler with second-rate OS interface declarations.
> 
> -- gil

  Amen to that, brother Gil.  I have been saying for over 
30 years that withholding PL/S was a huge blunder by IBM, and that
it continues to cost us dearly. 

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

Flash Cards on MVS

[Ed Gould]

Some of you may have/use them, correct?

My limited understanding of flash memory is that they have a  
"limited" life (ie X many writes)


My curiosity is about what happens when a FLASH card reaches its  
limit of X many writes.


How do you handle these cards take it out and toss the old one out or  
can they be recycled...


I am looking for general day in and day out issues of FLASH CARDS.

Any general information would be appreciated.

Also a estimate as to their cost.

Ed

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

Re: Flash Cards on MVS

[R.S.]

W dniu 2013-03-03 22:35, Ed Gould pisze:

Some of you may have/use them, correct?


Correct and obvious since it's a feature of EC12


My limited understanding of flash memory is that they have a "limited"
life (ie X many writes)


Correct but limited. See below.



My curiosity is about what happens when a FLASH card reaches its limit
of X many writes.


Are your trolling? Google is your friend.
Professional (as opposed to flashcard in your camera) flash memories 
have spare cells and complex algorithms to make the cells evenly weared. 
So even if your application wants to rewrite some "track" much more 
frequently the real memory cells are wared evenly. And weared cellas are 
replaced with spares. It can be compared to STK Iceberg aka RAMAC RVA.




I am looking for general day in and day out issues of FLASH CARDS.

Any general information would be appreciated.


GIYF



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

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


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



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

Re: REFRPROT History Question

[Charles Mills]

Okay, while we are delving into nostalgia here.

I had a program that was failing with a S0C4 on either a 360/40 or 360/50 --
I remember the customer, and they had one of each, but don't recall which
box it was. Probably the 50 -- the 50 was a little touchy while the 40 was a
rock.

Anyway, I looked and looked and looked at the code and finally determined
that it had to be a hardware error. Try convincing anyone of that! Yeah,
right, your S0C4 is a hardware error! But eventually I convinced my boss at
the small contracting firm, and then eventually he convinced the customer,
and then we finally convinced IBM, who swapped a memory board and the
problem went away. But -- the point I am getting to here -- the clincher was
that someone (me?) noticed at some point that the exception being reported
was a fetch protection exception, and OS/360 did not implement
fetch-protected memory, so given that the program was a more-or-less basic
application that did not manipulate storage keys, it tended to point to some
sort of error outside of my application.

Don't recall exactly what triggered the error -- some issue of write address
X and then read address Y, or some timing thing, or something.



Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Sunday, March 03, 2013 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REFRPROT History Question

On Mar 2, 2013, at 20:04, Charles Mills wrote:

> I recall distinctly the hardware having fetch protection but there being
no apparent OS support for it.
>  
That matches my old recollection of an Old Timer's recounting
his astonishment at having read a dump in which a Protection
Exception appeared to have been taken on a fetch instruction.

I believe (with no good evidence) that it was controlled by
a bit in the page key.  It may have been model-dependent.
A matching PSW key always allowed read-write access; a
different PSW key might have either no access or read-only
access depending on the bit's setting.

Truly the Bad Old Days, when there was no privacy enforced
between jobs.  And IBM OS technology has always trailed the
hardware technology.  To wit, nowadays, the absence in z/OS
of complete support for 64-bit virtual.  (The less said of
COBOL the better; it's not part of the OS.)

Jim Mulder's explanation is most plausible; at some point
there may have been understandable reluctance to load user
code in key 0, only partly because there would have been no
way to guarantee confidentiality of such code.

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

Re: RLS SMSVSAM and PLEX wide IPL

[Lizette Koehler]

According to IBM when the couple datasets are built new, as in our case, the
only was to do the V SMS,SHCDS(dsname),NEW commands.

I think it would be better to either have a PARM in IGDSMSxx when RLS is
being used, or provide a function in the  IXCL1DSU program to generate a
connection.  A new item name like RLS could be created for this purpose in
IXCL1DSU.  Or a new parm in the IGDSMSxx member could include the RLS
dataset names or vary command syntax.

I would like to know if the group would find this a better alternative?  If
so, I am willing to open a SHARE requirement on this.

I would think most shops do not rebuild their couple datasets on a regular
basis, and will run into the IGW611A or IGW609A and have to dig for the
commands.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Lizette Koehler
> Sent: Sunday, March 03, 2013 1:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RLS SMSVSAM and PLEX wide IPL
> 
> We upgraded the CPU this weekend, and SMSVSAM would not come up.
> 
> We got the IGW611a and IGW609A messages
> 
> After a bit of investigation, I did the V SMS,SHCDS(xxx),NEW putting back
the
> Prim/Sec/Spare files.
> 
> There were no issues with the definition and the only changes were
un-cabling/re-
> cabling the DASD from the old CPU to the new CPU and IPLing with new CF
datasets.
> 
> I am curious if when there is a PLEX wide IPL (All Lpars down at the same
time then
> IPL one at a time up) if there is some way to prevent the loss of the
SHCDS data set
> names?
> 
> Any thoughts?
> 
> My hunts through the manuals and internet is not providing much detail on
PLEX wide
> IPLs and SHCDS datasets
> 
> Thanks.
> 
> Lizette Koehler
> 

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

Re: DFSORT Weirdness

[Jim Mulder]

> One thing that's worth pointing out - and is relevant to DFSORT and 
memory
> in general but possibly not this situation in particular - is that Flash
> Express capacity is not regarded as free or otherwise for the purposes 
of
> STGTEST SYSEVENT.
> 
> This is, to me, a significant benefit of Flash Express for the "DFSORT
> chases online address spaces into Aux" category of behaviour - and one I
> mentioned in
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/
> MartinPacker/entry/flash_saviour_of_the_universe?lang=en
> just last week. I checked with z/OS Development specifically on how
> STGTEST SYSEVENT treated Flash Express.

  STGTEST SYSEVENT treats Flash Express exactly as it treats 
page data sets.  For purposes of understanding STGTEST SYSEVENT,
one can think of the Flash Express storage defined to a z/OS LPAR
as if it was just another page data set. 

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: Not I (was: SAVE macro, I think.)

[Chris Craddock]

On Sun, Mar 3, 2013 at 1:35 PM, Jim Mulder  wrote:

> ...
>   Amen to that, brother Gil.  I have been saying for over
> 30 years that withholding PL/S was a huge blunder by IBM, and that
> it continues to cost us dearly.
>

and i will throw in an hallelujah. Yes it is one of the most spectacularly
dumb things IBM has ever done. Even today after the horse has well and
truly left the barn (and the enclosing county) they still won't let it go.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

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

Re: Not I (was: SAVE macro, I think.)

[Phil Smith III]

NOT disagreeing with any of the sentiments, but here's a tiny glimpse into
one aspect of the battle.

 

At one point in the early 1990s, whatever IBM PartnerWorld was called at the
time went from being no-charge to $5,000 per year. We signed up, having no
real choice. One of the touted benefits was that we could get the PL/X
compiler! So I asked for it, and was sent a tape (minireel, 6250bpi, I
think).

 

A couple of months later, they changed the rules so PWD was now a no-charge
program, but PL/X as a benefit went away.

 

"No problem," I hear you cry, "You already had the compiler, right?"

 

Right - but part of it becoming no-charge was that we'd get our $5,000 back!
Only.we were the only vendor (or one of the few) who had received the
compiler, and GDL had had to PAY whatever lab (I think Raleigh but not sure)
"owned" the compiler a license fee. So I got to go to my boss and tell him
"I have good news and bad news, and it's the same news: we're getting MOST
of that $5K back." And why. I think the compiler cost us about $1600 or the
$5K.

 

So. it was indeed a bonehead move, but I don't think it was quite as simple
as it appeared on the outside. Perhaps the lab that owned it are the ones to
blame, not the z people (at the time, System/390 people!).

 

.phsiii

 


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

Re: DFSORT Weirdness

[Patrick Falcone]

Hmm...I've been following this as well. So I'm wondering what affect 
dynamically cutting over the disk subsystem by delete/draining from old aux. 
while adding new aux. might have on STGTEST, prior to the IPL to 
cleanup/cutover. I saw some strangeness during this type cutover on a DB2 LPAR 
where aux. took a jump, aux. datasets were very uneven in slot allocation and 
we were facing an aux. storage shortage. This could have been WAD but we almost 
painted ourselves into a corner with this one. I'm wondering how STGTEST looks 
at a delete/drain status of an aux. storage volume in his scheme of things.
 
Thanks for your input Jim.
 


From: Jim Mulder 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, March 3, 2013 4:19 PM
Subject: Re: DFSORT Weirdness

> Yes Jim, that pretty much sums it up. We essentially plugged in a 
> new disk drive and suddenly DFSORT didn't work the way it used to. 
> Despite everything everyone says, something else is influencing 
> DFSORT's decisions on how much storage to use and where it's going 
> to get it. We do know that if we reconfigure our page datasets to be
> of uniform size, we get different results (different amount of 
> memory being used, different amount of memory objects being used for
> work) even if the total amount of slots doesn't change. I cannot 
> believe that the speed of the drives and the availability of DASD 
> Fast Write, Cache Fast Write, and even PAVs aren't playing some part. 

  I have reviewed your PMR,  and I would suggest that most effective
way to continue the investigation would be to work with DFSORT support 
via your PMR by providing the SORTDIAG data they have requested,
from both the original page data set configuration and the
the new page data set configuration. 

  The RMF data provided in your PMR suggests that your old
page data set configuration provided 4218MB of local space,
and your new page data set provided 9140MB of local space.
This change could have a direct effect on word 2 of the 
results returned by STGTEST, which in turn has a direct effect
on the DFSORT storage decisions. This remains by far the most
likely explanation for the change in DFSORT behavior.

The STGTEST Sysevent does not know anything about things
like "the speed of the drives and the availability of DASD 
Fast Write, Cache Fast Write, and even PAVs", so those things
cannot directly the results returned by STGTEST.  To the extent
that those things might reduce the elapsed time needed for
other jobs and processes in the system, they could possibly
affect real and aux storage occupancy for other things in your
workload, and this could indirectly affect the things that 
STGTEST does look at (like available real storage, UIC buckets,
available aux storage), and thus indirectly affect the results
of STGTEST.  But those would be second order effects, while
the total amount of available local aux space is a first order effect.

  With regard to your assertion that  "We do know that if we
reconfigure our page datasets to be
of uniform size, we get different results (different amount of 
memory being used, different amount of memory objects being used for
work) even if the total amount of slots doesn't change.", I have
not seen any data in your PMR to support that assertion.
STGTEST does not know anything about the sizes of individual 
page data sets, so that cannot figure directly into its results.
While the size distribution could affect paging performance
(not paging capacity) and thus indirectly storage occupancy,
that would again be a second order effect. 

  
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

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

Need for structure converters wasRe: Paul Gilmartin

[Clark Morris]

On 3 Mar 2013 10:43:30 -0800, in bit.listserv.ibm-main John McKown
wrote:

>Which adds to the need, IMO, for customers to have access to the PL/AS
>compiler. Or for IBM to write a PL/AS structure to C struct transformer.
>Not that it would help me, what with my lack of a C license.
Not just PL/AS to C but PL/AS to COBOL, PL/AS to PL/1, PL/AS to Java
and PL/AS to REXX structure converters.  I really despised having to
code the SMF records I needed for my COBOL file and program usage
programs.

Clark Morris

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

Re: Me? (was: SAVE macro, I think)

[Robert A. Rosenberg]

At 08:54 -0600 on 03/03/2013, Paul Gilmartin wrote about Me? (was: 
SAVE macro, I think):



And I have known IBM support to reply to my minimal test
case similarly to, "Why do you need this program to work?
It appears to do nothing useful."


After getting this type of blow-off reply to a submission of a 
minimal demo,in future problem submissions I always added extra 
comment documentation to the start of the code to acknowledge that 
the code did not do anything useful EXCEPT demonstrate the 
problem/bug - Thus cutting short the first round-trip for the 
usefulness query.


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

Re: Me? (was: SAVE macro, I think)

[Paul Gilmartin]

On Sun, 3 Mar 2013 21:39:59 -0500, Robert A. Rosenberg wrote:

>At 08:54 -0600 on 03/03/2013, Paul Gilmartin wrote about Me? (was:
>SAVE macro, I think):
>
>>And I have known IBM support to reply to my minimal test
>>case similarly to, "Why do you need this program to work?
>>It appears to do nothing useful."
>
>After getting this type of blow-off reply to a submission of a
>minimal demo,in future problem submissions I always added extra
>comment documentation to the start of the code to acknowledge that
>the code did not do anything useful EXCEPT demonstrate the
>problem/bug - Thus cutting short the first round-trip for the
>usefulness query.
> 
Another variant I got once was, "Are you seriously developing an
application, or are you just testing?"  I replied, somewhat snarkily,
"Testing, but not 'just testing'.  I consider testing an essential
part of software quality assurance.  Apparently IBM believes
otherwise."

In honesty, sometimes when reading a description of a feature,
perhaps a new one, in a manual, I think, "It would be difficult,
perhaps logically impossible, to code that feature to operate as
described, particularly in some boundary condition."  So, out of
intellectual curiosity, I code a test case to exercise such a
boundary condition.  Usually, I'm pleasantly surprised that the
feature works as described.  If not, I submit a PMR.

Where's the Black Team when you need them?

-- gil

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

Re: Me? (was: SAVE macro, I think)

[Scott Ford]

Anyone take into consideration the lack of skills nowdays. I am sure IBM is 
also running into this situation.

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Mar 3, 2013, at 11:26 PM, Paul Gilmartin  wrote:

> On Sun, 3 Mar 2013 21:39:59 -0500, Robert A. Rosenberg wrote:
> 
>> At 08:54 -0600 on 03/03/2013, Paul Gilmartin wrote about Me? (was:
>> SAVE macro, I think):
>> 
>>> And I have known IBM support to reply to my minimal test
>>> case similarly to, "Why do you need this program to work?
>>> It appears to do nothing useful."
>> 
>> After getting this type of blow-off reply to a submission of a
>> minimal demo,in future problem submissions I always added extra
>> comment documentation to the start of the code to acknowledge that
>> the code did not do anything useful EXCEPT demonstrate the
>> problem/bug - Thus cutting short the first round-trip for the
>> usefulness query.
> Another variant I got once was, "Are you seriously developing an
> application, or are you just testing?"  I replied, somewhat snarkily,
> "Testing, but not 'just testing'.  I consider testing an essential
> part of software quality assurance.  Apparently IBM believes
> otherwise."
> 
> In honesty, sometimes when reading a description of a feature,
> perhaps a new one, in a manual, I think, "It would be difficult,
> perhaps logically impossible, to code that feature to operate as
> described, particularly in some boundary condition."  So, out of
> intellectual curiosity, I code a test case to exercise such a
> boundary condition.  Usually, I'm pleasantly surprised that the
> feature works as described.  If not, I submit a PMR.
> 
> Where's the Black Team when you need them?
> 
> -- 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

Paging Behaviour; was: Re: DFSORT Weirdness

[nitz-...@gmx.net]

> All data sets are the same size at 5,008 cylinders, half of a 3390-9. 
> 
> LOCAL 55%   OK  1208  SYS1.PAGELOC0
> LOCAL 34%   OK  1208  SYS1.PAGELOC1
> LOCAL 51%   OK  1308  SYS1.PAGELOC2
> LOCAL 32%   OK  1308  SYS1.PAGELOC3
> LOCAL 53%   OK  1207  SYS1.PAGELOC4
> LOCAL 37%   OK  1207  SYS1.PAGELOC5
> LOCAL 53%   OK  1218  SYS1.PAGELOC6
> LOCAL 35%   OK  1218  SYS1.PAGELOC7

> I can remember (but not pinpoint) when usage stayed 
> very low all week long.

Two things come to my mind on this: 

I have only ever seen wildly different numbers like yours in page data set 
percentage usage (when they are all the same size) when page data sets were 
added later, when the rest already had a certain usage. It seemed that adding a 
page ds doesn't favour that page ds so it reaches the same threshold as the 
others, but instead it gets pages in round-robin fashion, slowly building up 
percentage usage, but never reaching the usage of the previous page ds's. In 
our case, all page ds were the same size, too, and were all behind the same 
controller. It took an IPL to even out usage.

Do you have that CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE) health check active on that 
system? I once used the exception thrown via the hardcopy log messages to 
pinpoint that usage increased way before I thought it had increased. It was a 
gradual creep.

I had also seen similar (in my opinion strange) behaviour, and in essence I 
established a reporting network for storage usage, including total amount of 
slots and paging rates. By now, that is quite a trend grafic. Some of the 
behaviour visible in those grafics was also quite unexpected. Mostly, I used 
the numbers to get those lpars a bit more real storage when we migrated to 1.12 
and had several RSM problems that never were found. They went away with just a 
bit more real storage. But I had to fight tooth and nail for it. One would 
think that that real storage was intended for my personal enjoyment, the way my 
management kept withholding it for z/OS while throwing it at z/Linux

Barbara

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

Re: Me?

[Gerhard Postpischil]

On 3/4/2013 12:56 AM, Scott Ford wrote:

Anyone take into consideration the lack of skills nowdays. I am sure IBM is 
also running into this situation.


They're sort of coming full circle. The programming team on OS/360 had 
to start from scratch, and many had experience only on the 7094. The 
word orientation shows in IEFSD095 (big letter routine) that did 
character manipulation using word instructions, and almost no character 
instructions (IIRC, they used an STC, but that was about it).


Of course I may be doing them an injustice, and they might have found 
their version to be faster on the early machines?


Gerhard Postpischil
Bradford, Vermont

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