Re: [EXT] Re: Is the IBM Assembler List still alive - Dumps - Early days

[Crawford Robert C (Contractor)]

I used WYLBUR at Texas A&M University in the early 80's.  It worked well enough 
for undergraduate programmers although it got very slow towards the end of the 
semester when everybody was trying to finish their final projects.  The EXEC 
facility was pretty slick.

I hated the line editor but didn't know any better.  When I got my first real 
job someone showed me SPF edit and I thought I'd died on gone to heaven.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Thursday, September 7, 2023 9:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Is the IBM Assembler List still alive - Dumps - Early days

You ever work with WYLBUR?

Single address space, keeping users from crossing boundaries (RACF, ACF2, Top 
Secret and WACF). Could edit a library with RECFM=U. So one could keep source 
there if they wanted. Would, on close compress the PDS to a single extent if it 
could.

Used very low level interfaces for allocation, such that SMS would not even see 
the file get opened or closed. So I had to finish fixing that so that in an SMS 
environment, that interface could be turned off (in testing we found we could 
cause MVS to have to be re-ipled), and then we used SVC99 for all allocations 
after that (SVC99 takes a lot of resources as I recall).

Had its own scripting language, so applications were written to run inside of 
Wylbur. With the SRB mode, we could read JES2 spool directly (this was a 
problem, that I was going to fix when I got to implementing SAF sigh.)

I have forgotten all the stuff that Wylbur did with stack processing, and all 
so it could handle 250 simultaneous users in one address space.

That was another thing I needed to fix. I needed to change Wylbur Paging to use 
a larger number of pages to accommodate more users. 
(yes, it did its own paging, and interestingly enough, CICS was following along 
with what we did so that CICS/TS was doing what we had just done with task 
management).

I absolutely loved working on Wylbur, best job I ever had after Amdahl MDF.

Steve Thompson


On 9/7/2023 9:15 PM, Leonard D Woren wrote:
> Bill Johnson wrote on 9/7/2023 1:05 PM:
>> We used to use ROSCOE at a small shop in the 80’s because it used 
>> less resources. I hated it.
>
> ROSCOE was one of a collection of TSO alternatives, which were all 
> junk.  TONE, ACEP, Wylbur, maybe more that I don't remember.  They all 
> had 1 two-pronged design goal:  except for Wylbur, a PITA in its own 
> category, allow TSO-like online use without the perceived overhead of 
> TSO, and also, they would run on systems other than MVS.
>
> The reason the resource utilization of all of those was lower than TSO 
> is that it took longer for programmers to get their work done, so the 
> resource utilization was spread out over more elapsed time, lowering 
> the apparent resources used in a given elapsed time period, but also 
> lowering productivity.  Something beancounters generally don't factor 
> because they don't understand it.  They liked the fact that a given 
> set of hardware could support 50 (choose your poison from above) 
> online users while TSO could support only 25.
>
> Fortunately, we're way past hardware costing more than people.
>
>
> /Leonard
>
>
> --
>
> 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: [EXT] Re: The ultimate (another one!) definition of mainframe

[Crawford Robert C (Contractor)]

...and that's one of the ironies of this whole thing.  And why did Apple keep 
their systems closed?  For control, security and (wait for it) money.  Sound 
familiar?


Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, August 15, 2023 8:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: The ultimate (another one!) definition of mainframe

1984? You mean when Apple announced a system that was less open the IBM's? Are 
you sure that it isn't Apple who is "Big Brother"?


From: IBM Mainframe Discussion List  on behalf of 
Crawford Robert C (Contractor) <04e08f385650-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, August 15, 2023 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: The ultimate (another one!) definition of mainframe

I also have to wonder if MS-DOS would've taken off at all if IBM had kept it.  
In the 20th century I remember a lot of companies, Microsoft and Apple 
included, styling themselves as IBM "giant killers."  They were cool, 
(relatively) inexpensive and bringing computing to the masses.  IBM, on the 
other hand, was stodgy, old fashioned  and, for lack of a better term, evil.  
I'm thinking of Apple's "1984" commercial.

For those reasons, people might have rejected MS-DOS just because IBM owned it 
and glommed onto something like DR-DOS.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, August 14, 2023 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: The ultimate (another one!) definition of mainframe

I sort of agree, but I think underneath we still disagree.  I agree that IBM 
didn't think the PC software was worth developing.  And if they had held onto 
MS-DOS and approached its development in the same way that Microsoft did, sure, 
they'd probably be worth bazillions.

(Probably.  I suppose there's market perception involved here too; maybe 
customers accepted software from Microsoft in numbers that they wouldn't have 
from IBM.  But I don't know how to evaluate that, so lets pretend it's not an 
issue.)

Where we may disagree is in your belief - what I think is your belief - that 
IBM was therefore short-sighted to let it go.  What I was hinting at a week or 
so ago is that IBM was ~always~ going to judge that MS-DOS wasn't worth their 
bother, and they were never going to develop it as Microsoft did, and therefore 
(in a sense) they did the sensible thing by letting go of it, letting someone 
else take it and run with it.  They did themselves no harm because they would 
never have done it themselves - and incidentally in the process they did the 
rest of us an enormous favor.  And did themselves the same favor, because I can 
be certain without looking that every employee at IBM now has a powerful PC on 
his desk, which would not have happened had they kept control of DOS themselves.

If IBM were a different company, sure, maybe that different company should have 
held on to MS-DOS.  But as it is ...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* [Your patient] has not yet been anything like long enough with the Enemy to 
have any real humility yet.  What he says, even on his knees, about his own 
sinfulness is all parrot talk.  At bottom, he still believes he has run up a 
very favourable credit balance in the Enemy's ledger by allowing himself to be 
converted  -advice to a tempter from The Screwtape Letters by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Monday, August 14, 2023 15:23

I'm saying that if IBM retained control in MS-DOS and put in the same effort as 
z/OS, they could have been worth bazillions. The problem is that IBM has always 
been half-assed in the PC market. Bill Gates didn't do anything groundbreaking. 
MS-Windows came 6 years after Mac. The mouse & GUI was invented by Xerox before 
1973. These corporations simply considered PC's chump change not worth the 
bother. IBM and Xerox failed because they considered PC more of a nuisance than 
a goldmine.

> --- On Monday, August 14, 2023 at 06:56:39 AM PDT, Bob Bridges 
>  wrote:
> Wait, MS-DOS is what you were talking about, before?  You're 
> suggesting that if IBM had hung on to MS-DOS at the time, they would now be 
> worth bazillions instead of Microsoft?

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

-

Re: [EXT] Re: The ultimate (another one!) definition of mainframe

[Crawford Robert C (Contractor)]

I also have to wonder if MS-DOS would've taken off at all if IBM had kept it.  
In the 20th century I remember a lot of companies, Microsoft and Apple 
included, styling themselves as IBM "giant killers."  They were cool, 
(relatively) inexpensive and bringing computing to the masses.  IBM, on the 
other hand, was stodgy, old fashioned  and, for lack of a better term, evil.  
I'm thinking of Apple's "1984" commercial.

For those reasons, people might have rejected MS-DOS just because IBM owned it 
and glommed onto something like DR-DOS. 

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, August 14, 2023 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: The ultimate (another one!) definition of mainframe

I sort of agree, but I think underneath we still disagree.  I agree that IBM 
didn't think the PC software was worth developing.  And if they had held onto 
MS-DOS and approached its development in the same way that Microsoft did, sure, 
they'd probably be worth bazillions.

(Probably.  I suppose there's market perception involved here too; maybe 
customers accepted software from Microsoft in numbers that they wouldn't have 
from IBM.  But I don't know how to evaluate that, so lets pretend it's not an 
issue.)

Where we may disagree is in your belief - what I think is your belief - that 
IBM was therefore short-sighted to let it go.  What I was hinting at a week or 
so ago is that IBM was ~always~ going to judge that MS-DOS wasn't worth their 
bother, and they were never going to develop it as Microsoft did, and therefore 
(in a sense) they did the sensible thing by letting go of it, letting someone 
else take it and run with it.  They did themselves no harm because they would 
never have done it themselves - and incidentally in the process they did the 
rest of us an enormous favor.  And did themselves the same favor, because I can 
be certain without looking that every employee at IBM now has a powerful PC on 
his desk, which would not have happened had they kept control of DOS themselves.

If IBM were a different company, sure, maybe that different company should have 
held on to MS-DOS.  But as it is ...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* [Your patient] has not yet been anything like long enough with the Enemy to 
have any real humility yet.  What he says, even on his knees, about his own 
sinfulness is all parrot talk.  At bottom, he still believes he has run up a 
very favourable credit balance in the Enemy's ledger by allowing himself to be 
converted  -advice to a tempter from The Screwtape Letters by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Monday, August 14, 2023 15:23

I'm saying that if IBM retained control in MS-DOS and put in the same effort as 
z/OS, they could have been worth bazillions. The problem is that IBM has always 
been half-assed in the PC market. Bill Gates didn't do anything groundbreaking. 
MS-Windows came 6 years after Mac. The mouse & GUI was invented by Xerox before 
1973. These corporations simply considered PC's chump change not worth the 
bother. IBM and Xerox failed because they considered PC more of a nuisance than 
a goldmine.

> --- On Monday, August 14, 2023 at 06:56:39 AM PDT, Bob Bridges 
>  wrote:
> Wait, MS-DOS is what you were talking about, before?  You're 
> suggesting that if IBM had hung on to MS-DOS at the time, they would now be 
> worth bazillions instead of Microsoft?

--
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: [EXT] Re: Cloud may be overpriced compared to on-premises systems

[Crawford Robert C (Contractor)]

The genius of the autobahn is the left lane is for passing only and passing on 
the right is illegal.  Nobody camping out in the left lane, going the speed 
limit and turning the highway into a dodgeball court. 



Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Tuesday, August 8, 2023 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: Cloud may be overpriced compared to on-premises systems

No, I wasn’t including the UK. I’ve been to England twice, Ireland, Northern 
Ireland, & Scotland. I never drove in the UK. Perhaps fearful of driving on the 
left side. I took tours via bus or van, (Bath, Stonehenge) and rail to Windsor. 
Tours (bus, rail, van, car) in Scotland, Ireland, & Northern Ireland.

The highways in Europe are just as big as US highways. And that’s what we are 
talking about. Not back roads.

The trucks in Europe don’t pass much. Because the max speed is 54 MPH. And they 
are all doing the max. It’s truly unusual to watch. Cars are flying by what is 
a long line of trucks. Looks like a convoy. And the trucks are much smaller 
than US trucks.

Americans also don’t understand the autobahn. Most think it is 1 road with 
unlimited speed limit. It’s not 1 road and the unlimited speeds aren’t on the 
entire length of road but actually goes down near cities. In fact, it goes down 
below where most US highways limit is within cities. For the safety of people. 

Sent from Yahoo Mail for iPhone


On Tuesday, August 8, 2023, 1:58 PM, Jeremy Nicoll 
 wrote:

On Tue, 8 Aug 2023, at 14:07, Bill Johnson wrote:
> I’ve driven roads in Europe. 

Which definition of Europe are you using?  That is, are you including the uK 
(recently in the EU but no longer)?

>Every truck is in the right most lane, unless they are passing which 
>isn’t common.

Isn't it?  Do you think the faster ones drive over the slower ones, then?


> It’s nothing like the US

Did anyone ever suggest it might be?  I've never been in the US, but I've 
driven tour coaches in France albeit not all that recently.

 > trucking which is designed for large trucks and fast speeds.

The US roads you're talking about - and the European ones - are presumably just 
the (UK) motorways, German autobahns etc.

There's significantly smaller roads in a lot of places.  Eg there are no 
motorways in Scotland north of Perth or thereabouts.  But the supermarkets 
still send 44 ton trucks up there.  They are not able to travel fast.

> In Germany and other European Union counties, trucks with a gross 
> vehicle weight rating of 3.5 tonnes (7,700 pounds) or more must have a 
> governor that limits their speed to 90 kph (54 miles per hour).

There must be some exceptions to that, maybe in older vehicles.


--
Jeremy Nicoll - my opinions are my own.

--
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: [EXT] Re: Cloud may be overpriced compared to on-premises systems

[Crawford Robert C (Contractor)]

As a witness to an outsourcing followed some years later by an insourcing, I 
can infer that cloud providers (which are essentially outsourcers) can and will 
lowball companies to get their business on the platform.  Then comes the big 
contract renewal.  A customer's bargaining position is weaker during renewal 
because of the time, risk and expense of moving to another provider or, God 
help them, bringing the process back in-house.  

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Monday, August 7, 2023 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Cloud may be overpriced compared to on-premises systems

