Re: z/OSMF and the Old Timer

[Marna WALLE]

Hi Tom,
Glad to see that you are getting back on track. For your catalog question, it 
sounds like you want to use your existing mcat for your new z/OS V2.5 system.  
That's fine.  If you use your existing mcat, you've got to be using indirect 
cataloging. That is reasonable, as you'd want to use that mcat for both an old 
instance and new instance, which are on different volumes.  You can create new 
ucat if you like, into your existing mcat, if you desired. 

For keeping your existing mcat (and it is using indirect entries) you are 
correct in saying that is on the Objectives section, and you should select 
Existing master catalog:
---cut and paste from the screen---
Catalogs:
Are you deploying z/OS? YES
 
Indicate which catalogs to use for the new target z/OS data sets. For 
additional help on making the proper selection Learn more...

__New target system master catalog: Target system data sets will be cataloged 
in a new master catalog or new user catalogs connected to the new master 
catalog.
 
X  Existing master catalog: Target system data sets will be cataloged in the 
existing master catalog, existing user catalogs, or new user catalogs connected 
to the existing master catalog.
 

If you click on "Help" on that screen, and then "Catalogs" within the help, 
there are some good pictures which show what will happen with your existing 
mcat. 

What is the "Existing master catalog" option there for?  To know whether z/OSMF 
Software Management needs to create a new mcat for you, or to verify that the 
existing mcat you are using can correctly represent the system you are building 
with the matching entries (like SYS1.LINKLIB).  

You're getting there!  Often the first time through the interface, if you 
haven't practiced with a smaller product, can be harder.  z/OS is big, and can 
be a lot to get through.  But I'm very happy to see that you are modelling 
after z/OS V2.4 which will definitely help. 

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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

Re: Is the IBM Assembler List still alive - TSO alternatives

[Bill Hitefield]

TONE was a single-address space player too. I converted a shop from VS1 to 
MVS/370. On the VS1 machine we had TONE (TSO for VS1). It worked fairly well, 
other than the fact it was a single address space. I do recall when we went 
live with MVS/370 on our first weekend test, none of the developers wanted to 
go back to TONE. They really preferred TSO and ISPF to TONE.

At a shop I worked at on the Texas Gulf coast we ran VS2 (prior to MVS being an 
actual product). We were one of the first sites in the are to try SPF (before 
"I"SPF was a thing). It was a new concept, as everyone was used to ye olde line 
editor (this was in the 70s). Once you picked up on what SPF was doing, it made 
work a whole lot easier.

Bill Hitefield

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Leonard D Woren
> Sent: Thursday, September 07, 2023 9:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
> 
> 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

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

[Steve Thompson]

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

Re: Ray Mullins on Assembler demand.

[Seymour J Metz]

There's a difference between "learn" and "use". The original context was 
learning a language, which is rather vague.


From: IBM Mainframe Discussion List  on behalf of 
Andrew Rowley 
Sent: Thursday, September 7, 2023 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ray Mullins on Assembler demand.

On 7/09/2023 1:38 am, Seymour J Metz wrote:
> With that definition the learning curve is very different.

You don't need to learn all the classes to use Java. It obviously helps
if you know they are there, but if you know the commonly used classes
and know how to find information when you hit a "how do I..." question
you will be fine.

Inheritance and interfaces help immensely, because many classes have
common interfaces so you only really need to learn them if you need
their particular specialization.

--
Andrew Rowley
Black Hill Software

--
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: Is the IBM Assembler List still alive - Dumps - Early days

[Bill Johnson]

I agree. ROSCOE was clunky & less productive. I’ve never used the other TSO 
alternatives.
I seem to remember vaguely ROSCOE requiring the user to “attach” the member you 
wanted to edit but that was 35 years ago.


Sent from Yahoo Mail for iPhone


On Thursday, September 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

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

[Mike Schwab]

Roscoe was one address space so everything was there when you logged
in.  Much like using a CICS editor.

On Thu, Sep 7, 2023 at 8: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



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

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

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

[Leonard D Woren]

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

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

[Wayne Bickerdike]

I used ROSCOE in a couple of sites. Once you got used to it, it was better
than TSO EDIT with the same footprint.

RPF was easier to master than ISPF/PDF and it had a lot of similarities
with REXX.

I regressed back to a DOS/VSE shop for a while. A 4331 with 1 MB of memory.
We managed to run CICS with ADABAS and write all the code in PL/I. ICCF was
our only editor. It was a dog. A few years later I found myself in another
VSE shop and they had VOLLIE. Way better than ICCF.

On Fri, Sep 8, 2023 at 10:42 AM Roberto Halais 
wrote:

> This list is becoming like Tik Tok. Enough.
>
> On Thu, Sep 7, 2023 at 8:37 PM Lance D. Jackson <
> ljack...@pandrueassociates.com> wrote:
>
> > UNSUBSCRIBE- I'm OUT!  You guys go on far too long about stories no one
> > else is interested in.  You should consider taking these drawn out
> > discussions offline.
> >
> > > On 07/09/2023 15:56 EDT Leonard D Woren 
> wrote:
> > >
> > >
> > > What was the first OS that you had a 2 MB TSO region?  What hardware.
> > >
> > > MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> > > you could do, although it was slow.  I did experiment with overlay
> > > modules though.  Bleah.
> > >
> > > The reason you could do a lot in 3/4 MB is that it was done in
> > > efficient languages, like Assembler.  None of these modern bloatware
> > > languages that make every app on my phone 32 MB minimum, and often up
> > > to 500 MB.
> > >
> > > /Leonard
> > >
> > >
> > > Seymour J Metz wrote on 9/7/2023 3:32 AM:
> > > > I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf of Clem Clarke 
> > > > Sent: Wednesday, September 6, 2023 6:38 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: Is the IBM Assembler List still alive - Dumps - Early
> days
> > > >
> > > >
> > > > Running TSO in 3/4 of a meg was interesting.  And VERY slow.
> > > >
> > >
> > > --
> > > 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
>


-- 
Wayne V. Bickerdike

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

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

[Roberto Halais]

This list is becoming like Tik Tok. Enough.

On Thu, Sep 7, 2023 at 8:37 PM Lance D. Jackson <
ljack...@pandrueassociates.com> wrote:

> UNSUBSCRIBE- I'm OUT!  You guys go on far too long about stories no one
> else is interested in.  You should consider taking these drawn out
> discussions offline.
>
> > On 07/09/2023 15:56 EDT Leonard D Woren  wrote:
> >
> >
> > What was the first OS that you had a 2 MB TSO region?  What hardware.
> >
> > MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> > you could do, although it was slow.  I did experiment with overlay
> > modules though.  Bleah.
> >
> > The reason you could do a lot in 3/4 MB is that it was done in
> > efficient languages, like Assembler.  None of these modern bloatware
> > languages that make every app on my phone 32 MB minimum, and often up
> > to 500 MB.
> >
> > /Leonard
> >
> >
> > Seymour J Metz wrote on 9/7/2023 3:32 AM:
> > > I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf of Clem Clarke 
> > > Sent: Wednesday, September 6, 2023 6:38 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
> > >
> > >
> > > Running TSO in 3/4 of a meg was interesting.  And VERY slow.
> > >
> >
> > --
> > 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: Is the IBM Assembler List still alive - Dumps - Early days

[Lance D. Jackson]

UNSUBSCRIBE- I'm OUT!  You guys go on far too long about stories no one else is 
interested in.  You should consider taking these drawn out discussions offline.

> On 07/09/2023 15:56 EDT Leonard D Woren  wrote:
> 
>  
> What was the first OS that you had a 2 MB TSO region?  What hardware.
> 
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot 
> you could do, although it was slow.  I did experiment with overlay 
> modules though.  Bleah.
> 
> The reason you could do a lot in 3/4 MB is that it was done in 
> efficient languages, like Assembler.  None of these modern bloatware 
> languages that make every app on my phone 32 MB minimum, and often up 
> to 500 MB.
> 
> /Leonard
> 
> 
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
> > I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf of 
> > Clem Clarke 
> > Sent: Wednesday, September 6, 2023 6:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
> >
> >
> > Running TSO in 3/4 of a meg was interesting.  And VERY slow.
> >
> 
> --
> 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: Is the IBM Assembler List still alive - Dumps - Early days

[Bill Johnson]

Agree. 


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 8:00 PM, Matt Hogstrom  
wrote:

We used it at a bank because of the number of application developers.  TSO was 
reserved for system programmers.  Also, it was limited in what you could do 
with the OS.  made sense for the purpose but it was not a lot of fun.  It was 
like being moderated at every turn.  TSO, was, Liberating.

Matt Hogstrom
PGP key 0F143BC1

> On Sep 7, 2023, at 15:41, Bob Bridges  wrote:
> 
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources.

--
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: Is the IBM Assembler List still alive - Dumps - Early days

[Bill Johnson]

I didn’t start it. But, I’ll bet I get the warnings.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 7:21 PM, Bob Bridges  
wrote:

And, they're off again.

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

/* "If dickering won't work, then you have to fight.  But I think maybe it 
takes a man who has been shot at to appreciate how much better it is to fumble 
your way through a political compromise rather than have the top of your head 
blown off."  He frowned and suddenly looked very old.  "When to talk and when 
to fight -- that is the most difficult decision to make wisely of all the 
decisions in life."  -from _Podkayne of Mars_, by Robert A Heinlein */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, September 7, 2023 18:50

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it behooves you 
to write more correctly.
It might even increase your credibility.

--- On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.

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




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

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

[Bill Johnson]

