Re: TS7700 abandoned volumes questions

[kekronbekron]

I'm afraid the best bet is to work with IBM VTL engineers to manually get rid 
of them.

- KB

--- Original Message ---
On Monday, April 10th, 2023 at 7:15 AM, Mark Jacobs 
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:


> I'm not able to answer your question but I totally sympathize. There have 
> been many times where I wanted "systems programmer mode" to be enabled where 
> the @#$!!**@#$ software would let me do what I asked, regardless of whether 
> it thought it was smarter than I am and wouldn't do what I asked for.
> 
> Mark Jacobs
> 
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key - 
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
> 
> 
> --- Original Message ---
> On Sunday, April 9th, 2023 at 9:37 PM, Tom Longfellow 
> 03e29b607131-dmarc-requ...@listserv.ua.edu wrote:
> 
> 
> 
> > I have a TS7700 Grid of three cluster members. In the past volumes were 
> > created for a z/OS system that no longer exists. We have hundreds of tapes 
> > in scratch (0012) and private (001F) category. So now, the data is taking 
> > up space in my newest grid member because of COPYRFSH activities.
> > 
> > What I would like to do is totally remove the existence of these volumes 
> > from the Grid. Every standard method I have found via management GUIs fails 
> > because these volumes have once left the 'INSERT' status at some time in 
> > the past. Everything that implies it might work from Z host to 'EJECT' 
> > these tapes require all the infrastructure of RMM, DEVSUP00 changes, and a 
> > Tape Volume Catalog (TVC). I do not want to rebuild an entire z/OS LPAR so 
> > that it will talk the special DEVSUP language to manipulate these tapes. 
> > Nor do I wish to add hundreds of volumes to my tape management system and 
> > TVC) just to turn around and delete them again.
> > 
> > I really need a way for this GRID to never mention these tapes in any way 
> > ever again. One of the prime directives of the TS7700 seems to be 'never 
> > delete data until you have no other choice'. For example a 'scratch' tape 
> > is still there even after the hold period expires and is still known after 
> > storage RECLAIM has happened. Those 'zombie' reclaimed volumes are 
> > preserved in perpetuity as you migrate from TS7700 to TS7700. I am trying 
> > to Stop the Madness. The 'Default' of 'We shall delete no data before its 
> > time' needs to be broken. A full mind wipe for these volumes is in order.
> > 
> > I know this defeats the 'feature' of miraculous unexpected recoveries of 
> > data that has served its purpose and been honorably discharged but reality 
> > does have to play a role here. If I say keep it for 8 days, I do not want 
> > it storing data forever and deleted by its own arcane incomprehensible 
> > rules. If it is available for miracle unexpected recoveries, there may be 
> > some security auditors interested what that equipment is up to.
> > 
> > Anybody know a fast and efficient way to accomplish this?
> > 
> > --
> > 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: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall

[Eric D Rossman]

Branding is very tricky. (hardware branding 
https://www.ibm.com/downloads/cas/ROXKD4JV, Red Hat/IBM cobranding 
https://www.redhat.com/en/about/brand/standards/red-hat-and-ibm-logos, etc)

BTW, despite posting this using my IBM email, I'm posting this using only 
externally visible documentation. I like my job.

It is not a secret that IBM called it "PL/X," nor is it a secret that it is now 
called "zPLX." (That name is in several redpapers.)

While it usually implies "hardware" when we leave out the slash, that is not 
always the case. zPLX is classified as software ("PL/X on System z" is my best 
take). "IBM z Systems Advanced Workload Analysis Reporter" (IBM zAware) is 
definitely classified as software. I don't see anywhere IBM is classifying 
either otherwise.

Phil Smith III wrote:

>No, but if it's "zPLX", that means IBM considers it hardware. Software would 
>be "z/PLX".
>
>Besides being pedantic, this is an interesting distinction here: some stuff, 
>e.g., zAware, that seems like it's software is classed as hardware.
>
>Michael Schmitt wrote:
>>Anyone have an idea of what the actual name of zPLX is?

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

Re: TS7700 abandoned volumes questions

[Mark Jacobs]

I'm not able to answer your question but I totally sympathize. There have been 
many times where I wanted "systems programmer mode" to be enabled where the 
@#$!!**@#$ software would let me do what I asked, regardless of whether it 
thought it was smarter than I am and wouldn't do what I asked for.

Mark Jacobs 


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Sunday, April 9th, 2023 at 9:37 PM, Tom Longfellow 
<03e29b607131-dmarc-requ...@listserv.ua.edu> wrote:


> I have a TS7700 Grid of three cluster members. In the past volumes were 
> created for a z/OS system that no longer exists. We have hundreds of tapes in 
> scratch (0012) and private (001F) category. So now, the data is taking up 
> space in my newest grid member because of COPYRFSH activities.
> 
> What I would like to do is totally remove the existence of these volumes from 
> the Grid. Every standard method I have found via management GUIs fails 
> because these volumes have once left the 'INSERT' status at some time in the 
> past. Everything that implies it might work from Z host to 'EJECT' these 
> tapes require all the infrastructure of RMM, DEVSUP00 changes, and a Tape 
> Volume Catalog (TVC). I do not want to rebuild an entire z/OS LPAR so that it 
> will talk the special DEVSUP language to manipulate these tapes. Nor do I 
> wish to add hundreds of volumes to my tape management system and TVC) just to 
> turn around and delete them again.
> 
> I really need a way for this GRID to never mention these tapes in any way 
> ever again. One of the prime directives of the TS7700 seems to be 'never 
> delete data until you have no other choice'. For example a 'scratch' tape is 
> still there even after the hold period expires and is still known after 
> storage RECLAIM has happened. Those 'zombie' reclaimed volumes are preserved 
> in perpetuity as you migrate from TS7700 to TS7700. I am trying to Stop the 
> Madness. The 'Default' of 'We shall delete no data before its time' needs to 
> be broken. A full mind wipe for these volumes is in order.
> 
> I know this defeats the 'feature' of miraculous unexpected recoveries of data 
> that has served its purpose and been honorably discharged but reality does 
> have to play a role here. If I say keep it for 8 days, I do not want it 
> storing data forever and deleted by its own arcane incomprehensible rules. If 
> it is available for miracle unexpected recoveries, there may be some security 
> auditors interested what that equipment is up to.
> 
> Anybody know a fast and efficient way to accomplish this?
> 
> --
> 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