It would be interesting to understand if the early adopters of cloud were the 
beneficiaries of aggressive discount pricing and now find themselves trapped on 
those platforms.  For a long time storage was “unlimited and not expensive” but 
now you’re starting to see the reality of costs factor into the cloud 
offerings.  

Agree on the religious undertones comment.  Many people wanted to be the cool 
kids and move to the cloud.  Those architects are likely long gone but the 
impact of those decisions live on.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



> On Aug 7, 2023, at 12:51 PM, Dave Jones  wrote:
> 
> Savvy architects consider all the options.


--
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: [EXT] Using SAS/MXG to create a .csv file

[Crawford Robert C (Contractor)]

PROC EXPORT will create CSV files (DBMS=CSV) on Windows machines.  It doesn't 
work on mainframe, for some reasons with SAS.  However, I had a lot of luck 
creating CSV's with PROC EXPORT and WPS.

Since my current shop doesn't have WPS I wrote a SAS macro  that ultimate 
writes a CSV file to a USS directory.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Regan
Sent: Wednesday, August 2, 2023 12:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Using SAS/MXG to create a .csv file

 Is it possible to create a .csv file using both SAS & MXG? I ask because SAS, 
for PROC PRINT, only supports a line length of 256, and the report I want to 
create from SMF119, subtype 66 records, would be longer than that.

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017 z/OS Network Systems Programmer (z 
NetView, z/OS Communications Server)

Email: marktre...@gmail.com
LinkedIn:  https://www.linkedin.com/in/mark-t-regan

--
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: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

480 characters?  Sounds like Twitter.

Was the 2260 keyboard the one with two, count 'em, two PF keys?

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
billogden
Sent: Saturday, July 29, 2023 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

>From:Seymour J Metz 
>Yep, "Model 1 displays 480 characters (12 rows of 40 characters)."
>Did you have keyboard issues?

My memory of those ancient history days (early 70s) simply fails too much. I 
seem to remember "something" simple we did with the keyboard, but the details 
have vanished. (And I am probably confusing it with the 2260 keyboards from a 
few years earlier!)

Bill Ogden

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

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

Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

Oh man, I feel your pain.

I looked at the FAQ for the product.  Does MacKinney provide means to update 
the programs or does the customer have to keep the old macro level translator 
around?

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Wednesday, July 26, 2023 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs 
and why it survives

"potential"?  :-)   

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crawford Robert C (Contractor)
Sent: Wednesday, July 26, 2023 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs 
and why it survives

I don't remember the specific date.  I think CICS 3.2.1 was the last release 
that supported it. 

Fortunately, we only had to run CICS 3.2.1 and CICS 3.3 in parallel for a few 
months.  I'm glad our application guys didn't know about MLI.  It sounds like a 
transition tool that has the potential to turn into a permanent solution.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Wednesday, July 26, 2023 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs 
and why it survives

And then there's this handy little tool from MacKinney systems called MLI that 
allows macro level code to still run in 2023!  Was macro code deprecated around 
1988?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crawford Robert C (Contractor)
Sent: Wednesday, July 26, 2023 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and 
why it survives

That's good to know.  I always assumed CICS had a storage manager because it 
was faster than GETMAIN/FREEMAIN.

I remember the old macro interface and it was a mess, especially with 
application programs addressing system control blocks directly.  Not to mention 
how weird macro code looked in the middle of a PL/1 program.  IBM was wise to 
deprecate the interface even though the conversion caused pain.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, July 26, 2023 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

CICS was "common code" between VS1 and DOS/VS(E) DOS/VS (I used to build it for 
CICS development), with AIF.. ANOP  statements around VS1/DOS specific code.  
DOS/VS did not have the same facilities as VS1, so CICS had to be written to 
the lowest level of code.