1972-3. My high school was rated one of the best high schools in America. And 
just recently received an award for being one of the best again. (Last week)

The Ohio rankings are dragged down by white rural MAGA schools and inner city 
students. The suburban schools in my area are top performers, nationally.

I’ve been published approximately 100 times in the local newspaper. Also in 
Information Week. Mostly political in the newspaper. Because I’m politically 
active. I also ran for commissioner. Ran 2 businesses, including one that did 
business with the mafia. Was on the Millionaire show with Regis. Missed the hot 
seat by .08. I was 4 time spelling runner up in grade school. My spelling and 
grammar can be perfect when I care. Which I don’t on this list. Heck, some 
posters are barely literate. I’m making you the grammar and spelling police.







Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 7:14 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
According to a recent study, Ohio ranked 36. I'm not so sure I would want to 
boast about that.

Please see: 2023’s States with the Best & Worst School Systems 
(wallethub.com)

Regards,
David
[https://cdn.wallethub.com/wallethub/posts/94009/states-with-the-best-worst-school-systems.png]
2023’s States with the Best & Worst School 
Systems
wallethub.com


From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: September 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the 
awards program. I’m very proud of it and my Math expertise paid off handsomely.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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

--
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: Is the IBM Assembler List still alive - Dumps - Early days

[Matt Hogstrom]

We used it at a bank because of the number of application developers.  TSO was 
reserved for system programmers.   Also, it was limited in what you could do 
with the OS.  made sense for the purpose but it was not a lot of fun.  It was 
like being moderated at every turn.  TSO, was, Liberating.

Matt Hogstrom
PGP key 0F143BC1

> On Sep 7, 2023, at 15:41, Bob Bridges  wrote:
> 
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources.

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

Re: Ray Mullins on Assembler demand.

[Andrew Rowley]

On 7/09/2023 1:38 am, Seymour J Metz wrote:

With that definition the learning curve is very different.


You don't need to learn all the classes to use Java. It obviously helps 
if you know they are there, but if you know the commonly used classes 
and know how to find information when you hit a "how do I..." question 
you will be fine.


Inheritance and interfaces help immensely, because many classes have 
common interfaces so you only really need to learn them if you need 
their particular specialization.


--
Andrew Rowley
Black Hill Software

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

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

[Bob Bridges]

And, they're off again.

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

/* "If dickering won't work, then you have to fight.  But I think maybe it 
takes a man who has been shot at to appreciate how much better it is to fumble 
your way through a political compromise rather than have the top of your head 
blown off."  He frowned and suddenly looked very old.  "When to talk and when 
to fight -- that is the most difficult decision to make wisely of all the 
decisions in life."  -from _Podkayne of Mars_, by Robert A Heinlein */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, September 7, 2023 18:50

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it behooves you 
to write more correctly.
It might even increase your credibility.

--- On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.

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

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

[Bill Johnson]

English your second language? The program from the awards ceremony. I still 
have it.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 7:15 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... I still have the awards program ..."
Please translate this statement into English.

Regards,
David

From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: September 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the 
awards program. I’m very proud of it and my Math expertise paid off handsomely.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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

--
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: Is the IBM Assembler List still alive - Dumps - Early days

[David Spiegel]

Hi Bill,
You said: "... I still have the awards program ..."
Please translate this statement into English.

Regards,
David

From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: September 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the 
awards program. I’m very proud of it and my Math expertise paid off handsomely.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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

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

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

[David Spiegel]

Hi Bill,
According to a recent study, Ohio ranked 36. I'm not so sure I would want to 
boast about that.

Please see: 2023’s States with the Best & Worst School Systems 
(wallethub.com)

Regards,
David
[https://cdn.wallethub.com/wallethub/posts/94009/states-with-the-best-worst-school-systems.png]
2023’s States with the Best & Worst School 
Systems
wallethub.com


From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: September 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the 
awards program. I’m very proud of it and my Math expertise paid off handsomely.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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

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

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

[Bill Johnson]

Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the 
awards program. I’m very proud of it and my Math expertise paid off handsomely.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it 
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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: Is the IBM Assembler List still alive - Dumps - Early days

[Bill Johnson]

LOLOLOLOL, I love that you’re obsessed with me. Are you getting enough sleep?


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 6:50 PM, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it 
behooves you to write more correctly.
It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:
> We used to use ROSCOE at a small shop in the 80’s because it used less 
> resources. I hated it.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
>  wrote:
>
> What was the first OS that you had a 2 MB TSO region?  What hardware.
>
> MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
> you could do, although it was slow.  I did experiment with overlay
> modules though.  Bleah.
>
> The reason you could do a lot in 3/4 MB is that it was done in
> efficient languages, like Assembler.  None of these modern bloatware
> languages that make every app on my phone 32 MB minimum, and often up
> to 500 MB.
>
> /Leonard
>
>
> Seymour J Metz wrote on 9/7/2023 3:32 AM:
>> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Clem Clarke 
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>>
>>
>> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>>
> --
> 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: Is the IBM Assembler List still alive - Dumps - Early days

[David Spiegel]

Hi Bill,
You said: "... because it used less resources ..."
Shmegegge, you should've said "fewer". That is the correct usage.
For a guy who knows so much about about a multitude of topics, it 
behooves you to write more correctly.

It might even increase your credibility.

Regards,
David

On 2023-09-07 16:05, Bill Johnson wrote:

We used to use ROSCOE at a small shop in the 80’s because it used less 
resources. I hated it.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
 wrote:

What was the first OS that you had a 2 MB TSO region?  What hardware.

MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
you could do, although it was slow.  I did experiment with overlay
modules though.  Bleah.

The reason you could do a lot in 3/4 MB is that it was done in
efficient languages, like Assembler.  None of these modern bloatware
languages that make every app on my phone 32 MB minimum, and often up
to 500 MB.

/Leonard


Seymour J Metz wrote on 9/7/2023 3:32 AM:

I never had TSO in less than 2 MiB; 768 KiB gives me shudders.


From: IBM Mainframe Discussion List  on behalf of Clem 
Clarke 
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days


Running TSO in 3/4 of a meg was interesting.  And VERY slow.


--
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: Is the IBM Assembler List still alive - Dumps - Early days

[Seymour J Metz]

Not a 2 MiB region; that was the installed memory. I don't recall how big our 
TSO regions were. This was on a 370/165 running OS/360, then upgraded* to a 
370/168 running SVS. We had a fixd-head disk, which helped performance.

The students ran PL/I and FORTRAN programs on TSO, not just assembler.

* Yes, I know, you supposedly can only upgrade to a 370/165 II,
   but IBM really did not want the Technion to go to CDC.


From: IBM Mainframe Discussion List  on behalf of 
Leonard D Woren 
Sent: Thursday, September 7, 2023 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

What was the first OS that you had a 2 MB TSO region?  What hardware.

MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot
you could do, although it was slow.  I did experiment with overlay
modules though.  Bleah.

The reason you could do a lot in 3/4 MB is that it was done in
efficient languages, like Assembler.  None of these modern bloatware
languages that make every app on my phone 32 MB minimum, and often up
to 500 MB.

/Leonard


Seymour J Metz wrote on 9/7/2023 3:32 AM:
> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Clem Clarke 
> Sent: Wednesday, September 6, 2023 6:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>
>
> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>

--
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: z/OSMF and the Old Timer

[Tom Longfellow]

Yet another answer to my own post

I stripped out everything to do with the Software instances and deployments 
related to my Zos25 install.

I defined an instance  for my new deployment
This instance was modeled on my ZOS V2R4 install. The source for the instance 
is the downloaded ShopZ ZFS.
The Dataset names had to be trimmed due to assumptions and defaults prefixed to 
the Target dataset names.   The names were modified to match what they will 
have to be when I continue to use the indirect cataloging in my active system.
Volumes and Storage Classes were assigned to local standard locations for DASD 
placement.

Catalog Selection was NOT a chance to select a Catalog for these new to be 
created datasets.Job generations then fail with IZU9702E messages saying 
that the dataset in question is ALREADY in that Master Catalog that I am 
forcing you to use.

I am assuming that this is because I am NOT creating a new master of any kind 
(temporary or other).  This is because I actually read my choices for 
configuring the objectives of the install.  and the 'no new catalog' option 
where you IPL using your old indirect catalog entries from your existing master 
catalog described exactly what I think I want to do.   

Do I want to change the objectives to create a new catalog where all the 
building would be done?   If so, what the heck is the 'Existing' catalog 
objective for??

Time to step back and wait for a flash of brilliance to come to me.   
Mandatory cooling off period starts...  NOW

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

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

[Bill Johnson]

I had been using TSO/ISPF for a decade mostly at GM, then EDS when GM bought 
them. Before accepting the job at the small local company (hospital) that used 
ROSCOE. In my programming days.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 4:41 PM, Bob Bridges  
wrote:

If you can explain why without deriding anyone, Bill, I'd be interested in 
knowing why.  I first encountered ROSCOE in 1980 and used it for a while 
without thinking much about it.  When I realized I could change things around 
in it, I got excited.

It was another two years before I was exposed to ISPF.  I still have ROSCOE on 
my resume, but there isn't much excuse for it; I haven't touched it since then, 
so if anyone asked me to do anything with it I'd have to start over.

If you were already familiar with ISPF and thought ROSCOE a poorer product, I 
guess that makes sense.  I didn't know anything about ISPF until ~after~ 
ROSCOE, so I was unable to compare them.

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

/* A woman means by Unselfishness chiefly taking trouble for others; a man 
means not giving trouble for othersThus while the woman thinks of doing 
good offices and the man of respecting other people's rights, each sex, without 
any obvious unreason, can and does regard the other as radically selfish.  
-from The Screwtape Letters by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Thursday, September 7, 2023 16:06

We used to use ROSCOE at a small shop in the 80’s because it used less 
resources. I hated it.

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




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

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

[Bob Bridges]

If you can explain why without deriding anyone, Bill, I'd be interested in 
knowing why.  I first encountered ROSCOE in 1980 and used it for a while 
without thinking much about it.  When I realized I could change things around 
in it, I got excited.

It was another two years before I was exposed to ISPF.  I still have ROSCOE on 
my resume, but there isn't much excuse for it; I haven't touched it since then, 
so if anyone asked me to do anything with it I'd have to start over.

If you were already familiar with ISPF and thought ROSCOE a poorer product, I 
guess that makes sense.  I didn't know anything about ISPF until ~after~ 
ROSCOE, so I was unable to compare them.

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

/* A woman means by Unselfishness chiefly taking trouble for others; a man 
means not giving trouble for othersThus while the woman thinks of doing 
good offices and the man of respecting other people's rights, each sex, without 
any obvious unreason, can and does regard the other as radically selfish.  
-from The Screwtape Letters by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Thursday, September 7, 2023 16:06

We used to use ROSCOE at a small shop in the 80’s because it used less 
resources. I hated it.

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

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

[Bill Johnson]

We used to use ROSCOE at a small shop in the 80’s because it used less 
resources. I hated it.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 3:56 PM, Leonard D Woren 
 wrote:

What was the first OS that you had a 2 MB TSO region?  What hardware.

MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot 
you could do, although it was slow.  I did experiment with overlay 
modules though.  Bleah.

The reason you could do a lot in 3/4 MB is that it was done in 
efficient languages, like Assembler.  None of these modern bloatware 
languages that make every app on my phone 32 MB minimum, and often up 
to 500 MB.

/Leonard


Seymour J Metz wrote on 9/7/2023 3:32 AM:
> I never had TSO in less than 2 MiB; 768 KiB gives me shudders.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Clem Clarke 
> Sent: Wednesday, September 6, 2023 6:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>
>
> Running TSO in 3/4 of a meg was interesting.  And VERY slow.
>

--
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: Is the IBM Assembler List still alive - Dumps - Early days

[Leonard D Woren]

What was the first OS that you had a 2 MB TSO region?  What hardware.

MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot 
you could do, although it was slow.  I did experiment with overlay 
modules though.  Bleah.


The reason you could do a lot in 3/4 MB is that it was done in 
efficient languages, like Assembler.  None of these modern bloatware 
languages that make every app on my phone 32 MB minimum, and often up 
to 500 MB.


/Leonard


Seymour J Metz wrote on 9/7/2023 3:32 AM:

I never had TSO in less than 2 MiB; 768 KiB gives me shudders.


From: IBM Mainframe Discussion List  on behalf of Clem 
Clarke 
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days


Running TSO in 3/4 of a meg was interesting.  And VERY slow.



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

Re: z/OSMF and the Old Timer

[Tom Longfellow]

As always Marna - THANK YOU very much.  You are always a treasure trove of 
information.

I am ready to hand the reigns of the temporary HLQ manipulations back to 
z/OSMF, but am having some difficulties during Job Generation.
When I removed my 'unneeded' personal HLQ --- I got 800+ errors that 'you 
cannot define something that it already in the catalog'

I have tried 'juggling' catalog definitions without success.   
The Deployment is configured to use the 'Existing' catalogs and not create a 
new master because I wish to IPL from my standard master cat in use today.
Software Management detects that the final names already exist in the current 
master cat and stops.

Unfortunately - An aggressive flush of datasets has deleted datasets that 
belonged to the base Software Instance.   This has left me unable to define a 
workable Deployment at all.  Too many 'missing' datasets that are assumed to be 
there from the Software Management unzips from the Portable Software Instance 
downloaded  from my Software order.
I need to go back to Square Zero and re-Install my downloaded Portable Software 
Instance.

I am looking for a Rip and Replace set of steps that will take me back to 
creating my Software environment from my downloaded ShopZ order.
How do you totally clean the installation and its deployments back to that 
level?My latest hurdle is the DDDEFs in my previously manipulated GLOBAL 
and TARGET zones point to DSNs that no longer exist and cannot be recovered.
I have tried configuring to 'Use a New Master'  without success..   I have yet 
to see anywhere for me to influence or select the old SSA values.

It is always difficult to recover from failed, canned procedures that have 
failed spectacularly.

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

Re: There are good bosses and then there are the other kind

[Bill Johnson]

Disregard AI at your own peril.





OpenAI launches ChatGPT Enterprise, the firm's biggest announcement since 
ChatGPT.

https://www.cnbc.com/2023/08/28/openai-chatgpt-enterprise-launches.html






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

Re: There are good bosses and then there are the other kind

[Bill Johnson]

Agree completely. What really irked me was bosses who weren’t mainframe 
literate who thought they had a better grasp of what and how to solve mainframe 
issues.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2023, 12:55 PM, Retired Mainframer 
<03a485c129c3-dmarc-requ...@listserv.ua.edu> wrote:

I always gave my bosses two choices:
    Tell me what to do and I'll do it.
    Tell me what you want and I'll see that you get it.

It took a while for some to figure out that the second was a better option.
A few never did.

Very few could compare to your Mr. Condon but they were indeed a pleasure.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, September 7, 2023 3:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: There are good bosses and then there are the other kind

I remember with fondness an old warrant officer who

 1. Had firm ideas about what he wanted.
 2' Ensured that we understood what he wanted.
 3. Insisted that we give him what he wanted.
 4. Got out of our way and let us do our jobs.
 5. Had our backs.

On item 4, I don't mean that he was aloof; he was always available if we
wanted to discuss things. But I never saw him micromanaging.

Mr. Condon, wherever you are, it was a pleasure working for you.

--
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: Help on DFSORT SUM FIELDS

[Sri h Kolusu]

>> UBFLAG4 and UMFLAG4 are not recognized as valid names. As far as I can tell, 
>> the DCOLLECT record descriptors that I am using are the most recent ones on 
>> the IBM site, even if they are for z/OS 2.1.
Any suggestions?

Jack,

Looks like you have old symbols for DCollect. I will send an offline email with 
the updated symbols.



Thanks,
Kolusu
DFSORT Development
IBM Corporation


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

Re: There are good bosses and then there are the other kind

[Retired Mainframer]

I always gave my bosses two choices:
Tell me what to do and I'll do it.
Tell me what you want and I'll see that you get it.

It took a while for some to figure out that the second was a better option.
A few never did.

Very few could compare to your Mr. Condon but they were indeed a pleasure.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, September 7, 2023 3:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: There are good bosses and then there are the other kind

I remember with fondness an old warrant officer who

 1. Had firm ideas about what he wanted.
 2' Ensured that we understood what he wanted.
 3. Insisted that we give him what he wanted.
 4. Got out of our way and let us do our jobs.
 5. Had our backs.

On item 4, I don't mean that he was aloof; he was always available if we
wanted to discuss things. But I never saw him micromanaging.

Mr. Condon, wherever you are, it was a pleasure working for you.

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

Re: Help on DFSORT SUM FIELDS

[Jack Zukt]

Hi Kolusu,

UBFLAG4 and UMFLAG4 are not recognized as valid names. As far as I can
tell, the DCOLLECT record descriptors that I am using are the most recent
ones on the IBM site, even if they are for z/OS 2.1.
Any suggestions?
Best wishes
Jack

On Thu, 7 Sept 2023 at 17:15, Sri h Kolusu  wrote:

> >> DFSORT is a magnificent product but I still am in an very early user
> stage.
>
> Jack,
>
> Thank you very much.
>
> >> You are so right about that. I was waiting for having this right before
> I would attempt that step. I have to do this in small steps.
>
> It is quite simple to add it in the existing job itself.  All you need is
> to change the INREC. Here are the updated control cards.  I added comments
> so that it is easy to see what is changed/added
>
> //SYSINDD *
>   OPTION VLSCMP,DYNALLOC=(,4)
>   INCLUDE COND=(DCURCTYP,EQ,DCUDATAT,OR, * DATA RECORD
> DCURCTYP,EQ,UKTMIGR,OR,  * MIGR RECORD
> DCURCTYP,EQ,UKTBACK) * BACKUP RECORD
>
> ** Parse the datasetname for HLQ and init the space values
>
>   INREC IFTHEN=(WHEN=INIT,
>PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
>  OVERLAY=(FMT-HLQ:%01,
>   TMP-DCDALLSP:8Z,
>   TMP-UMALLSP:8Z,
>   TMP-UBALLSP:8Z)),
>
> ** If allocated space is 31-bit value for type "D" records
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT,AND,
>   DCDFLAG2,EQ,DCDALLFG),
>  OVERLAY=(TMP-DCDALLSP2:DCDALLSP),HIT=NEXT),
>
> ** If allocated space is 64-bit value for type "D" records
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT,AND,
>   DCDFLAG5,EQ,DCDALLFX),
>  OVERLAY=(TMP-DCDALLSP:DCDALLSX)),
>
> ** Assume allocated space is in "KB" for type "M" records
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
>  OVERLAY=(TMP-UMALLSP2:UMALLSP),HIT=NEXT),
>
> ** Check if allocated spaces is in "MB" for type "M" records and
> ** convert it to KB value by multiplying with +1024
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR,AND,
>   UMFLAG4,EQ,UMALLSP_FMB),
>  OVERLAY=(TMP-UMALLSP:UMALLSP,MUL,+1024,BI,LENGTH=8)),
>
> ** Assume allocated space is in "KB" for type "B" records
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTBACK),
> OVERLAY=(TMP-UBALLSP2:UBALLSP),HIT=NEXT),
>
> ** Check if allocated spaces is in "MB" for type "B" records and
> ** convert it to KB value by multiplying with +1024
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTBACK,AND,
>   UBFLAG4,EQ,UBALLSP_FMB),
>  OVERLAY=(TMP-UBALLSP:UBALLSP,MUL,+1024,BI,LENGTH=8))
>
>   SORT FIELDS=(FMT-HLQ,A)   * SORT BY DATASET HLQ
> *
>   SUM FIELDS=(TMP-DCDALLSP, * SUM ALLOC SPACE
>   TMP-UMALLSP,  * SUM MIGRAT SPACE
>   TMP-UBALLSP)  * SUM BACKUP SPACE
> *
>   OUTREC BUILD=(1,4,
> FMT-HLQ,
> X,
> TMP-DCDALLSP,EDIT=(III.III.III.III.IIT),
> C' KB ',
> TMP-UMALLSP,EDIT=(III.III.III.III.IIT),
> C' KB ',
> TMP-UBALLSP,EDIT=(III.III.III.III.IIT),
> C' KB ')
> /*
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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

Coupling Facility volatility status

[Radoslaw Skorupka]

CF volatility status depends on IBF (Internal Battery Feature).
Without IBF the status is volatile, however when external UPS is used 
you may change the status manually using operator command.


Q: Is it possible to change default status? I mean some hidden checkbox 
in Image profile or parameter in CFRM definition.


My comment: IBF is rarely used and AFAIK z15 (or z16) is the last 
machine with that option. From the other hand UPS is quite obvious 
equipment nowadays. So most CF users have to manually change the 
volatility status everytime the CF is re-activated.



--
Radoslaw Skorupka
Lodz, Poland

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

Re: Help on DFSORT SUM FIELDS

[Sri h Kolusu]

>> DFSORT is a magnificent product but I still am in an very early user stage.

Jack,

Thank you very much.

>> You are so right about that. I was waiting for having this right before I 
>> would attempt that step. I have to do this in small steps.

It is quite simple to add it in the existing job itself.  All you need is to 
change the INREC. Here are the updated control cards.  I added comments so that 
it is easy to see what is changed/added

//SYSINDD *
  OPTION VLSCMP,DYNALLOC=(,4)
  INCLUDE COND=(DCURCTYP,EQ,DCUDATAT,OR, * DATA RECORD
DCURCTYP,EQ,UKTMIGR,OR,  * MIGR RECORD
DCURCTYP,EQ,UKTBACK) * BACKUP RECORD

** Parse the datasetname for HLQ and init the space values

  INREC IFTHEN=(WHEN=INIT,
   PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
 OVERLAY=(FMT-HLQ:%01,
  TMP-DCDALLSP:8Z,
  TMP-UMALLSP:8Z,
  TMP-UBALLSP:8Z)),

** If allocated space is 31-bit value for type "D" records

IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT,AND,
  DCDFLAG2,EQ,DCDALLFG),
 OVERLAY=(TMP-DCDALLSP2:DCDALLSP),HIT=NEXT),

** If allocated space is 64-bit value for type "D" records

IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT,AND,
  DCDFLAG5,EQ,DCDALLFX),
 OVERLAY=(TMP-DCDALLSP:DCDALLSX)),

** Assume allocated space is in "KB" for type "M" records

IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
 OVERLAY=(TMP-UMALLSP2:UMALLSP),HIT=NEXT),

** Check if allocated spaces is in "MB" for type "M" records and
** convert it to KB value by multiplying with +1024

IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR,AND,
  UMFLAG4,EQ,UMALLSP_FMB),
 OVERLAY=(TMP-UMALLSP:UMALLSP,MUL,+1024,BI,LENGTH=8)),

** Assume allocated space is in "KB" for type "B" records

IFTHEN=(WHEN=(DCURCTYP,EQ,UKTBACK),
OVERLAY=(TMP-UBALLSP2:UBALLSP),HIT=NEXT),

** Check if allocated spaces is in "MB" for type "B" records and
** convert it to KB value by multiplying with +1024

IFTHEN=(WHEN=(DCURCTYP,EQ,UKTBACK,AND,
  UBFLAG4,EQ,UBALLSP_FMB),
 OVERLAY=(TMP-UBALLSP:UBALLSP,MUL,+1024,BI,LENGTH=8))

  SORT FIELDS=(FMT-HLQ,A)   * SORT BY DATASET HLQ
*
  SUM FIELDS=(TMP-DCDALLSP, * SUM ALLOC SPACE
  TMP-UMALLSP,  * SUM MIGRAT SPACE
  TMP-UBALLSP)  * SUM BACKUP SPACE
*
  OUTREC BUILD=(1,4,
FMT-HLQ,
X,
TMP-DCDALLSP,EDIT=(III.III.III.III.IIT),
C' KB ',
TMP-UMALLSP,EDIT=(III.III.III.III.IIT),
C' KB ',
TMP-UBALLSP,EDIT=(III.III.III.III.IIT),
C' KB ')
/*

Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: Help on DFSORT SUM FIELDS

[Jack Zukt]

Kolusu,
You are so right about that. I was waiting for having this right before I
would attempt that step.
DFSORT is a magnificent product but I still am in an very early user stage.
I have to do this in small steps.
Thank you once again for your help
Best wishes
Jack

On Thu, 7 Sept 2023 at 16:33, Sri h Kolusu  wrote:

> >> Of course it was that. That is what happens when you copy something so
> it you will not have to write everything from scratch.
>
> Jack,
>
> Glad to hear that the issue is resolved. I wanted to bring this up
> yesterday itself. you may want to check if the space values you are getting
> are indeed 31-bit values.
>
> For example, the Type "D" records, you need to look at the flags.
>
> DCDALLSP,*,4,FIDATA SET ALLOCATED SPACE IN KBS (1024)
> WHEN DCDALLFG IS ON
>
>  DCDFLAG5,*,1,BIINFORMATION FLAG #5
>DCDALLFX,B'1...'   63BIT ALLOCATED SPACE IN DCDALLSX
>
>
> Similarly you need to check for record types "B" and "M"
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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: Help on DFSORT SUM FIELDS

[Sri h Kolusu]

>> Of course it was that. That is what happens when you copy something so it 
>> you will not have to write everything from scratch.

Jack,

Glad to hear that the issue is resolved. I wanted to bring this up yesterday 
itself. you may want to check if the space values you are getting are indeed 
31-bit values.

For example, the Type "D" records, you need to look at the flags.

DCDALLSP,*,4,FIDATA SET ALLOCATED SPACE IN KBS (1024)
WHEN DCDALLFG IS ON

 DCDFLAG5,*,1,BIINFORMATION FLAG #5
   DCDALLFX,B'1...'   63BIT ALLOCATED SPACE IN DCDALLSX


Similarly you need to check for record types "B" and "M"

Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: Help on DFSORT SUM FIELDS

[Jack Zukt]

Kolusu,

Of course it was that. That is what happens when you copy something so it
you will not have to write everything from scratch.
I forgot to change that 12 to 8, as I did on the other places.
Thank you so much for your help. That is one of those errors that was
staring me on the face and yet I could not see it.
At least most of the other stuff was as it should have been.
My heartfelt thank you. This has been driving me crazy for the past two
days.
Best wishes.
Jack

On Thu, 7 Sept 2023 at 15:52, Sri h Kolusu  wrote:

> >> After tinkering a little bit more, as I was far form satisfied with the
> last result, I managed to get twenty two output records:
>
>
> Jack,
>
> Looking at the results, something does NOT add up. Your HLQ is 8 bytes,
> however you have defined the symbol for it as FMT-HLQ as 12 Bytes.  May be
> the garbage values are being considered as a break. Can you turn HEX on the
> 3 record output and see if you can see any values after the hlq ASCLI ?
>
> You  can change the symbol
>
> FMT-HLQ,*,12,CH
>
> To
>
> FMT-HLQ,*,08,CH
>
>
> Now re-run the job once again and see if you are getting the right
> results.  If you are still getting incorrect results, then please terse the
> DCOLLECT file and send it as an attachment to my email offline and I will
> see if I can find something.
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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: Can I search the Archives

[Joseph Reichman]

There was no hamburger button

But you are correct within a message clicking on the drop down menu I am able 
to search

Thank you

Get Outlook for iOS

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 7, 2023 10:52:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Can I search the Archives

On Thu, 7 Sep 2023 10:03:45 -0400, Joseph Reichman wrote:

>I am on the listeserv web
>
Can you view individual messages on the listeserv web?

If so, while viewing one, click on the hamburger button and
select "search archives".

--
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: Can I search the Archives

[Paul Gilmartin]

On Thu, 7 Sep 2023 10:03:45 -0400, Joseph Reichman wrote:

>I am on the listeserv web 
> 
Can you view individual messages on the listeserv web?

If so, while viewing one, click on the hamburger button and
select "search archives".

-- 
gil

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

Re: Help on DFSORT SUM FIELDS

[Sri h Kolusu]

>> After tinkering a little bit more, as I was far form satisfied with the last 
>> result, I managed to get twenty two output records:


Jack,

Looking at the results, something does NOT add up. Your HLQ is 8 bytes, however 
you have defined the symbol for it as FMT-HLQ as 12 Bytes.  May be the garbage 
values are being considered as a break. Can you turn HEX on the 3 record output 
and see if you can see any values after the hlq ASCLI ?

You  can change the symbol

FMT-HLQ,*,12,CH

To

FMT-HLQ,*,08,CH


Now re-run the job once again and see if you are getting the right results.  If 
you are still getting incorrect results, then please terse the DCOLLECT file 
and send it as an attachment to my email offline and I will see if I can find 
something.

Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: Help on DFSORT SUM FIELDS

[Jack Zukt]

Hello again,
After tinkering a little bit more, as I was far form satisfied with the
last result, I managed to get twenty two output records:

ASCLI830 KB  0 KB  0 KB
ASCLI  8.190 KB  0 KB  0 KB
ASCLI166 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI  3.320 KB  0 KB  0 KB
ASCLI332 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI  0 KB830 KB  0 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB332 KB
ASCLI  0 KB  0 KB  3.320 KB
ASCLI  0 KB  0 KB  8.189 KB
ASCLI  0 KB  0 KB166 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB830 KB
ASCLI  0 KB  0 KB830 KB

So, now I have one output record for each input one, but if I add the SORT
FIELDS=HLQ, I get three, one total for each record type:
ASCLI  0 KB830 KB  0 KB
ASCLI 16.988 KB  0 KB  0 KB
ASCLI  0 KB  0 KB 17.817 KB

And I still cannot understand why.
Best wishes
Jack

On Thu, 7 Sept 2023 at 15:11, Jack Zukt  wrote:

> Hi Kolusu,
>
> Thank you for you help.
> I used one HLQ that has few files, (10 DASD; 1 Migrated; 11 HSM Backup; 22
> DCOLLECT records).
>
> On my first try it gave me three output records:
> ASCLI  0 KB830 KB  0 KB
> ASCLI 16.988 KB  0 KB  0 KB
> ASCLI  0 KB  0 KB 17.817 KB
>
> on the second run, with OUTFIL INCLUDE and without SUM FIELDS, it gave me
> ten records:
> ASCLI830 KB  0 KB  0 KB
> ASCLI  8.190 KB  0 KB  0 KB
> ASCLI166 KB  0 KB  0 KB
> ASCLI830 KB  0 KB  0 KB
> ASCLI830 KB  0 KB  0 KB
> ASCLI830 KB  0 KB  0 KB
> ASCLI  3.320 KB  0 KB  0 KB
> ASCLI332 KB  0 KB  0 KB
> ASCLI830 KB  0 KB  0 KB
> ASCLI830 KB  0 KB  0 KB
>
> It has the info from the ten type "D" records but there is no information
> for the type "B" and type "M" records.
>
> Any ideas?
> Jack
>
>
> On Thu, 7 Sept 2023 at 13:14, Sri h Kolusu  wrote:
>
>> >> Now, I hope that you do not mind if I ask you for one more thing. I
>> wanted to have one line with the high level qualifier and all the three
>> values but instead I am getting three lines for each HLQ.
>>
>> Jack,
>>
>> If you used the updated INREC then you should have gotten a summary
>> record of 1 record per HLQ.  If you are still getting multiple records per
>> hlq, then you still must be getting an overflow. How about we diagnose the
>> issue?
>>
>> Pick a HLQ where you are getting multiple records and use it in the
>> include on OUTFIL without SUM fields
>>
>> //SYSINDD *
>>   OPTION VLSHRT,VLSCMP,DYNALLOC=(,4)
>>   INCLUDE COND=(DCURCTYP,EQ,DCUDATAT,OR, * DATA RECORD
>> DCURCTYP,EQ,UKTMIGR,OR,  * MIGR RECORD
>> DCURCTYP,EQ,UKTBACK) * BACKUP RECORD
>>
>>   INREC IFTHEN=(WHEN=INIT,
>> PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
>> OVERLAY=(FMT-HLQ:%01,
>>  TMP-DCDALLSP:8Z,
>>  TMP-UMALLSP:8Z,
>>  TMP-UBALLSP:8Z)),
>>
>> IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT),
>> OVERLAY=(TMP-DCDALLSP2:DCDALLSP)),  * ALLOC SPACE
>>
>> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
>> OVERLAY=(TMP-UMALLSP2:UMALLSP)),* MIGRATED SPACE
>>
>> IFTHEN=(WHEN=NONE,
>> OVERLAY=(TMP-UBALLSP2:UBALLSP)) * BACKUP SPACE
>>
>>   SORT FIELDS=(FMT-HLQ,A)   * SORT BY DATASET HLQ
>>
>>   OUTFIL 

Re: Help on DFSORT SUM FIELDS

[Jack Zukt]

Hi Kolusu,

Thank you for you help.
I used one HLQ that has few files, (10 DASD; 1 Migrated; 11 HSM Backup; 22
DCOLLECT records).

On my first try it gave me three output records:
ASCLI  0 KB830 KB  0 KB
ASCLI 16.988 KB  0 KB  0 KB
ASCLI  0 KB  0 KB 17.817 KB

on the second run, with OUTFIL INCLUDE and without SUM FIELDS, it gave me
ten records:
ASCLI830 KB  0 KB  0 KB
ASCLI  8.190 KB  0 KB  0 KB
ASCLI166 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI  3.320 KB  0 KB  0 KB
ASCLI332 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB
ASCLI830 KB  0 KB  0 KB

It has the info from the ten type "D" records but there is no information
for the type "B" and type "M" records.

Any ideas?
Jack


On Thu, 7 Sept 2023 at 13:14, Sri h Kolusu  wrote:

> >> Now, I hope that you do not mind if I ask you for one more thing. I
> wanted to have one line with the high level qualifier and all the three
> values but instead I am getting three lines for each HLQ.
>
> Jack,
>
> If you used the updated INREC then you should have gotten a summary record
> of 1 record per HLQ.  If you are still getting multiple records per hlq,
> then you still must be getting an overflow. How about we diagnose the issue?
>
> Pick a HLQ where you are getting multiple records and use it in the
> include on OUTFIL without SUM fields
>
> //SYSINDD *
>   OPTION VLSHRT,VLSCMP,DYNALLOC=(,4)
>   INCLUDE COND=(DCURCTYP,EQ,DCUDATAT,OR, * DATA RECORD
> DCURCTYP,EQ,UKTMIGR,OR,  * MIGR RECORD
> DCURCTYP,EQ,UKTBACK) * BACKUP RECORD
>
>   INREC IFTHEN=(WHEN=INIT,
> PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
> OVERLAY=(FMT-HLQ:%01,
>  TMP-DCDALLSP:8Z,
>  TMP-UMALLSP:8Z,
>  TMP-UBALLSP:8Z)),
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT),
> OVERLAY=(TMP-DCDALLSP2:DCDALLSP)),  * ALLOC SPACE
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
> OVERLAY=(TMP-UMALLSP2:UMALLSP)),* MIGRATED SPACE
>
> IFTHEN=(WHEN=NONE,
> OVERLAY=(TMP-UBALLSP2:UBALLSP)) * BACKUP SPACE
>
>   SORT FIELDS=(FMT-HLQ,A)   * SORT BY DATASET HLQ
>
>   OUTFIL INCLUDE=(FMT-HLQ,EQ,C'JACKZUKT')
> /*
>
>
> Now check the output for the field values of all the space fields that you
> added.
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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: Can I search the Archives

[Joseph Reichman]

I am on the listeserv web 

I click on the left side search the archives 
I check IBMMAIN and IBMMAIN archives 
Takes me to web page not authorized 
We’re I can input a password I register 
The password it then me a email
With a link I click on the link after receiving the email 

A try the process again apparently what I did was insufficient  

> On Sep 7, 2023, at 9:41 AM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Apparently you can't.
> 
> Here we go again with insufficient information. You didn't tell us:
> 
> How you are trying to search. web or email
> What web/email address
> the precise error message.
> 
> -- 
> Tom Marchant
> 
>> On Thu, 7 Sep 2023 09:29:55 -0400, Joseph Reichman  
>> wrote:
>> 
>> I tried to search archives i registered my password 
>> 
>> Had it activated 
>> 
>> After all that told me I wasn’t authorized 
>> 
>> Can I do search the archives ?
> 
> --
> 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: z/OSMF and the Old Timer

[Marna WALLE]

Tom,
The job to remove the temporary catalog alias (aka SSA) and rename the data 
sets to prepare for an IPL is done during the z/OSMF Deployment  (not in the 
Post Deploy Workflow), and is found in the Software Management provided job, 
IZUD05RN - that's the name that my generated job was, and it was job #5 out of 
6 jobs that were provided for my configuration.  

It looks like this in Software Management.  Sorry for the horrible formatting, 
but you can see it with the "5" below:

-
4   IZUD04UZUnzip Data Sets: Extract the target software instance 
data sets from the portable software instance archive files, into the location 
defined by the deployment configuration, using temporary and unique data set 
names.AQFT
Complete 
MWALLEZOJOB20193CC 0256 U
5   IZUD05RNRename Data Sets: Rename the target software instance 
data sets from their temporary and unique names to their true names defined by 
the deployment configuration, and update catalog entries for the data sets as 
needed.  AQFT
Complete
MWALLEZOJOB26729CC 0008 U
6   IZUD06UCUpdate CSI Data Sets: Update the entries within the 
SMP/E CSI data sets to reflect the target software instance zone names, data 
set names and locations, and UNIX directory prefixes.  AQFT
Complete
MWALLEZOJOB28159CC  U


In that 5th job, I can see that the rename is happening like this.  Note 
"ZS25VBNM" is my temporary catalog alias (SSA):

 LISTCAT -
ENTRY(ZS25VBMW.SYS1.LINKLIB) -
CATALOG(MWALLE.VB25.MCAT)
  IF LASTCC = 0 THEN DO
 ALTER -
   ZS25VBMW.SYS1.LINKLIB -
   NEWNAME(SYS1.LINKLIB) -
   CATALOG(MWALLE.VB25.MCAT)
  END


What might be happening, is that during the configuration of your deployment, 
you entered in the names of the final data sets WITH a temporary high level 
qualifier yourself. If that is so, then you have indicated that that 
"temporary" HLQ is the final name you wanted.  This is something that we've 
seen experienced CustomPac people do, as they assume they need to handle the 
temporary HLQ themselves which is not the case in z/OSMF.  You can see that 
z/OSMF will be adding(and removing) the temporary HLQ itself, if you look at 
the Configuration sample for the data set, so that you will know you don't have 
to handle the temporary HLQ yourself.

Here's the spot in Configure Deployment of Software Management, in Modify where 
you can see that (see NEWMCAT below as the sample temporary HLQ), and that your 
name should not attempt to add a temporary HLQ:

Enter the data set name or qualifiers to use for the selected data sets.
Common data set qualifiers: Example data set name:
From:   SYS1.LINKLIBSYS1.LINKLIB
To: 
SYS1.LINKLIB
SYS1.LINKLIB

NEWMCAT.SYS1.LINKLIB( Target data set name with temporary catalog alias ) 
z/OSMF automatically adds the temporary catalog alias to reference the target 
data set from the driving system catalog. "NEWMCAT" is the default temporary 
catalog alias and can be updated in the Catalogs step of the Deployment 
Configuration.
-

If indeed, you did add your "own temporary" final name to the data sets, you 
will need to go back and remove it.  You can either go back into the same 
deployment and do that to backtrack, or if that Deployment is Complete you can 
start a new Deployment. 

For a Completed Deployment, you can copy that configuration to do another 
Deployment which is nice as the pre-defined configuration is reused.  It is 
under Actions -> Copy.  It will be grayed out if if the Deployment is not 
Complete.   I duplicate my Deployments often to save time, and only change 
small things, like the target system, or volumes.  

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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

Re: Can I search the Archives

[Tom Marchant]

Apparently you can't.

Here we go again with insufficient information. You didn't tell us:

How you are trying to search. web or email
What web/email address
the precise error message.

-- 
Tom Marchant

On Thu, 7 Sep 2023 09:29:55 -0400, Joseph Reichman  
wrote:

>I tried to search archives i registered my password 
>
>Had it activated 
>
>After all that told me I wasn’t authorized 
>
>Can I do search the archives ?

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

Can I search the Archives

[Joseph Reichman]

I tried to search archives i registered my password 

Had it activated 

After all that told me I wasn’t authorized 

Can I do search the archives ?

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

Re: z/OSMF and the Old Timer

[Tom Longfellow]

And the battle continues.   Ignorance is taking the hits.

I am obviously ignorant to the design of the approved 'how to' way to do this.

I tried removing the CB. prefix on my dataset names.   800+ error messages 
later, I found that the Lion cannot digest that.  It regurgitates every name 
that already exists in my current master catalog.   Totally understandable and 
I sympathized.
I returned the CB prefix and moved on. 
The Catalog step  had identified CB as a 'New' prefix that requires a 'New' 
master catalog to be created. I had done the 'use existing master' option 
during setup, but I guess I am ignorant to what that truly means.

Nothing I try can tell the Lion to use my current existing Master catalog to 
hold the 'temporary'  CB catalog entries.

Do I need a new USER cat for the CB entries???  (WILDLY guessing here).   
Would this be someplace for the Lion to play with its food while the physical 
datasets are created on the volumes?

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

Re: Switching between SMT-1 and SMT-2

[Scott Chapman]

Prior to those functions being zIIP-eligible they equally depended upon access 
to CPU. Yet there's an unfortunately limited amount of calls for running GCPs 
less busy, which would also be good for performance overall. 

It's also worth noting that not all Db2 subsystems are production and don't 
need production levels of performance. 

But I agree that many environments would benefits from more zIIPs. Almost as 
many would benefit from more GCPs as well, but that's usually even more 
difficult to do because of the way software pricing works on the mainframe and 
the fact that it's often more than the hardware cost. And the z16 A02 machines 
remain limited to  only allowing 6 GCPs. Which is a shame: I was just working 
with a customer whose environment cries out for more than 6 CPs and and a 
processor capacity setting that's between the A01 5xx and 6xx. Their situation 
was particularly problematic, but they're not the only ones that could benefit 
from more than 6 CPs that could be finely adjusted in terms of capacity. 

Scott Chapman


On Wed, 6 Sep 2023 09:52:47 +, Martin Packer  
wrote:

>I really hope you�re not advising customers to run the zIIP pool at 100%. Key 
>functions such as Db2 DBM1 Deferred Write and Prefetch, as well as Db2 Log 
>Writes, depend on very good access to zIIP.
>
>(This is actually why I first wrote my zIIP Capacity & Performance 
>presentation 10 years ago.)

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

Re: Help on DFSORT SUM FIELDS

[Sri h Kolusu]

>> Now, I hope that you do not mind if I ask you for one more thing. I wanted 
>> to have one line with the high level qualifier and all the three values but 
>> instead I am getting three lines for each HLQ.

Jack,

If you used the updated INREC then you should have gotten a summary record of 1 
record per HLQ.  If you are still getting multiple records per hlq, then you 
still must be getting an overflow. How about we diagnose the issue?

Pick a HLQ where you are getting multiple records and use it in the include on 
OUTFIL without SUM fields

//SYSINDD *
  OPTION VLSHRT,VLSCMP,DYNALLOC=(,4)
  INCLUDE COND=(DCURCTYP,EQ,DCUDATAT,OR, * DATA RECORD
DCURCTYP,EQ,UKTMIGR,OR,  * MIGR RECORD
DCURCTYP,EQ,UKTBACK) * BACKUP RECORD

  INREC IFTHEN=(WHEN=INIT,
PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
OVERLAY=(FMT-HLQ:%01,
 TMP-DCDALLSP:8Z,
 TMP-UMALLSP:8Z,
 TMP-UBALLSP:8Z)),

IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT),
OVERLAY=(TMP-DCDALLSP2:DCDALLSP)),  * ALLOC SPACE

IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
OVERLAY=(TMP-UMALLSP2:UMALLSP)),* MIGRATED SPACE

IFTHEN=(WHEN=NONE,
OVERLAY=(TMP-UBALLSP2:UBALLSP)) * BACKUP SPACE

  SORT FIELDS=(FMT-HLQ,A)   * SORT BY DATASET HLQ

  OUTFIL INCLUDE=(FMT-HLQ,EQ,C'JACKZUKT')
/*


Now check the output for the field values of all the space fields that you 
added.

Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: z/OSMF and the Old Timer

[Tom Longfellow]

I always feel foolish when I reply to my own posts, but here goes.

For those of you playing the home game and watching the gladiatorial combat 
between "Software Management" and the "Grizzled Veteran"  here is todays battle.

I think I see where I have not toed the line with the 'new' method of 
Installing things. I went "old school" and modified my dataset names to 
prepend a HLQ of CB (I still do not know where that came from - me or z/OSMF).  
 What I did not know is that my worthy opponent (which I will now call the 
Lion) had secret strategies that it was going to deploy.   The Lion took my 
well crafted and meaningful dataset names and suffixed them with '.#'.

The old ServerPac dialogs generated jobs would remove the HLQ on the physical 
volume and make the names match what was indirectly cataloged in the system 
being upgraded.   For example  HLQ.SYS1.LINKLIB cataloged on the newly created 
SYSRES would be 'zapped' to the name SYS1.LINKLIB which has been indirectly 
cataloged to ** for many many years and will NOT be changed.   A HLQ.xxx 
catalog entry would be created so that JCL could be used to select which one 
you were trying to modify. My review of these new jobs is not showing me 
where any catalog ALIAS entries are being created (but I could have missed 
them).
This left us with the option of IPLing the old release,  then new release for 
testing, then back to old release to get on with our work.


To adopt this new suffixing approach, I now have to lose a week of work in 
order to rename the data sets in such a way that the suffixing process 'might' 
work.
Then back to my local usermods again for re-APPLY.

This sort of thing has been happening to me for years.  I make a choice for 
local needs  (like software upgrade vs software replacement in the old 
ServerPacs)  only to find out that two days later the generated jobs will not 
do what I wanted to do or what I thought they would do.   Square One!!!
Like an Abbot and Costello routing,   THIRD BASE!!!.   All convoluted 
difficulties mean Square One.   I just have not taking to drinking the IBM 
Cool-Aid and will stray into the world of independent thought.

What I would love to do is 'Copy' my current Deployment as a baseline from 
which to start over.I cannot find a 'Copy Deployment' under z/OSMF --- Only 
'Add'.Welcome to the next battle trying to tame this Lion.

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

Re: Legal Problems with ChatGPT [Was Re: Simple request from chatGPT to write assembler program.]

[Seymour J Metz]

This isn't new; you are responsible for work you sign off on. It doesn't matter 
that your legal assistant drew up the brief; you are obligated to do due 
diligence and verify it.


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Tuesday, September 5, 2023 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Legal Problems with ChatGPT [Was Re: Simple request from chatGPT to 
write assembler program.]

Here is a take-off on the forbes article which is from the Legal
Ethics Law 360 email list (I also get the transportation law
stuff too):


Insurance Coverage For ChatGPT Legal Fiasco: A Hypothetical


William Passannante at Anderson Kill draws on the recent case of
an attorney sanctioned by the Southern District of New York for
submitting a ChatGPT-authored brief to discuss what the insurance
coverage for the attorney's hypothetical claim might look like.


And I think this is the original case:


Attys Behind ChatGPT Fiasco Apologize To Client, 7 Judges


By Hailey Konnath

A pair of New York personal injury attorneys apologized Wednesday
to seven federal and state judges and to a client for submitting
a brief prepared by artificial intelligence that cited
nonexistent case law attributed to the judges, according to
copies of the letters filed in Manhattan federal court.

And there are now other articles over whether or not chatGPT can
defame a person or something like that... And something about the
case being remanded.. (my head hurts).


Steve Thompson



On 9/5/2023 5:11 PM, Mike Schwab wrote:
> https://www.forbes.com/sites/mollybohannon/2023/06/08/lawyer-used-chatgpt-in-court-and-cited-fake-cases-a-judge-is-considering-sanctions/
>
> On Tue, Sep 5, 2023 at 4:03 PM Bob Bridges  wrote:
>> Can't remember whether I read about it here or somewhere else, but 
>> apparently there was a recent episode in which a lawyer got an AI machine to 
>> write a legal brief for him.  It looked impressive, but it turned out the 
>> precedents the brief cited didn't exist; the AI made them up.  The judge 
>> fined the lawyer.
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* The most important fundamental laws and facts of physical science have 
>> all been discovered, and these are now so firmly established that the 
>> possibility of their ever being supplemented in consequence of new 
>> discoveries is exceedingly remote.  -Abraham Albert Michelson in 1903 */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Dean Kent
>> Sent: Tuesday, September 5, 2023 12:46
>>
>> I spent a bit of time playing with chatGPT to see what it could do.   So did 
>> my two sons - one an MS in biotech, the other a PhD in theoretical physics.  
>>   We all came to the same conclusion - chatGPT is a very, very good Google 
>> search that can filter many different possible 'answers' and come to one 
>> that is 'most likely' based on various factors.  It has little to no 
>> creativity or understanding of what it is asked to do. Not surprising, but 
>> different than what the popular press seems to say about it.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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

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

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

[Seymour J Metz]

Dead tree? That was excusable in the 1960s, but it's a lot harder to find 
things on paper. If the programmer didn't have a SYSMDUMP I can at least browse 
the dump on SPOOL; releasing the dump to print just adds to the work.

I never had TSO in less than 2 MiB; 768 KiB gives me shudders.


From: IBM Mainframe Discussion List  on behalf of 
Clem Clarke 
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days

I used to arrive at work every morning to have to wade through a two
foot high paper system dump to see why an OS abend had occurred that
night.  Every night, pretty well in the early days!

MFT, MVT, MVS.  MVS was a LOT better.

Running TSO in 3/4 of a meg was interesting.  And VERY slow.

We used to keep the IBM SE's pretty busy in the 1960's and 1970's.

Shell Oil Melbourne used to have English Electric Leo computers, and
moved to an IBM 65.  The English Leos were pretty much the first
commercial computers available. Fully multi programming in the '60s.

And we were seriously into PL./I - all our Cleo programs were converted
to PL/I (F).  CLEO was a bit like COBOL - absolutely excellent for
commercial programs.

Clem


Colin Paice wrote:
> I remember going to a customer to discuss a deep technical problem.  Before
> they let us into the inner sanctum were given a dump and were asked "what's
> the problem?" My colleague looked at it and said there is a program check
> at this address, and this is fixed in ptf uy " come on in you've
> passed" they said .  They said this weeded out non technical people
>
> On Tue, Sep 5, 2023, 23:32 Bernd Oppolzer 
> wrote:
>
>> Hi Peter,
>>
>> this reminds me of another story ...
>>
>> some day my customer (a large insurance company here in Germany) asked
>> me to talk with their IBM rep,
>> because we had a severe problem with one of the DB2 components which I
>> discovered, and I was asked to
>> have IBM fix it or otherwise provide a solution of my own (it was in the
>> DB2 interface for Batch - CAF - IIRC,
>> and it used 5 % of the overall CPU in some of our IMS regions simply by
>> walking sequentially through
>> some MVS control blocks chains)
>>
>> So I called the IBM rep, and the first thing he asked me was: "are you a
>> systems programmer"?
>> and, although I wasn't sure at that time what that means, I said: "yes,
>> but why do you want to know?",
>> and he said: "well, if not, we're not gonna talk with you"
>>
>> :-)
>>
>> Kind regards
>>
>> Bernd
>>
>>
>> Am 04.09.2023 um 16:23 schrieb Peter Sylvester:
>>> Namen sind Schall und Rauch,
>>>
>>> Some parts of the discussion reminds me to Lewis Carroll, Through the
>>> looking glass.
>>>
>>> It reminds me to the citation that that I made in ibmmail descript
>>>
>>> https://www.funet.fi/pub/doc/netinfo/EARN/ (There are some other
>>> gems in that directory).
>>>
>>> "song" = "what is your profession."
>>>
>>>
>>> Peter Sylvester
>>>
>>>
>>>
>>>
>>> --
>>> 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

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

