Re: [Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4

[Doug Shupe]

Maybe this is a better pointer 

https://www.ibm.com/docs/en/zos/2.3.0?topic=ulero-storage#clstora

Stay Safe

> On Oct 3, 2022, at 21:07, Doug Shupe  wrote:
> 
> Possibly the WSCLEAR LE runtime option?
> 
> https://www.ibm.com/support/pages/wsclear-runtime-option-vs-cobol-ii-not-supported-current-cics-releases
> 
> Just a thought as you said old cobol and CICS.
> Best Regards, Doug
> 
> 
>>> On Oct 3, 2022, at 15:59, Usher, Darrold 
>>> <014f796d148d-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>> What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)?
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Crusty Old Guy
>> Sent: Monday, October 3, 2022 2:19 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4
>> 
>> I have further information from the programmers.
>> 
>> These are CICS programs. The programs do not initialize their working 
>> storage.  I'm told everything is fine under z/OS 2.1.
>> 
>> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know 
>> why it runs OK under 2.1.
>> I have not found an answer for them in the migration guide.  Can anyone help?
>> 
>> COG
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email 
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> USAA Classification: Public
>> 
>> Disclaimer: This email and any attachments are the property of USAA and may 
>> contain confidential and/or privileged material. If you are not the intended 
>> recipient, any use, disclosure or copying of this email or any attachments 
>> is unauthorized. If you received this email in error, please immediately 
>> notify the sender and delete the email and any attachments from your 
>> computer.
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 4/10/22 01:56, Farley, Peter x23353 wrote:

I have read that tagging behavior page and it makes sense when applied to files stored in 
the Unix file system.  MVS datasets could just as easily just be considered always tagged 
as cp1047 (with an option to change the CCSID to 037 or one of the European EBCIDIC code 
pages) and then you just go on from there.  Connecting to the MVS file system "under 
the covers" is the runtime implementor's job, not the application developer's job.

As to providing a package to specifically access MVS datasets, my first question is why IBM didn't 
provide one in the first place, or better yet build it into the python I/O subsystem from the 
start?  Why does the community need to provide such a basic functionality?  "zoautil_py" 
is one such implementation, but it is extraordinarily "heavyweight" and expensive to use, 
and is not an acceptable solution in a world where every second counts and costs real money.


I am quite sure an MVS I/O package will happen just like it did for 
golang and Node.js. Yet again, open source code documented in Github and 
the respective package manager repositories. You may not like that but 
it's how these things work.


https://github.com/ibmruntimes/go-recordio



The lack of easy-to-use and efficient MVS file access may well discourage more 
widespread use of python on z/OS for everyday computing tasks.


Maybe not as much as you think. The tooling coming online will require 
Python so it's mandatory. The vast majority on this forum would rather 
use REXX anyway!





And yes, I can accept that my expectations are not realistic.  It is just a shame that an 
easy-to-use and efficient access to MVS datasets isn't and won't be there unless the 
"community" provides it.  IMHO it should have been part-and-parcel of the 
original language implementation, but I know what my opinions and expectations are worth.


The community involves IBM and the team that ported Python, Golang, 
Node.js etc. The team from IBM Toronto have setup and open source 
community that are actively ported FOSS to z/OS. Interestingly, this 
includes the zsh which I'm delighted about.




Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, October 3, 2022 1:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

On 3/10/22 07:18, Farley, Peter x23353 wrote:

Where, for instance, in the documentation that you linked to is there information on 
whether the python "open()" function for files will or will not support direct 
access to MVS datasets without transferring them down to the Unix file system?  I.E.,  
are either of these calls to the open() function valid or not:

Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")

Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course
assumes that a call to "bpxunix" (or by other means) has been used to
establish a DD allocation in the AS where the python program is
executing

This will *never* happen. If you read the doc WRT tagging behaviors you will 
understand why 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/python-zos/3.9?topic=translation-tagging-behaviors__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUYFy-CaGg$
  .
Rocket's Python port supported reading MVS data sets but it was not a 
documented feature and was used with great care. Patching the Python core I/O 
libraries to support MVS data sets is not a great idea. It's much better to 
write a specific library that *only* support MVS data sets and not z/OS UNIX 
files. A good reference implementation is the JZOS ZFile class. If you open an 
RFE IBM may do this. Or maybe the community can contribute? Either way it's 
going to be implemented as a specific package.