TS7700 abandoned volumes questions

[Tom Longfellow]

I have a TS7700 Grid of three cluster members.   In the past volumes were 
created for a z/OS system that no longer exists.  We have hundreds of tapes in 
scratch (0012) and private (001F) category.So now, the data is taking up 
space in my newest grid member because of COPYRFSH activities.

What I would like to do is totally remove the existence of these volumes from 
the Grid.   Every standard method I have found via management GUIs fails 
because these volumes have once left the 'INSERT' status at some time in the 
past.Everything that implies it might work from Z host to 'EJECT' these 
tapes require all the infrastructure  of RMM, DEVSUP00 changes, and a Tape 
Volume Catalog (TVC).   I do not want to rebuild an entire z/OS LPAR so that it 
will talk the special DEVSUP language to manipulate these tapes.  Nor do I wish 
to add hundreds of volumes to my tape management system and TVC) just to turn 
around and delete them again.

I really need a way for this GRID to never mention these tapes in any way ever 
again.   One of the prime directives of the TS7700 seems to be 'never delete 
data until you have no other choice'.  For example a 'scratch' tape is still 
there even after the hold period expires  and is still known after storage 
RECLAIM has happened.Those 'zombie' reclaimed volumes are preserved in 
perpetuity as you migrate from TS7700 to TS7700.   I am trying to Stop the 
Madness.   The 'Default' of 'We shall delete no data before its time' needs to 
be broken.  A full mind wipe for these volumes is in order. 

I know this defeats the 'feature' of miraculous unexpected recoveries of data 
that has served its purpose and been honorably discharged but reality does have 
to play a role here.   If I say keep it for 8 days, I do not want it storing 
data forever and deleted by its own arcane incomprehensible rules.   If it is 
available for miracle unexpected recoveries, there may be some security 
auditors interested what that equipment is up to.

Anybody know a fast and efficient way to accomplish this?

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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Paul Gilmartin]

On Fri, 7 Apr 2023 22:07:03 +, Frank Swarbrick wrote:

>I've tried calling modules (that exist!) with both '@' and '#' signs in them 
>and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
>any good reason why this is the case?
>
No.  Higher level components should not presume to enforce the rules of
lower level components.  They should simply attempt the link (in this
case) and report any errors returned, just like any unresolved symbol.

-- 
gil

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

Re: COBOL question

[Charles Mills]

I can't see your code of course but my WAG is a programmer logic error. 
(Sorry!) I am going to guess your logic is such that you try to free the same 
area twice or, less likely, corrupt your pointer.

You say you check to see if it is null before freeing. Do you set it to NULL 
after freeing?

Charles

On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher  
wrote:

>Thanks Bob,
>No I initialize the Pointer to NULL, and then allocate. Successfully.
>And then later I check to see it the pointer = NULL. If it is not NULL, then I 
>do the FREE.

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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Wayne Bickerdike]

I can see a point whereby you wouldn't use interactive RDO to define
resources.

We used a change control system to implement CICS resources via batch jobs
running DFHCSDUP utility. It gives a better audit trail than using the CEDA
transaction. We also used a separate CSD for 14 CICS regions and rolling
out a common change meant more work.

We also always COLD started CICS so the odd "temporary" install that should
have been permanent often went missing. LOL.