Re: Simple request from chatGPT to write assembler program.

[Seymour J Metz]

There you go again, lying about what people believe. If you're referring to 
people who chose to plonk you, your right to speak does not confer an 
obligation to listen. They don't believe that they run the list, but they 
rightly believe that they run their own property.


From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 6, 2023 12:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple request from chatGPT to write assembler program.

In fact I’m not. Because I only respond to attacks from the TT. Many here 
actually fear the TT. (Terrible Twenty) The TT thinks they run the list. They 
don’t.

Like I’ve said a number of times, there are very few experts here. I’m not one. 
If you have an SMP/E question, you probably have a 60-70% chance of getting the 
correct answer from the TT. Whereas you’ve got 99.9% chance with Kurt 
Quackenbush. You probably have a 60% chance of getting the correct answer for 
z/OS internals from the TT & 99.9% from Mr. Relson.

Knowing who to trust 100% and who to fact check with the experts is probably 
the most important thing here. I know if I want hardware numbers from the 60’s 
& 70’s, you’re the man.




Sent from Yahoo Mail for iPhone


On Wednesday, September 6, 2023, 11:47 AM, Seymour J Metz  
wrote:

> Putting down other people in this profession is the MO of guys like the 
> terrible twenty.

I hope that you are including yourself in that.