Porting tools to support MVS data sets in trivial. They use open() because it's 
a low-level API and read/write support sockets, FIFO's, pipes etc. It's not 
just a case of replacing open with fopen(). Python implements a fdopen()
https://urldefense.com/v3/__https://docs.python.org/3/library/os.html*os.fdopen__;Iw!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUY6MzWLWc$
   method for wrapping
file descriptors.
--


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 

Re: [Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4

[Doug Shupe]

Possibly the WSCLEAR LE runtime option?

https://www.ibm.com/support/pages/wsclear-runtime-option-vs-cobol-ii-not-supported-current-cics-releases

Just a thought as you said old cobol and CICS.
Best Regards, Doug


> On Oct 3, 2022, at 15:59, Usher, Darrold 
> <014f796d148d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)?
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Crusty Old Guy
> Sent: Monday, October 3, 2022 2:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4
> 
> I have further information from the programmers.
> 
> These are CICS programs. The programs do not initialize their working 
> storage.  I'm told everything is fine under z/OS 2.1.
> 
> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know 
> why it runs OK under 2.1.
> I have not found an answer for them in the migration guide.  Can anyone help?
> 
> COG
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> USAA Classification: Public
> 
> Disclaimer: This email and any attachments are the property of USAA and may 
> contain confidential and/or privileged material. If you are not the intended 
> recipient, any use, disclosure or copying of this email or any attachments is 
> unauthorized. If you received this email in error, please immediately notify 
> the sender and delete the email and any attachments from your computer.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: COBOL - z/OS 2.1 vs 2.4

[Feller, Paul]

I would suggest checking your LE parms between the two systems.  It almost 
feels like there is a difference in the setting between to two systems around 
how CICS is handled.


Paul Feller
GTS Mainframe Technical Support


From: IBM Mainframe Discussion List  On Behalf Of 
Crusty Old Guy
Sent: Monday, October 3, 2022 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL - z/OS 2.1 vs 2.4

I have further information from the programmers. These are CICS programs. The 
programs do not initialize their working storage. I'm told everything is fine 
under z/OS 2. 1. Under z/OS 2. 4, they are getting garbage in the COMMAREA. 
They want


I have further information from the programmers.



These are CICS programs. The programs do not initialize their working storage.  
I'm told everything is fine under z/OS 2.1.



Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why 
it runs OK under 2.1.

I have not found an answer for them in the migration guide.  Can anyone help?



COG



--

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 - z/OS 2.1 vs 2.4

[Charles Mills]

Interesting business model. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Monday, October 3, 2022 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL - z/OS 2.1 vs 2.4

https://www.fiverr.com/devoutoccamist/answer-your-questions-regarding-zos-and-the-mainframe-3a9c

And are you going to share the proceeds. Do you by any chance work for a
company that provides support to companies that have cancelled their
support contracts with IBM?

Just asking, I've opted not to sign a contract with them...

Robert

On Fri, 30 Sept 2022 at 13:24, Crusty Old Guy 
wrote:

> We have a client with loadmods that are ancient.  Some are very ancient.
> All of those loadmods are currently running under z/OS 2.1.
> Under z/OS 2.4, some of these loadmods are abending.  Others are creating
> incorrect output.
>
> What could account for this behavior?  What has changed between 2.1 & 2.4?
>
> Regards,
> Crusty Old Guy
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
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 - z/OS 2.1 vs 2.4

[Robert Prins]

https://www.fiverr.com/devoutoccamist/answer-your-questions-regarding-zos-and-the-mainframe-3a9c

And are you going to share the proceeds. Do you by any chance work for a
company that provides support to companies that have cancelled their
support contracts with IBM?

Just asking, I've opted not to sign a contract with them...

Robert

On Fri, 30 Sept 2022 at 13:24, Crusty Old Guy 
wrote:

> We have a client with loadmods that are ancient.  Some are very ancient.
> All of those loadmods are currently running under z/OS 2.1.
> Under z/OS 2.4, some of these loadmods are abending.  Others are creating
> incorrect output.
>
> What could account for this behavior?  What has changed between 2.1 & 2.4?
>
> Regards,
> Crusty Old Guy
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: COBOL - z/OS 2.1 vs 2.4

[Joe Monk]

Can you post a CEDF trace?

Joe

On Mon, Oct 3, 2022 at 2:19 PM Crusty Old Guy 
wrote:

> I have further information from the programmers.
>
> These are CICS programs. The programs do not initialize their working
> storage.  I'm told everything is fine under z/OS 2.1.
>
> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to
> know why it runs OK under 2.1.
> I have not found an answer for them in the migration guide.  Can anyone
> help?
>
> COG
>
> --
> 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

[Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4

[Usher, Darrold]

What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crusty Old Guy
Sent: Monday, October 3, 2022 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4

I have further information from the programmers.

These are CICS programs. The programs do not initialize their working storage.  
I'm told everything is fine under z/OS 2.1.

Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why 
it runs OK under 2.1.
I have not found an answer for them in the migration guide.  Can anyone help?

COG

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

USAA Classification: Public

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


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

Re: COBOL - z/OS 2.1 vs 2.4

[Gibney, Dave]

Level of CIS would be in play.   This is likely one of the changes in how and 
where memory gets allocated and initialized in 2.2 or 2.3 on.  There are some 
compatibility DIAGxx parms

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Crusty Old Guy
> Sent: Monday, October 03, 2022 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL - z/OS 2.1 vs 2.4
> 
> [EXTERNAL EMAIL]
> 
> I have further information from the programmers.
> 
> These are CICS programs. The programs do not initialize their working
> storage.  I'm told everything is fine under z/OS 2.1.
> 
> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to
> know why it runs OK under 2.1.
> I have not found an answer for them in the migration guide.  Can anyone
> help?
> 
> COG
> 
> --
> 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

Pass Phrases

[Steve Beaver]

Has anyone SUCCESSFULLY converted to Pass Phrases.

 

IRS is starting to push and I'm afraid that CICS, DB2, Natural, and the
Password exits are 

Are going to be disaster and about 1 year.

 

Any hints or shoves would be appreciated 

 

TIA

 

Steve


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

Re: COBOL - z/OS 2.1 vs 2.4

[Crusty Old Guy]

I have further information from the programmers.  

These are CICS programs. The programs do not initialize their working storage.  
I'm told everything is fine under z/OS 2.1.

Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why 
it runs OK under 2.1.
I have not found an answer for them in the migration guide.  Can anyone help?

COG

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

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[Farley, Peter x23353]

I have read that tagging behavior page and it makes sense when applied to files 
stored in the Unix file system.  MVS datasets could just as easily just be 
considered always tagged as cp1047 (with an option to change the CCSID to 037 
or one of the European EBCIDIC code pages) and then you just go on from there.  
Connecting to the MVS file system "under the covers" is the runtime 
implementor's job, not the application developer's job.

As to providing a package to specifically access MVS datasets, my first 
question is why IBM didn't provide one in the first place, or better yet build 
it into the python I/O subsystem from the start?  Why does the community need 
to provide such a basic functionality?  "zoautil_py" is one such 
implementation, but it is extraordinarily "heavyweight" and expensive to use, 
and is not an acceptable solution in a world where every second counts and 
costs real money.  The lack of easy-to-use and efficient MVS file access may 
well discourage more widespread use of python on z/OS for everyday computing 
tasks.

And yes, I can accept that my expectations are not realistic.  It is just a 
shame that an easy-to-use and efficient access to MVS datasets isn't and won't 
be there unless the "community" provides it.  IMHO it should have been 
part-and-parcel of the original language implementation, but I know what my 
opinions and expectations are worth.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, October 3, 2022 1:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

On 3/10/22 07:18, Farley, Peter x23353 wrote:
> Where, for instance, in the documentation that you linked to is there 
> information on whether the python "open()" function for files will or will 
> not support direct access to MVS datasets without transferring them down to 
> the Unix file system?  I.E.,  are either of these calls to the open() 
> function valid or not:
>
> Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")
>
> Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course 
> assumes that a call to "bpxunix" (or by other means) has been used to 
> establish a DD allocation in the AS where the python program is 
> executing

This will *never* happen. If you read the doc WRT tagging behaviors you will 
understand why 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/python-zos/3.9?topic=translation-tagging-behaviors__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUYFy-CaGg$
  . 
Rocket's Python port supported reading MVS data sets but it was not a 
documented feature and was used with great care. Patching the Python core I/O 
libraries to support MVS data sets is not a great idea. It's much better to 
write a specific library that *only* support MVS data sets and not z/OS UNIX 
files. A good reference implementation is the JZOS ZFile class. If you open an 
RFE IBM may do this. Or maybe the community can contribute? Either way it's 
going to be implemented as a specific package.

Porting tools to support MVS data sets in trivial. They use open() because it's 
a low-level API and read/write support sockets, FIFO's, pipes etc. It's not 
just a case of replacing open with fopen(). Python implements a fdopen() 
https://urldefense.com/v3/__https://docs.python.org/3/library/os.html*os.fdopen__;Iw!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUY6MzWLWc$
   method for wrapping 
file descriptors.
--


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: Dasd Mod conversion mod9 to mod27

[Seymour J Metz]

The AFAIK a V OFFLINE, a V ONLINE and a reinitialize should be all you need. If 
the conversion preserves the original data then REFVTOC rather than initialize 
should work.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jake Anderson [justmainfra...@gmail.com]
Sent: Monday, October 3, 2022 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dasd Mod conversion mod9 to mod27

Addresses are not changing

It's the same UCB

On Mon, Oct 3, 2022, 5:14 PM Seymour J Metz  wrote:

> HCD if addresses have changed.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Jake Anderson [justmainfra...@gmail.com]
> Sent: Monday, October 3, 2022 5:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dasd Mod conversion mod9 to mod27
>
> Hello
>
> We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.
>
> Post the mod conversion before initializing are there any other steps needs
> to be performed in zOS ?
>
> 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
>

--
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: Dasd Mod conversion mod9 to mod27

[Paul Gorlinsky]

Yes, If they are truly empty, then reinit is good. We couldn't tell if they had 
data or not based on the message chain ... 

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

Re: Dasd Mod conversion mod9 to mod27

[Jake Anderson]

Nigel

These are just a empty volumes which are mod9 and I wanted to convert them
to mod27 on both DR and Production site.



I believe instead of REFVTOC reinitializing the volume will do good ?

On Mon, Oct 3, 2022, 5:37 PM Nigel Morton  wrote:

> ICKDSF REFVTOC so that the VTOC reflects the increase in size and free
> space. If the volumes are in copy services relationships, they will
> probably need to be rebuilt and you'll need to change the size of secondary
> volumes. Consider the number of PAV aliases you define - maybe you would
> benefit from more with bigger volumes? I'd disable the volumes for new
> allocations while I was doing the conversion at the very least although I'd
> prefer to define new volumes and use something like TDMF to move the data
> to give the opportunity to use larger VTOC/VTOC index.
>
> Out of curiosity, why not go to 3390-54s if you have the space?
>
> On Mon, 3 Oct 2022 at 14:22, Jake Anderson 
> wrote:
>
> > Addresses are not changing
> >
> > It's the same UCB
> >
> > On Mon, Oct 3, 2022, 5:14 PM Seymour J Metz  wrote:
> >
> > > HCD if addresses have changed.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> > > of Jake Anderson [justmainfra...@gmail.com]
> > > Sent: Monday, October 3, 2022 5:37 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Dasd Mod conversion mod9 to mod27
> > >
> > > Hello
> > >
> > > We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.
> > >
> > > Post the mod conversion before initializing are there any other steps
> > needs
> > > to be performed in zOS ?
> > >
> > > 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
> > >
> >
> > --
> > 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: IBM python documentation?

[Phil Smith III]

Shmuel asked:
> BTW, has usage shifted from ISO-8859-1 (Latin 1) to ISO-8859-15 (Latin-9) to 
> accomodate the Euro €?



Not that I’ve noticed, though it may be that they’re really doing -15 and 
calling it -1. Have not looked at Encoding headers to see.

 

Not to trivialize it—it’s an important character!—but for the most part it’s 
names and the like that people get bent about (accented characters etc.), which 
I think is why it either hasn’t happened or isn’t visible as such.


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

Re: Dasd Mod conversion mod9 to mod27

[Nigel Morton]

ICKDSF REFVTOC so that the VTOC reflects the increase in size and free
space. If the volumes are in copy services relationships, they will
probably need to be rebuilt and you'll need to change the size of secondary
volumes. Consider the number of PAV aliases you define - maybe you would
benefit from more with bigger volumes? I'd disable the volumes for new
allocations while I was doing the conversion at the very least although I'd
prefer to define new volumes and use something like TDMF to move the data
to give the opportunity to use larger VTOC/VTOC index.

Out of curiosity, why not go to 3390-54s if you have the space?

On Mon, 3 Oct 2022 at 14:22, Jake Anderson  wrote:

> Addresses are not changing
>
> It's the same UCB
>
> On Mon, Oct 3, 2022, 5:14 PM Seymour J Metz  wrote:
>
> > HCD if addresses have changed.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Jake Anderson [justmainfra...@gmail.com]
> > Sent: Monday, October 3, 2022 5:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Dasd Mod conversion mod9 to mod27
> >
> > Hello
> >
> > We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.
> >
> > Post the mod conversion before initializing are there any other steps
> needs
> > to be performed in zOS ?
> >
> > 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
> >
>
> --
> 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: Dasd Mod conversion mod9 to mod27

[Paul Gorlinsky]

For the most part, z/OS versions from the last couple of decades, perform 
SenseID, RDC and RCD CCWs to determine the device type and characteristics of 
the device, that is the number of cylinders and if EAV is supported. That being 
said, you should not have to do anything but either VARY ON/OFF or IPL.

The DS8K will report the correct number of CYLs to the OS. 

Use DS QD,,RDC,RCD where  is an address and the response will look like:
IEE459I 09.28.56 DEVSERV QDASD 771   
 UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EFC   
03040 RES250 2107961 2107900 10017  3000 0175-ZB771 0175-ZB771 *OK  
 10017 CYL count
  READ DEVICE CHARACTERISTIC 
2107E833900C5E84 1FF720322721000F E000E5A205940222 13090674 
  <<< 2107E8 3390-0C 
 32321F02DFEE0001 0677080F007F4800 003C2721  
  READ CONFIGURATION DATA
DC010100F0F0F2F1 F0F7F9F0F0C9C2D4 F7F5F0F0F0F0F0F0 F0E9C2F7F7F11040  
D402F0F0F2F1 F0F7F9F6F1C9C2D4 F7F5F0F0F0F0F0F0 F0E9C2F7F7F11000  
D000F0F0F2F1 F0F7F9F6F1C9C2D4 F7F5F0F0F0F0F0F0 F0E9C2F7F7F01000  
F001F0F0F2F1 F0F7F9F0F0C9C2D4 F7F5F0F0F0F0F0F0 F0E9C2F7F7F11000  
     
     
     
83012D001E00 30430201 0008C04004FEF44C 03012800  
  1 DEVICE(S) MET THE SELECTION CRITERIA 
  0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dasd Mod conversion mod9 to mod27

[Jake Anderson]

Addresses are not changing

It's the same UCB

On Mon, Oct 3, 2022, 5:14 PM Seymour J Metz  wrote:

> HCD if addresses have changed.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Jake Anderson [justmainfra...@gmail.com]
> Sent: Monday, October 3, 2022 5:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dasd Mod conversion mod9 to mod27
>
> Hello
>
> We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.
>
> Post the mod conversion before initializing are there any other steps needs
> to be performed in zOS ?
>
> 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
>

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

Re: Dasd Mod conversion mod9 to mod27

[Seymour J Metz]

HCD if addresses have changed.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jake Anderson [justmainfra...@gmail.com]
Sent: Monday, October 3, 2022 5:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dasd Mod conversion mod9 to mod27

Hello

We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.

Post the mod conversion before initializing are there any other steps needs
to be performed in zOS ?

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: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 3/10/22 13:47, David Crayford wrote:

Porting tools to support MVS data sets in trivial.

I meant Porting tools to support MVS data sets is non trivial.

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

[Public] RE: EXTERNAL: COBOL - z/OS 2.1 vs 2.4

[Usher, Darrold]

We encountered a fair amount of U4088-63 abends with z/OS v2.4. Relinks were 
required to ensure called utilities by the application were LE-compliant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crusty Old Guy
Sent: Friday, September 30, 2022 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: COBOL - z/OS 2.1 vs 2.4

We have a client with loadmods that are ancient.  Some are very ancient.  All 
of those loadmods are currently running under z/OS 2.1.
Under z/OS 2.4, some of these loadmods are abending.  Others are creating 
incorrect output.

What could account for this behavior?  What has changed between 2.1 & 2.4?

Regards,
Crusty Old Guy

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

USAA Classification: Public

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


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

Dasd Mod conversion mod9 to mod27

[Jake Anderson]

Hello

We are planning to perform mod conversion of mod 9 to nod 27 from DS8K.

Post the mod conversion before initializing are there any other steps needs
to be performed in zOS ?

Jake

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