On Mon, Apr 10, 2023 at 7:48 AM Farley, Peter <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> OK, so this was a shop standard rather than any actual requirement.  So
> not "cannot be defined to RDO" but "chose not to be allowed to be defined
> in RDO by management decision".
>
> That kind of thing is a deliberate decision to live with the consequences
> for some perceived benefit.  To each their own.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Steve Thompson
> Sent: Sunday, April 9, 2023 4:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cobol calling module with non alphanumeric no longer
> allowed???
>
> In the case of a common routine(s) that is (are) statically linked for
> Batch and CICS environments. I didn't design the system the customer had, I
> just had to be aware of it when I was working on Compile support tools.
>
> So I thought that this aspect should be considered in this conversation.
>
> And, yes, if these routines changed, the causing the common
> copybook(s) to be changed, that would require a recompile and linkedit of
> the batch and CICS sides, QA testing, and then promotion back into
> production. So that had to be coordinated across a few application groups
> for each program that used one of those "dual" routine programs (dual from
> the idea that they were used in both environments).
>
> Steve Thompson
>
> On 4/9/2023 2:50 PM, Farley, Peter wrote:
> > The only CICS routines that MUST be statically linked are the DFH
> subroutines that are called as the result of coding CICS commands like EXEC
> CICS LINK or EXEC SQL SELECT.  AFAIK, any user-written program can be
> defined to RDO including those with national characters ($#@) in the name.
> >
> > I am curious, in what case(s) do you believe that a callable subroutine
> could NOT be definable in RDO?
> >
> > Unless it is for very high frequency user programs where maximum
> performance is critical, statically linked functional subroutines (under
> CICS or not) are a maintenance nightmare, because when (not if) those
> subroutines need to change, whether for new function or for defect repair,
> EVERY program that statically linked them must be re-linked and (more
> costly and more critically) MUST be re-tested for quality assurance.
> >
> > And even for high performance requirements, the EXEC CICS LINK (or
> better, a plain COBOL CALL variable-name, even under CICS) has a fairly
> efficient path to execute already-loaded subroutines, and if they are being
> used frequently they are almost surely already loaded in memory.
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Steve Thompson
> > Sent: Sunday, April 9, 2023 2:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Cobol calling module with non alphanumeric no longer
> allowed???
> >
> > The other reason for the literal calls is because one wants the load
> module to have the subroutines statically linked that the COBOL program is
> using. In this way there is no LOAD done during execution time because
> COBOL "knows" that these are statically linked.
> >
> > There are a few reasons to want this behavior.
> >
> > The major one that comes to mind is you have to have static linkage for
> running in a CICS environment because the subroutines are not CICS
> definable (RDO) and so have to be statically linked.
> >
> > Steve Thompson
> >
> > On 4/8/2023 1:50 AM, Farley, Peter wrote:
> >> Not true for non-static calls.  We are past COBOL 5 (V6.2 at the
> moment) and "CALL variable USING . . . " where "variable" has any of the
> "national" characters ($#@) works every time.  We have multiple dynamically
> called utility subroutines with those characters in the program name.
> >>
> >> Why in the world are you using literal calls?  Or are you using the
> DYNAM option to convert literal calls to dynamic ones?  If so, bite the
> bullet - convert them to "CALL variable" and you are done.
> >>
> >> The only legitimate case I have seen for using literal CALL's is when
> you are using nested subroutine programs in the same source file as the
> calling program.
> >>
> >> Peter
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Frank Swarbrick
> >> Sent: Friday, April 7, 2023 6:07 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Cobol calling module with non alphanumeric no longer allowed???
> >>
> >> I've tried calling modules (that exist!) with both '@' and '#' 

Re: AI wipes out humanity?

[Bob Bridges]

Yeah, I realize I didn't define anything.  But in this case I'm really just
saying that we have no idea whether an AI can have an impulse to preserve
itself.  We observe that impulse in every form of life, but it's well to
keep in mind that an AI isn't of that sort.  It may have that impulse, but
so far that's just an assumption, no?

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

/* For Sale: Toddler bed, white metal frame, practically new but had
monsters under it, $20  -from Reader's Digest, Feb 1999 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Sunday, April 9, 2023 16:36

There are a lot of questions that are best answered by asking "What do you
mean by life?"; in this case, what do you mean by life? Is a virus alive? A
prion? An organization not based on proteins and RNA? An organism not based
on CHON, P, S and a few stray metals?


From: [robhbrid...@gmail.com]
Sent: Sunday, April 9, 2023 3:57 PM

An interesting article in some ways.  I don't take seriously all of its
speculations, partly because as a Christian I see world events progressing
rather differently.  But one assumption I want to question here starts with
the observation that all life seeks to survive, and speculates that AIs are
likely to 1) find themselves in competition with humans and therefore 2)
conclude that we have to be wiped out.

My challenge is this:  All life seeks to survive, yes, but AIs are not life.
Maybe they'll discover an urge to survive, but maybe that's not in their
makeup and cannot be.  Does anyone know?

Just a thought.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Bill Johnson
Sent: Sunday, April 9, 2023 15:01

Thoughts.

The Aliens Have Landed, and We Created Them
https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligenc
e-the-aliens-have-landed-and-we-created-them

--
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: COBOL question

[Cameron Conacher]

Thanks Bob,
No I initialize the Pointer to NULL, and then allocate. Successfully.
And then later I check to see it the pointer = NULL. If it is not NULL, then I 
do the FREE.

Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
T Roller
Sent: Saturday, April 8, 2023 8:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

Region card big enough? I’ve seen that abend via not enough memory.

Bob

Sent from Proton Mail for iOS

On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee  wrote:

> I have not seen this exactly like what you describe, but I do have
> some thoughts.
> The pointer you are using for the ALLOCATE, does it have a value
> clause, specifically VALUE NULL.
> If not, the pointer could have an unknown value that does not compare
> equal to NULL so you would attempt to FREE it.
>
> On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher  wrote:
>
>> Hello folks
>> I have written an IMS COBOL program. I have included a couple of
>> ALLOCATE statements.
>> At the end of processing I check my pointers and if they are not NULL
>> I try to FREE. This results in a U4038 abend. At least inside Expediter.
>> I have not used ALLOCATE/FREE before.
>> I am thinking it may be related to Expediter somehow.
>> I mean FREE is pretty darned straight forward.
>> At the moment I have commented out the statements. Memory should be
>> freed at the end of processing anyway, but good housekeeping is well good.
>> Has anyone seen this before?
>>
>> Thanks
>>
>> Sent from my iPhone
>> -
>> - 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Farley, Peter]

OK, so this was a shop standard rather than any actual requirement.  So not 
"cannot be defined to RDO" but "chose not to be allowed to be defined in RDO by 
management decision".

That kind of thing is a deliberate decision to live with the consequences for 
some perceived benefit.  To each their own.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, April 9, 2023 4:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

In the case of a common routine(s) that is (are) statically linked for Batch 
and CICS environments. I didn't design the system the customer had, I just had 
to be aware of it when I was working on Compile support tools.

So I thought that this aspect should be considered in this conversation.

And, yes, if these routines changed, the causing the common
copybook(s) to be changed, that would require a recompile and linkedit of the 
batch and CICS sides, QA testing, and then promotion back into production. So 
that had to be coordinated across a few application groups for each program 
that used one of those "dual" routine programs (dual from the idea that they 
were used in both environments).

Steve Thompson

On 4/9/2023 2:50 PM, Farley, Peter wrote:
> The only CICS routines that MUST be statically linked are the DFH 
> subroutines that are called as the result of coding CICS commands like EXEC 
> CICS LINK or EXEC SQL SELECT.  AFAIK, any user-written program can be defined 
> to RDO including those with national characters ($#@) in the name.
>
> I am curious, in what case(s) do you believe that a callable subroutine could 
> NOT be definable in RDO?
>
> Unless it is for very high frequency user programs where maximum performance 
> is critical, statically linked functional subroutines (under CICS or not) are 
> a maintenance nightmare, because when (not if) those subroutines need to 
> change, whether for new function or for defect repair, EVERY program that 
> statically linked them must be re-linked and (more costly and more 
> critically) MUST be re-tested for quality assurance.
>
> And even for high performance requirements, the EXEC CICS LINK (or better, a 
> plain COBOL CALL variable-name, even under CICS) has a fairly efficient path 
> to execute already-loaded subroutines, and if they are being used frequently 
> they are almost surely already loaded in memory.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Steve Thompson
> Sent: Sunday, April 9, 2023 2:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cobol calling module with non alphanumeric no longer allowed???
>
> The other reason for the literal calls is because one wants the load module 
> to have the subroutines statically linked that the COBOL program is using. In 
> this way there is no LOAD done during execution time because COBOL "knows" 
> that these are statically linked.
>
> There are a few reasons to want this behavior.
>
> The major one that comes to mind is you have to have static linkage for 
> running in a CICS environment because the subroutines are not CICS definable 
> (RDO) and so have to be statically linked.
>
> Steve Thompson
>
> On 4/8/2023 1:50 AM, Farley, Peter wrote:
>> Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
>> "CALL variable USING . . . " where "variable" has any of the "national" 
>> characters ($#@) works every time.  We have multiple dynamically called 
>> utility subroutines with those characters in the program name.
>>
>> Why in the world are you using literal calls?  Or are you using the DYNAM 
>> option to convert literal calls to dynamic ones?  If so, bite the bullet - 
>> convert them to "CALL variable" and you are done.
>>
>> The only legitimate case I have seen for using literal CALL's is when you 
>> are using nested subroutine programs in the same source file as the calling 
>> program.
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Frank Swarbrick
>> Sent: Friday, April 7, 2023 6:07 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Cobol calling module with non alphanumeric no longer allowed???
>>
>> I've tried calling modules (that exist!) with both '@' and '#' signs in them 
>> and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is 
>> there any good reason why this is the case?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Paul Gilmartin]

On Sun, 9 Apr 2023 20:41:33 +, Seymour J Metz wrote:

>Curse you, OCO!
>
>I suspect that validating a potential ENVB address requires running a tree 
>rather than just a list.
>

shows only linear chains.  So there can't be other kids of trees.

-- 
gil

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

Re: AI wipes out humanity?

[Seymour J Metz]

AI certainly raises all sorts of ethical and practical issue beyon the obvious 
"Will we ever achieve it?", but predicting when is even harder than predicting 
what. Further, evolution has many pathways, not all of which involve driving 
competitors to extinction. Of course, some of the alternative pathways may also 
be horrifying.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, April 9, 2023 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AI wipes out humanity?

Thoughts.

The Aliens Have Landed, and We Created Them
https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligence-the-aliens-have-landed-and-we-created-them




Sent from Yahoo Mail for iPhone

--
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: Specifhing the ENVBLOCK (was: Just PDSE)

[Seymour J Metz]

Curse you, OCO!

I suspect that validating a potential ENVB address requires running a tree 
rather than just a list.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, April 9, 2023 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Specifhing the ENVBLOCK (was: Just PDSE)

(Subject: changed: this has drifted far from"PDSE")

On Sun, 9 Apr 2023 09:50:44 +, Seymour J Metz wrote:

>Chapter 12. TSO/E REXX programming services
>
Thanks.  Eek!  TMI.  Where I see:
Entry specifications
For the IRXEXCOM routine, the contents of the registers on entry are:
Register 0  Address of an environment block (optional)

It should clarify that with "see Parameter 5 (below)"
Where it says:
... However, IRXEXCOM does not check whether the address is valid.
Ouch!
And the concern raised earlier that many languages don't allow control
of R0 is serious.  REXX should provide standard CALL interfaces.

The Services book mentions IKJCT441 as an alternative.  However:
IKJCT441 uses the REXX direct interface (rather than the symbolic
interface).  Why this serious restriction?  Compatibility with CLIST
limitations?

Is there a callable service that returns a *valid* EXECBLOCK address?

>"f you do not specify an address in the environment block address parameter, 
>the TSO/E REXX routine
>checks register 0 for the address of an environment block. If register 0 
>contains the address of a
>valid environment block, the routine runs in the environment represented by 
>that environment block.
>If the address is not valid, the routine locates the current non-reentrant 
>environment and runs in that
>
There is much mention of environment chains.  How are those chains rooted?
It may not matter if it has no supported user interface.

How does it check for validity?  Merely verifying the identifier "ENVBLOCK"?
Or does it verify that block exists in a chain.

>environment. If register 0 contains a 0, the routine immediately searches for 
>the last non-reentrant
>environment created, thereby eliminating the processing required to check 
>whether register 0 contains a
>valid environment block address."

So it's quicker to search a list than validate a passed address!?

--
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: Dave Josuma's post

[Jousma, David]

Glad to see you are still kicking around, Ed!

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Edward Gould <04bcc43af339-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 9, 2023 3:51:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Dave Josuma's post

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I have been here lurking for the last five or so years. Here is my response to 
Dave’s post.

As for me “arguing,” much of it had to do with IBMer’s sugar-coating many 
issues in older times. To name two, a few were IBM and their blind attitude 
towards COBOL. Arguing on COBOL was and always has been IBM’s blind attitude 
toward the lack of support for large table sizes. They still can’t do large 
table sizes (i.e., 64-bit).

The other issue was for the group of IBM-Main people at GUIDE (SCIDS, to be 
specific) who refused to talk to other IBM Main people. The favorites on here 
seemed (to me anyway encourage it). I should add here that other people sent me 
private replies agreeing with me.

The other sticking point was the old IBM HUGE fix tapes for VSAM. They still 
should be hung out to dry for not doing it well.
 The systems type started the process of turning gray from those. My point 
(beside the complexity of the number of fixes) and to be a bit fair towards 
IBM, SMPE has helped a bit in this area but not to the extent of large numbers 
of fixes).

My health has declined over the years, so I have stayed out of IBM-Main as much 
as possible.

Ed

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: AI wipes out humanity?

[Seymour J Metz]

There are a lot of questions that are best answered by asking "What do you mean 
by life?"; in this case, what do you mean by life? Is a virus alive? A prion? 
An organization not based on proteins and RNA? An organism not based on CHON, 
P, S and a few stray metals?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Sunday, April 9, 2023 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AI wipes out humanity?

An interesting article in some ways.  I don't take seriously all of its 
speculations, partly because as a Christian I see world events progressing 
rather differently.  But one assumption I want to question here starts with the 
observation that all life seeks to survive, and speculates that AIs are likely 
to 1) find themselves in competition with humans and therefore 2) conclude that 
we have to be wiped out.

My challenge is this:  All life seeks to survive, yes, but AIs are not life.  
Maybe they'll discover an urge to survive, but maybe that's not in their makeup 
and cannot be.  Does anyone know?

Just a thought.

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

/* [Many young people today] resent the ethical demands of society as 
infringements of their personal freedom.  They believe that their rights as 
individuals include the right to "create their own values," but they cannot 
explain what that means, aside from the right to do as they please.  They 
cannot seem to grasp the idea that values imply some principle of moral 
obligation.  -Christopher Lasch */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Sunday, April 9, 2023 15:01

Thoughts.

The Aliens Have Landed, and We Created Them 
https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligence-the-aliens-have-landed-and-we-created-them

--
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: ssid not recognized after erly code update

[Wayne Bickerdike]

Bill,

Read this:

https://www.ibm.com/docs/en/db2-for-zos/12?topic=delivery-updating-db2-initialization-parameters-function-level-activation



On Sun, Apr 9, 2023 at 8:45 PM Bill Giannelli 
wrote:

> I updated DB2 ERLY code dataset SDSNLINK, now the SSID is not recognized.
> Have IPLd and refreshed LLA then tried stopping and starting LLA.
> What is wrong?
> thanks
> Bill
>
> --
> 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: ssid not recognized after erly code update

[Wayne Bickerdike]

Bill,

Check the DSNTIJUZ member from your installation.

This should show you what subsystem was created in ZPARMS. Perhaps you have
dropped your custom module.

On Sun, Apr 9, 2023 at 8:45 PM Bill Giannelli 
wrote:

> I updated DB2 ERLY code dataset SDSNLINK, now the SSID is not recognized.
> Have IPLd and refreshed LLA then tried stopping and starting LLA.
> What is wrong?
> thanks
> Bill
>
> --
> 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: Cobol calling module with non alphanumeric no longer allowed???

[Steve Thompson]

In the case of a common routine(s) that is (are) statically 
linked for Batch and CICS environments. I didn't design the 
system the customer had, I just had to be aware of it when I was 
working on Compile support tools.


So I thought that this aspect should be considered in this 
conversation.


And, yes, if these routines changed, the causing the common 
copybook(s) to be changed, that would require a recompile and 
linkedit of the batch and CICS sides, QA testing, and then 
promotion back into production. So that had to be coordinated 
across a few application groups for each program that used one of 
those "dual" routine programs (dual from the idea that they were 
used in both environments).


Steve Thompson

On 4/9/2023 2:50 PM, Farley, Peter wrote:

The only CICS routines that MUST be statically linked are the DFH 
subroutines that are called as the result of coding CICS commands like EXEC 
CICS LINK or EXEC SQL SELECT.  AFAIK, any user-written program can be defined 
to RDO including those with national characters ($#@) in the name.

I am curious, in what case(s) do you believe that a callable subroutine could 
NOT be definable in RDO?

Unless it is for very high frequency user programs where maximum performance is 
critical, statically linked functional subroutines (under CICS or not) are a 
maintenance nightmare, because when (not if) those subroutines need to change, 
whether for new function or for defect repair, EVERY program that statically 
linked them must be re-linked and (more costly and more critically) MUST be 
re-tested for quality assurance.

And even for high performance requirements, the EXEC CICS LINK (or better, a 
plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to 
execute already-loaded subroutines, and if they are being used frequently they 
are almost surely already loaded in memory.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, April 9, 2023 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

The other reason for the literal calls is because one wants the load module to have the 
subroutines statically linked that the COBOL program is using. In this way there is no 
LOAD done during execution time because COBOL "knows" that these are statically 
linked.

There are a few reasons to want this behavior.

The major one that comes to mind is you have to have static linkage for running 
in a CICS environment because the subroutines are not CICS definable (RDO) and 
so have to be statically linked.

Steve Thompson

On 4/8/2023 1:50 AM, Farley, Peter wrote:

Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and "CALL variable USING . . . 
" where "variable" has any of the "national" characters ($#@) works every time.  We 
have multiple dynamically called utility subroutines with those characters in the program name.

Why in the world are you using literal calls?  Or are you using the DYNAM option to 
convert literal calls to dynamic ones?  If so, bite the bullet - convert them to 
"CALL variable" and you are done.

The only legitimate case I have seen for using literal CALL's is when you are 
using nested subroutine programs in the same source file as the calling program.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Frank Swarbrick
Sent: Friday, April 7, 2023 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol calling module with non alphanumeric no longer allowed???

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

Re: AI wipes out humanity?

[Bob Bridges]

An interesting article in some ways.  I don't take seriously all of its 
speculations, partly because as a Christian I see world events progressing 
rather differently.  But one assumption I want to question here starts with the 
observation that all life seeks to survive, and speculates that AIs are likely 
to 1) find themselves in competition with humans and therefore 2) conclude that 
we have to be wiped out.

My challenge is this:  All life seeks to survive, yes, but AIs are not life.  
Maybe they'll discover an urge to survive, but maybe that's not in their makeup 
and cannot be.  Does anyone know?

Just a thought.

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

/* [Many young people today] resent the ethical demands of society as 
infringements of their personal freedom.  They believe that their rights as 
individuals include the right to "create their own values," but they cannot 
explain what that means, aside from the right to do as they please.  They 
cannot seem to grasp the idea that values imply some principle of moral 
obligation.  -Christopher Lasch */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Sunday, April 9, 2023 15:01

Thoughts.

The Aliens Have Landed, and We Created Them 
https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligence-the-aliens-have-landed-and-we-created-them

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

Re: reallocating a linklist dataset

[Doug]

Well, I apologize foir the brevity of the LNKLIST update. I really did 
not think anyone would take it to be those were the only steps, just the 
intent.
But yes, you do have to create a new LNKLIST from the old, remove the 
dataset from it, then activate that new LNKLIST, then you can rename the 
old and reallocate a new.


The actual step by step procedure IS in the book. Sorry anyone thouoght 
my short version was the whole thing. :-)



Doug Fuerst

-- Original Message --
From: "Peter Relson" 
To: IBM-MAIN@listserv.ua.edu
Sent: 09-Apr-23 8:38:54
Subject: Re: reallocating a linklist dataset


Bill G wrote

Would the dataset be de-allocated at IPL so I might redefine my dataset?
Or would there be allocation across the sysplex for other Lpars?

All the allocations are local to the system. The only safe time to do what you 
want is while any system(s) using that data set are not IPL'd. It is

Doug F wrote

Take LLA down.
Take the dataset out of the active LNKLIST
Reallocate it.
Put it back.
Start LLA


That is incomplete and therefore cannot be considered correct. The missing step 
is unpredictably dangerous and you take it wholly at your system's risk. Only 
you can decide if that risk is worth taking.

The 2nd step above would really be stated as making sure that nothing is 
running with a LNKLST set (there could be multiple) that has the current data 
set in it. In most cases you would do that by defining a single new LNKLST set 
that does not have the data set. If, within this window, work needs that data 
set you'll need to have a copy of the data set within the new LNKLST set. Once 
defined, then you would activate this new LNKLST set.

Then you get to making sure that no address space is using a LNKLST set that 
has the data set in it.
That is the unpredictably dangerous step. SETPROG LNKLST UPDATE will happily do 
what you tell it to do.
Don't rely on your system to stay up after that happens. Will it? Very likely. 
Will it stay up without encountering problems? Very likely. Can you tell if 
something bad is going to happen in advance? No.

Peter Relson
z/OS Core Technology Design


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


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

Dave Josuma's post

[Edward Gould]

I have been here lurking for the last five or so years. Here is my response to 
Dave’s post.

As for me “arguing,” much of it had to do with IBMer’s sugar-coating many 
issues in older times. To name two, a few were IBM and their blind attitude 
towards COBOL. Arguing on COBOL was and always has been IBM’s blind attitude 
toward the lack of support for large table sizes. They still can’t do large 
table sizes (i.e., 64-bit). 

The other issue was for the group of IBM-Main people at GUIDE (SCIDS, to be 
specific) who refused to talk to other IBM Main people. The favorites on here 
seemed (to me anyway encourage it). I should add here that other people sent me 
private replies agreeing with me.

The other sticking point was the old IBM HUGE fix tapes for VSAM. They still 
should be hung out to dry for not doing it well. 
 The systems type started the process of turning gray from those. My point 
(beside the complexity of the number of fixes) and to be a bit fair towards 
IBM, SMPE has helped a bit in this area but not to the extent of large numbers 
of fixes).