From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 6, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple request from chatGPT to write assembler program.

Assembler is of little value and declining every year for most 
Installers/Systems Programmers not a part of ISVs. Which is the vast majority.

Putting down other people in this profession is the MO of guys like the 
terrible twenty. Who claim that if you don’t know or use assembler, you’re just 
an “Installer” and a second rate Systems Programmer.


Sent from Yahoo Mail for iPhone


On Wednesday, September 6, 2023, 9:03 AM, Bernd Oppolzer 
 wrote:

What you are quoting (1., 2., 3.) are facts ... of course true, and
nothing to dispute about.
But your conclusions are wrong ... Assembler is of value anyway; Ray
Mullins DID say that.
For example for studying the outcome of translators and for performance
analysis etc.
IMO knowledge of Assembler is NEEDED, once you want to dig a little
deeper into machine architecture
and other related topics. The Assembler language opens the door for the
understanding of registers,
storage, addressing schemes, operation formats and so on ... that is:
the hardware.

IMO, you always seem to be forced to put down other people and their
skills; I don't understand why.
But what scares me most is that your constant use of words like
"dinosaurs" and "narcissists"
(and "idiots", BTW) in this discussions. And that's why I will not
answer to any more mails from you from now on.
Should have done so earlier, maybe.

Bernd