On Wed, 26 Jul 2023 at 14:45, Crawford Robert C (Contractor) < 
04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, CICS has problems with shared memory which it mitigates through 
> storage protection and transaction isolation.  IMS MPR's are not 
> entirely immune from this either as a bad array index or funky pointer 
> can wipe out acres of storage and leave a region inoperative.  I saw 
> some MPR loops that were so tight all we could do is put the address 
> space in a WLM penalty box and bring down the control region at night.
>
> I also remember that canceling an MPR was always a last resort 
> because, if the interface was in the wrong state, it could bring down 
> the control region.
>
> CICS has had open TCB's for decades now that enable application 
> programs to use any old OS interface they want.  Global User Exits
> (GLUE's) provide clean interfaces for all sorts of system software and DBMS' .
>
> When I worked in an IMS dominated shop we always had to carefully 
> watch CSA and ECSA.  Sure, CICS regions can use a lot of memory, but 
> you can always buy more real storage.
>
> MPR's, which I saw implemented as batch jobs, do provide great 
> isolation between processes and allow for exploitation of OS services.
> CICS duplicates a lot of OS services but why have a storage manager on 
> top of a storage manager?  On the other hand, keeping things going 
> smoothly means running dozens, if not hundreds, of MPR's to support a 
> transaction rate that could be executed by a fourth as many CICS regions.
>
> MPR's are basically batch jobs getting fed one message at a time.  
> This implementation requires a lot of bolt-ons (e.g., IMS Connect) 
> which come with their own quirks.  I've also seen it require weird 
> solutions for fitting synchronous processes to an asynchronous system.
>
> I did like MFS because it provides true device independence.  It 
> allow

Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

I don't remember the specific date.  I think CICS 3.2.1 was the last release 
that supported it. 

Fortunately, we only had to run CICS 3.2.1 and CICS 3.3 in parallel for a few 
months.  I'm glad our application guys didn't know about MLI.  It sounds like a 
transition tool that has the potential to turn into a permanent solution.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Wednesday, July 26, 2023 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs 
and why it survives

And then there's this handy little tool from MacKinney systems called MLI that 
allows macro level code to still run in 2023!  Was macro code deprecated around 
1988?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crawford Robert C (Contractor)
Sent: Wednesday, July 26, 2023 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and 
why it survives

That's good to know.  I always assumed CICS had a storage manager because it 
was faster than GETMAIN/FREEMAIN.

I remember the old macro interface and it was a mess, especially with 
application programs addressing system control blocks directly.  Not to mention 
how weird macro code looked in the middle of a PL/1 program.  IBM was wise to 
deprecate the interface even though the conversion caused pain.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, July 26, 2023 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

CICS was "common code" between VS1 and DOS/VS(E) DOS/VS (I used to build it for 
CICS development), with AIF.. ANOP  statements around VS1/DOS specific code.  
DOS/VS did not have the same facilities as VS1, so CICS had to be written to 
the lowest level of code.


On Wed, 26 Jul 2023 at 14:45, Crawford Robert C (Contractor) < 
04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, CICS has problems with shared memory which it mitigates through 
> storage protection and transaction isolation.  IMS MPR's are not 
> entirely immune from this either as a bad array index or funky pointer 
> can wipe out acres of storage and leave a region inoperative.  I saw 
> some MPR loops that were so tight all we could do is put the address 
> space in a WLM penalty box and bring down the control region at night.
>
> I also remember that canceling an MPR was always a last resort 
> because, if the interface was in the wrong state, it could bring down 
> the control region.
>
> CICS has had open TCB's for decades now that enable application 
> programs to use any old OS interface they want.  Global User Exits
> (GLUE's) provide clean interfaces for all sorts of system software and DBMS' .
>
> When I worked in an IMS dominated shop we always had to carefully 
> watch CSA and ECSA.  Sure, CICS regions can use a lot of memory, but 
> you can always buy more real storage.
>
> MPR's, which I saw implemented as batch jobs, do provide great 
> isolation between processes and allow for exploitation of OS services.
> CICS duplicates a lot of OS services but why have a storage manager on 
> top of a storage manager?  On the other hand, keeping things going 
> smoothly means running dozens, if not hundreds, of MPR's to support a 
> transaction rate that could be executed by a fourth as many CICS regions.
>
> MPR's are basically batch jobs getting fed one message at a time.  
> This implementation requires a lot of bolt-ons (e.g., IMS Connect) 
> which come with their own quirks.  I've also seen it require weird 
> solutions for fitting synchronous processes to an asynchronous system.
>
> I did like MFS because it provides true device independence.  It 
> allowed us to drive 3270 transactions with LU6.1 messages from CICS 
> without any changes.
>
> I could also go on about dynamic resource definition, automated 
> emergency restart (without using automation), better system management 
> interfaces.
> Not to mention quicker, cleaner and native implementations of newer 
> technologies.
>
> IMO, CICS is much more flexible and better positioned to continue 
> processing in the modern world.
>
> Robert Crawford
> Abstract Evolutions LLC
> (210) 913-3822
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Schmitt, Michael
> Sent: Tuesday, July 25, 2023 9:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and 
> why it survives
&g

Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

That's good to know.  I always assumed CICS had a storage manager because it 
was faster than GETMAIN/FREEMAIN.

I remember the old macro interface and it was a mess, especially with 
application programs addressing system control blocks directly.  Not to mention 
how weird macro code looked in the middle of a PL/1 program.  IBM was wise to 
deprecate the interface even though the conversion caused pain.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, July 26, 2023 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

CICS was "common code" between VS1 and DOS/VS(E) DOS/VS (I used to build it for 
CICS development), with AIF.. ANOP  statements around VS1/DOS specific code.  
DOS/VS did not have the same facilities as VS1, so CICS had to be written to 
the lowest level of code.


On Wed, 26 Jul 2023 at 14:45, Crawford Robert C (Contractor) < 
04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, CICS has problems with shared memory which it mitigates through 
> storage protection and transaction isolation.  IMS MPR's are not 
> entirely immune from this either as a bad array index or funky pointer 
> can wipe out acres of storage and leave a region inoperative.  I saw 
> some MPR loops that were so tight all we could do is put the address 
> space in a WLM penalty box and bring down the control region at night.
>
> I also remember that canceling an MPR was always a last resort 
> because, if the interface was in the wrong state, it could bring down 
> the control region.
>
> CICS has had open TCB's for decades now that enable application 
> programs to use any old OS interface they want.  Global User Exits 
> (GLUE's) provide clean interfaces for all sorts of system software and DBMS' .
>
> When I worked in an IMS dominated shop we always had to carefully 
> watch CSA and ECSA.  Sure, CICS regions can use a lot of memory, but 
> you can always buy more real storage.
>
> MPR's, which I saw implemented as batch jobs, do provide great 
> isolation between processes and allow for exploitation of OS services.  
> CICS duplicates a lot of OS services but why have a storage manager on 
> top of a storage manager?  On the other hand, keeping things going 
> smoothly means running dozens, if not hundreds, of MPR's to support a 
> transaction rate that could be executed by a fourth as many CICS regions.
>
> MPR's are basically batch jobs getting fed one message at a time.  
> This implementation requires a lot of bolt-ons (e.g., IMS Connect) 
> which come with their own quirks.  I've also seen it require weird 
> solutions for fitting synchronous processes to an asynchronous system.
>
> I did like MFS because it provides true device independence.  It 
> allowed us to drive 3270 transactions with LU6.1 messages from CICS 
> without any changes.
>
> I could also go on about dynamic resource definition, automated 
> emergency restart (without using automation), better system management 
> interfaces.
> Not to mention quicker, cleaner and native implementations of newer 
> technologies.
>
> IMO, CICS is much more flexible and better positioned to continue 
> processing in the modern world.
>
> Robert Crawford
> Abstract Evolutions LLC
> (210) 913-3822
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Schmitt, Michael
> Sent: Tuesday, July 25, 2023 9:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and 
> why it survives
>
> So CICS is no longer doing cooperative multitasking within each AOR, 
> and thus requiring CICS versions of OS commands to prevent wait states 
> from freezing the entire AOR? A CICS program can do direct GETMAINs, 
> LOADS, abends, rather than use CICS commands? CICS no longer requires 
> special versions of tools (e.g. debugger, abend dump management) and 
> instead can use the same tools as batch programs? A CICS programmer no 
> longer needs to learn a long list of CICS commands and EXEC CICS 
> syntax? A CICS region no longer contains the storage from all of the 
> transactions currently running and is now only one transaction in the 
> region at a time? CICS transactions can no longer stomp on each other's 
> memory?
>
> Great, I did not know that.
>
> IMS/TM uses the operating system for multitasking. There are no IMS/TM 
> specific tools. An IMS/TM programmer only needs to know two commands, 
> one to get a message and another to send it. IMS transaction abends 
> look
> (almost) exactly like a batch abend. IMS programs have no

Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

Yes, CICS has problems with shared memory which it mitigates through storage 
protection and transaction isolation.  IMS MPR's are not entirely immune from 
this either as a bad array index or funky pointer can wipe out acres of storage 
and leave a region inoperative.  I saw some MPR loops that were so tight all we 
could do is put the address space in a WLM penalty box and bring down the 
control region at night.  

I also remember that canceling an MPR was always a last resort because, if the 
interface was in the wrong state, it could bring down the control region.

CICS has had open TCB's for decades now that enable application programs to use 
any old OS interface they want.  Global User Exits (GLUE's) provide clean 
interfaces for all sorts of system software and DBMS' .

When I worked in an IMS dominated shop we always had to carefully watch CSA and 
ECSA.  Sure, CICS regions can use a lot of memory, but you can always buy more 
real storage.

MPR's, which I saw implemented as batch jobs, do provide great isolation 
between processes and allow for exploitation of OS services.  CICS duplicates a 
lot of OS services but why have a storage manager on top of a storage manager?  
On the other hand, keeping things going smoothly means running dozens, if not 
hundreds, of MPR's to support a transaction rate that could be executed by a 
fourth as many CICS regions.

MPR's are basically batch jobs getting fed one message at a time.  This 
implementation requires a lot of bolt-ons (e.g., IMS Connect) which come with 
their own quirks.  I've also seen it require weird solutions for fitting 
synchronous processes to an asynchronous system.

I did like MFS because it provides true device independence.  It allowed us to 
drive 3270 transactions with LU6.1 messages from CICS without any changes.

I could also go on about dynamic resource definition, automated emergency 
restart (without using automation), better system management interfaces.  Not 
to mention quicker, cleaner and native implementations of newer technologies.

IMO, CICS is much more flexible and better positioned to continue processing in 
the modern world.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Tuesday, July 25, 2023 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

So CICS is no longer doing cooperative multitasking within each AOR, and thus 
requiring CICS versions of OS commands to prevent wait states from freezing the 
entire AOR? A CICS program can do direct GETMAINs, LOADS, abends, rather than 
use CICS commands? CICS no longer requires special versions of tools (e.g. 
debugger, abend dump management) and instead can use the same tools as batch 
programs? A CICS programmer no longer needs to learn a long list of CICS 
commands and EXEC CICS syntax? A CICS region no longer contains the storage 
from all of the transactions currently running and is now only one transaction 
in the region at a time? CICS transactions can no longer stomp on each other's 
memory?

Great, I did not know that.

IMS/TM uses the operating system for multitasking. There are no IMS/TM specific 
tools. An IMS/TM programmer only needs to know two commands, one to get a 
message and another to send it. IMS transaction abends look (almost) exactly 
like a batch abend. IMS programs have no restrictions on OS facilities. An IMS 
program can even do an STIMER (WAIT) without affecting any other transaction 
processing. Because, it uses the OS to do *preemptive* multitasking, like a 
modern operating system.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crawford Robert C (Contractor)
Sent: Tuesday, July 25, 2023 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it 
survives

Sorry, I worked in a shop that had both and I can tell you CICS is way more 
flexible, modern and performed better.

I will give you this:  IMS is a great piece of 90's technology.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, July 24, 2023 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

Ars Technica published a deep-dive explainer of modern IBM mainframes:

https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/


I’d quibble with the application server topic that talks about CICS with no 
mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10.  😊



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

Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

[Crawford Robert C (Contractor)]

Sorry, I worked in a shop that had both and I can tell you CICS is way more 
flexible, modern and performed better.

I will give you this:  IMS is a great piece of 90's technology. 

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, July 24, 2023 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives

Ars Technica published a deep-dive explainer of modern IBM mainframes:

https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/


I’d quibble with the application server topic that talks about CICS with no 
mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10.  😊



--
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: [EXT] Re: Userid schemes

[Crawford Robert C (Contractor)]

My favorite user ID mess was on an old Vax system that used the last name 
followed by first initial.  Of course this system began each printed report 
with a banner page listing the user's ID printed in large, block letters.  One 
day I went to the printer and noticed a report from user SEXTONG.  While I was 
puzzling over this an embarrassed Greg Sexton came up and snatched his report 
off of the printer.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, July 13, 2023 4:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Userid schemes

On Thu, 13 Jul 2023 17:22:12 -0400, Phil Smith III wrote:

>I've seen various schemes used for creating up-to-eight-character userids, all 
>truncated as needed, of course. These are IDs I've had, won't tell ya where 
>each was (and omitting just firstname, just lastname, or intials):
>
It was egregious underreaching when IBM increased the permitted length of TSO 
IDs from 7 to 8.  They should have gone to something more characteristic of 
extant systems, probably several dozen, using USERIDALIASTABLE if needed to 
perform the mapping.


>Anyone got any other variations? This is purely a curiosity item, no agenda.
>
I once worked for an organization that used last name, first initial, middle 
initial.  After searching phone directories, I wondered whether Cheng K. Fu of 
San Diego, CA would ever apply for employment there.

(They were inflexible.  A co-worker was required to change her user ID because 
of marriage.)

--
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: [EXT] Re: Invoke Java from Assembler

[Crawford Robert C (Contractor)]

Denis,

Thank you for the detailed answer.  I'll start looking into your suggestions.

I may be misunderstanding your question, but we would like a persistent JVM so 
the assembler code can call Java classes as subroutines.  Creating and 
terminating a JVM for each call would be prohibitively expensive.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Denis
Sent: Wednesday, July 12, 2023 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: Invoke Java from Assembler

 Hi Robert,

IMS uses the CEEPIPI approach to make the JVM persistent, but thats actually 
only needed if multiple modules are serially executed and (speaking with COBOL) 
end with a GOBACK. The GOBACK of the first module called would terminate the LE 
enclave (and as such the JVM) so CEEPIPI is used to allow the next program to 
work the same way without tiering down the JVM.
The COBOL (and C JNI) work like this, you start a program e.g. with JCL 
PGM=PROG1. Enterprise COBOL initializes the JVM (CreateJavaVM and 
AttachCurrentThread JNI calls under the covers if I remember correctly, in C 
and e.g. PL/I you do that by yourself and the environment for the JVM is 
pointed to by _CEE_ENVFILE) and with that JVM pointer you can do any number of 
JNI calls (e.g. call Java methods) and after each call the calling program is 
returned control. The JNIEnvPtr will be valid as long as the JVM or the LE 
enclave stay up.You can do the same thing in assembler, but you need an LE 
enclave with POSIX(ON) and XPLINK(ON) since the JVM on z/OS is written in C and 
requires those settings (in addition that up to Java 8 the 31bit version of 
Java needs to be used). But if the inital assembler uses CEEENTRY and CEETERM 
it will be quite easy to achieve, because it would create the LE enclave and 
remain until the initial assembler ends. From that first module you can call 
any non LE assembler as you like.The JVM can be ended by using JNI call 
DestroyJavaVM to make sure any unfinished work on the Java side is ended (as 
opposed to just end the first module and terminate the JVM together with the LE 
enclave and the address space).
One question is, why would you need to make the JVM persistent with CEEPIPI in 
batch?You can do PROG1 call anything then return, PROG1 call Java then return 
as long and as many times as you want without the need of CEEPIPI and reusing 
the JVM - since its not terminated after return from Java.
But to make it more complicated, since Java 11 for z/OS there is no 31bit JVM 
anymore and the JVM will be in a secondary 64bit LE enclave. There is a 
libjvm31.so shared library which can be used to make the JNI calls work, with 
the difference that most references require 64bit parameters. (Under the covers 
CEL4RO64 service is 
used)https://www.ibm.com/support/pages/enhancement-coboljni-interface

For now, I think the easiest way to do it, is in COBOL.
Hope that helps,Denis.
On Wednesday, July 12, 2023 at 02:40:08 PM GMT+2, Crawford Robert C 
(Contractor) <04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:
 
 
 Thanks, Allan.

Back in the 90's I used CEEPIPI to create a persistent C enclave I could call 
from Assembler because building the environment is expensive.  Unfortunately, 
CEEPIPI documentation is kind of scarce.  What we do find doesn't give us very 
many clues for how to get to Java.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
allan winston
Sent: Tuesday, July 11, 2023 5:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Invoke Java from Assembler

Robert,

  This reminds me of a situation I ran into 25 years ago involving assembler 
and COBOL.  Granted, COBOL and Java are different environments, but there may 
be enough similarity in the issues to be relevant.

    We had an assembler main program that called a COBOL subroutine repeatedly. 
 It was chugging along just fine until LE maintenance showed a large spike in 
CPU time within LE library routines, as shown by Strobe.
It seemed as though the LE environment was constantly being created and torn 
down. I did look into solutions, such as using CEEPIPI, but this program was a 
major CPU consumer in this shop and we needed a quick solution.  The solution I 
proposed and was implemented was to create a new main program, written in 
COBOL, that called the former assembler main program.  That way the new main 
program established the LE environment that persisted until the program 
terminated.

  So, ALC calling COBOL changed to COBOL calling ALC calling COBOL.
In your case: Java calling COBOL changed to COBOL calling Java calling COBOL.

  I have never used Java, so this is somewhat a shot in the dark.

  I should have created an ETR on IBMLINK about the increased CPU overhead, but 
did not bother since we had a circumvention.

    Allan

On Tue, Jul 11, 2023 at 5:58

Re: [EXT] Re: C DLL abend CEE3350S

[Crawford Robert C (Contractor)]

You might want to try disassembling the LE initialization modules beginning at 
the entry point and follow the logic.  Some of the CEE CSECT's are included 
from SCEELKED while the compiler generates others specific to the module's 
requirements (e.g., stack storage, application code entry point). 

I once ran into a problem where one program linked in a different program's 
CEESTART (I think it was) which resulted in S0C4's.   

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Eric Erickson
Sent: Tuesday, July 11, 2023 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: C DLL abend CEE3350S

I know, but the CEESTART CSECT is included in the program object. On another 
DLL, which is just 1 module with multiple functions, the CEESTART CSECT is 
listed in the load map as such.

  
   0  CEESTART*  CSECTB0  SYSLIB03  CEESTART  
  

In my problem DLL its listed as: 

  A48  CEESTART*  CSECTB0  SYSLIB03  CEESTART   
   

   
Not sure what is going on here. Its my first foray into C DLLs and I wonder if 
mixing in the C LE Assembler routines is causing an issue? 

If I don't but the Entry statement into the deck, I get one what looks to be 
the module with the first alphabetically marked as the entry point. 

--
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: [EXT] Re: Invoke Java from Assembler

[Crawford Robert C (Contractor)]

Thanks, Allan.

Back in the 90's I used CEEPIPI to create a persistent C enclave I could call 
from Assembler because building the environment is expensive.  Unfortunately, 
CEEPIPI documentation is kind of scarce.  What we do find doesn't give us very 
many clues for how to get to Java.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
allan winston
Sent: Tuesday, July 11, 2023 5:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Invoke Java from Assembler

Robert,

   This reminds me of a situation I ran into 25 years ago involving assembler 
and COBOL.  Granted, COBOL and Java are different environments, but there may 
be enough similarity in the issues to be relevant.

We had an assembler main program that called a COBOL subroutine repeatedly. 
 It was chugging along just fine until LE maintenance showed a large spike in 
CPU time within LE library routines, as shown by Strobe.
It seemed as though the LE environment was constantly being created and torn 
down. I did look into solutions, such as using CEEPIPI, but this program was a 
major CPU consumer in this shop and we needed a quick solution.  The solution I 
proposed and was implemented was to create a new main program, written in 
COBOL, that called the former assembler main program.  That way the new main 
program established the LE environment that persisted until the program 
terminated.

   So, ALC calling COBOL changed to COBOL calling ALC calling COBOL.
In your case: Java calling COBOL changed to COBOL calling Java calling COBOL.

   I have never used Java, so this is somewhat a shot in the dark.

   I should have created an ETR on IBMLINK about the increased CPU overhead, 
but did not bother since we had a circumvention.

 Allan

On Tue, Jul 11, 2023 at 5:58 PM Crawford Robert C (Contractor) < 
04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:

> We're interested in invoking Java from assembler in batch.  
> Specifically, we'd like to create a persistent Java environment we can 
> call repeatedly and terminate when we're through.
>
> Has anyone done this?  Is the LE pre-initialization module CEEPIPI 
> worth exploring?
>
> Thanks.
>
> Robert Crawford
> Abstract Evolutions LLC
> (210) 913-3822
>
>
> --
> 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

Invoke Java from Assembler

[Crawford Robert C (Contractor)]

We're interested in invoking Java from assembler in batch.  Specifically, we'd 
like to create a persistent Java environment we can call repeatedly and 
terminate when we're through.

Has anyone done this?  Is the LE pre-initialization module CEEPIPI worth 
exploring?

Thanks.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822


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

Re: [EXT] Re: z/OSMF

[Crawford Robert C (Contractor)]

Sorry, that was a couple of jobs ago.  Wish I'd made a copy before I left.

We also had a text-based version of Star Trek that ran on CICS.  It was 
actually kind of boring so I eventually ended up blowing up the starbases.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Wednesday, July 5, 2023 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXT] Re: z/OSMF

Hi Robert,
Is the source code available?
If yes, how does one get it?

Thanks and regards,
David

On 2023-07-05 09:17, Crawford Robert C (Contractor) wrote:
> In the early 80's we had an adventure game written in PL/1.  It was largely 
> table driven so I added a room full of Texas Aggies.  To retrieve the 
> "treasure," an Aggie Joke book, you had to find a bar of soap and throw it 
> into the room at which point the Aggies would run out of the room enabling 
> you to get the book.
>
> For the record, I am a Texas Aggie and I understand that the joke will be 
> lost on 49/50ths of the US.
>
> Robert Crawford
> Abstract Evolutions LLC
> (210) 913-3822
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Pew, Curtis G
> Sent: Monday, July 3, 2023 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXT] Re: z/OSMF
>
> On Jul 3, 2023, at 1:26 PM, Seymour J Metz  wrote:
>
> I was thinking of the old text Adventure written in FORTRAN.
>
>
> You’re talking about the same game. The full name was “Colossal Cave 
> Adventure”, but the program file name was usually as many characters 
> of “ADVENTURE” as the system supported. 
> https://en.wikipedia.org/wiki/Colossal_Cave_Adventure
>
> Forty years ago I knew how to make it all the way through, but that knowledge 
> is now lost in the mists of time for me.
>
> --
> Curtis Pew
> ITS Campus Solutions
> curtis@austin.utexas.edu
>
>
>
>
> --
> 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

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

Re: [EXT] Re: z/OSMF

[Crawford Robert C (Contractor)]

YES!!

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Eric Erickson
Sent: Monday, July 3, 2023 10:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: z/OSMF

PLUGH!

--
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: [EXT] Re: z/OSMF

[Crawford Robert C (Contractor)]

In the early 80's we had an adventure game written in PL/1.  It was largely 
table driven so I added a room full of Texas Aggies.  To retrieve the 
"treasure," an Aggie Joke book, you had to find a bar of soap and throw it into 
the room at which point the Aggies would run out of the room enabling you to 
get the book.

For the record, I am a Texas Aggie and I understand that the joke will be lost 
on 49/50ths of the US. 

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: Monday, July 3, 2023 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: z/OSMF

On Jul 3, 2023, at 1:26 PM, Seymour J Metz  wrote:

I was thinking of the old text Adventure written in FORTRAN.


You’re talking about the same game. The full name was “Colossal Cave 
Adventure”, but the program file name was usually as many characters of 
“ADVENTURE” as the system supported. 
https://en.wikipedia.org/wiki/Colossal_Cave_Adventure

Forty years ago I knew how to make it all the way through, but that knowledge 
is now lost in the mists of time for me.

--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




--
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: [EXT] Re: Counting EXIT invocations

[Crawford Robert C (Contractor)]

Are you talking about the EXIT macro?  You might be able to use a SLIP trap to 
count the invocations.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Thursday, June 29, 2023 3:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Counting EXIT invocations

On Wed, 28 Jun 2023 at 19:28, Colin Paice  wrote:
>
> Allocate a block of 8 bytes in common memory.   Use name token to point to
> it.   Use Compare double and swap to update value.  every 1000 entries
> reset to zero and write out

Or use Add Immediate (ASI/AGSI) instead, which is interlocked unless you have 
quite an old machine and probably performs better than CDS.
But even if you do have a machine without the interlock, it's unlikely your 
update will actually clash, and even if it does your count will probably be off 
by only 1. Would it matter? You're not adding to the balance in a bank account.

Tony H.

> On Wed, 28 Jun 2023 at 15:49, Seymour J Metz  wrote:
>
> > If the exit serializes access to the N/T pair then there should be 
> > no lost data.
> >
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Colin Paice 
> > Sent: Wednesday, June 28, 2023 10:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Counting EXIT invocations
> >
> > Having a WTO depends on how many exit calls there are per second. 
> > 100  a second might cause a problem.
> >
> > Depending on where your exit runs, and what state it is in, a system 
> > level name token pair might be a good compromise.
> > On first use - allocate a name token, set use count = 0; do a STCK 
> > and add
> > 10 minutes - and store it in name token.
> > on every other call
> >
> >- increment counter
> >- If stck(now) > the stored STCK
> >   - calculate the time delta - and WTO out # seconds and count
> >   - store now + 10 minutes in the name token.
> >
> > The time between WTOs may be > 10 minutes  but it gives you a flavour of
> > the count.   You might lose the odd entry if two TSBs are trying to update
> > concurrently.
> >
> > Or do the WTO every 1000 calls.
> >
> > On Wed, 28 Jun 2023 at 15:10, Jousma, David < 
> > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Best option would be to have the exit issue a WTO, and then scan 
> > > operlog for that.
> > >
> > > Dave Jousma
> > > Vice President | Director, Technology Engineering
> > >
> > >
> > >
> > >
> > >
> > > From: IBM Mainframe Discussion List  on 
> > > behalf of jgmauta...@yahoo.com.ar <
> > 01f9499d67db-dmarc-requ...@listserv.ua.edu
> > > >
> > > Date: Wednesday, June 28, 2023 at 9:21 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU 
> > > Subject: Counting EXIT invocations Hi! We have recently 
> > > implemented a RACF exit. Is there a way to know how many times 
> > > this EXIT was executed (on a given period of time)? Thanks in 
> > > advance for your help, Juan Mautalen
> > > --
> > > 
> > >
> > >
> > > Hi!
> > >
> > > We have recently implemented a RACF exit. Is there a way to know 
> > > how many times this EXIT was executed (on a given period of time)?
> > >
> > > Thanks in advance for your help,
> > >
> > > Juan Mautalen
> > >
> > >
> > >
> > > --
> > > 
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO 
> > > IBM-MAIN
> > >
> > > This e-mail transmission contains information that is confidential 
> > > and
> > may
> > > be privileged.   It is intended only for the addressee(s) named above. If
> > > you receive this e-mail in error, please do not read, copy or 
> > > disseminate it in any manner. If you are not the intended 
> > > recipient, any disclosure, copying, distribution or use of the 
> > > contents of this information is prohibited. Please reply to the 
> > > message immediately by informing the
> > sender
> > > that the message was misdirected. After replying, please erase it 
> > > from
> > your
> > > computer system. Your assistance in correcting this error is appreciated.
> > >
> > > --
> > >  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: [EXT] Re: SAS Replacement

[Crawford Robert C (Contractor)]

WPS worked very well for us on several important reporting applications.  Even 
better, it supports MXG which was really important for performance and tuning.

However, there are some quirks and a few things that don't work exactly the 
same.  If you trial WPS I suggest you perform extensive testing on your most 
critical code so you don't stub any toes.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Thursday, June 29, 2023 6:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: SAS Replacement

Classification: Confidential

Sounds like bean counters run amuck.

You might have a look at WPS (claims to be source compatible w/SAS)

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kenneth Kripke
Sent: Wednesday, June 28, 2023 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SAS Replacement

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello;

 I am curious if there is a known replacement product for SAS, specifically 
Performance and Capacity software that is not dependent on using the SAS 
product to collect, process, and, report on Capacity and performance?

I have heard of IntelliMagic, however, I do not know the capabilities of the 
product.  Any recommendations would be appreciated.



Regards,



Kenneth James Kripke

k.kri...@comcast.net 

443-851-1237




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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
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: [EXT] Re: Coupling Facility Structure Resizing

[Crawford Robert C (Contractor)]

Note on GBP duplexing:  Not duplexing, to my understanding, would force a DB2 
group restart after a CF failure.

On the other hand, duplexing GBP's can be expensive.  Fortunately, IBM 
introduced asynchronous duplexing which saves quite a bit of CPU.  You just 
have to make sure your z/OS, CF microcode and DB2 levels support it.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Martin Packer
Sent: Wednesday, June 21, 2023 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Coupling Facility Structure Resizing

I presented - briefly - on this yesterday at the Munich Resilience/Resiliency 
conference.

Yes, SMF 74-4 tells you what IS - and perhaps tells you stuff to make you 
resize structures.

To the point, though: You need to think through the scenarios - both for memory 
and CF CPU. For example, you probably aren't going to move XCF structures from 
a failing CF to a surviving one. Likewise, you might forego duplexing of GBPs 
or even LOCK1 in an emergency. (A third coupling facility to re-establish 
duplexing is a luxury many customers don't have.)

Yes, you need some margin for growth. But you probably don't need 50% white 
space in a CF.

But, to repeat, do it by walking through the scenarios. And SMF 74-4 is your 
friend.

Cheers, Martin

From: IBM Mainframe Discussion List  on behalf of 
kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu>
Date: Sunday, 18 June 2023 at 06:25
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Coupling Facility Structure Resizing Hi Bill, everyone

On top of this, we manually factor for failover, headroom for growth etc. as 
20% of current avg/peak (for example), and then allocate 1.2x memory for the CF 
LPAR itself?
In short, how does one go from structure size calculations to CF LPAR memory 
sizing, in the context of machine or CFCC upgrades.

- KB

--- Original Message ---
On Sunday, June 18th, 2023 at 8:05 AM, Bill Neiman  wrote:


> The appropriate tool for resizing structures during a migration from one 
> CFLevel to another is the SIZER utility, which is distinct from CFSizer. 
> SIZER uses the IXLMG and IXCQUERY APIs to collect structure attribute and 
> count information from all allocated structures, and then uses the IXLCSP API 
> to direct structure size computation requests based on that collected 
> information to all CFs connected to the system from which it is running. You 
> can download the SIZER package, containing the executable, linkedit JCL, 
> execution JCL, and a user guide, from the CFSizer alternate sizing techniques 
> page at 
> https://www.ibm.com/support/pages/cfsizer-alternate-sizing-techniques. The 
> utility runs as a batch job or started task. The documentation explains the 
> use case, procedure for use, and interpretation of the results. Read it 
> carefully before running the utility. Note in particular that for SIZER to be 
> helpful during migration, you must run it when both old and new CFs are 
> installed in the sysplex.
>
> Bill Neiman
> IBM Parallel Sysplex Development
>
> --
> 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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598 Registered office: PO Box 
41, North Harbour, Portsmouth, Hants. PO6 3AU

--
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: [EXT] Re: Mainframe help now available!

[Crawford Robert C (Contractor)]

Nice Sabbath reference.  

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bfishing
Sent: Tuesday, June 13, 2023 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Mainframe help now available!

This also fits into an easy game.  Name that song:
"Treating people just like pawns in chess, wait till their judgment day comes, 
yeah!"

On Tue, Jun 13, 2023 at 9:47 AM Tom Marchant < 
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> Orchestra conductor talking to a violin player: "I know you usually 
> play the violin, but today we need another french horn player. You are 
> a musician. You can do it."
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 

><º>`·.¸¸´¯`·.¸.·´¯`·...¸>(((º>
.·´¯`·.><º>`·.¸¸.·´¯`·.¸.·´¯`·...¸><º>

<>< Go fishing ><>

--
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: [EXT] Re: Mainframe help now available!

[Crawford Robert C (Contractor)]

I knew a couple of VP's who didn't understand why mainframe folks weren't 
interchangeable.  

You have too many MVS guys and need a CICS guy.  Move an MVS guy over to the 
CICS team.  What could be simpler?

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Monday, June 12, 2023 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Mainframe help now available!

LOL.  When things like the "Project Management Office" became common in maybe 
the late 1990's where I worked, they called us Resources.  I remember writing a 
note back saying I'm not a lump of coal or even a vein of gold.

The real problem though, was like you mentioned, they treated us as a simple 
headcount.  That didn't work because it might take 10 of me to do the work of 
(for example) one good CICS person, if I can figure it out at all.

On 6/12/2023 4:18 PM, Tony Harminc wrote:
> On Mon, 12 Jun 2023 at 22:13, James FRSolutions 
> 
> wrote:
> 
>> FR Solutions has programs to help find resources or build new 
>> resources for organizations in search of Mainframe professionals.  
>> With the marketplace shrinking in the MF skills area, we can help.
>> https://www.frsolutionscorp.com/mainframe
> 
> 
> So "resources" is your respectful word for, uh people? I've always 
> aspired to be a resource. Or maybe a headcount.
> 
> Tony H.
> 
> --
> 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: [EXT] Re: JZOS SMF 121 Records

[Crawford Robert C (Contractor)]

Darrold,

Thanks for the tip.

About three milliseconds after I sent my email it occurred to me I could 
compare SMF121JRS_STRTTME to SMF121TME (time the record moved into the SMF 
buffer).  It turns out that SMF121JRS_STRTTME  plus the JVM elapsed time 
(SMF121JRS_UPTIME) is four hours ahead of SMF121TME which is the GMT offset for 
EDT.  

Again, thanks and sorry about the thrash.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Darrold Usher
Sent: Wednesday, June 7, 2023 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: JZOS SMF 121 Records

Robert,

I replied to your personal email just now.

Darrold

On Thu, Jun 1, 2023 at 9:45 AM Crawford Robert C (Contractor) < 
04e08f385650-dmarc-requ...@listserv.ua.edu> wrote:

> I'm trying to figure out some of the finer details for JZOS' type 121 
> SMF records.
>
> For instance, field SMF121JRS_STRTTME contains the JVM startup time.  
> The doc says it uses method 
> java.lang.management.RuntimeMXBean::getStartTime()
> which returns the time in milliseconds.
>
> Does anyone know if JZOS formats that time as GMT or local time?
>
> Also, is there a listserv group specific to z/OS JVM or USS issues?
>
> Thanks.
>
> Robert Crawford
> Abstract Evolutions LLC
> (210) 913-3822
>
>
> --
> 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

JZOS SMF 121 Records

[Crawford Robert C (Contractor)]

I'm trying to figure out some of the finer details for JZOS' type 121 SMF 
records.

For instance, field SMF121JRS_STRTTME contains the JVM startup time.  The doc 
says it uses method java.lang.management.RuntimeMXBean::getStartTime() which 
returns the time in milliseconds.

Does anyone know if JZOS formats that time as GMT or local time?

Also, is there a listserv group specific to z/OS JVM or USS issues?

Thanks.

Robert Crawford
Abstract Evolutions LLC
(210) 913-3822


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

[Public] RE: EXTERNAL: Re: Transmitting SMF records

[Crawford, Robert C.]

Sorry, I see what you mean.

I've installed a couple of IBM tools from my Windows workstation that were in 
XMIT format.  I uploaded them to z/OS with binary FTP then did a RECEIVE to 
recreate the file.  I guess you could do the same by XMIT'ing to a dataset, 
downloading that to Windows, to Windows, to z/OS where you do a RECEIVE.  All 
in binary format, of course.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Nothing can be beautiful which is not true."
John Ruskin
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ituriel do Neto
Sent: Wednesday, December 14, 2022 8:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Transmitting SMF records

The idea is to send an SMF dataset from one z/OS to another one, but first, it 
needs to be downloaded to windows to be sent to us, also in windows. Once we 
have the file, we upload it to our mainframe to process it.

It is possible to split the original SMF dataset in smaller pieces but demands 
a lot of control, so it would be the last resource..


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em quarta-feira, 14 de dezembro de 2022 11:06:35 BRT, Matt Hogstrom 
 escreveu:





Are you processing this on another z/OS system ?  You indicated you’re 
downloading it so I wanted to make sure I understand the requirements.

For “downloading”  are you using FTP, SFTP or SCP.  Are you processing the data 
on a non-Z platform ?

Matt Hogstrom
m...@hogstrom.org

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



> On Dec 14, 2022, at 8:56 AM, Ituriel do Neto 
> <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
>
> Hi all,
>
> I know we can TERSE or use XMIT a SMF dataset to generate a fixed-form
> dataset, that can be downloaded in binary mode, transmitted, and then
> recovered following the reverse order.
> My attempts of downloading the SMF dataset directly, in binary, and
> then uploading it to another SMF dataset with the same DCB attributes
> did not work. The file got corrupted.
>
> I have a customer that has a huge SMF dataset that can't be TERSED or
> XMITTED because of a lack of space.
>
> Is there a way to send it, without previous use of XMIT or TRS ?
>
> Thanks in advance.
>
>
> Best Regards
>
> Ituriel do Nascimento Neto
> z/OS System Programmer
>
> --
> 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

USAA Classification: Public

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.


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

[Public] RE: EXTERNAL: Transmitting SMF records

[Crawford, Robert C.]

I've used XMIT to send small SMF files between Sysplex's.  The catch is the 
transmitted file occupies spool space until someone receives it.  If your shop 
is hurting for space they probably don't have a lot of spool volumes either.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Nothing can be beautiful which is not true."
John Ruskin
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ituriel do Neto
Sent: Wednesday, December 14, 2022 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Transmitting SMF records

Hi all,

I know we can TERSE or use XMIT a SMF dataset to generate a fixed-form dataset, 
that can be downloaded in binary mode, transmitted, and then recovered 
following the reverse order.
My attempts of downloading the SMF dataset directly, in binary, and then 
uploading it to another SMF dataset with the same DCB attributes did not work. 
The file got corrupted.

I have a customer that has a huge SMF dataset that can't be TERSED or XMITTED 
because of a lack of space.

Is there a way to send it, without previous use of XMIT or TRS ?

Thanks in advance.


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

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

USAA Classification: Public

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.


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

[Public] RE: EXTERNAL: SAS ODS in the Mainframe environment

[Crawford, Robert C.]

If you don't mind storing CSV's instead of spreadsheet, you can use PROC EXPORT 
like this:

proc export data=HSMFSRBO outfile='/tmp/hsmfsrbo.csv'
dbms=csv replace label;

This code writes the CSV file out to the /tmp directory for the system it runs 
on.  Sadly, it'll take an extra step to get it into a PDS.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Nothing can be beautiful which is not true."
John Ruskin
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kenneth J. Kripke
Sent: Tuesday, November 22, 2022 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: SAS ODS in the Mainframe environment

Hello;

 I realize this is not the correct forum to be asking questions regarding 
SAS, but, it appears that SAS-L is no longer available?

The question is as follows:

I would like to produce an XCEL spreadsheet written to a member of a 
pre-allocated PDSE.  I have fiddled with the various statements to accomplish 
this, but, to no avail.

The type of data to be stored is the result of a PROC PRINT with character 
data.  Does anyone else on the list have some experience and suggestions on 
this?



Kenneth J. Kripke



k.kri...@comcast.net 




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

USAA Classification: Public

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.

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

[Public] RE: EXTERNAL: Re: End of several eras

[Crawford, Robert C.]

I learned a lot from the CICS source code IBM distributed for years.  I learned 
how to hash, build segmented tables, how to build linked lists, all techniques 
I incorporated in my programs to make them dynamic and resilient.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Nothing can be beautiful which is not true."
John Ruskin
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Monday, October 31, 2022 11:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: End of several eras

I agree, I can't possibly convey how much I learned from some old IBM fiche 
that I had access to in the computer center when I just started college.  The 
first really important thing I wrote (I was 17) were mods to pass the condition 
codes from step to step within JES2 and then send the highest one to the 
console and syslog at job end.  I later learned that others had done the same 
thing, and long before me, but I learned a lot.  That code didn't work with the 
first version of MVS I was exposed to after college, so it was followed by 
doing that same thing with two jes exits and then even later writing our 
companies Automation software that pulls the condition codes from the same 
fields they were placed in originally way back then.

Everything I have written over the years is still based on concepts and 
techniques that I first learned by looking at the code in the IBM fiche.

I had an extra advantage in that I worked for IBM throughout that same time and 
was able to see some truly spectacular coding techniques and I am truly 
thankful for that opportunity.

I realize that IBM wanted to keep nefarious people from copying the code, but I 
think that we lost a great deal of experience and expertise when we lost access 
to the code.  Some of those techniques are just not around for people to 
examine and learn from, and that's very sad.

Brian



On Mon, 31 Oct 2022 19:42:50 -0400, David Spiegel  
wrote:

>Hi Tom,
>1983, eh?
>The same year as the (expletive deleted) OCO policy.
>I've seen IBM-lifers defend it on this forum, yet, it still did
>not/does not make sense.
>
>Regards,
>David
>

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

USAA Classification: Public

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.


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

Re: EXTERNAL: CIBXUTOK fetch protected

[Crawford, Robert C.]

Does your program get loaded out of an APF authorized library when it runs as a 
STC?  What's in the STEPLIB concatenation for the batch job?  One unauthorized 
library makes the whole STEPLIB unauthorized.  

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Моє око! Я не повинен брати в нього пудинг!”
Emma Andijewska
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ituriel do Neto
Sent: Wednesday, April 27, 2022 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: CIBXUTOK fetch protected

Hi all,

I'm trying to reach CIBXTOKN field under CIBX control block, and if the program 
is executed as a batch job, this field is fetch protected, but if it runs as an 
STC, the access is granted.

What is the difference?

Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

--
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: What not to do on a z/OS system...

[Crawford, Robert C.]

Those rings can serve many purposes.  Years ago we had a spy cam in the machine 
room with four lenses only one of which really worked.  The operators figured 
out which was the active one and hung a tape ring off of it.  That way they 
could always tell if the camera was pointed at them. 

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, January 19, 2022 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: What not to do on a z/OS system...

File protection ring? I've seen those in multiple colors. Easy  to pull apart, 
until the random tough one popped up.


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!Qsl_bxq7E9cN_Potq8RCiR3YAeGlYez8Fh7Sy0BEFZUNWOWI4AohL0xYAM_sUVFbo40$
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Carmen Vitullo [cvitu...@hughes.net]
Sent: Wednesday, January 19, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What not to do on a z/OS system...

yellow ring frizbes :)


On 1/19/2022 12:26 PM, Richards, Robert B. (CTR) wrote:
> Same story, but a Yellow write ring tossed with force (think dodge ball). 
> Same result.
>
> Every time I notice a Plexiglas cover over the EPO button, I smile.
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: Wednesday, January 19, 2022 1:05 PM To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What not to do on a z/OS system...
>
> At my first job (1975) one of the programmers was chatting to the operators 
> and then lent against that red button on the wall. Shutdown the entire 
> machine room of course.
>
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Mike Shaw
> Sent: 19 January 2022 16:44
> To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What not to do on a z/OS system...
>
> We once had a data check we could not get past on a 3420 tape. This was 
> around 1980, MVS/SE 1 or thereabouts. The lead sysprog hit stop on the tape 
> drive, pulled the leading tape portion out of the vacuum column, rubbed it 
> gently back and forth between his finger and thumb, and slowly released the 
> tape back into the vacuum column. He hit start on the tape drive and we got 
> past the data check and read the rest of the data on that tape without a 
> problem. No blocks were missed.
>
> I thought that was magic at the time...
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
>
> On Wed, Jan 19, 2022 at 10:31 AM Seymour J Metz  wrote:
>
>> Back in the old days the R/W heads lifted up when you unloaded  a 
>> tape and moved down when you mounted a new reel. One day an interlock 
>> didn't interlock and the R/W head mashed the hand of an operator. The 
>> damage wasn't permanent, but everybody was more cautious after that.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb
>> 6B1VCs0SfC!Qsl_bxq7E9cN_Potq8RCiR3YAeGlYez8Fh7Sy0BEFZUNWOWI4AohL0xYAM
>> _sUVFbo40$
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
>> behalf of Cameron Conacher 
>> [03cfc59146bb-dmarc-requ...@listserv.ua.edu]
>> Sent: Wednesday, January 19, 2022 10:22 AM 
>> To:IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What not to do on a z/OS system...
>>
>> A very long time ago, (mid seventies I think) I was loading a tape to 
>> a tape drive.
>> A button on my jean jacket trapped the edge of my jacket sleeve 
>> inside the tape drive when as the glass closed.
>> I stood patiently and waited for the tape processing to complete so 
>> the tape could unload.
>>
>> After that, I paid more attention when loading tapes.
>>
>> Thanks,
>>
>> ...Cameron
>>
>>
>>
>>
>>
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Kirk Wolf
>> Sent: Wednesday, January 19, 2022 9:41 AM To:IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [External] Re: What not to do on a z/OS system...
>>
>> Hooray! Now we've got the kind of thread that is the life blood of 
>> ibm-main :-)
>>
>> On Wed, Jan 19, 2022, at 7:21 AM, John McKown wrote:
>>> I know of one MVT operator who trapped his girlfriend against a 3725 
>>> communication controller and dropped a university's entire network.
>>> Multiple sites.
>>>
>>>
>> Kirk Wolf
>> Dovetailed Technologies
>>
>> https://urldefense.com/v3/__http://secure-web.cisco.com/1cn5-HpTYfIre
>> u2cSKoha63Y8gzW7Fj_PXrE92YSaO__;!!GryZGb6B1VCs0SfC!Qsl_bxq7E9cN_Potq8
>> RCiR3YAeGlYez8Fh7Sy0BEFZUNWOWI4AohL0xYAM_sD2Mec6U$
>> IYX4-Aa02x-L7Bs1YFxIRmL8cmskPf0sybkr9abzZzF199DWdz0Ykp9FHL5bGGt4xmkeT
>> e 
>> L0BR-IP-4bbomeF9cRq

Re: EXTERNAL: Re: What not to do on a z/OS system...

[Crawford, Robert C.]

In the early 80's I was customizing some 3274's with another guy who, for some 
reason, lifted up one of the floor tiles to look at the wiring underneath.  The 
floor tile didn't go back into place right away, so he stomped on it, when all 
of a sudden, sparks flew out of the floor when the tile cut through the 3274's 
power cables.

Also early in the 80's, we had just installed a halon system in the machine 
with alarms that triggered at the first whiff of smoke.  I was giving my Dad a 
tour of the datacenter when he lit up a cigarette.  It took me a few seconds to 
realize what he did before I quickly ushered him out of the door much to his 
confusion and consternation. 

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Moy glaz! YA ne dolzhen dobavlyat' v nego puding!”
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Shaw
Sent: Wednesday, January 19, 2022 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: What not to do on a z/OS system...

We once had a data check we could not get past on a 3420 tape. This was around 
1980, MVS/SE 1 or thereabouts. The lead sysprog hit stop on the tape drive, 
pulled the leading tape portion out of the vacuum column, rubbed it gently back 
and forth between his finger and thumb, and slowly released the tape back into 
the vacuum column. He hit start on the tape drive and we got past the data 
check and read the rest of the data on that tape without a problem. No blocks 
were missed.

I thought that was magic at the time...

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Wed, Jan 19, 2022 at 10:31 AM Seymour J Metz  wrote:

> Back in the old days the R/W heads lifted up when you unloaded  a tape 
> and moved down when you mounted a new reel. One day an interlock 
> didn't interlock and the R/W head mashed the hand of an operator. The 
> damage wasn't permanent, but everybody was more cautious after that.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6
> B1VCs0SfC!QH6TeSLlqkT2_Y99bdoorulRCxbsUZxg_adNO1Fy0gicRULs8lH3VdRUE3E5
> nADWlA8$
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Cameron Conacher 
> [03cfc59146bb-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, January 19, 2022 10:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What not to do on a z/OS system...
>
> A very long time ago, (mid seventies I think) I was loading a tape to 
> a tape drive.
> A button on my jean jacket trapped the edge of my jacket sleeve inside 
> the tape drive when as the glass closed.
> I stood patiently and waited for the tape processing to complete so 
> the tape could unload.
>
> After that, I paid more attention when loading tapes.
>
> Thanks,
>
> ...Cameron
>
>
>
>
>
> From: IBM Mainframe Discussion List  On 
> Behalf Of Kirk Wolf
> Sent: Wednesday, January 19, 2022 9:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: What not to do on a z/OS system...
>
> Hooray! Now we've got the kind of thread that is the life blood of 
> ibm-main :-)
>
> On Wed, Jan 19, 2022, at 7:21 AM, John McKown wrote:
> > I know of one MVT operator who trapped his girlfriend against a 3725 
> > communication controller and dropped a university's entire network.
> > Multiple sites.
> >
> >
>
> Kirk Wolf
> Dovetailed Technologies
>
> https://urldefense.com/v3/__http://secure-web.cisco.com/1cn5-HpTYfIreu
> 2cSKoha63Y8gzW7Fj_PXrE92YSaOIYX4-Aa02x-L7Bs1YFxIRmL8cmskPf0sybkr9abzZz
> F199DWdz0Ykp9FHL5bGGt4xmkeTeL0BR-IP-4bbomeF9cRqRy_bfzwte8ereRwNUBuJpR-
> zoczTxEh9fDeQfNRfZH6VHksinm_XjXYh733Xljj6PtqiGJfh7s1sGbZ79ymHznTYdxWdH
> lnBE67BXeYHYTdlkiFdjCovYB674dhzGy5dtMVsQ9iTkQKkBwt6w3SQjmsyzXEUWpv401T
> IfmhcItrgRlmrX75JqZBHJ-DtzhAY4N-beS9ilUZoOQRfGkSjj2c98ccwmf6vN9GYmKP0l
> A7nZNPFxlqPHXD-BM9eStbm1z-CBx7m40jwWuZxedUzGR2pA_y2ZoHHg4FdpvEZtlZOvON
> rzby1iyUtLqEoas/http*3A*2F*2Fdovetail.com__;JSUl!!GryZGb6B1VCs0SfC!QH6
> TeSLlqkT2_Y99bdoorulRCxbsUZxg_adNO1Fy0gicRULs8lH3VdRUE3E5ODtj3x8$
> <
> https://urldefense.com/v3/__https://secure-web.cisco.com/1CMNJvovBdp9y
> BnlyYMX7XDwMols2kkKGgmrwSROSW0hnu2b_NKhNXLtkgwMMcPwd1HBr_ggnaz-jOwBW47
> DnVEGIt4bpW8COmjVD8XqVin4Eu-x_4HLZpGXoDORG_9Dib3tJq7_ABHXsnB_cOZ6onLOn
> cz6m8qRxHlbuSRz29vFEJgKt_Mra5sXumBbRXeklvWffrMgCdm7h3-uIE-BE2zjT8qDyZa
> 9w1nSg6wnBjmblwuVV6lUkPjJm9NYO7sjt7IIE3oKSuCrBzJhb8dOF5aXoc4vT0JenP__8
> Xsug2eziZJMK48OUmxY5e-94ngrzsGRHaYOmnzU5tmHh4jet_pvGp2n0pooHyyoGJoI39j
> y-YnXJwIlOsQ4ks2OtnTA5u6L2rE7KNygGdkGR6GXneZsk9vjAnS0Ih18ujwz99-0vUGfa
> l7K8z518ZueSeQJL/https*3A*2F*2Fisolate.menlosecurity.com*2F1*2F3735928
> 037*2Fhttp*3A*2Fdovetail.com__;JSUlJSUlJSU!!GryZGb6B1VCs0SfC!QH6TeSLlq
> kT2_Y99bdoorulRCxbsUZxg_adNO1Fy0gicRULs8lH3VdRUE3E5YGBDDK4$
> >
>
> ---

Re: EXTERNAL: Re: RLS False Contention Statistics

[Crawford, Robert C.]

Our MAXSYSTEM is set to 8 although there're only 6 LPAR's in the Sysplex.

The IBM recommends false contention to be less than .5%.  We consistently go 
over that threshold during our prime shift.

Our dirty little secret:  We're running a dozen or so active ESDS' under RLS.  
I know IBM recommends against this but we're pretty much stuck due to the 
application's architecture.  The best we might be able to do is change our 
application's "randomizer" to reduce cross-system/cross-CICS contention.  File 
owning regions (FOR's) aren't an option due to availability concerns.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Moy glaz! YA ne dolzhen dobavlyat' v nego puding!”
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Tuesday, January 11, 2022 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: RLS False Contention Statistics

What is your MAXSYSTEMS value?  There is a false lock contention penalty when 
your MAXSYSTEMS value exceeds 7 or 23.  Of course your MAXSYSTEMS has to match 
the actual number of parallel sysplex members :)  Also what is your false lock 
contention rate?  1% is typically acceptable though it really varies with your 
application structure.  Ultimately it is an application design issue, and 
Db2/IMS do a much better job of concurrent data access.

On Wed, Jan 12, 2022 at 2:19 AM Crawford, Robert C. < 
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> All,
>
> I can't reconcile RLS lock structure false lock contention between the 
> various SMS statistics records.
>
> According to the type 42 subtype 17 we have a lot of false contention 
> (field SMF42HCC).  However, our type 42 subtypes 15 (storage class 
> response
> time) and 16 (dataset response time) false contention buckets are zero.
> The only exception in the 16's and 17's are fields SMF42GUB and 
> SMF42FUB that record locks that hashed to the same entry, which I 
> thought was the definition of false contention.  However, the 
> statistics in those fields are a little more than half than the false 
> contention reported in the subtype 15's.
>
> I have SMS dataset monitoring set up for both SMF and IGWDATA.
>
> We are feature level Z (don't ask) so all the statistics should be 
> below the line.
>
> Our lock structure is already 1G in size so I'd like to find the root 
> cause of the false contention before making it any bigger.
>
> Does anyone have some advice?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> "Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
> - Tolstoy
> Please send requests to mainframe management through our front door at 
> go/mfmfrontdoor< 
> https://urldefense.com/v3/__https://onc.jira.usaacloud.com/secure/Dash
> board.jspa?selectPageId=15466__;!!GryZGb6B1VCs0SfC!TrpjUotsagny5EiQXOx
> Ek8XLA34t_PRZ1cAAEi6zQn9KKZOwLw1z2wVKBGQ6eOWQPuE$ >
>
>
> --
> 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

RLS False Contention Statistics

[Crawford, Robert C.]

All,

I can't reconcile RLS lock structure false lock contention between the various 
SMS statistics records.

According to the type 42 subtype 17 we have a lot of false contention (field 
SMF42HCC).  However, our type 42 subtypes 15 (storage class response time) and 
16 (dataset response time) false contention buckets are zero.  The only 
exception in the 16's and 17's are fields SMF42GUB and SMF42FUB that record 
locks that hashed to the same entry, which I thought was the definition of 
false contention.  However, the statistics in those fields are a little more 
than half than the false contention reported in the subtype 15's.

I have SMS dataset monitoring set up for both SMF and IGWDATA.

We are feature level Z (don't ask) so all the statistics should be below the 
line.

Our lock structure is already 1G in size so I'd like to find the root cause of 
the false contention before making it any bigger.

Does anyone have some advice?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor


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

Re: EXTERNAL: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Crawford, Robert C.]

The 4GL's from the 80's had two problems, as I remember.  First, if you wanted 
to customize something, make it a little snazzier than out of the box, you had 
to od some pretty wicked things that weren't human language like at all.  

Second, they didn't perform as well as real programming languages.  That may be 
why the 4GL's tended to be relegated to back-office work by end-users.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, January 7, 2022 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS

I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s, but I 
never saw one that lived up to the claims.  DYL-280II, for example, was 
advertised as a 4GL, but it wasn't close.  Don't get me wrong, as a 3GL I liked 
it just fine, and my company had me teach it to end users so they could fetch 
data from their particular databases without throwing off developers' estimated 
completion dates -- very successfully, I add happily.
But it was no 4GL.

Actually I lump 4GLs and AI into the same bucket.  They're related, I think:
Folks dream of getting computers to think and talk like a human, but so far it 
hasn't happened and I suspect it cannot happen.  But then as a Christian I'm 
also a mystic, by which I mean that the 37 cents' worth of chemicals that one 
often hears about are not what we are, only what we're made of, and that the 
scientists' attempts to figure out what consciousness is and why it evolved is 
doomed to failure because they're starting with the wrong postulates.  But, 
heck, I may be mistaken.  Maybe someday a computer will pass a really decent 
Turing test.

I'm not concerned that my profession is about to wither away, though.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Woe to him inside a nonconformist clique who does not conform with 
nonconformity.  -Eric Hoffer */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, January 7, 2022 16:09

I know of languages that have been peddled as human oriented or English like; I 
don't know of any that even come close. 

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

VSAM RLS False Contention

[Crawford, Robert C.]

Off and on we VSAM RLS false contention plateaus going over IBM's recommended 
.5% rate.  We don't see any kind of triggering behavior in CICS or the CICS 
application.

I would like to at least see the datasets causing the false contention but all 
the false contention buckets in the RMF type 42 subtype 16 records are zero.  
The true contention buckets have values.

It's my understanding the subtype 16 are supposed to have dataset level 
information.  I specified several dataset name levels in RMF VSAMRLS options.  
I also see the same dataset levels in SMS display MONDS commands.

Is it possible I'm missing something that causes DFSSMS to write dataset level 
false contention data?  Am I looking in the wrong place?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, October 5, 2021 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: PL/I vs. JCL

And before that MVS-OE., with MVS before Open.


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsISBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LMQqR2TA$
 



From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Tuesday, October 5, 2021 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Maybe they should've left it as "Open MVS"? (OS/390)

On 2021-10-05 13:08, Tom Brennan wrote:
> I always thought IBM's position on that was pretty silly.  If you make 
> up a new three word name, expect it to quickly be turned into an 
> acronym.  If they didn't want us to reuse an existing little-known 
> acronym they should have named it something else.
>
> On 10/5/2021 9:56 AM, Seymour J Metz wrote:
>>>   USS has always meant Unix System Services.
>>
>>
>> Not unless you have a time machine; Unformatted System Services dates 
>> to the 1970s. Further, the last post here from IBM on the issue said 
>> that USS was not an approved abbreviation for Unix System Services.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook
>> .com/?url=http*3A*2F*2Fmason.gmu.edu*2F*smetz3&data=04*7C01*7C*7C
>> 66d0453903554718720608d98822bd8d*7C84df9e7fe9f640afb435*7
>> C1*7C0*7C637690505140660718*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Lx
>> w1EM03nZsemipAC1ktZCbgKrL*2BedD7*2BDDlG*2Fiwn*2B8*3D&reserved=0__
>> ;JSUlJX4lJSUlJSUlJSUlJSUlJSUl!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsI
>> SBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LiSU-R24$
>>
>>
>>
>> 
>> From: IBM Mainframe Discussion List  on 
>> behalf of Joe Monk 
>> Sent: Monday, October 4, 2021 9:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> USS is a VTAM term for Unformatted System Services.
>>
>> USS has always meant Unix System Services.
>>
>> Joe
>>
>> On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab 
>> wrote:
>>
>>> U.S.S.  Unformated System Services, until Unix System Services tried 
>>> to take it over.
>>>
>>> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin 
>>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

 On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:

> While TSO does not support unambiguous truncation for command 
> names, it
>>> does for keywords. I don't know about ICCF.
>
 Unambiguous truncation is treacherous.  Addition of new
>>> commands/keywords can break
 legacy art.  For that reason I eschew abbreviations in code and
>>> pedagogy.  The worst
 case occurs when one command is a proper prefix of another command.

 I freely abbreviate on a command line.

 
 On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> I have no problem with the DD/member ambiguity:
> \edu with the message: INFO IBM-MAIN

 -- gil

 ---
 --- For IBM-MAIN subscribe / signoff / archive access instructions, 
 send email to lists...@listserv.ua.edu with the message: INFO 
 IBM-MAIN
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua

Re: EXTERNAL: Coding for the future

[Crawford, Robert C.]

It's a small thing, but I now longer try to cram as much code into line as I 
can.  Now I put spaces between operators and variables and after commas.  I 
also put the clauses following "THEN" and "ELSE" on another line.

Oh, and I used to this:
LOOP  MVC   HERE,THERE

And now do this:
LOOP  DS   0H
MVC   HERE,THERE

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Tuesday, June 15, 2021 5:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Coding for the future

In a recent email one of our number, whose name I won't mention except to say 
that his initials are Jeremy Nicoll, made a comment that got me thinking about 
~my~ past and present coding habits.

Like most programmers (maybe), I had some habits that I no longer tolerate.
For example:

1) I used to hate long-winded variable names.  Ok, that's a bad example to 
start with, because I still do.  But I no longer use one-character variable 
names, ever; I use two- to four-character names if they're to be used only in 
one brief section, but if they're supposed to last longer I make them more 
descriptive; and even the shorter ones follow a naming standard that I'm 
familiar with.  It wouldn't be any help to someone else who had to modify my 
code, though.

2) I know everyone says to comment your work, but I never used to.  "I'm the 
only one who'll use this code", I thought, "and I know what I did".  Oh, fool!  
I can forget what I was doing a mere two months later, much less two years or 
two decades.  So now I'm more likely to use one-line comments on every other 
line and a paragraph at the head of each section.  Well, perhaps I exaggerate, 
but not much.

3) Not for me, any longer, to assume that my TSO commands will work correctly.  
For pretty much every interaction with the outside world I include checks for 
file-not-found, empty datasets, missing non-optional arguments, anything I can 
think of.  I want my programs to go on working long after I've forgotten how to 
invoke them properly.

4) This isn't exactly a bad-coding issue, but as much as possible I want the 
input arguments on a command to come in any order I happen to think of them at 
the time.  My routine to search through a concatenation of PDSs for a 
particular module has to receive the DD and module name in a particular order, 
but mostly it's possible to say "tso command arg1 arg2 arg3" or "tso command 
arg2 arg1 arg3" without any confusion.

5) One thing hasn't changed:  Like most of us here, I was ~always~ rabid about 
proper indentation.  (Where by "proper" I mean "consistent"; I know styles can 
vary, but as long as there's no variation...)

I'm just curious about other issues that y'all are careful about that maybe you 
weren't when we were young and foolish.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* While the best judge of Christianity is a Christian, the next best judge 
would be something more like a Confucian.  The worst judge of all is the man 
now most ready with his judgements: the ill-educated Christian turning 
gradually into the ill-tempered agnostic, entangled in the end of a feud of 
which he never understood the beginning, blighted with a sort of hereditary 
boredom with he knows not what, and already weary of hearing what he has never 
heard.  -from the Introduction to _Everlasting Man_ by G K Chesterton */

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

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

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

It's not a huge performance issue but it should definitely be cleaned up.  I'll 
submit an RFE and Share requirement.  We'll see who wants to jump on the 
bandwagon.

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, June 3, 2021 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

IBM takes formal customer requests into account. If you need it, then it is in 
your best interest to submit a formal requirements and to ask others to endorse 
it, whether that be a direct RFE or a SHARE requirement. It's really a win-win 
proposition; it helps you and it helps IBM.


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!QMUuiuZCVrO-GbcjmeQ6mA3kR9wvJYFrD1ahHbKd0G6UpmX7n61Ed8oSwKxLkEsS8xY$
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Crawford, Robert C. [01feadb2c2d2-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 3, 2021 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Jim,

Thank you for the explanation.  It is WAD (working as designed).

Do I need to submit a formal requirement or is being on the list sufficient?

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire 
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Here's what happened:

Apar: OA41307
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES Closed Date: 13/02/23 
RSM support for FORK copies high virtual memory objects from the parent address 
space to the child as part of duplicating the parent process' address space. 
However, the request currently fails if the parent process owns high virtual 
that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will be demoted to 4k pages 
and copied into the child address space.


  The easiest and safest solution for the APAR was to simply demote the source 
1MB pages so the the existing code could then handle them.  Over the years, RSM 
has changed other functions to reduce the number of cases where demotion is 
done. For example, z/OS 2.2 avoids demotion when possible for PGSER FIX. and 
z/OS 2.3 tries to avoid demotion when
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, ForkCopy slipped 
through the cracks.  As a result of your question, it is being added to the 
list of things to look at for a future release.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C."
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion 
> [Internal] Sent by: "IBM Mainframe Discussion List"
> 
>
> Here is the full trace.  I'll gladly accept any help in interpreting.
>
> Sorry about the bad formatting.
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU.
> 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET
> 0800 ADASID.. 0215 XMASID.. 022D CMASID.. 
> STASID.. 
>  KEY. 0036 ADDR 035E1008 ALET 
>  70207520 C710
>  KEY. 009A ADDR 035E22B0 ALET 
>  035E22F8      0100
>       
>   
>  
>  KEY. 009B ADDR 035E22F8 ALET 
>  0001 0103 7FF74D38 04134B00 003B E5398D00 
>    0050 1A00  
>   
>  
>
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Assoc

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

Jim,

Thank you for the explanation.  It is WAD (working as designed).

Do I need to submit a formal requirement or is being on the list sufficient?

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Here's what happened:

Apar: OA41307
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES Closed Date: 13/02/23 
RSM support for FORK copies high virtual memory objects from the parent address 
space to the child as part of duplicating the parent process' address space. 
However, the request currently fails if the parent process owns high virtual 
that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will be demoted to 4k pages 
and copied into the child address space.


  The easiest and safest solution for the APAR was to simply demote the source 
1MB pages so the the existing code could then handle them.  Over the years, RSM 
has changed other functions to reduce the number of cases where demotion is 
done. For example, z/OS 2.2 avoids demotion when possible for PGSER FIX. and 
z/OS 2.3 tries to avoid demotion when
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, ForkCopy slipped 
through the cracks.  As a result of your question, it is being added to the 
list of things to look at for a future release. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion 
> [Internal] Sent by: "IBM Mainframe Discussion List" 
> 
> 
> Here is the full trace.  I'll gladly accept any help in interpreting.
> 
> Sorry about the bad formatting.
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page  
>  FUNC1... COPYSRVH  High Virtual Copy Service  
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 
> 0006  
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 
> 0800 ADASID.. 0215 XMASID.. 022D CMASID..  
> STASID..  
>  KEY. 0036 ADDR 035E1008 ALET   
>  70207520 C710  
>  KEY. 009A ADDR 035E22B0 ALET   
>  035E22F8      0100
>       
>   
>    
>  KEY. 009B ADDR 035E22F8 ALET   
>  0001 0103 7FF74D38 04134B00 003B E5398D00 
>    0050 1A00  
>   
>  
> 
> 
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822




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

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

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

Here is the full trace.  I'll gladly accept any help in interpreting.

Sorry about the bad formatting.

SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
 
 FUNC1... COPYSRVH  High Virtual Copy Service   
 
 JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
 
 JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800 
ADASID.. 0215 XMASID.. 022D CMASID..  STASID..  
 KEY. 0036 ADDR 035E1008 ALET   
 
 70207520 C710  
 
 KEY. 009A ADDR 035E22B0 ALET   
 
 035E22F8      0100  
        
    
 
 KEY. 009B ADDR 035E22F8 ALET   
 
 0001 0103 7FF74D38 04134B00 003B E5398D00   
  0050 1A00     
    
 


Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

  Please show the entire trace entry.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/01/2021 04:12:18 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 12:06 PM
> Subject: Why Would COPYSRVH Cause a 1M Page Demtion [Internal] Sent 
> by: "IBM Mainframe Discussion List" 
> 
> I've been trying to track down what's causing system 1M page demotions 
> on our test system.  The component trace IBM gave me shows, in
part:
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
> 
> The COPYSRVH function isn't well documented but, from I see, UNIX fork 
> processing invokes it to copy memory to the new process.  This makes 
> sense in that JOBN1 and JOBN3 are both USS processes.
> 
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/ 
> OS demoting pages?



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

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

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

It wasn't a page fix request in this instance unless RSM wants to fix pages 
while it does a massive copy of memory from one process to another.

This is a 2.3 system.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » – Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

Classification: Internal



Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Tuesday, June 1, 2021 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

IARV64 pagefix will cause demotion if the area is not 1MB on a 1MB boundary.  
This was fixed in z/os 2.3 ... what release/ptf level are you running?

On Wed, Jun 2, 2021 at 6:12 AM Crawford, Robert C. < 
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> I've been trying to track down what's causing system 1M page demotions 
> on our test system.  The component trace IBM gave me shows, in part:
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
>
> The COPYSRVH function isn't well documented but, from I see, UNIX fork 
> processing invokes it to copy memory to the new process.  This makes 
> sense in that JOBN1 and JOBN3 are both USS processes.
>
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/OS 
> demoting pages?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> « Des clochards comme nous, bébé nous sommes nés pour courir » - 
> Voltaire Please send requests to mainframe management through our 
> front door at go/mfmfrontdoor< 
> https://urldefense.com/v3/__https://onc.jira.usaacloud.com/secure/Dash
> board.jspa?selectPageId=15466__;!!GryZGb6B1VCs0SfC!XavpJVotC1FDzbPYC6D
> UPI2ZAGWiVF08MgtKLVmLjoEb0U3yAV8t9Ev7UE96IhgV-cw$ >
>
> Classification: Internal
>
> Disclaimer: This email and any attachments are the property of USAA 
> and may contain confidential and/or privileged material. If you are 
> not the intended recipient, any use, disclosure or copying of this 
> email or any attachments is unauthorized. If you received this email 
> in error, please immediately notify the sender and delete the email 
> and any attachments from your computer.
>
>
> --
> 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

Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

I've been trying to track down what's causing system 1M page demotions on our 
test system.  The component trace IBM gave me shows, in part:

SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
 FUNC1... COPYSRVH  High Virtual Copy Service
 JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
 JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
 KEY. 0036 ADDR 035E1008 ALET 

The COPYSRVH function isn't well documented but, from I see, UNIX fork 
processing invokes it to copy memory to the new process.  This makes sense in 
that JOBN1 and JOBN3 are both USS processes.

Both LFAREA and SCM on this system are less than 1% used.  Why is z/OS demoting 
pages?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

Classification: Internal

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.


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

Re: EXTERNAL: Re: LFAREA in z/OS 2.3

[Crawford, Robert C.]

>From my research (and some Share presentations) my understanding is that, 
>prior to 2.3, z/OS reserved large frames at IPL time which would make them 
>unavailable for 4K pages unless the system broke them up.

Making LFAREA a limit rather than a reservation is much better.  

My question, essentially, is if there is any penalty for leaving LFAREA much 
higher than required.  

I'm asking because it's tempting to set some parameters artificially high so 
you don't have mess with them but there's a hidden cost.  One example is CICS 
max task (MXT).  A lot of shops set it to the max of 999 which causes WLM to 
waste a lot of CPU going through unused performance data blocks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Harris Morgenstern
Sent: Monday, March 29, 2021 9:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: LFAREA in z/OS 2.3

Prior to V2R3 the specification of the 1M LFAREA resulted in storage being 
physically reserved for  LFAREA frames (used to back IARV64 PAGEFRAMESIZE=1Meg 
requests), but 
which could potentially be used for other purposes.   If the system
ran low on memory,  the 1M LFAREA could  be used to satisfy  non-LFAREA 
real storage requests.   So even though the 1M LFAREA was a reservation, 
the reservation could be broken and so
it might have behaved more like a limit. 

In V2R3 and above, the real storage management is more effective at reducing 
fragmentation,
resulting in more available  1Meg units of real.   The need for the 1M 
LFAREA (as a reservation)  went away. 




Harris Morgenstern
z/OS Storage Management and System REXX
Dept. OBPA
IBM Poughkeepsie
8-295-4221 
hmor...@us.ibm.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

LFAREA in z/OS 2.3

[Crawford, Robert C.]

According to the documentation, after z/OS 2.3 the LFAREA parameter no longer 
reserves real memory for large frames at IPL.  Instead, it's a limit on the 
number of fixed 1M frames.

Since it's now a limit is there any harm in leaving LFAREA too high as long as 
you keep an eye on large fixed frame usage and paging?

I'm asking because we have some LPAR's with wildly underused LFAREA's and few 
opportunities to exploit them.  The lazy systems programmer in me would rather 
leave LFAREA alone rather than try to pick a target value that needs to be 
closely managed.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor


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

IPSEC Configuration and Performance

[Crawford, Robert C.]

We're considering using IPSEC to secure traffic between an internal router and 
a CICS application.  Can anyone on this list give us any hints, tips or gotchas 
they may have from doing something similar themselves.

Thanks in advance.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor


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

SIIS and VTFM

[Crawford, Robert C.]

There was a lot of discussion at the last Share about how store in instruction 
stream (SIIS) can be a drag on performance.  An MXG report revealed we have a 
high SIIS percentage in our zIIP's but the only thing running of note at the 
time was Virtual Tape for Mainframe (VTFM).

Someone told me a while ago that VTFM dynamically changes channel programs in 
memory to redirect tape I/O to DASD.  Is that true?  If it is, would said 
jimmying of channel programs drive high SIIS percentages?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Est multum ineptias atque in volumine petram et de illius ineptias est 
pulchellus frigus."
- Virgil
Please send requests to Mainframe Management through our front door at go/mfm


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

Re: EXTERNAL: Mobile pricing query

[Crawford, Robert C.]

We were fortunate in that we implemented communication between our midrange and 
host through infrastructure.  The midrange infrastructure detects the mobile 
request and flags the message.  The host infrastructure records the flag in our 
performance data.  By using the infrastructure we didn't need to make any 
application coding changes.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822 

“Est multum ineptias atque in volumine petram et de illius ineptias est 
pulchellus frigus.”
- Virgil
Please send requests to Mainframe Management through our front door at go/mfm

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Laurence Chiu
Sent: Wednesday, June 19, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Mobile pricing query

Looking at the options of using mobile pricing as a way to manage our 
increasing CPU cost, just wondering if readers of this list have implemented 
mobile pricing and if so, was it hard to do and the benefits worthwhile?

I'm trying to counter some arguments internally that the reporting requirements 
including potential application coding changes to tag the workload, would 
outweigh any pricing benefits.

I'm just interested in general experiences, nothing specific.

Thanks

Larry

--
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: article about Grace Hopper, developer of COBOL

[Crawford, Robert C.]

Cool!

I got to hear her speak at Texas A&M University in '81.  She was funny, smart 
and made plain that she didn't take guff from anybody.  A great techie. 

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822 

Manchmal ist das Denken lästig.
- Albert Einstein 
Please send requests to Mainframe Management through our front door at go/mfm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: Thursday, January 10, 2019 7:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: article about Grace Hopper, developer of COBOL

Navigate to page A8 for interesting article about Grace Hopper, developer of 
COBOL

https://urldefense.proofpoint.com/v2/url?u=http-3A__paper.amny.com_html5_reader_production_default.aspx-3F-26pubid-3D4af0aa34-2D706c-2D410d-2Da9ff-2Df93a3c23b1c7&d=DwIFAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=ZyZdGidsLn0WzhB4qFUXAIlLSRuVkwsGwQAj9EUr4ks&m=2YM_BdYvvW43W9bv1emxjwi4Hv09wbJXnuQfLFxkgX0&s=pJwtaIAv_WVW_6fifIY_g7K-XZjBK3o53XKQJoewGm4&e=



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

--
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: Generic query on Region allocation failure

[Crawford, Robert C.]

We went through a similar round of problems with private areas below the line.

You have to remember that the REGION parameter or whatever is SMFLIMxx is a 
limit, not an allocation.  In other words, specifying REGION=7M doesn't mean 
the program will use 7 megs, it means it can't use more than 7 megs.  
Therefore, to my mind, there's no harm in setting limits as high as possible 
while reserving enough storage for the system and let everyone have at it.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822 

Manchmal ist das Denken lästig.
- Albert Einstein 
Please send requests to Mainframe Management through our front door at go/mfm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, January 08, 2019 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Generic query on Region allocation failure

Usually such ABEND codes have a reason in R15 and a message in the job log. 
Please include those when you ask for help.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Wayne Bickerdike 
Sent: Tuesday, January 8, 2019 2:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure

We keep seeing S106 abends trying to run DFHEISUP utility.

It's been discussed a few times on various fora but no definitive solution yet.

At CICS 5.2 it ran fine.5.3 it's hit and miss and 5.4 just plain doesn't  work.

All permutations of region size, MEMLIMIT=NOLIMIT, no IEFUSI have worked.
Tried on 4 different systems. No joy. PMR time..


On Wed, Jan 9, 2019 at 6:19 AM Carmen Vitullo  wrote:

> A good point, I myself have overlooked STC's region size because it's 
> never been a problem, I see some tasks never updated for 10+ years and 
> still have very small regions sizes.
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Jesse 1 Robinson" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, January 8, 2019 1:13:14 PM
> Subject: Re: Generic query on Region allocation failure
>
> This post is not intended to be enlightening; it's merely corroborative.
> We recently went from z12EC to z14. We had already upgraded to z/OS 
> 2.3 with hardware support service. In the week or so afterwards, we 
> experienced a handful of 'storage shortage abends' in tasks that had 
> been running unchanged for years. AFAIK no technical explanations ever 
> came forth. In the few PMRs we opened, the advice was to increase region 
> size. We did.
> Problems went away. Move on.
>
> I do have one piece of advice. Never specify a smallish region size. 
> If it's worth your time and effort to type in any region size at all, 
> go for some number >16M. It generally costs nothing and may save some 
> debugging grief down the road. I've seen cases where 0M may be 
> required for a particular product. Again, the cost of doing so is minimal. 
> Why quibble?
> Someone needs to refresh the communal coffee pot.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Tuesday, January 08, 2019 7:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Generic query on Region allocation failure
>
> On Tue, 8 Jan 2019 10:16:00 +0400, Jake Anderson wrote:
>
> >IEF085I REGION NOT AVAILABLE ERROR CODE = 20 IEF187I NJJJ FAILED 
> >- SYSTEM ERROR IN INITIATOR IEF472I NJJJ
>
> That means that the region that was specified is not available.
>
> Most likely, the region specified is less than 16M and that much 
> storage is not available below the line. It is certainly possible that 
> the available region size below the line is smaller on your old system 
> than is available on your new system.
>
> --
> 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
>


--
Wayne V. Bickerdike

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

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

Re: EXTERNAL: Exit Calls or Using

[Crawford, Robert C.]

Instruction fetch SLIP trap that creates a trace record every time the exit is 
or is not entered?

Unfortunately, negatives like this are very hard to prove.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822 

Manchmal ist das Denken lästig.
- Albert Einstein 
Please send requests to Mainframe Management through our front door at go/mfm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Wednesday, January 02, 2019 10:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Exit Calls or Using

Hi

Is there a way to determine if an EXIT is being used by anyone ? Like to know 
the number of times it is called for performing any functions or if it is 
invoked ?

I am trying to take some list of obsolete EXITS which are not being used .

Peter

--
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: Creating .xls on z/OS

[Crawford, Robert C.]

I've used POI to create simple, straightforward spreadsheets and it works fine. 
 The program is easy enough although I'm not sure what complications have been 
introduced with Excel 2007.

Robert Crawford
CICS Technical Support
United Services Automobile Association
(210) 913-3822 
For Service Requests please use our Customer Portal. 
"Seek not to follow in the footsteps of the wise;  seek what they sought." - 
Matsuo Basho, poet (1644-1694) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Friday, September 14, 2012 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Creating .xls on z/OS

Supposedly, but I haven't actually tried. Look at:
http://poi.apache.org/

The Apache POI Project's mission is to create and maintain Java APIs for 
manipulating various file formats based upon the Office Open XML standards 
(OOXML) and Microsoft's OLE 2 Compound Document format (OLE2). In short, you 
can read and write MS Excel files using Java. In addition, you can read and 
write MS Word and MS PowerPoint files using Java. Apache POI is your Java Excel 
solution (for Excel 97-2008). We have a complete API for porting other OOXML 
and OLE2 formats and welcome others to participate. 

OLE2 files include most Microsoft Office files such as XLS, DOC, and PPT as 
well as MFC serialization API based file formats. The project provides APIs for 
the OLE2 Filesystem (POIFS) and OLE2 Document Properties (HPSF). 

Office OpenXML Format is the new standards based XML file format found in 
Microsoft Office 2007 and 2008. This includes XLSX, DOCX and PPTX. The project 
provides a low level API to support the Open Packaging Conventions using 
openxml4j. 

For each MS Office application there exists a component module that attempts to 
provide a common high level Java api to both OLE2 and OOXML document formats. 
This is most developed for Excel workbooks (SS=HSSF+XSSF). Work is progressing 
for Word documents (HWPF+XWPF) and PowerPoint presentations (HSLF+XSLF). 

The project has recently added support for Outlook (HSMF). Microsoft opened the 
specifications to this format in October 2007. We would welcome contributions. 

There are also projects for Visio (HDGF), TNEF (HMEF), and Publisher (HPBF). 

As a general policy we collaborate as much as possible with other projects to 
provide this functionality. Examples include: Cocoon for which there are 
serializers for HSSF; Open Office.org with whom we collaborate in documenting 
the XLS format; and Tika / Lucene, for which we provide format interpretors. 
When practical, we donate components directly to those projects for 
POI-enabling them. 



--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Walter Marguccio
> Sent: Friday, September 14, 2012 8:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Creating .xls on z/OS
> 
> Hello all,
> 
> I've been asked if there is the possibility to create Excel tables
> (.xls) files on z/OS,
> using a batch job. I've searched the archives, the developerwork IBM's 
> site, redbooks, but found no clue.
> We run the XMITIP tool which is able to create .csv files, but this 
> seems not enough.
> 
> We are at z/OS 1.13, with Java 6.0.1, and Perl from the Ported Tools, 
> 1.2.0.
> 
> Any thoughts, experiences links, books ?
> 
> 
> Walter Marguccio
> z/OS Systems Programmer
> BELENUS LOB Informatic GmbH
> Munich - Germany
> 
> --
> 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