My health has declined over the years, so I have stayed out of IBM-Main as much 
as possible.

Ed

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

Re: AI wipes out humanity?

[Rupert Reynolds]

You might get more responses on the offtopic day (Friday), but here are my
thoughts:-

Hardly! It can do statistics and answer "Roughly what kind of word soup
would someone expect in answer to..." but it doesn't understand what the
words mean, and even when you prove it wrong, it can only BS like an idiot
or back down.

It's quite good at writing unit tests for me, though. Coypu-pasty the text
into Notepad++, run a simple script to extract the tests, and instead of
"Kermits all the way down" I get a couple of Animals instead :-)

Roops

On Sun, 9 Apr 2023, 20:00 Bill Johnson, <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Thoughts.
>
> The Aliens Have Landed, and We Created Them
>
> https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligence-the-aliens-have-landed-and-we-created-them
>
>
>
>
> Sent from Yahoo Mail for iPhone
>
> --
> 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

Specifhing the ENVBLOCK (was: Just PDSE)

[Paul Gilmartin]

(Subject: changed: this has drifted far from"PDSE")

On Sun, 9 Apr 2023 09:50:44 +, Seymour J Metz wrote:

>Chapter 12. TSO/E REXX programming services
>
Thanks.  Eek!  TMI.  Where I see:
Entry specifications
For the IRXEXCOM routine, the contents of the registers on entry are:
Register 0  Address of an environment block (optional)

