Re: Mixing C/C++ with LE-conforming IBM HLASM

[Seymour J Metz]

The brain-dead e-mail client to which I referred is a web interface. Or did you 
mean the listserv web site, which I have not yet investigated?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, July 19, 2021 11:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

On Tue, 20 Jul 2021 01:51:32 +, Seymour J Metz  wrote:

>> Writing multiple members of a PDSE (not PDS) concurrently
>Who said anything about concurrently? Consider a program to create sequence 
>numbers in every member (or remove them).
>
I did:  On Fri, 16 Jul 2021 18:32:51 -0500, Paul Gilmartin ...

>> Too often, "is for" is a feckless apologia, paraphrasing "can only ... 
>> although it would be nice ..."
>
>The problem isn't that BSAM doesn't handle logical records, the problem is 
>that QSAM doesn't handle repositioning. The distinction between READ and GET 
>is a legitimate one.
>
There ought to be a synthesis of their two capabilities.

>> Was there a similar analogue for NOTE?
>Sort of, with limitations.
>
For VISAM, it might suffice to record the sequence number.

>>  Did the TSS assembler(?) use those?
>I believe that all of the compilers, including ASM (F), supported reading 
>source from VISAM with sequence numbers as keys.
>
An irritant to  modern languages such as Rexx and C which prefer
RECFM=VB, unnumbered.

>> (What became of the tradition of ">" quotation marks?  I faked them.)
>I'm using a brain-dead e-mail client. I  have to handle quoting by hand.
>
At times I circumvent such problems by posting from the Web interface.

-- 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: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Tue, 20 Jul 2021 01:51:32 +, Seymour J Metz  wrote:

>> Writing multiple members of a PDSE (not PDS) concurrently 
>Who said anything about concurrently? Consider a program to create sequence 
>numbers in every member (or remove them).
>
I did:  On Fri, 16 Jul 2021 18:32:51 -0500, Paul Gilmartin ...

>> Too often, "is for" is a feckless apologia, paraphrasing "can only ... 
>> although it would be nice ..."
>
>The problem isn't that BSAM doesn't handle logical records, the problem is 
>that QSAM doesn't handle repositioning. The distinction between READ and GET 
>is a legitimate one.
>
There ought to be a synthesis of their two capabilities.

>> Was there a similar analogue for NOTE?
>Sort of, with limitations.
> 
For VISAM, it might suffice to record the sequence number.

>>  Did the TSS assembler(?) use those?
>I believe that all of the compilers, including ASM (F), supported reading 
>source from VISAM with sequence numbers as keys.
>
An irritant to  modern languages such as Rexx and C which prefer
RECFM=VB, unnumbered.

>> (What became of the tradition of ">" quotation marks?  I faked them.)
>I'm using a brain-dead e-mail client. I  have to handle quoting by hand.
> 
At times I circumvent such problems by posting from the Web interface.

-- gil

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

Re: Mixing C/C++ with LE-conforming IBM HLASM

[Seymour J Metz]

> Writing multiple members of a PDSE (not PDS) concurrently 

Who said anything about concurrently? Consider a program to create sequence 
numbers in every member (or remove them).

> Too often, "is for" is a feckless apologia, paraphrasing "can only ... 
> although it would be nice ..."

The problem isn't that BSAM doesn't handle logical records, the problem is that 
QSAM doesn't handle repositioning. The distinction between READ and GET is a 
legitimate one.

> Was there a similar analogue for NOTE?

Sort of, with limitations.

>  Did the TSS assembler(?) use those?

I believe that all of the compilers, including ASM (F), supported reading 
source from VISAM with sequence numbers as keys.

> (What became of the tradition of ">" quotation marks?  I faked them.)

I'm using a brain-dead e-mail client. I  have to handle quoting by hand.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, July 19, 2021 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

On Mon, 19 Jul 2021 19:43:23 +, Seymour J Metz wrote:

>> OK.  It requires multiple DCBs.

>Yes, and if I'm doing something with every member of a PDS then I really don't 
>want all of those OPENs.
>
If I'm doing something with multiple members, e.g. comparing two members, I 
consider
it good design to use one DDNAME, two DCBs and two OPENs.  Isn't the 
alternative an
nightmare  of ping-ponging NOTEs and POINTs?  What would ISRSUPC do?

Writing multiple members of a PDSE (not PDS) concurrently should probably
be done with multiple DCBs.

"doing something with every member of a PDS" is probably better done serially 
than concurrently.

>> A member is not named when it is created,  but only at the point of STOW

>Thanks. Yes, the same issue exists with VPAM.

>> BPAM shoud support GET and PUT.

>Why? BSAM is for dealing with blocks. Although it would be nice if QSAM had 
>equivalents to equivalents to NOTE and POINT.
>
Too often, "is for" is a feckless apologia, paraphrasing "can only ... although 
it would be nice ..."

>In TSS, you use SETL to point to a logical VPAM record. Check the references I 
>gave you.
>
I got information overload.  Thanks for filtering for me.  Was there a similar 
analogue
for NOTE?  Did the TSS assembler(?) use those?

(What became of the tradition of ">" quotation marks?  I faked them.)

Thanks again,
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: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Mon, 19 Jul 2021 19:43:23 +, Seymour J Metz wrote:

>> OK.  It requires multiple DCBs.

>Yes, and if I'm doing something with every member of a PDS then I really don't 
>want all of those OPENs.
>
If I'm doing something with multiple members, e.g. comparing two members, I 
consider
it good design to use one DDNAME, two DCBs and two OPENs.  Isn't the 
alternative an
nightmare  of ping-ponging NOTEs and POINTs?  What would ISRSUPC do?

Writing multiple members of a PDSE (not PDS) concurrently should probably
be done with multiple DCBs.

"doing something with every member of a PDS" is probably better done serially 
than concurrently.

>> A member is not named when it is created,  but only at the point of STOW

>Thanks. Yes, the same issue exists with VPAM.

>> BPAM shoud support GET and PUT. 

>Why? BSAM is for dealing with blocks. Although it would be nice if QSAM had 
>equivalents to equivalents to NOTE and POINT.
>
Too often, "is for" is a feckless apologia, paraphrasing "can only ... although 
it would be nice ..."

>In TSS, you use SETL to point to a logical VPAM record. Check the references I 
>gave you.
>
I got information overload.  Thanks for filtering for me.  Was there a similar 
analogue
for NOTE?  Did the TSS assembler(?) use those?

(What became of the tradition of ">" quotation marks?  I faked them.)

Thanks again,
gil

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

Re: Serverpac installs January 2022 and beyond - Requests

[Shaffer, Terri]

Hi Marna,
  Thanks for the response.

So remembering my last serverpac install was 2.4 about a year ago, I am going 
by memory, but also from my past history.

There has always been issue, with a system upgrade, where I am re-using my 
existing catalog structure, but yet all forced IPL required datasets are not 
used.

These are like CPAC.  Datasets.   This causes cataloging issues in a few jobs 
as they are "required".  The way around this was to edit the job, change the 
names, etc and submit.

The other thing and maybe I am missing it, was the SSA,  I always used SYS1SSA. 
 Which was prefixed to all my SYS1 datasets only.

This caused issues with how jobs are built, because I used datasets, like 
CPAC.PARMLIB, etc and a template to copy things I might need for my upgrade in 
MY operational datasets.

There are at least 2-3 times I had to edit JCL to "fix" these operational 
changes.  Again I understand exactly where I want things and put datasets on 
alternate volumes just so I have them.

I can see why the junior or someone without that experience you might not want 
to fiddle with layout, but I have gotten my process down to about 3-4 hours for 
my complete SERVERPAC install.

I saved off my configuration, merged with the NEW configuration to any new 
datasets, changed the Logical to place the datasets where I want them and load.

I also see the dataset where you build all the JCL and even though I hope I 
don’t have too,  I could copy this dataset to a backup, edit my changes and 
submit outside of z/OSMF.

Like I said you are forcing a learning curve just like SERVERPAC was eons ago, 
which I am okay with AS LONG as I don’t lose functionality or flexibility, or 
maybe under an ADVANCED TAB, use caution, etc.

I have many thoughts. Just like you said, you should read my 
CPAC.OS240860.CONFIG dataset and merge the new serverpac information with it.

Since many already do this, and it was a SERVERPAC staple, why not prompt the 
user for the information and once a user states NEW or UPGRADE, merge with 
their configuration???

Again maybe you do, but I get the feeling you are throwing that responsibility 
back, which then causes more time and learning curves..

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Monday, July 19, 2021 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email


Hi Terri,
You are correct that within the z/OSMF interface, there is no way to edit a 
produced job for Deployment.  It is intended that no editing is necessary, in 
that if you need to "tweak" the job, we should be providing that capability 
within the interface itself.  The JCL produced should reflect what you want and 
also can be saved such that it can be reused for similar deployments, to avoid 
the same future tweaking.

Did you have any specifics on what you wanted to change in z/OSMF, but 
couldn't?  Realize that the data set configuration, volumes, and cataloging 
capabilities are extremely flexible and should be able to do whatever you want. 
 Even more so than the old ServerPac ISPF dialog.  For instance, you can rename 
any data set you want, put it anywhere you want, and the old dialog had some 
restrictions on certain data sets.  Might there be something in the data set, 
volume, and catalog capabilities we are missing?  I'd like to solve the 
editing-JCL problem, with a solution for you that allows you to incorporate 
your intentions right within the GUI much earlier, save that intention, and 
make it so that you never have to "remember" it again should you do a similar 
deploy of the product.   (I can see how tweaks to the old ServerPac JCL would 
not be saved in the configuration, and then you would have a need to keep doing 
those tweaks in the future for every install.  That is not the intention here 
with z/OSMF.)

I believe the "work data set prefix" you are referring to is the temporary file 
system for use as SMPWKDIR on "Define Job Settings".  Would you like more 
information provided for that description to help understand what you are 
providing?  Maybe something like a "Learn more..." to quickly show with more 
details that we are asking for the beginning qualifier(s) of data set name, 
that is a temporary zFS (completely handled within the jobs and accurately 
sized) that will be used as the SMPWKDIR?  This should be an easy thing to do, 
if it would help.

On that same checklist location for "Define Job Settings", the jobcard can be 
supplied, and also the place where you want all the generated jobs saved (like 
we had in SCPPBENU).  Of course, you could run the jobs from that saved data 
set from ISPF, but again, the intention is that they are run through z/OSMF so 
the interface can keep track of what you've done and how far you've 