Am 06.09.2023 um 14:11 schrieb Bill Johnson:
> Everything I said about assembler has rung true.
>
> 1. The assembler listserv is nearly dead.
> 2. One of assemblers experts, Ray Mullins, stated unequivocally its market is 
> getting smaller and smaller and is a niche product.
> 3. Bernd said since 2005, there’s been little demand for assembler training.
>
> ...
>
> And the dinosaurs here trying so hard to not become extinct.
> Notice how the 20-30 experts can’t say, Bill Johnson is right. Because it 
> makes them wrong and narcissists don’t like saying they were wrong.
>
> ...

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

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

Re: SMP/E and USS

[Seymour J Metz]

Remember that JCLIN was originally intended to process sysgen stage 2 input, 
which used true names.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 6, 2023 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and USS

On Wed, 6 Sep 2023 19:27:36 +, Seymour J Metz wrote:

>The SMP convention is that LINK is a hard link and SYMLINK is a soft link.
>
Long ago I was (disingenuously) dismayed to learn that in SMP/E Linkage
Editor JCLIN:
INCLUDE SYSLIB(alias-name)

... failed even though alias-name was specified as both TALIAS and DALIAS
on ++MOD MCS.

Worked in stand-alone JCL, so I went to SR.  Got WAD.

--
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: z/OSMF and the Old Timer