It should clarify that with "see Parameter 5 (below)"
Where it says:
... However, IRXEXCOM does not check whether the address is valid. 
Ouch!
And the concern raised earlier that many languages don't allow control
of R0 is serious.  REXX should provide standard CALL interfaces.

The Services book mentions IKJCT441 as an alternative.  However:
IKJCT441 uses the REXX direct interface (rather than the symbolic
interface).  Why this serious restriction?  Compatibility with CLIST
limitations?

Is there a callable service that returns a *valid* EXECBLOCK address?

>"f you do not specify an address in the environment block address parameter, 
>the TSO/E REXX routine
>checks register 0 for the address of an environment block. If register 0 
>contains the address of a
>valid environment block, the routine runs in the environment represented by 
>that environment block.
>If the address is not valid, the routine locates the current non-reentrant 
>environment and runs in that
>
There is much mention of environment chains.  How are those chains rooted?
It may not matter if it has no supported user interface.

How does it check for validity?  Merely verifying the identifier "ENVBLOCK"?
Or does it verify that block exists in a chain.

>environment. If register 0 contains a 0, the routine immediately searches for 
>the last non-reentrant
>environment created, thereby eliminating the processing required to check 
>whether register 0 contains a
>valid environment block address."

So it's quicker to search a list than validate a passed address!?