Re: Serverpac installs January 2022 and beyond - Requests

[Al Loeffler]

Hi Marna,

You can't change the size of a dataset and you can't change PDS to PDSE. It's 
easy in ServerPac to mass change to PDSE. It skips ones that aren't eligible.

-Al Loeffler

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Monday, July 19, 2021 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

Hi Terri,
You are correct that within the z/OSMF interface, there is no way to edit a 
produced job for Deployment.  It is intended that no editing is necessary, in 
that if you need to "tweak" the job, we should be providing that capability 
within the interface itself.  The JCL produced should reflect what you want and 
also can be saved such that it can be reused for similar deployments, to avoid 
the same future tweaking.  

Did you have any specifics on what you wanted to change in z/OSMF, but 
couldn't?  Realize that the data set configuration, volumes, and cataloging 
capabilities are extremely flexible and should be able to do whatever you want. 
 Even more so than the old ServerPac ISPF dialog.  For instance, you can rename 
any data set you want, put it anywhere you want, and the old dialog had some 
restrictions on certain data sets.  Might there be something in the data set, 
volume, and catalog capabilities we are missing?  I'd like to solve the 
editing-JCL problem, with a solution for you that allows you to incorporate 
your intentions right within the GUI much earlier, save that intention, and 
make it so that you never have to "remember" it again should you do a similar 
deploy of the product.   (I can see how tweaks to the old ServerPac JCL would 
not be saved in the configuration, and then you would have a need to keep doing 
those tweaks in the future for every install.  That is not the intention here 
with z/OSMF.)

I believe the "work data set prefix" you are referring to is the temporary file 
system for use as SMPWKDIR on "Define Job Settings".  Would you like more 
information provided for that description to help understand what you are 
providing?  Maybe something like a "Learn more..." to quickly show with more 
details that we are asking for the beginning qualifier(s) of data set name, 
that is a temporary zFS (completely handled within the jobs and accurately 
sized) that will be used as the SMPWKDIR?  This should be an easy thing to do, 
if it would help. 

On that same checklist location for "Define Job Settings", the jobcard can be 
supplied, and also the place where you want all the generated jobs saved (like 
we had in SCPPBENU).  Of course, you could run the jobs from that saved data 
set from ISPF, but again, the intention is that they are run through z/OSMF so 
the interface can keep track of what you've done and how far you've gone.  You 
could re-submit the same job again, from z/OSMF, should you wish. Or even 
indicate that the job is complete as your ran it from ISPF and you want to 
continue on.  

If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really 
behooves you to define your prior z/OS release right now as a Software 
Instance.  This will allow you to model z/OS V2.5 from that prior z/OS release 
and not have to re-specify hundreds of data sets and volume placement.  This is 
very very similar to the old ISPF ServerPac dialog "save and merge 
configuration".  You will still have some unique data sets to deal with, but it 
will be a lot fewer than the entire z/OS ServerPac.  Of course, I'd do that 
with CICS, Db2, and IMS also.

-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

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

Re: Invalid names in Catalog

[ste...@copper.net]

As I recall, in doing tests, we could catalog an MVS "bad" name that was a good 
name for DOS.

So, back when I was doing NDM/Connect:Direct, I ran some tests to validate the 
handling (because someone managed to set up a bad DSN).

I knew about this stuff because I used to make a living off of DOS* to MVS* 
migrations. And the last time I did one was with z/OS 1.1 and I think we did 
have a tape that got cataloged with a "bad" MVS name.' 

This stuff was documented at one time because of sharing disk volumes with DOS. 

Regards,
Steve Thompson

--- mike.a.sch...@gmail.com wrote:

From: Mike Schwab 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Invalid names in Catalog
Date: Mon, 19 Jul 2021 13:20:35 -0500

I think quoted DSNs get into a VTOC but not the catalog.