[Gadi Ben-Avi]

It is created as part of the workflow jobs. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Longfellow
Sent: יום ה 07 ספטמבר 2023 12:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF and the Old Timer

I am very familiar with that Job --- I have run it under ServerPac for a dozen 
times over the past 20-30 years.

What I cannot find now is how to get z/OSMF to generate that JOB for the 
current software order.
I have not been able to find it in the z/OSMF GUI interface.

--
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: Simple request from chatGPT to write assembler program.

[Seymour J Metz]

91? That mean big bucks, and the "optimizing" compiler, which didn't have that 
problem, was chump change by comparison.


From: IBM Mainframe Discussion List  on behalf of 
Michael Stein 
Sent: Wednesday, September 6, 2023 6:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple request from chatGPT to write assembler program.

On Wed, Sep 06, 2023 at 09:02:28PM +0200, Bernd Oppolzer wrote:
> IIRC, in the first years of HLLs, there were some debates that HLLs
> are not usable because of the poor code the compilers generated at that
> time. This was true even in the 1960s for the first versions of PL/1.

A lot later than that, try the 70s.  PL/1 F level subroutine calls did
a getmain/freemain for each subroutine call.  Too much overhead to call
even one subroutine for each of 30K records on a 360/91 & MVT.

--
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: There are good bosses and then there are the other kind

