Re: Running z/OS 1.12 apps on 2.4
Dave Gibney wrote: >Or even steplib the old runtime libraries into the jobs. Not generally a great idea beyond a contingency, which is what I think you meant. At least some of the runtime library updates are vital for stability, integrity, security, and myriad other reasons. I also recall one occasion when the supplier of a runtime library got quite upset when someone copied a licensed library and used it without a license. It was an expensive lesson. However, if you've got a proper license, experience a problem with the newer library, AND the old library helps (temporarily, until you can fix the underlying problem) then that all seems reasonable to me. — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running z/OS 1.12 apps on 2.4
Key question is whether all those old Cobol applications are using LE at 1.12 level or are some pre-LE runtime? Chances are the outsourcer will not have the right pre-LE runtime available, so you'd have to port the matching runtime with the application. Being on 1.12 is very unfortunate as LE z/OS 2.2 introduced some incompatibilities which IBM rectified back to z/OS 1.13 (as LE guarantees upward and downward compatibility for all supported releases). Your applications may or may not run into these; if they do, it is fixable only by recompile under supported levels on 2.4 -- which will be very expensive bill from that outsourcer. Could be a lot cheaper to keep that z10BC running :) On Tue, Aug 2, 2022 at 4:22 AM John McKown wrote: > My current employer is still running stuff on z/OS 1.12 on a z10BC. They > are shutting it down. But they have mentioned an "archive solution" for ??? > apps which might not make the "hard" decommission date. > > Their latest idea is basically outsourcing to an "on demand" service. It is > running 2.4 . I am curious if they might run into problem with old COBOL > code with the new LE. It's just curiosity because I will not be involved, > supposedly. I am not sure about EasyTrieve Plus either. > > Thanks for any thoughts. My actual work for them will end, supposedly end > 1Q23, but my employment & pay will last until 1Aug23, regardless (a kind of > severance). > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
Home is where your stuff is, so sounds like a good place to be. As I said, you seem like you would be a fun guy to work with. Curiosity and cleverness go a long way. 2023 is a little ways off, so please continue to contribute to the conversation here! On Mon, Aug 1, 2022 at 7:11 PM John McKown wrote: > Forgot to mention, I'll be 70 & I'm not in good health (dialysis), so I'm > retiring and just going to stay home (gaming) or go on short weekend trips > in the car. I will most likely resign from all email groups. > > On Mon, Aug 1, 2022, 16:12 Usher, Darrold < > 014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > > > z/OS v2.4 appears to really enforce LE compliance especially for any > > called utility routines will need to be LE compliant or you could end up > > with a U4088-63 abend. Generally, straightforward old COBOL code will > > continue to run on newer LE versions with some exceptions. It would nice > to > > keep the old environment around at least until you can determine whether > > the apps that will remain can run on z/OS v2.4. > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Steve Horein > > Sent: Monday, August 1, 2022 4:02 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 > > > > Where are you going after that? > > You seem like you would be a fun guy to work with. > > > > On Mon, Aug 1, 2022 at 1:22 PM John McKown > > > wrote: > > > > > My current employer is still running stuff on z/OS 1.12 on a z10BC. > > > They are shutting it down. But they have mentioned an "archive > solution" > > for ??? > > > apps which might not make the "hard" decommission date. > > > > > > Their latest idea is basically outsourcing to an "on demand" service. > > > It is running 2.4 . I am curious if they might run into problem with > > > old COBOL code with the new LE. It's just curiosity because I will not > > > be involved, supposedly. I am not sure about EasyTrieve Plus either. > > > > > > Thanks for any thoughts. My actual work for them will end, supposedly > > > end 1Q23, but my employment & pay will last until 1Aug23, regardless > > > (a kind of severance). > > > > > > -- > > > 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: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
Best of luck John … as Mark Twain was quoted saying that “Youth is wasted on the young” continues to hold true. Matt Hogstrom m...@hogstrom.org “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running z/OS 1.12 apps on 2.4
Or even steplib the old runtime libraries into the jobs. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: Monday, August 01, 2022 4:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Running z/OS 1.12 apps on 2.4 > > [EXTERNAL EMAIL] > > Echoing what others have said, upward OS compatibility for compiled and > linked applications is a hallmark of MVS and its descendants. I would be > stunned if you had a problem with the COBOL apps. Trust but verify: you > might want to run a test or two on the new hardware. And it's not the end of > the world, right? You/they *could* recompile a failing application? > > Is Easytrieve interpreted or compiled? My recollection is interpreted. If so, > it's hard to see how there could be an upward compatibility problem. > > Charles > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
Joined the retirement club myself yesterday. Too many bucket list things to accomplish. Sent from Yahoo Mail for iPhone On Monday, August 1, 2022, 8:11 PM, John McKown wrote: Forgot to mention, I'll be 70 & I'm not in good health (dialysis), so I'm retiring and just going to stay home (gaming) or go on short weekend trips in the car. I will most likely resign from all email groups. On Mon, Aug 1, 2022, 16:12 Usher, Darrold < 014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > z/OS v2.4 appears to really enforce LE compliance especially for any > called utility routines will need to be LE compliant or you could end up > with a U4088-63 abend. Generally, straightforward old COBOL code will > continue to run on newer LE versions with some exceptions. It would nice to > keep the old environment around at least until you can determine whether > the apps that will remain can run on z/OS v2.4. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Horein > Sent: Monday, August 1, 2022 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 > > Where are you going after that? > You seem like you would be a fun guy to work with. > > On Mon, Aug 1, 2022 at 1:22 PM John McKown > wrote: > > > My current employer is still running stuff on z/OS 1.12 on a z10BC. > > They are shutting it down. But they have mentioned an "archive solution" > for ??? > > apps which might not make the "hard" decommission date. > > > > Their latest idea is basically outsourcing to an "on demand" service. > > It is running 2.4 . I am curious if they might run into problem with > > old COBOL code with the new LE. It's just curiosity because I will not > > be involved, supposedly. I am not sure about EasyTrieve Plus either. > > > > Thanks for any thoughts. My actual work for them will end, supposedly > > end 1Q23, but my employment & pay will last until 1Aug23, regardless > > (a kind of severance). > > > > -- > > 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: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
John , Best of luck to you. Always enjoyed your unique point of view. Best Regards, Doug . On Aug 1, 2022, at 20:11, John McKown wrote: Forgot to mention, I'll be 70 & I'm not in good health (dialysis), so I'm retiring and just going to stay home (gaming) or go on short weekend trips in the car. I will most likely resign from all email groups. On Mon, Aug 1, 2022, 16:12 Usher, Darrold < 014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > z/OS v2.4 appears to really enforce LE compliance especially for any > called utility routines will need to be LE compliant or you could end up > with a U4088-63 abend. Generally, straightforward old COBOL code will > continue to run on newer LE versions with some exceptions. It would nice to > keep the old environment around at least until you can determine whether > the apps that will remain can run on z/OS v2.4. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Horein > Sent: Monday, August 1, 2022 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 > > Where are you going after that? > You seem like you would be a fun guy to work with. > > On Mon, Aug 1, 2022 at 1:22 PM John McKown > wrote: > >> My current employer is still running stuff on z/OS 1.12 on a z10BC. >> They are shutting it down. But they have mentioned an "archive solution" > for ??? >> apps which might not make the "hard" decommission date. >> >> Their latest idea is basically outsourcing to an "on demand" service. >> It is running 2.4 . I am curious if they might run into problem with >> old COBOL code with the new LE. It's just curiosity because I will not >> be involved, supposedly. I am not sure about EasyTrieve Plus either. >> >> Thanks for any thoughts. My actual work for them will end, supposedly >> end 1Q23, but my employment & pay will last until 1Aug23, regardless >> (a kind of severance). >> >> -- >> 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: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
Forgot to mention, I'll be 70 & I'm not in good health (dialysis), so I'm retiring and just going to stay home (gaming) or go on short weekend trips in the car. I will most likely resign from all email groups. On Mon, Aug 1, 2022, 16:12 Usher, Darrold < 014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > z/OS v2.4 appears to really enforce LE compliance especially for any > called utility routines will need to be LE compliant or you could end up > with a U4088-63 abend. Generally, straightforward old COBOL code will > continue to run on newer LE versions with some exceptions. It would nice to > keep the old environment around at least until you can determine whether > the apps that will remain can run on z/OS v2.4. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Horein > Sent: Monday, August 1, 2022 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 > > Where are you going after that? > You seem like you would be a fun guy to work with. > > On Mon, Aug 1, 2022 at 1:22 PM John McKown > wrote: > > > My current employer is still running stuff on z/OS 1.12 on a z10BC. > > They are shutting it down. But they have mentioned an "archive solution" > for ??? > > apps which might not make the "hard" decommission date. > > > > Their latest idea is basically outsourcing to an "on demand" service. > > It is running 2.4 . I am curious if they might run into problem with > > old COBOL code with the new LE. It's just curiosity because I will not > > be involved, supposedly. I am not sure about EasyTrieve Plus either. > > > > Thanks for any thoughts. My actual work for them will end, supposedly > > end 1Q23, but my employment & pay will last until 1Aug23, regardless > > (a kind of severance). > > > > -- > > 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: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
Thanks. That's comforting. On Mon, Aug 1, 2022, 16:12 Usher, Darrold < 014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > z/OS v2.4 appears to really enforce LE compliance especially for any > called utility routines will need to be LE compliant or you could end up > with a U4088-63 abend. Generally, straightforward old COBOL code will > continue to run on newer LE versions with some exceptions. It would nice to > keep the old environment around at least until you can determine whether > the apps that will remain can run on z/OS v2.4. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Horein > Sent: Monday, August 1, 2022 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 > > Where are you going after that? > You seem like you would be a fun guy to work with. > > On Mon, Aug 1, 2022 at 1:22 PM John McKown > wrote: > > > My current employer is still running stuff on z/OS 1.12 on a z10BC. > > They are shutting it down. But they have mentioned an "archive solution" > for ??? > > apps which might not make the "hard" decommission date. > > > > Their latest idea is basically outsourcing to an "on demand" service. > > It is running 2.4 . I am curious if they might run into problem with > > old COBOL code with the new LE. It's just curiosity because I will not > > be involved, supposedly. I am not sure about EasyTrieve Plus either. > > > > Thanks for any thoughts. My actual work for them will end, supposedly > > end 1Q23, but my employment & pay will last until 1Aug23, regardless > > (a kind of severance). > > > > -- > > 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: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
I call a lot of assembler from LE C++, assembler that was written for the most part eons ago, and had zero issues with V2R4. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running z/OS 1.12 apps on 2.4
Echoing what others have said, upward OS compatibility for compiled and linked applications is a hallmark of MVS and its descendants. I would be stunned if you had a problem with the COBOL apps. Trust but verify: you might want to run a test or two on the new hardware. And it's not the end of the world, right? You/they *could* recompile a failing application? Is Easytrieve interpreted or compiled? My recollection is interpreted. If so, it's hard to see how there could be an upward compatibility problem. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4
z/OS v2.4 appears to really enforce LE compliance especially for any called utility routines will need to be LE compliant or you could end up with a U4088-63 abend. Generally, straightforward old COBOL code will continue to run on newer LE versions with some exceptions. It would nice to keep the old environment around at least until you can determine whether the apps that will remain can run on z/OS v2.4. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Horein Sent: Monday, August 1, 2022 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: Running z/OS 1.12 apps on 2.4 Where are you going after that? You seem like you would be a fun guy to work with. On Mon, Aug 1, 2022 at 1:22 PM John McKown wrote: > My current employer is still running stuff on z/OS 1.12 on a z10BC. > They are shutting it down. But they have mentioned an "archive solution" for > ??? > apps which might not make the "hard" decommission date. > > Their latest idea is basically outsourcing to an "on demand" service. > It is running 2.4 . I am curious if they might run into problem with > old COBOL code with the new LE. It's just curiosity because I will not > be involved, supposedly. I am not sure about EasyTrieve Plus either. > > Thanks for any thoughts. My actual work for them will end, supposedly > end 1Q23, but my employment & pay will last until 1Aug23, regardless > (a kind of severance). > > -- > 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: Running z/OS 1.12 apps on 2.4
Where are you going after that? You seem like you would be a fun guy to work with. On Mon, Aug 1, 2022 at 1:22 PM John McKown wrote: > My current employer is still running stuff on z/OS 1.12 on a z10BC. They > are shutting it down. But they have mentioned an "archive solution" for ??? > apps which might not make the "hard" decommission date. > > Their latest idea is basically outsourcing to an "on demand" service. It is > running 2.4 . I am curious if they might run into problem with old COBOL > code with the new LE. It's just curiosity because I will not be involved, > supposedly. I am not sure about EasyTrieve Plus either. > > Thanks for any thoughts. My actual work for them will end, supposedly end > 1Q23, but my employment & pay will last until 1Aug23, regardless (a kind of > severance). > > -- > 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: AWS and IDRC/compression
And I want data interchange with IBM and Broadcom, both of which accept .AWS files based on z/VSE's VTAPE implementation (which uses AWS). Currently, I just take an .AWS tape off my VTA and FTP it to them and they can read it. I really don't want to have to convert files before sending them. HET looks promising. Tony Thigpen Jay Maynard wrote on 8/1/22 10:04: I think Tony was looking for a way to do it transparently, so that no changes were needed to the programs reading or writing what they see as a real tape. Your approach requires modifying the host program or jobstream. On Mon, Aug 1, 2022 at 8:58 AM Joe Monk wrote: I dont even understand what the problem is. AWS is simply a disk format for a sequential file of tape blocks. What is inside those blocks are for the program that reads/writes them to decide... AWS does not decide that. You can easily compress, slice into blocks, and write to AWS. Sam Golobs article on AWSTAPE makes that pretty clear ... https://www.cbttape.org/awstape.htm Joe On Mon, Aug 1, 2022 at 7:59 AM Seymour J Metz wrote: Why is IDRC compatibility an issue when you're not using a physical cartridge or physical drive that supports IDRC? If you modify AWS to support compression, use whatever format that gives you the best results. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, July 30, 2022 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AWS and IDRC/compression I am working with my VTA vendor to reduce storage usage on the appliance. Currently, they can compress after the unmount and uncompress before the mount. But, this takes time, especially when servicing the mount request if the tape is large. I was thinking that doing an IDRC implementation, which is stream based and performed during write/read, it might be faster even if it's not compresses as much as with their current method. But, if the AWS file is not compatible with IBM's implementation, then it's going to add a step to send them the file. The current compressed files can be uncompressed using standard linux tools. Tony Thigpen Jay Maynard wrote on 7/29/22 22:44: I'm curious. What are you trying to accomplish with it? If it's just a matter of faster transmission of entire tape images, AWS tapes compress very well. On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen wrote: Yes. But, it sounds like nobody else will support it as a data interchange, so it may be unusable for us. I will go look at it. Tony Thigpen Jay Maynard wrote on 7/29/22 06:38: Are you talking about the tape data being compressed inside the AWS image? Hercules has a format that does this, upwardly compatible with AWS, called HET (Hercules Emulated Tape), but I don't know of any other implementations of it. Each block is compressed after being received from the program writing the tape but before being written to the file and uncompressed after being read but before being returned to the program reading the tape. On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen wrote: Does anyone know of any 'standard' for stream based (during file creation) compression of AWS tapes? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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 -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: SYSTEM REXX
On Fri, 15 Jul 2022 14:03:30 +, Harris Morgenstern wrote: >The AXRWTO, AXRWTOR etc. external functions are only available when running >under System REXX.You'll need to add your exec to a data set in the >REXXLIB concatenation and run it as a system command via MODIFY > AXR,xxx where xxx is the name of your exec. More info here: https://www.ibm.com/docs/en/zos/2.5.0?topic=command-communicating-system-rexx Note that REXXLIB is a "system-wide" specification -- you will have to ensure that your test EXECs do not have names that match current production level EXECs. Scott Fagen Sirius Computer Solutions, A CDW company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extending a VTOC
If you have FDR they have a very safe way of extending the VTOC. I have done it multiple times sometimes at 3 a.m. Willie On Monday, August 1, 2022 at 06:15:35 a.m. EDT, Jack Zukt wrote: Hi all, It has been way too many years since the last time I dabbled with ICKDSF and VTOC definitions (probably over twenty, but I would rather not do the math). Back on those days, if memory serves me right, the only way to extend a VTOC was to clean the DASD of all its contents, put it offline, and recreate the VTOC with the new size. As a few years have passed, I have been going through the ICKDSF manual trying to find out if a VTOC can be extended without having to clear the volume first. I can not say that I have became enlightened. It seems to be possible but I am not quite sure about it. And this being a production volume I really would hate if things do not work as expected. So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without having first to clean the DASD of all its files? Thank you in advance for any help, Best regards 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: [EXTERNAL] Running z/OS 1.12 apps on 2.4
I agree. All COBOL code, all versions, should run without issues. With respect to the EasyTrieve programs, we are on z/OS V2.4 here and run several different generations of EasyTrieve without any issues. If your current version of EasyTrieve is relatively recent they should be fine. I would tell them to ask the "service" what version of EasyTrieve the "service" runs just to check. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 1, 2022 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Running z/OS 1.12 apps on 2.4 Shouldn't be an issue. We're running 2.4 and just disabled our Cobol 4.2 compiler to keep people from trying to use it. We also just finished migrating our Cobol code from 4.2 and Cobol 2. We didn't recompile any of that code when we migrated to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Monday, August 1, 2022 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Running z/OS 1.12 apps on 2.4 My current employer is still running stuff on z/OS 1.12 on a z10BC. They are shutting it down. But they have mentioned an "archive solution" for ??? apps which might not make the "hard" decommission date. Their latest idea is basically outsourcing to an "on demand" service. It is running 2.4 . I am curious if they might run into problem with old COBOL code with the new LE. It's just curiosity because I will not be involved, supposedly. I am not sure about EasyTrieve Plus either. Thanks for any thoughts. My actual work for them will end, supposedly end 1Q23, but my employment & pay will last until 1Aug23, regardless (a kind of severance). -- 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: [EXTERNAL] Running z/OS 1.12 apps on 2.4
Shouldn't be an issue. We're running 2.4 and just disabled our Cobol 4.2 compiler to keep people from trying to use it. We also just finished migrating our Cobol code from 4.2 and Cobol 2. We didn't recompile any of that code when we migrated to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Monday, August 1, 2022 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Running z/OS 1.12 apps on 2.4 My current employer is still running stuff on z/OS 1.12 on a z10BC. They are shutting it down. But they have mentioned an "archive solution" for ??? apps which might not make the "hard" decommission date. Their latest idea is basically outsourcing to an "on demand" service. It is running 2.4 . I am curious if they might run into problem with old COBOL code with the new LE. It's just curiosity because I will not be involved, supposedly. I am not sure about EasyTrieve Plus either. Thanks for any thoughts. My actual work for them will end, supposedly end 1Q23, but my employment & pay will last until 1Aug23, regardless (a kind of severance). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Running z/OS 1.12 apps on 2.4
My current employer is still running stuff on z/OS 1.12 on a z10BC. They are shutting it down. But they have mentioned an "archive solution" for ??? apps which might not make the "hard" decommission date. Their latest idea is basically outsourcing to an "on demand" service. It is running 2.4 . I am curious if they might run into problem with old COBOL code with the new LE. It's just curiosity because I will not be involved, supposedly. I am not sure about EasyTrieve Plus either. Thanks for any thoughts. My actual work for them will end, supposedly end 1Q23, but my employment & pay will last until 1Aug23, regardless (a kind of severance). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog to VTOC comparison
Hi, As you requested: //STEP001 EXEC PGM=IKJEFT01 //STEPLIB DD DISP=SHR,DSN=FILE135.PDS //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * VTOC volser - CAT - LIM(CAT NE C) - PRINT(NEW (CAT ALLOC UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT - VOLUME DSNAME)) - where "volser" is the actual VOLSER (e.g. ABC123) or the first few characters of a group of VOLSERs with the same prefix (e.g. code ABC for VOLSERs ABC001, ABC002, ABC003 etc.) - If you download FILE 135, VTOC (and other CBT programs) are pre-built. Regards, David On 2022-08-01 11:29, rpinion865 wrote: Last month there was a discussion regarding identifying uncataloged datasets. My need is to compare the contents of a catalog, or catalogs, with DASD VTOC's. Essentially, some report that would show the catalog status between entries in the catalog and VTOC. For example, dataset A.B.C is NOT cataloged or is mis-cataloged. Or dataset A.B.C is cataloged, but does not exist on any DASD volume. FDREPORT, from BMC, does this type of reporting. But, my current employer does not have FDREPORT. The CBT tape VTOC command would provide the information for the first example. Thanks in advance. Sent with [Proton Mail](https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fproton.me%2Fdata=05%7C01%7C%7Ca1893a3106c94d46c4b108da73d2c202%7C84df9e7fe9f640afb435%7C1%7C0%7C637949646342191811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=wj2%2Fq7NkJhbDM44AbSKTYr%2F8cfhYxXiDM9LGkmA4Rmw%3Dreserved=0) secure email. -- 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: Extending a VTOC
The Extend VTOC is nice, but has one problem ... you could end up with your VTOC in multiple extents. I would back it up, empty the volume, and reinit. Joe On Mon, Aug 1, 2022 at 10:01 AM Jack Zukt wrote: > Thank you all for your input. > I am going to try it like that > Regards, > Jack > > On Mon, 1 Aug 2022 at 11:58, Immo wrote: > > > P.S. > > EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT. > > Michael > > > > -Ursprüngliche Nachricht- > > Von: IBM Mainframe Discussion List Im Auftrag > > von Jack Zukt > > Gesendet: Montag, 1. August 2022 12:15 > > An: IBM-MAIN@LISTSERV.UA.EDU > > Betreff: Extending a VTOC > > > > Hi all, > > It has been way too many years since the last time I dabbled with ICKDSF > > and VTOC definitions (probably over twenty, but I would rather not do the > > math). > > Back on those days, if memory serves me right, the only way to extend a > > VTOC was to clean the DASD of all its contents, put it offline, and > > recreate the VTOC with the new size. As a few years have passed, I have > > been going through the ICKDSF manual trying to find out if a VTOC can be > > extended without having to clear the volume first. I can not say that I > > have became enlightened. It seems to be possible but I am not quite sure > > about it. And this being a production volume I really would hate if > things > > do not work as expected. > > So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without > > having first to clean the DASD of all its files? > > Thank you in advance for any help, > > Best regards > > 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 > > > > -- > 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
Catalog to VTOC comparison
Last month there was a discussion regarding identifying uncataloged datasets. My need is to compare the contents of a catalog, or catalogs, with DASD VTOC's. Essentially, some report that would show the catalog status between entries in the catalog and VTOC. For example, dataset A.B.C is NOT cataloged or is mis-cataloged. Or dataset A.B.C is cataloged, but does not exist on any DASD volume. FDREPORT, from BMC, does this type of reporting. But, my current employer does not have FDREPORT. The CBT tape VTOC command would provide the information for the first example. Thanks in advance. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extending a VTOC
I hope I'm only stating the obvious, but back the volume up before you do anything. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jack Zukt Sent: Monday, August 1, 2022 10:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extending a VTOC Thank you all for your input. I am going to try it like that Regards, Jack On Mon, 1 Aug 2022 at 11:58, Immo wrote: > P.S. > EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT. > Michael > > -Ursprüngliche Nachricht- > Von: IBM Mainframe Discussion List Im > Auftrag von Jack Zukt > Gesendet: Montag, 1. August 2022 12:15 > An: IBM-MAIN@LISTSERV.UA.EDU > Betreff: Extending a VTOC > > Hi all, > It has been way too many years since the last time I dabbled with > ICKDSF and VTOC definitions (probably over twenty, but I would rather > not do the math). > Back on those days, if memory serves me right, the only way to extend > a VTOC was to clean the DASD of all its contents, put it offline, and > recreate the VTOC with the new size. As a few years have passed, I > have been going through the ICKDSF manual trying to find out if a VTOC > can be extended without having to clear the volume first. I can not > say that I have became enlightened. It seems to be possible but I am > not quite sure about it. And this being a production volume I really > would hate if things do not work as expected. > So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without > having first to clean the DASD of all its files? > Thank you in advance for any help, > Best regards > 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 > -- 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: Extending a VTOC
Thank you all for your input. I am going to try it like that Regards, Jack On Mon, 1 Aug 2022 at 11:58, Immo wrote: > P.S. > EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT. > Michael > > -Ursprüngliche Nachricht- > Von: IBM Mainframe Discussion List Im Auftrag > von Jack Zukt > Gesendet: Montag, 1. August 2022 12:15 > An: IBM-MAIN@LISTSERV.UA.EDU > Betreff: Extending a VTOC > > Hi all, > It has been way too many years since the last time I dabbled with ICKDSF > and VTOC definitions (probably over twenty, but I would rather not do the > math). > Back on those days, if memory serves me right, the only way to extend a > VTOC was to clean the DASD of all its contents, put it offline, and > recreate the VTOC with the new size. As a few years have passed, I have > been going through the ICKDSF manual trying to find out if a VTOC can be > extended without having to clear the volume first. I can not say that I > have became enlightened. It seems to be possible but I am not quite sure > about it. And this being a production volume I really would hate if things > do not work as expected. > So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without > having first to clean the DASD of all its files? > Thank you in advance for any help, > Best regards > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Location of IBM python SDK language and standard library documentation?
Rockets Python could do I/O to MVS data sets. Rocket also ported the Python CFFI package which would make writing a library in pure Python a snip. I wonder if IBM has ported CFFI? I would open an RFE. IBM have created MVS file I/O packages for golang and Node.js. On 31/07/2022 7:02 am, Farley, Peter x23353 wrote: I have been looking around on various IBM websites trying to find the IBM versions of the normal python language and python standard library documentation to answer a few z/OS-specific python questions. 1. Does the z/OS implementation of the python language standard function "open()" accept z/OS Unix System Services file name format for MVS flat and PDS(E) datasets (e.g., "//'MVS.FLAT.FILE'" and "//'MVS.PDS(PDSMEM)'")? (I.E., under the covers does it use the "open()" or "fopen()" C library function?) 2. Is the "zos_util" library package available in all versions of the z/OS python SDK? TIA for any RTFM or url's you can point me to. PDF's of the documentation for offline reading would be welcome if they are available. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AWS and IDRC/compression
I think Tony was looking for a way to do it transparently, so that no changes were needed to the programs reading or writing what they see as a real tape. Your approach requires modifying the host program or jobstream. On Mon, Aug 1, 2022 at 8:58 AM Joe Monk wrote: > I dont even understand what the problem is. > > AWS is simply a disk format for a sequential file of tape blocks. What is > inside those blocks are for the program that reads/writes them to decide... > AWS does not decide that. You can easily compress, slice into blocks, and > write to AWS. > > Sam Golobs article on AWSTAPE makes that pretty clear ... > https://www.cbttape.org/awstape.htm > > Joe > > On Mon, Aug 1, 2022 at 7:59 AM Seymour J Metz wrote: > > > Why is IDRC compatibility an issue when you're not using a physical > > cartridge or physical drive that supports IDRC? If you modify AWS to > > support compression, use whatever format that gives you the best results. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Tony Thigpen [t...@vse2pdf.com] > > Sent: Saturday, July 30, 2022 12:45 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: AWS and IDRC/compression > > > > I am working with my VTA vendor to reduce storage usage on the > > appliance. Currently, they can compress after the unmount and uncompress > > before the mount. But, this takes time, especially when servicing the > > mount request if the tape is large. > > > > I was thinking that doing an IDRC implementation, which is stream based > > and performed during write/read, it might be faster even if it's not > > compresses as much as with their current method. > > > > But, if the AWS file is not compatible with IBM's implementation, then > > it's going to add a step to send them the file. The current compressed > > files can be uncompressed using standard linux tools. > > > > Tony Thigpen > > > > Jay Maynard wrote on 7/29/22 22:44: > > > I'm curious. What are you trying to accomplish with it? If it's just a > > > matter of faster transmission of entire tape images, AWS tapes compress > > > very well. > > > > > > On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen wrote: > > > > > >> Yes. But, it sounds like nobody else will support it as a data > > >> interchange, so it may be unusable for us. > > >> > > >> I will go look at it. > > >> > > >> Tony Thigpen > > >> > > >> Jay Maynard wrote on 7/29/22 06:38: > > >>> Are you talking about the tape data being compressed inside the AWS > > >> image? > > >>> Hercules has a format that does this, upwardly compatible with AWS, > > >> called > > >>> HET (Hercules Emulated Tape), but I don't know of any other > > >> implementations > > >>> of it. Each block is compressed after being received from the program > > >>> writing the tape but before being written to the file and > uncompressed > > >>> after being read but before being returned to the program reading the > > >> tape. > > >>> > > >>> On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen > wrote: > > >>> > > Does anyone know of any 'standard' for stream based (during file > > creation) compression of AWS tapes? > > > > Tony Thigpen > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > >>> > > >>> > > >>> -- > > >>> Jay Maynard > > >>> > > >>> > -- > > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > > >>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > >> > > >> -- > > >> For IBM-MAIN subscribe / signoff / archive access instructions, > > >> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > >> > > > > > > > > > -- > > > Jay Maynard > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > 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
Re: AWS and IDRC/compression
I dont even understand what the problem is. AWS is simply a disk format for a sequential file of tape blocks. What is inside those blocks are for the program that reads/writes them to decide... AWS does not decide that. You can easily compress, slice into blocks, and write to AWS. Sam Golobs article on AWSTAPE makes that pretty clear ... https://www.cbttape.org/awstape.htm Joe On Mon, Aug 1, 2022 at 7:59 AM Seymour J Metz wrote: > Why is IDRC compatibility an issue when you're not using a physical > cartridge or physical drive that supports IDRC? If you modify AWS to > support compression, use whatever format that gives you the best results. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Tony Thigpen [t...@vse2pdf.com] > Sent: Saturday, July 30, 2022 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: AWS and IDRC/compression > > I am working with my VTA vendor to reduce storage usage on the > appliance. Currently, they can compress after the unmount and uncompress > before the mount. But, this takes time, especially when servicing the > mount request if the tape is large. > > I was thinking that doing an IDRC implementation, which is stream based > and performed during write/read, it might be faster even if it's not > compresses as much as with their current method. > > But, if the AWS file is not compatible with IBM's implementation, then > it's going to add a step to send them the file. The current compressed > files can be uncompressed using standard linux tools. > > Tony Thigpen > > Jay Maynard wrote on 7/29/22 22:44: > > I'm curious. What are you trying to accomplish with it? If it's just a > > matter of faster transmission of entire tape images, AWS tapes compress > > very well. > > > > On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen wrote: > > > >> Yes. But, it sounds like nobody else will support it as a data > >> interchange, so it may be unusable for us. > >> > >> I will go look at it. > >> > >> Tony Thigpen > >> > >> Jay Maynard wrote on 7/29/22 06:38: > >>> Are you talking about the tape data being compressed inside the AWS > >> image? > >>> Hercules has a format that does this, upwardly compatible with AWS, > >> called > >>> HET (Hercules Emulated Tape), but I don't know of any other > >> implementations > >>> of it. Each block is compressed after being received from the program > >>> writing the tape but before being written to the file and uncompressed > >>> after being read but before being returned to the program reading the > >> tape. > >>> > >>> On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen wrote: > >>> > Does anyone know of any 'standard' for stream based (during file > creation) compression of AWS tapes? > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > >>> > >>> > >>> -- > >>> Jay Maynard > >>> > >>> -- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > > > > -- > > Jay Maynard > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > 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: User-written condition handlers with COBOL
No responses yet? I am interested too in seeing real-world examples of LE condition handling in COBOL. Where I work, we just take the Abend and examine what happened using Fault Analyzer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AWS and IDRC/compression
Why is IDRC compatibility an issue when you're not using a physical cartridge or physical drive that supports IDRC? If you modify AWS to support compression, use whatever format that gives you the best results. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, July 30, 2022 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AWS and IDRC/compression I am working with my VTA vendor to reduce storage usage on the appliance. Currently, they can compress after the unmount and uncompress before the mount. But, this takes time, especially when servicing the mount request if the tape is large. I was thinking that doing an IDRC implementation, which is stream based and performed during write/read, it might be faster even if it's not compresses as much as with their current method. But, if the AWS file is not compatible with IBM's implementation, then it's going to add a step to send them the file. The current compressed files can be uncompressed using standard linux tools. Tony Thigpen Jay Maynard wrote on 7/29/22 22:44: > I'm curious. What are you trying to accomplish with it? If it's just a > matter of faster transmission of entire tape images, AWS tapes compress > very well. > > On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen wrote: > >> Yes. But, it sounds like nobody else will support it as a data >> interchange, so it may be unusable for us. >> >> I will go look at it. >> >> Tony Thigpen >> >> Jay Maynard wrote on 7/29/22 06:38: >>> Are you talking about the tape data being compressed inside the AWS >> image? >>> Hercules has a format that does this, upwardly compatible with AWS, >> called >>> HET (Hercules Emulated Tape), but I don't know of any other >> implementations >>> of it. Each block is compressed after being received from the program >>> writing the tape but before being written to the file and uncompressed >>> after being read but before being returned to the program reading the >> tape. >>> >>> On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen wrote: >>> Does anyone know of any 'standard' for stream based (during file creation) compression of AWS tapes? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> >>> -- >>> Jay Maynard >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > Jay Maynard > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
AW: Extending a VTOC
P.S. EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT. Michael -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List Im Auftrag von Jack Zukt Gesendet: Montag, 1. August 2022 12:15 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Extending a VTOC Hi all, It has been way too many years since the last time I dabbled with ICKDSF and VTOC definitions (probably over twenty, but I would rather not do the math). Back on those days, if memory serves me right, the only way to extend a VTOC was to clean the DASD of all its contents, put it offline, and recreate the VTOC with the new size. As a few years have passed, I have been going through the ICKDSF manual trying to find out if a VTOC can be extended without having to clear the volume first. I can not say that I have became enlightened. It seems to be possible but I am not quite sure about it. And this being a production volume I really would hate if things do not work as expected. So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without having first to clean the DASD of all its files? Thank you in advance for any help, Best regards 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
AW: Extending a VTOC
Hi Jack, have a look at ICKDSF parameter "EXTVTOC(n): Expands the VTOC at its current location." This may do what you want. Regards Michael -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List Im Auftrag von Jack Zukt Gesendet: Montag, 1. August 2022 12:15 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Extending a VTOC Hi all, It has been way too many years since the last time I dabbled with ICKDSF and VTOC definitions (probably over twenty, but I would rather not do the math). Back on those days, if memory serves me right, the only way to extend a VTOC was to clean the DASD of all its contents, put it offline, and recreate the VTOC with the new size. As a few years have passed, I have been going through the ICKDSF manual trying to find out if a VTOC can be extended without having to clear the volume first. I can not say that I have became enlightened. It seems to be possible but I am not quite sure about it. And this being a production volume I really would hate if things do not work as expected. So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without having first to clean the DASD of all its files? Thank you in advance for any help, Best regards 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: Extending a VTOC
In theory you can. The VTOC has to be contiguous, so the area on the disk just passed to current VTOC must be free. If that is not the case, you will have to move the files that occupy that space, or do it the old way, by emptying the dasd and reinitializing it with a larger VTOC. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jack Zukt Sent: Monday, August 1, 2022 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Extending a VTOC Hi all, It has been way too many years since the last time I dabbled with ICKDSF and VTOC definitions (probably over twenty, but I would rather not do the math). Back on those days, if memory serves me right, the only way to extend a VTOC was to clean the DASD of all its contents, put it offline, and recreate the VTOC with the new size. As a few years have passed, I have been going through the ICKDSF manual trying to find out if a VTOC can be extended without having to clear the volume first. I can not say that I have became enlightened. It seems to be possible but I am not quite sure about it. And this being a production volume I really would hate if things do not work as expected. So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without having first to clean the DASD of all its files? Thank you in advance for any help, Best regards Jack -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email secured by Check Point -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Extending a VTOC
Hi all, It has been way too many years since the last time I dabbled with ICKDSF and VTOC definitions (probably over twenty, but I would rather not do the math). Back on those days, if memory serves me right, the only way to extend a VTOC was to clean the DASD of all its contents, put it offline, and recreate the VTOC with the new size. As a few years have passed, I have been going through the ICKDSF manual trying to find out if a VTOC can be extended without having to clear the volume first. I can not say that I have became enlightened. It seems to be possible but I am not quite sure about it. And this being a production volume I really would hate if things do not work as expected. So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without having first to clean the DASD of all its files? Thank you in advance for any help, Best regards Jack -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Location of IBM python SDK language and standard library documentation?
Hi,
What about:
https://docs.python.org/3/library/io.html
A quick idea:
https://www.w3schools.com/python/python_file_open.asp
Or this.
https://www.geeksforgeeks.org/read-a-file-line-by-line-in-python/
Best
Peter Sylvester
On 31/07/2022 20:29, Farley, Peter x23353 wrote:
Thanks Colin, I did already find that manual, but the only two useful things in there for
ordinary programmers is the zos_util documentation and the table of "tagging"
behavior.
There are also the zoautil command line utilities and python API, but the file "read()" and "write()" functions there
assume you can read/write the entire file into/from memory. No "readline()" ow "writeline()" functions are provided as
far as I can see. And the "read()" and "write()" functions are quite slow (6 to 9 seconds to read a 300-record
LRECL=80 PDS member for instance).
I was hoping for better integration and performance than what I have seen so far, as well
as better z/OS-specific documentation. A "Programmers Guide" kind of book.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Colin Paice
Sent: Sunday, July 31, 2022 3:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Location of IBM python SDK language and standard library
documentation?
The manual SC28-3143-02 I*BM Open Enterprise SDK for Python 3.10* may be what
you want
import zos_util
f = open("//'USER.Z24C.PROCLIB(PYT)'","r")
read_data = f.read()
print(read_data)
gives
Traceback (most recent call last):
File "/u/tmp/zos/z.py", line 1, in
f = open("//'USER.Z24C.PROCLIB(PYT)'","r")
FileNotFoundError: [Errno 129] EDC5129I No such file or directory.:
"//'USER.Z24C.PROCLIB(PYT)'"
I've blogged on several Python topics on z/OS ... see here
.
I'm currently looking at writing an extension to use fopen etc. and read
datasets, so please contact me offline if you would like more info
Colin
On Sun, 31 Jul 2022 at 00:03, Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
I have been looking around on various IBM websites trying to find the
IBM versions of the normal python language and python standard library
documentation to answer a few z/OS-specific python questions.
1. Does the z/OS implementation of the python language standard
function "open()" accept z/OS Unix System Services file name format
for MVS flat and PDS(E) datasets (e.g., "//'MVS.FLAT.FILE'" and
"//'MVS.PDS(PDSMEM)'")? (I.E., under the covers does it use the "open()"
or "fopen()" C library function?)
2. Is the "zos_util" library package available in all versions of the
z/OS python SDK?
TIA for any RTFM or url's you can point me to. PDF's of the
documentation for offline reading would be welcome if they are available.
Peter
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