-- 
gil

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

Re: AI wipes out humanity?

[Phil Smith III]

I think that when it's time to railroad, people are gonna railroad, aka the
genie doesn't go back in the bottle. All the calls for a "moratorium" are
silly: there's no way to enforce one, so it's just a waste of time. Spend
the effort looking for ways to mitigate/avoid the risks, don't pretend that
we can wish them away.


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

AI wipes out humanity?

[Bill Johnson]

Thoughts.

The Aliens Have Landed, and We Created Them 
https://www.bloomberg.com/opinion/articles/2023-04-09/artificial-intelligence-the-aliens-have-landed-and-we-created-them




Sent from Yahoo Mail for iPhone

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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Farley, Peter]

The only CICS routines that MUST be statically linked are the DFH 
subroutines that are called as the result of coding CICS commands like EXEC 
CICS LINK or EXEC SQL SELECT.  AFAIK, any user-written program can be defined 
to RDO including those with national characters ($#@) in the name.

I am curious, in what case(s) do you believe that a callable subroutine could 
NOT be definable in RDO?

Unless it is for very high frequency user programs where maximum performance is 
critical, statically linked functional subroutines (under CICS or not) are a 
maintenance nightmare, because when (not if) those subroutines need to change, 
whether for new function or for defect repair, EVERY program that statically 
linked them must be re-linked and (more costly and more critically) MUST be 
re-tested for quality assurance.

And even for high performance requirements, the EXEC CICS LINK (or better, a 
plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to 
execute already-loaded subroutines, and if they are being used frequently they 
are almost surely already loaded in memory.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, April 9, 2023 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

The other reason for the literal calls is because one wants the load module to 
have the subroutines statically linked that the COBOL program is using. In this 
way there is no LOAD done during execution time because COBOL "knows" that 
these are statically linked.

There are a few reasons to want this behavior.

The major one that comes to mind is you have to have static linkage for running 
in a CICS environment because the subroutines are not CICS definable (RDO) and 
so have to be statically linked.

Steve Thompson

On 4/8/2023 1:50 AM, Farley, Peter wrote:
> Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
> "CALL variable USING . . . " where "variable" has any of the "national" 
> characters ($#@) works every time.  We have multiple dynamically called 
> utility subroutines with those characters in the program name.
>
> Why in the world are you using literal calls?  Or are you using the DYNAM 
> option to convert literal calls to dynamic ones?  If so, bite the bullet - 
> convert them to "CALL variable" and you are done.
>
> The only legitimate case I have seen for using literal CALL's is when you are 
> using nested subroutine programs in the same source file as the calling 
> program.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Frank Swarbrick
> Sent: Friday, April 7, 2023 6:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Cobol calling module with non alphanumeric no longer allowed???
>
> I've tried calling modules (that exist!) with both '@' and '#' signs in them 
> and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
> any good reason why this is the case?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Steve Thompson]

The other reason for the literal calls is because one wants the 
load module to have the subroutines statically linked that the 
COBOL program is using. In this way there is no LOAD done during 
execution time because COBOL "knows" that these are statically 
linked.


There are a few reasons to want this behavior.

The major one that comes to mind is you have to have static 
linkage for running in a CICS environment because the subroutines 
are not CICS definable (RDO) and so have to be statically linked.


Steve Thompson

On 4/8/2023 1:50 AM, Farley, Peter wrote:

Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and "CALL variable USING . . . 
" where "variable" has any of the "national" characters ($#@) works every time.  We 
have multiple dynamically called utility subroutines with those characters in the program name.

Why in the world are you using literal calls?  Or are you using the DYNAM option to 
convert literal calls to dynamic ones?  If so, bite the bullet - convert them to 
"CALL variable" and you are done.

The only legitimate case I have seen for using literal CALL's is when you are 
using nested subroutine programs in the same source file as the calling program.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Friday, April 7, 2023 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol calling module with non alphanumeric no longer allowed???

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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


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

Re: Password alter record

[Tom Brennan]

Unless something changed over the last 10 years since I used to work 
with things like this, ALTUSER is recorded in SMF, including what userid 
made the change.  One way to format the records is:

https://www.ibm.com/docs/en/zos/2.4.0?topic=irradu00-example

On 4/8/2023 10:48 PM, Jake Anderson wrote:

Hello

Cross posted

Is there a way to know on who a changed a users password? Any SMF record
that can help ?

Or any audit reports in RACF ?

Jake

--
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: Call by value, final

[David Spiegel]

Hi Jeremy,
Maybe SMPSCDS?
I do not recall (I've used both extensively) EVER seeing member names 
like that in SMPPTS and SMPSTS


Regards,
David

On 2023-04-09 08:43, Jeremy Nicoll wrote:

On Sun, 9 Apr 2023, at 11:10, Seymour J Metz wrote:

Are you sure that you're not thinking of SMP through SMP4, the free SMP
that preceeded SMP/E?

Certain.  I only ever used SMP/E - roughly between 1986 and the late 1990s.

I don't recall precisely but I think these weird member names were visible via
ispf member lists, and I was probably looking at the SMPMTS or SMPPTS.



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

Re: Call by value, final

[Jeremy Nicoll]

On Sun, 9 Apr 2023, at 11:10, Seymour J Metz wrote:
> Are you sure that you're not thinking of SMP through SMP4, the free SMP 
> that preceeded SMP/E?

Certain.  I only ever used SMP/E - roughly between 1986 and the late 1990s.

I don't recall precisely but I think these weird member names were visible via
ispf member lists, and I was probably looking at the SMPMTS or SMPPTS.

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: reallocating a linklist dataset

[Jay Maynard]

Yes, an IPL is incredibly disruptive. There are times, however, where it is
needed to prevent even greater disruption from catastrophic system
failures. It seems to me that reallocating a dataset on the linklist is one
such time.

On Sun, Apr 9, 2023 at 7:39 AM Peter Relson  wrote:

> Bill G wrote
> 
> Would the dataset be de-allocated at IPL so I might redefine my dataset?
> Or would there be allocation across the sysplex for other Lpars?
> 
> All the allocations are local to the system. The only safe time to do what
> you want is while any system(s) using that data set are not IPL'd. It is
>
> Doug F wrote
> 
> Take LLA down.
> Take the dataset out of the active LNKLIST
> Reallocate it.
> Put it back.
> Start LLA
> 
>
> That is incomplete and therefore cannot be considered correct. The missing
> step is unpredictably dangerous and you take it wholly at your system's
> risk. Only you can decide if that risk is worth taking.
>
> The 2nd step above would really be stated as making sure that nothing is
> running with a LNKLST set (there could be multiple) that has the current
> data set in it. In most cases you would do that by defining a single new
> LNKLST set that does not have the data set. If, within this window, work
> needs that data set you'll need to have a copy of the data set within the
> new LNKLST set. Once defined, then you would activate this new LNKLST set.
>
> Then you get to making sure that no address space is using a LNKLST set
> that has the data set in it.
> That is the unpredictably dangerous step. SETPROG LNKLST UPDATE will
> happily do what you tell it to do.
> Don't rely on your system to stay up after that happens. Will it? Very
> likely. Will it stay up without encountering problems? Very likely. Can you
> tell if something bad is going to happen in advance? No.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: reallocating a linklist dataset

[Peter Relson]

Bill G wrote

Would the dataset be de-allocated at IPL so I might redefine my dataset?
Or would there be allocation across the sysplex for other Lpars?

All the allocations are local to the system. The only safe time to do what you 
want is while any system(s) using that data set are not IPL'd. It is

Doug F wrote

Take LLA down.
Take the dataset out of the active LNKLIST
Reallocate it.
Put it back.
Start LLA


That is incomplete and therefore cannot be considered correct. The missing step 
is unpredictably dangerous and you take it wholly at your system's risk. Only 
you can decide if that risk is worth taking.

The 2nd step above would really be stated as making sure that nothing is 
running with a LNKLST set (there could be multiple) that has the current data 
set in it. In most cases you would do that by defining a single new LNKLST set 
that does not have the data set. If, within this window, work needs that data 
set you'll need to have a copy of the data set within the new LNKLST set. Once 
defined, then you would activate this new LNKLST set.

Then you get to making sure that no address space is using a LNKLST set that 
has the data set in it.
That is the unpredictably dangerous step. SETPROG LNKLST UPDATE will happily do 
what you tell it to do.
Don't rely on your system to stay up after that happens. Will it? Very likely. 
Will it stay up without encountering problems? Very likely. Can you tell if 
something bad is going to happen in advance? No.

Peter Relson
z/OS Core Technology Design


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

ssid not recognized after erly code update

[Bill Giannelli]

I updated DB2 ERLY code dataset SDSNLINK, now the SSID is not recognized.
Have IPLd and refreshed LLA then tried stopping and starting LLA.
What is wrong?
thanks
Bill

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

Re: Not aging well (know-it-alls)

[Seymour J Metz]

"Trust but verify."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Matt Hogstrom [m...@hogstrom.org]
Sent: Friday, April 7, 2023 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Not aging well (know-it-alls)

Your comment wasn’t directed at my but it made me think of two of my favorite 
phrases.

"I’m proud of my humility."

“I’m smart enough to know how dumb I can be.”

Enjoy the Easter weekend all y’all.

Matt Hogstrom

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



>
> Are you also modest, or are you vain?


--
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: Call by value, final

[Seymour J Metz]

Are you sure that you're not thinking of SMP through SMP4, the free SMP that 
preceeded SMP/E?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
Sent: Saturday, April 8, 2023 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Call by value, final

On Sat, 8 Apr 2023, at 15:54, Paul Gilmartin wrote:
> On Sat, 8 Apr 2023 04:27:04 +, Frank Swarbrick wrote:
>>
>>...  The assembler seems OK with it, but the linker is converted to upper 
>> case, even though I've specified CASE(MIXED).
>>
> I'm surprised.  In an experiment long ago I was able to create a member
> in an (old-fashioned) PDS simply with CASE(MIXED); NAME lower.

I'm sure I recall that some of the SMP/E work PDSes had member names that
not only were mixed case but also included characters that you'd not see in
PDSs processed via standard ispf utilities.  I can't quite remember if they used
every single byte value in each of the 8 character positions, but I think they
might have done, thus allowing 256 ** 8 different member names.

--
Jeremy Nicoll - my opinions are my own.

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

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

Re: Call by value, final

[Seymour J Metz]

In particular, transient SVC routines with numbers that were multiples of 10 
had names ending in 'C0'x.

The free SMP also used some interesting member names.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, April 8, 2023 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Call by value, final

On Sat, 8 Apr 2023 09:15:32 -0700, M. Ray Mullins (Ray) wrote:

>PDSEs allow mixed case alias names up to 1023 bytes long. They can only be 
>seen through DESERV, so a utility not named ISPF can look at them (I think PDS 
>8.6 supports them).
>
>If you look at some of the CICS PDSE program object libraries, you can see 
>them in the member list (again, not under ISPF, sounds like a good IBM Idea™).
>
How does OMVS support program object names >8 characters or
containing "invalid" characters?  Must they be aliases? can they be
re-linked or copied with "cp  -X executable //LINKLIB.PDSE"?

My recollection of history, fading, corrections welcome:

Before Binder existed, syntax of Linkage Editor commands
limited names that could be used in commands to the
Classic conventions: upper case alphanumeric and a few
national.  The description of object (SYSLIN) formats had
no such restriction: any 8 octets were accepted.  Some ISVs
exploited this behavior to bootleg information in ESDs
containing "invalid" characters that were intentionally
difficult for end users to modify.

Binder, in order to accommodate long names, chose a
convention of regarding any character <=x'40' as a string
terminator.  (Cue outrage at "null-terminated" strings.)
Such ISV-generated ESDs caused Binder misbehavior,
perhaps even program checks.

I noted in these lists that this was a compatibility violation
uncharacteristic of IBM.  IBM representatives such as
John Ehrman responded that the ISVs had broken the
rules; it was their responsibility to deal with the damage.
I believe IBM was overstating the rules: they appeared to
apply only to Linkage Editor commands, not to the content
of object files generated by compilers.

--
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: Just PDSE

[Seymour J Metz]

Chapter 12. TSO/E REXX programming services

"f you do not specify an address in the environment block address parameter, 
the TSO/E REXX routine
checks register 0 for the address of an environment block. If register 0 
contains the address of a
valid environment block, the routine runs in the environment represented by 
that environment block.
If the address is not valid, the routine locates the current non-reentrant 
environment and runs in that
environment. If register 0 contains a 0, the routine immediately searches for 
the last non-reentrant
environment created, thereby eliminating the processing required to check 
whether register 0 contains a
valid environment block address."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, April 8, 2023 9:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just PDSE

On Sun, 9 Apr 2023 00:14:46 +, Seymour J Metz wrote:

>Presumably R0  should be zero if not pointing to an ENVB.
>
Cite the source, please.

--
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: reallocating a linklist dataset

[Seymour J Metz]

No allocation is retained across IPL. Everything in your LNKLST will be 
reallocated at IPL. You will get the desired effect in two scenarios:

 1. You build a replacement PDS and update LNKLST to point to it.

 2. You build a replacement PDS, rename the old, rename the new to the old
and the calog entry for the old name points to the new volume.

If you need to replace it for multiple systems then you will have to re-IPL 
each. That's true even if they are not in the same sysplex.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Giannelli [billgianne...@gmail.com]
Sent: Saturday, April 8, 2023 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: reallocating a linklist dataset

I have to reallocate a Linklisted dataset due to space reasons.
As expected it is allocated by LLA and XCFAS.
Would the dataset be de-allocated at IPL so I might redefine my dataset?
Or would there be allocation across the sysplex for other Lpars?
thanks
Bill

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