[Seymour J Metz]

I remember with fondness an old warrant officer who

 1. Had firm ideas about what he wanted.
 2' Ensured that we understood what he wanted.
 3. Insisted that we give him what he wanted.
 4. Got out of our way and let us do our jobs.
 5. Had our backs.

On item 4, I don't mean that he was aloof; he was always available if we wanted 
to discuss things. But I never saw him micromanaging.

Mr. Condon, wherever you are, it was a pleasure working for you.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Wednesday, September 6, 2023 8:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: There are good bosses and then there are the other kind

I remember our group showing up early for an interdepartmental meeting.  Our 
boss spent the time we waited deriding management's latest decisions.  Then the 
bosses showed up and he praised their wisdom and leadership.  Not very smart; 
even thinking that sort of thing in your own private head is dangerous, but to 
just out and say it in front of your subordinates...?

/* ...in your bedchamber do not curse a king, and in your sleeping rooms do not 
curse a rich man, for a bird of the heavens will carry the sound, and the 
winged creature will make the matter known.  -Ecclesiastes 10:20 */

I've had the other kind too; in fact it seems to me I've had a bunch of them.  
The very best one came to me privately one day, saying he'd assigned a coding 
task to a coworker and he'd decided the coworker wasn't up to it, so would I 
mind volunteering my lunch hours for the next  days and the boss and I 
would hit a meeting room and work on it together?  We never breathed a word of 
it to anyone else, and what I principally remember about those days was that 
EVERY SINGLE TIME we disagreed about how or at what point something had to be 
done in the code, he turned out to be right and I wrong.  Every time.  I'm used 
to being the smart one in the room, but not around him.

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