On Mon, Jul 19, 2021 at 11:17 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 19 Jul 2021 12:08:39 -0400, Steve Thompson wrote:
>
> >DSN=‘..=..’,disp=(OLD,DELETE etc.
> >
> Ah!  smartass quotes!
>
> >This is how you get rid of DOS file names that get cataloged from the old 
> >days.
> >
> I believe that JCL forbids any use of catalog if DSN is quoted, regardless of 
> DSNCHECK.
> (Silly rule except how would convererr know?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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



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

Usercat access on sysplex with ECS

[Elaine Beal]

We have a dev sysplex both in ECS mode
My 2.2 ServerPac catalog which has been around awhile shows  Inact(NotShrable)
and I cannot access datasets, even 3.4 from either sysplex.
By definition, I shouldn't be able to-

Listcat shows 

 master catalog   -   USERCATALOG --- CATALOG.ICF.VSMP301  

 usercat  CATALOG.ICF.VSMP301SHROPTNS(3,3)  and  
NOECSHARE ICFCATALOG
   
but I *know* we've been running in this environment. I mean it's our 2.2 
ServerPac!
I'm pretty confident AUTOADD has always been set across IPLs

I disconnected from ECS on one LPAR but still nothing.
I didn't do anything else after the disconnect, i.e., logoff, 
disconnect/reconnect the usercat.

Thanks,
Elaine

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

Re: Mixing C/C++ with LE-conforming IBM HLASM

[Seymour J Metz]

> OK.  It requires multiple DCBs.

Yes, and if I'm doing something with every member of a PDS then I really don't 
want all of those OPENs.

> A member is not named when it is created,  but only at the point of STOW

Thanks. Yes, the same issue exists with VPAM.

> BPAM shoud support GET and PUT. 

Why? BSAM is for dealing with blocks. Although it would be nice if QSAM had 
equivalents to equivalents to NOTE and POINT.

In TSS, you use SETL to point to a logical VPAM record. Check the references I 
gave you.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, July 16, 2021 7:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

On Fri, 16 Jul 2021 22:28:47 +, Seymour J Metz wrote:

>Except that PDSE doesn't allow me to open a QSAM DCB and do FIND and STOW for 
>multiple members.
>
OK.  It requires multiple DCBs.

>I'm not sure what you mean by deferring naming of members.
>
A member is not named when it is created,  but only at the point of STOW.
This opens serialization hazards which ISPF Edid covers with ENQ EXC SPFEDIT.
Of course the programmer can code this explicitly, but it should be in the
access method.

ISPF LMPUT allows multiple concurrent PDSE member creation.  If multiple tasks
attempt to create the same member name, the last STOW (LMCLOSE) one wins.
Only within a single job because LMPUT requires ENQ EXC SYSDSN, needlessly
because PDSE does its own serialization With PDS, data may be corrupted.

>You can use any macro appropriate for the type of member. GET and PUT, but 
>NOTE and POINT are only for BSAM.
>
Bummer.   BPAM shoud support GET and PUT.

-- 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: Invalid names in Catalog

[Paul Gilmartin]

On Mon, 19 Jul 2021 13:20:35 -0500, Mike Schwab wrote:

>I think quoted DSNs get into a VTOC but not the catalog.
> 
I've found that a quoted DSN beginning with a period, ".",
doesn't even get into a VTOC.  I don't know where that
restriction might be documented.

Of course the DSN of the VTOC itself is very special.  Don't
delete it.

-- gil

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

Re: Invalid names in Catalog

[Mike Schwab]

I think quoted DSNs get into a VTOC but not the catalog.

On Mon, Jul 19, 2021 at 11:17 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 19 Jul 2021 12:08:39 -0400, Steve Thompson wrote:
>
> >DSN=‘..=..’,disp=(OLD,DELETE etc.
> >
> Ah!  smartass quotes!
>
> >This is how you get rid of DOS file names that get cataloged from the old 
> >days.
> >
> I believe that JCL forbids any use of catalog if DSN is quoted, regardless of 
> DSNCHECK.
> (Silly rule except how would convererr know?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Concatinated datasets

[Seymour J Metz]

HEWLKED is the Linkage Editor; it creates load modules on SYSLMOD; I don''t 
know of any way to make it direct its output to storage.

Were you thinking of the loader? HEWLD, HEWLDI,  HEWLDIA, HEWLDRGO, IEWBLDGO , 
IEWLDRGO or LOADER? 




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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 19, 2021 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

On Mon, 19 Jul 2021 14:12:21 +, Seymour J Metz wrote:

>> HEWLKD

>Where is that EP documented.
>
My typo.  HEWLKED.  Mentioned sparsely in Program Management User's Guide.
Strangely, more extensive mentions in SMP/E material.

Accepts in SYSLIN concatenated:
o Object (SYSPUNCH) files
o Load Modules.

Does not accept:
o Commands
o GOFF objects
o Program Objects.

Feels obsolescent.


From: Paul Gilmartin
Sent: Saturday, July 17, 2021 1:32 PM
...
It's possible (PGM=HEWLKD) to create an executable in storage
directly from SYSLIN, never creating a program object on DASD.

-- 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: Serverpac installs January 2022 and beyond - Requests

[Marna WALLE]

Hi Terri,
You are correct that within the z/OSMF interface, there is no way to edit a 
produced job for Deployment.  It is intended that no editing is necessary, in 
that if you need to "tweak" the job, we should be providing that capability 
within the interface itself.  The JCL produced should reflect what you want and 
also can be saved such that it can be reused for similar deployments, to avoid 
the same future tweaking.  

Did you have any specifics on what you wanted to change in z/OSMF, but 
couldn't?  Realize that the data set configuration, volumes, and cataloging 
capabilities are extremely flexible and should be able to do whatever you want. 
 Even more so than the old ServerPac ISPF dialog.  For instance, you can rename 
any data set you want, put it anywhere you want, and the old dialog had some 
restrictions on certain data sets.  Might there be something in the data set, 
volume, and catalog capabilities we are missing?  I'd like to solve the 
editing-JCL problem, with a solution for you that allows you to incorporate 
your intentions right within the GUI much earlier, save that intention, and 
make it so that you never have to "remember" it again should you do a similar 
deploy of the product.   (I can see how tweaks to the old ServerPac JCL would 
not be saved in the configuration, and then you would have a need to keep doing 
those tweaks in the future for every install.  That is not the intention here 
with z/OSMF.)

I believe the "work data set prefix" you are referring to is the temporary file 
system for use as SMPWKDIR on "Define Job Settings".  Would you like more 
information provided for that description to help understand what you are 
providing?  Maybe something like a "Learn more..." to quickly show with more 
details that we are asking for the beginning qualifier(s) of data set name, 
that is a temporary zFS (completely handled within the jobs and accurately 
sized) that will be used as the SMPWKDIR?  This should be an easy thing to do, 
if it would help. 

On that same checklist location for "Define Job Settings", the jobcard can be 
supplied, and also the place where you want all the generated jobs saved (like 
we had in SCPPBENU).  Of course, you could run the jobs from that saved data 
set from ISPF, but again, the intention is that they are run through z/OSMF so 
the interface can keep track of what you've done and how far you've gone.  You 
could re-submit the same job again, from z/OSMF, should you wish. Or even 
indicate that the job is complete as your ran it from ISPF and you want to 
continue on.  

If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really 
behooves you to define your prior z/OS release right now as a Software 
Instance.  This will allow you to model z/OS V2.5 from that prior z/OS release 
and not have to re-specify hundreds of data sets and volume placement.  This is 
very very similar to the old ISPF ServerPac dialog "save and merge 
configuration".  You will still have some unique data sets to deal with, but it 
will be a lot fewer than the entire z/OS ServerPac.  Of course, I'd do that 
with CICS, Db2, and IMS also.

-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: z/OS versions

[McCabe, Ron]

Radoslaw,

You're like a prosecuting attorney digging down to get the truth out of your 
witness ...

Are we moving off the mainframe?  That is what I mentioned in my email.  Exact 
date?  Not really but they did say the goal was 4th quarter 2022.  Is the date 
guaranteed?  No, but what in life is?
Who is the guarantor?  Word has come from the President/CEO of the company and 
yes the CIO was pushing for it.
Do I/we have it on paper ... the President/CEO put it into one of his monthly 
status notices to the company so yes, I would say it is on paper and has been 
clearly communicated.
So you would lose the bet.

I doubt there will be new management in a few years ... I do not see the 
current President/CEO, CIO, and/or any of the other VP's leaving the company or 
being replaced by the board.
Yes our system will be unsupported but this won't be the first time plus IBM 
will still help for a known problem and truthfully I'm not expecting any 
because we are not doing any "new" development on the mainframe.
*I* will not be in trouble because I will be retired and if they find they need 
to go back (keep) the mainframe up and running then good luck to them to find 
those that will/do still work on the mainframe.
I do not classify us as a financial institution ... we are a Commercial and 
Personal Property Insurance Company ... I do not know if that classifies us as 
a financial institution.
I/we too have gotten the green light to do the upgrade but after trying to get 
BA's and DEV's to test on it for the last 6 months I'm about ready to give up 
since they are all too busy with their normal day to day work where they cannot 
spend an hour or two to do some testing for us.  Plus we have a couple of old 
applications that no one really knows how they work so testing them is next to 
impossible and if they don't work we cannot go through with the upgrade.

Thanks to those that I have heard from that are running on older z/OS versions 
with no problems ... that at least makes me a little more comfortable not 
keeping our system up to date.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Saturday, July 17, 2021 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS versions

CAUTION: This email is from an external address. Please be careful of links and 
attachments.


Are you moving off the mainframe?
Do you know exact date of mainframe shutdown?
Is the date guaranteed?
Who is the guarantor? Some team leader, project manager, external contractor? 
Is it CIO?
Do you have it on paper? Is it clearly communicated?

I bet NO.
So I bet few years later there will be new management, who did not guaranteed 
anything.
But *your* system will be unsupported with some effects of it.
*You* will be in trouble.
Note, it is sometimes against the rules to run such system by financial 
institution.

The last caused I've got green light for system upgrade, despite they want to 
move off the mainframe. However the willingness is approx. 10 years old, but 
results are still not promising.
Oh, BTW - while it was impossible to move off the mainframe, it occured 
possible to move off me. :-(



--
Radoslaw Skorupka
Lodz, Poland



W dniu 16.07.2021 o 21:52, McCabe, Ron pisze:
> Hello IBM List,
>
> Got a question about how you feel about running on an unsupported z/OS 
> version.  Just about like everyone else our company is moving off the 
> mainframe ... after several failed attempts I do believe they have something 
> that will work this time and I'm OK with it because if they reach their goal 
> End of Life for the mainframe will be when I was planning on retiring.
> Some background - we are currently running z/OS 2.2, we started the process 
> to upgrade to 2.3 about 6 months ago and we are close to implementing 
> providing our DEV's and BA's can finish up the testing that we require which 
> is not going very well.  Since the EOL goal for the mainframe is 4th quarter 
> 2022 we are now thinking of not implementing z/OS 2.3 since it could possibly 
> cause more problems for us than just staying with z/OS 2.2.
>
> So my question - how does everyone feel about running on an unsupported z/OS 
> system?
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, 

Re: Invalid names in Catalog

[Paul Gilmartin]

On Mon, 19 Jul 2021 12:08:39 -0400, Steve Thompson wrote:

>DSN=‘..=..’,disp=(OLD,DELETE etc. 
>
Ah!  smartass quotes!

>This is how you get rid of DOS file names that get cataloged from the old 
>days. 
>
I believe that JCL forbids any use of catalog if DSN is quoted, regardless of 
DSNCHECK.
(Silly rule except how would convererr know?)

-- gil

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

Re: Invalid names in Catalog

[Steve Thompson]

DSN=‘..=..’,disp=(OLD,DELETE etc. 

This is how you get rid of DOS file names that get cataloged from the old days. 

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
mistaks 


> On Jul 19, 2021, at 11:48 AM, Jack Zukt  wrote:
> 
> Hi all,
> 
> We are checking our ICF Catalogs for inconsistencies and come across a
> weird situation: we have found in several user catalogs multiple "dataset
> names" that can not have been defined by any userid as they do not adhere
> to valid dataset name rules; something along the lines of:
> 
> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
> IDC1566I ** ..=. NOT LISTED
> 
> All of those "." are x'4B'
> 
> Now the problem is, how can we delete such entries?
> Any ideas?
> 
> Jack
> 
> --
> 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: Invalid names in Catalog

[Paul Gilmartin]

On Mon, 19 Jul 2021 16:47:20 +0100, Jack Zukt wrote:
>
>We are checking our ICF Catalogs for inconsistencies and come across a
>weird situation: we have found in several user catalogs multiple "dataset
>names" that can not have been defined by any userid as they do not adhere
>
Conceivable, they might have been created with DISABLE(DSNCHECK)
in effect.  Irritatingly, by IBM's thoughtless design, they can not be
deleted/renamed with ENABLE(DSNCHECK) in effect.

AMASPZAP?

>to valid dataset name rules; something along the lines of:
>
>IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
>IDC1566I ** ..=. NOT LISTED
>
>All of those "." are x'4B'
>
>Now the problem is, how can we delete such entries?
>Any ideas?

-- gil

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

Re: Invalid names in Catalog

[Richards, Robert B. (CTR)]

ADRDSSU's DEFRAG would do that, but the dataset was recognizable.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Monday, July 19, 2021 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Invalid names in Catalog

I'm not sure if it was FDR compact or ADRDSSU that creates an invalid dataset 
name, usually not cataloged IIRC, to indicate a failure in the compact or reorg 
process, rerunning the failed process successfully usually removes these 
entries, in you case I'm not sure if this can help.

I'm thinking a merge-cat (REPRO) or export to a temp and rebuild the catalog 
should fix this.

Also I think TREX would help if you have the product


Carmen


On 7/19/2021 10:47 AM, Jack Zukt wrote:
> Hi all,
>
> We are checking our ICF Catalogs for inconsistencies and come across a 
> weird situation: we have found in several user catalogs multiple 
> "dataset names" that can not have been defined by any userid as they 
> do not adhere to valid dataset name rules; something along the lines of:
>
> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5 
> IDC1566I ** ..=. NOT LISTED
>
> All of those "." are x'4B'
>
> Now the problem is, how can we delete such entries?
> Any ideas?
>
> Jack
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
/I am not bound to win, but I am bound to be true. I am not bound to succeed, 
but I am bound to live by the light that I have. I must stand with anybody that 
stands right, and stand with him while he is right, and part with him when he 
goes wrong. *Abraham Lincoln*/

--
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: Invalid names in Catalog

[Allan Staller]

Classification: Confidential

DELETE 'datasetname' (NSCR if needed). Use ISPF Hex edit to match the existent 
entries.

Alternatative REPRO MERGECAT (entries or level) to a "dummy ucat" and after the 
REPRO activities are complete, delete the "dummy ucat".
There is an IDCAMS sub-parameter to allow deletion of a non-empty UCAT.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack Zukt
Sent: Monday, July 19, 2021 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Invalid names in Catalog

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

Hi all,

We are checking our ICF Catalogs for inconsistencies and come across a weird 
situation: we have found in several user catalogs multiple "dataset names" that 
can not have been defined by any userid as they do not adhere to valid dataset 
name rules; something along the lines of:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5 IDC1566I 
** ..=. NOT LISTED

All of those "." are x'4B'

Now the problem is, how can we delete such entries?
Any ideas?

Jack

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

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


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

Re: Invalid names in Catalog

[Carmen Vitullo]

I'm not sure if it was FDR compact or ADRDSSU that creates an invalid 
dataset name, usually not cataloged IIRC, to indicate a failure in the 
compact or reorg process, rerunning the failed process successfully 
usually removes these entries, in you case I'm not sure if this can help.


I'm thinking a merge-cat (REPRO) or export to a temp and rebuild the 
catalog should fix this.


Also I think TREX would help if you have the product


Carmen


On 7/19/2021 10:47 AM, Jack Zukt wrote:

Hi all,

We are checking our ICF Catalogs for inconsistencies and come across a
weird situation: we have found in several user catalogs multiple "dataset
names" that can not have been defined by any userid as they do not adhere
to valid dataset name rules; something along the lines of:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** ..=. NOT LISTED

All of those "." are x'4B'

Now the problem is, how can we delete such entries?
Any ideas?

Jack

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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: Concatinated datasets

[Paul Gilmartin]

On Mon, 19 Jul 2021 14:12:21 +, Seymour J Metz wrote:

>> HEWLKD

>Where is that EP documented.
>
My typo.  HEWLKED.  Mentioned sparsely in Program Management User's Guide.
Strangely, more extensive mentions in SMP/E material.

Accepts in SYSLIN concatenated:
o Object (SYSPUNCH) files
o Load Modules.

Does not accept:
o Commands
o GOFF objects
o Program Objects.

Feels obsolescent.


From: Paul Gilmartin 
Sent: Saturday, July 17, 2021 1:32 PM 
...
It's possible (PGM=HEWLKD) to create an executable in storage
directly from SYSLIN, never creating a program object on DASD.

-- gil

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

Invalid names in Catalog

[Jack Zukt]

Hi all,

We are checking our ICF Catalogs for inconsistencies and come across a
weird situation: we have found in several user catalogs multiple "dataset
names" that can not have been defined by any userid as they do not adhere
to valid dataset name rules; something along the lines of:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** ..=. NOT LISTED

All of those "." are x'4B'

Now the problem is, how can we delete such entries?
Any ideas?

Jack

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

Re: IKJEFT01 and highest condition code

[Charles Mills]

> do not dance with special rexx routine which executes command

But isn't that in fact potentially the exact answer to your requirement?

I have not done "big subsystem" type stuff in Rexx for a long time but it would 
not seem to me like it would be an impossible project to build a Rexx (or 
HLASM) "environment" that executed TSO commands from a file one at a time, and 
also implemented some sort of "structure" through commands of its own, such as

- Returning the maximum or last or a specified CC
- Perhaps some sort of "IF" logic
- Etc.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Monday, July 19, 2021 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IKJEFT01 and highest condition code

Obviously yes, but the goal is to run all the commands and get the 
highest CC.
And do not dance with special rexx routine which executes command by 
command and checks CC.
Something simple...


-- 
Radoslaw Skorupka
Lodz, Poland




W dniu 19.07.2021 o 15:48, Bill Johnson pisze:
> If it stops after the first non-zero, the last and highest are the same RC.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, July 19, 2021, 8:56 AM, Radoslaw Skorupka  
> wrote:
>
> Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC
> of last command.
> However I'd like to see the highest CC, like IDCAMS does.
> As far as I know IKJEFT1A and IKJEFT1B both stop processing after first
> non-zero code.
>
> Is there any magic switch to do 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: RFE TSO Pipes - the TOP voted RFE among all brands

[Roberto Halais]

Output of PIPEQ COMMAND:

FPLINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0110
(Version.Release/Mod) - Generated 7 Apr 1998 at 14:00:22




On Mon, Jul 19, 2021 at 10:22 AM Lionel B. Dyck  wrote:

> The RFE for TSO PIPES is now the top voted RFE - let's keep voting - if you
> haven't then please vote, if you have then encourage others to vote.
>
>
>
> The URL is http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
> <
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699
> >
> _ID=47699
>
>
>
> The current vote is 221 votes.
>
>
>
> IBM - it is time to release PIPES for TSO - let's keep z/OS productive and
> moving forward.
>
>
>
>
>
> Lionel B. Dyck <><
>
> Website: https://www.lbdsoftware.com
>
> Github: https://github.com/lbdyck
>
>
>
> "Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are."   - - - John Wooden
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Politics: Poli (many) - tics (blood sucking parasites)

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

Re: IKJEFT01 and highest condition code

[Bill Johnson]

I don’t usually run more than one command per IKJEFT, because often the second 
command is dependent on the previous command. Rarely are my IDCAMS commands 
dependent on a previous command or it just doesn’t matter.


Sent from Yahoo Mail for iPhone


On Monday, July 19, 2021, 10:10 AM, Radoslaw Skorupka  
wrote:

Obviously yes, but the goal is to run all the commands and get the 
highest CC.
And do not dance with special rexx routine which executes command by 
command and checks CC.
Something simple...


-- 
Radoslaw Skorupka
Lodz, Poland




W dniu 19.07.2021 o 15:48, Bill Johnson pisze:
> If it stops after the first non-zero, the last and highest are the same RC.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, July 19, 2021, 8:56 AM, Radoslaw Skorupka  
> wrote:
>
> Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC
> of last command.
> However I'd like to see the highest CC, like IDCAMS does.
> As far as I know IKJEFT1A and IKJEFT1B both stop processing after first
> non-zero code.
>
> Is there any magic switch to do 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: IKJEFT01 and highest condition code

[Joe Monk]

Only a script can do this. IKJEFT01 continues if there is an issue, but
only shows the final CC.

Joe

On Mon, Jul 19, 2021 at 9:10 AM Radoslaw Skorupka 
wrote:

> Obviously yes, but the goal is to run all the commands and get the
> highest CC.
> And do not dance with special rexx routine which executes command by
> command and checks CC.
> Something simple...
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 19.07.2021 o 15:48, Bill Johnson pisze:
> > If it stops after the first non-zero, the last and highest are the same
> RC.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Monday, July 19, 2021, 8:56 AM, Radoslaw Skorupka <
> r.skoru...@hotmail.com> wrote:
> >
> > Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC
> > of last command.
> > However I'd like to see the highest CC, like IDCAMS does.
> > As far as I know IKJEFT1A and IKJEFT1B both stop processing after first
> > non-zero code.
> >
> > Is there any magic switch to do 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

RFE TSO Pipes - the TOP voted RFE among all brands

[Lionel B. Dyck]

The RFE for TSO PIPES is now the top voted RFE - let's keep voting - if you
haven't then please vote, if you have then encourage others to vote.

 

The URL is http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe

_ID=47699

 

The current vote is 221 votes.

 

IBM - it is time to release PIPES for TSO - let's keep z/OS productive and
moving forward.

 

 

Lionel B. Dyck <><

Website: https://www.lbdsoftware.com

Github: https://github.com/lbdyck

 

"Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are."   - - - John Wooden

 


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

Re: Concatinated datasets

[Seymour J Metz]

> HEWLKD

Where is that EP documented.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, July 17, 2021 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

On Fri, 16 Jul 2021 18:59:03 -0700, Charles Mills wrote:

>Yeah, it is one of those problems that seems like it should have a simple
>answer "what DSN was this module loaded from? How hard is that?" but in
>reality has unlimited subtleties.
>
Sounds like an RFE candidate.  CSV should preserve the needed information
and provide an API to access it.

What about LPA?  Original data set and member?

What should happen if the program object is replaced in the interim?
Ideally, PDSE should keep a connection to the original instance until
CSV DELETE, so very little.  FETCHOPT(NOPRIME) requires something
like that.

It's possible (PGM=HEWLKD) to create an executable in storage
directly from SYSLIN, never creating a program object on DASD.

An authorized program can IDENTIFY an entry point in storage which has
not been fetched from a program object.

How should program objects fetched from UNIX files be reported?

-- 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: IKJEFT01 and highest condition code

[Radoslaw Skorupka]

Obviously yes, but the goal is to run all the commands and get the 
highest CC.
And do not dance with special rexx routine which executes command by 
command and checks CC.

Something simple...


--
Radoslaw Skorupka
Lodz, Poland




W dniu 19.07.2021 o 15:48, Bill Johnson pisze:

If it stops after the first non-zero, the last and highest are the same RC.


Sent from Yahoo Mail for iPhone


On Monday, July 19, 2021, 8:56 AM, Radoslaw Skorupka  
wrote:

Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC
of last command.
However I'd like to see the highest CC, like IDCAMS does.
As far as I know IKJEFT1A and IKJEFT1B both stop processing after first
non-zero code.

Is there any magic switch to do it?



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

Re: IKJEFT01 and highest condition code

[Bill Johnson]

If it stops after the first non-zero, the last and highest are the same RC.


Sent from Yahoo Mail for iPhone


On Monday, July 19, 2021, 8:56 AM, Radoslaw Skorupka  
wrote:

Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC 
of last command.
However I'd like to see the highest CC, like IDCAMS does.
As far as I know IKJEFT1A and IKJEFT1B both stop processing after first 
non-zero code.

Is there any magic switch to do it?

-- 

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




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

Re: IKJEFT01 and highest condition code

[Paul Gilmartin]

On Mon, 19 Jul 2021 08:00:21 -0500, Joe Monk wrote:

>Usually, you have to do the work from a REXX or CLIST.
>Then you can capture the highest CC in a variable and return it...
> 
This is absurdly hard in too many languages.

o In JCL I've coded IDCAMS steps simply to set CC.

o For Rexx I've coded a command simply to return its argument in R15.

o In POSIX shell it's simply ( exit $CC ) or "true" or "false".

-- gil

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

Re: IKJEFT01 and highest condition code

[Joe Monk]

Usually, you have to do the work from a REXX or CLIST.

Then you can capture the highest CC in a variable and return it...

Joe

On Mon, Jul 19, 2021 at 7:57 AM Radoslaw Skorupka 
wrote:

> Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC
> of last command.
> However I'd like to see the highest CC, like IDCAMS does.
> As far as I know IKJEFT1A and IKJEFT1B both stop processing after first
> non-zero code.
>
> Is there any magic switch to do it?
>
> --
>
> 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
>

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

IKJEFT01 and highest condition code

[Radoslaw Skorupka]

Usually when you run multiple TSO commands in batch, IKJEFT01 returns CC 
of last command.

However I'd like to see the highest CC, like IDCAMS does.
As far as I know IKJEFT1A and IKJEFT1B both stop processing after first 
non-zero code.


Is there any magic switch to do it?

--

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: Serverpac installs January 2022 and beyond - Requests

[Shaffer, Terri]

So,  I am going to ease up on IBM a little, except for the resources needed for 
z/OSMF,  But have a few usability requests just as in the serverpac.

I am not 100% convinced yet, but I see no way of editing a job that was 
generated, BEFORE submit!!

I also see fields on the screen but no context help as to know what they want 
to fill in, like * Work data set name prefix:  what was the equivalent ??

This is critical, in many shops I have every installed SEVERPAC in, due to 
catalogs naming's mostly and where datasets live.

In serverpac, you could SAVE JCL and recall using BACKUP to re-run something 
you had to modify for whatever reason.  That ability seems gone??

I will test using z/OSMF based on what I saw in the DEMO, but when dealing with 
1200+ z/OS datasets across, probably 5 or 6  volumes, in my experience always 
needed tweaked!

Again, maybe for the sysprog, who doesn’t understand, this make perfect sense, 
but there are many times, the canned/generated JCL will not work in an 
environment and the dialogs don’t allow it to be fixed.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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