/* Personally, I don't want politicians presuming to feel my pain; I'm happy if 
they respect my privacy.  -Joseph Sobran, 1999 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: Wednesday, September 6, 2023 19:18

Two weeks later Les quit.  His boss calls all of the workgroup into his 
office, points to Les and says "now here we have a rat deserting a sinking 
ship."  He was half-right. It was a sinking ship.  I gave it 3 years but it 
survived 6 years.  Oh, and a few months later that manager was fired.

--
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: z/OSMF and the Old Timer

[Tom Longfellow]

I am very familiar with that Job --- I have run it under ServerPac for a dozen 
times over the past 20-30 years.

What I cannot find now is how to get z/OSMF to generate that JOB for the 
current software order.
I have not been able to find it in the z/OSMF GUI interface.

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

Re: Simple request from chatGPT to write assembler program.

[Seymour J Metz]

While PL/I F did a GETMAIN for every DSA, no subsequent compiler did. Starting 
with Version 1 Release 1, the runtime library for the "optimizing" and checkout 
compiler did a GETMAIN for an ISA and as long as it was large enough, 
subsequent calls used it as a stack. Only when a DSA didn't fit was there a 
GETMAIN for an additional stack segment. Exiting a block adjusted the stack but 
did not do a FREEMAIN of unused stack segments.

The net result was to save time at the expense of storage; unless you were 
storage constrain, it was a btter approach.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Wednesday, September 6, 2023 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple request from chatGPT to write assembler program.

Am 07.09.2023 um 01:40 schrieb Leonard D Woren:
> Michael Stein wrote on 9/6/2023 3:45 PM:
>> [...] PL/1 F level subroutine calls did a getmain/freemain for each
>> subroutine call. Too much overhead to call even one subroutine for
>> each of 30K records on a 360/91 & MVT.
>
> Well, my recollection is that if you had only Static storage, no
> Automatic storage, it didn't do a GETMAIN.
> Or was that an enhancement in the new PL/I compiler?  Was that PLIX?
> Yeah, not using stuff for decades can cause memory fade.
>
>
> /Leonard
>

I first came into contact with PL/1 in the end of the 1980s at the
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced pretty
amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company
started with PL/1 in the beginning of the 1980s,
before that is was an ASSEMBLER only shop. (C came later, from 1992 on).

1992 (and 1994 again) I was asked to do a dump analysis class in another
PL/1 company. They indeed had

DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time and
thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load
module) are much easier to find than
auto variables (living in the stack). But now I have the impression that
this could have simply been a performance
issue in the beginning.

Kind regards

Bernd

--
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: PL/I early compilers performance issues

[Robin Vowels]

There may have been issues with LCS (Large Core Storage).
Our site had 128K core with 1 Mb LCS.
OS/360 took up almost all the core storage.
Access to LCS was much slower than to core store.
We therefore made local PL/I variables static
(except for arrays, which typically had variable dimensions).

On 2023-09-07 13:32, Bernd Oppolzer wrote:

Thinking a little bit more about this:

the insurance company used auto variables heavily, BUT:

until the 2010 time frame, they didn't allow (or: suggested not to use) 
INTERNAL PL/1 procedures !!
Instead they had some home grown macros based on label variables, which 
worked much the same like
procedure calls, but the "program blocks", which were built using these 
macros - of course - didn't have local variables;

all variables are GLOBAL.

Using this technique, performance issues during procedure startup are 
no problem, of course.


In 2010, one of my co-workers (and a friend of mine) checked out the 
performance of these "program blocks"
and found out that the heavy use of label variables COMPROMISES the 
optimizing strategies of the modern compilers,
so that now the "program blocks" based on label variables are MUCH 
SLOWER than original PL/1 procedures.


That's why the company now changed the recommendation and asked all 
programmers to change the
programs from the old "program blocks" to normal procedures (when doing 
maintenance to the programs).
This led to significant better performance in some cases (especially in 
large Batch programs with many "program blocks").


There are still many programs using the old "program blocks", and we 
are now thinking about forcing
the transformation process in the next months. When compiling a program 
using the old feature,
you get a return code of 8 and a compiler message, but the code is 
produced, anyway.


Kind regards

Bernd


Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer:

Am 07.09.2023 um 01:40 schrieb Leonard D Woren:

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler?  Was that PLIX?  
Yeah, not using stuff for decades can cause memory fade.



/Leonard



I first came into contact with PL/1 in the end of the 1980s at the 
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced 
pretty amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still 
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static 
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company 
started with PL/1 in the beginning of the 1980s,
before that is was an ASSEMBLER only shop. (C came later, from 1992 
on).


1992 (and 1994 again) I was asked to do a dump analysis class in 
another PL/1 company. They indeed had


DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time 
and thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load 
module) are much easier to find than
auto variables (living in the stack). But now I have the impression 
that this could have simply been a performance

issue in the beginning.

Kind regards

Bernd

--
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: Help on DFSORT SUM FIELDS

[Jack Zukt]

Hi Kolusu,

I knew it must be something simple,I just could not figure it out.
Thank you so much for your help and for the explanation.
Now, I hope that you do not mind if I ask you for one more thing. I wanted
to have one line with the high level qualifier and all the three values but
instead I am getting three lines for each HLQ.
I was under the impression that by doing the sort by the HLQ than I would
get that result but obviously that is not what is happening. Can you please
shed some light in this?
Thank you
Best wishes
Jack

On Wed, 6 Sept 2023 at 18:52, Sri h Kolusu  wrote:

> Jack,
>
> I just ran your control cards against my dcollect extract and I know the
> reason for overflow.  Your INREC is initializing the space values that you
> are summing with zeros IF that Record( D, B, M) is FOUND.  So, if you don't
> have any one of the record, you will be summing the spaces/garbage and it
> will exceed the 8 byte value.  So, you just need to change the INREC to the
> following.  I just moved the initialization of the space values to
> WHEN=INIT.
>
>   INREC IFTHEN=(WHEN=INIT,
> PARSE=(%01=(ABSPOS=29,ENDBEFR=C'.',FIXLEN=8)),
> OVERLAY=(FMT-HLQ:%01,
>  TMP-DCDALLSP:8Z,
>  TMP-UMALLSP:8Z,
>  TMP-UBALLSP:8Z)),
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,DCUDATAT),
> OVERLAY=(TMP-DCDALLSP2:DCDALLSP)),  * ALLOC SPACE
>
> IFTHEN=(WHEN=(DCURCTYP,EQ,UKTMIGR),
> OVERLAY=(TMP-UMALLSP2:UMALLSP)),* MIGRATED SPACE
>
> IFTHEN=(WHEN=NONE,
> OVERLAY=(TMP-UBALLSP2:UBALLSP)) * BACKUP SPACE
>
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sri h Kolusu
> Sent: Wednesday, September 6, 2023 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Help on DFSORT SUM FIELDS
>
> >> I am doing something wrong because I am getting one output record for
> each input record, instead of the few hundreds I was expecting to get.
>
> Jack,
>
> If I had to take an educated guess, you are getting an overflow error.
> Look for ICE152I message in the sysout.  I guess you earlier had a similar
> issue.
>
> https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg124452.html
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
> --
> 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