Re: virtual Tape consumption statistics - DFRMM
Your tape management system (CA-1, RMM etc.) can tell you what it thinks is the size, and your Virtual tape appliance has the data on how much it compressed it (if at all) after it got hold of the data. Also, if you data is sent to a storage point, i.e. like storing on a NetApp appliance instead of internally to the virtual tape appliance, then it could have yet a different number depending on it's compression and deduplication settings. So, I guess the answer is that you have the data available at multiple points, and they are all correct for that particular spot. CA1 could think it wrote 5GB to the tape, but the virtual tape appliance might have compressed it down to 2gb (IDRC and it's own internal compression) and the Network appliance could have manged to make it 1.5GB (or 3GB if it was poorly set up). They would all be "right". Brian -- 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
One of the vendors that uses AWS is Optica, their z/VT uses AWS format. It can also compress internally, but you don't have to. Brian On Fri, 29 Jul 2022 21:44:25 -0500, Jay Maynard wrote: >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
Re: AWS and IDRC/compression
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
Re: AWS and IDRC/compression
For quite a while, I tried to talk with my MFaaS provider about using .aws files as a transportable, potentially readable on Windows read-only archive. I know that some Virtual Tape Appliances use this format. After several months of confusion with the bookstore, there was some understanding, but no viable proposals. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tony Thigpen > Sent: Friday, July 29, 2022 6:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: AWS and IDRC/compression > > [EXTERNAL EMAIL] > > 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 -- 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
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
Re: DLMSCR - EDGJRPTE
DFSMSrmm/DLm guy here says:
The RMM scratch report that comes out of the housekeeping job RMMHSKP is when
needs to be sent to DLMSCR. Or if you choose another way to produce the report
it needs to match exactly. Below is the JCL EXEC card used to produce the
report.
//SCRATCHL EXEC PGM=EDGRPTD,
// PARM='SEC(''DAILY SCRATCH''),DATEFORM(I)'
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter
Sent: Friday, July 29, 2022 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DLMSCR - EDGJRPTE
CAUTION: This email originated from outside of the Texas Comptroller's email
system.
DO NOT click links or open attachments unless you expect them from the sender
and know the content is safe.
Hello
I am trying to run a DLM scratch job using EDGJRPTE output but unfortunately
DLMSCR is not able to recognize the header of the RPTE.
Is there any kind of tweak needs to be done in EDGRRPTE exec so that DLMSCR
understand the format ?
Could someone please help me with this?
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DLMSCR - EDGJRPTE
Hello I am trying to run a DLM scratch job using EDGJRPTE output but unfortunately DLMSCR is not able to recognize the header of the RPTE. Is there any kind of tweak needs to be done in EDGRRPTE exec so that DLMSCR understand the format ? Could someone please help me with this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe outage affecting W.Va. state agencies could take 48, 72 hours to resolve Inbox
One thing that impresses me about working at AWS is that they take the blameless RCA seriously. One of the things about the document (at Amazon, *everything* is a document) is that it is explicitly forbidden to mention anyone's name, and even trying is a serious CLM. The goal is to understand how things happened and put mechanisms in place to ensure they don't happen the same way next time, not to nail someone's hide to the wall. On Fri, Jul 29, 2022 at 12:18 PM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 7/29/22 8:48 AM, Bob Bridges wrote: > > Some of my favorite military authors talk about the dreaded post-battle > > analysis, in which a board sits on the officers involved and asks > > lots of penetrating questions: Why did you make that choice? > > If the enemy had done this, what would have been your options? > > Did you receive intelligence notification SR-45T, dated such-and-such, > > about the enemy's new tech, and did you take that into account when > > you arranged your forces? > > I remember the some time in the last 5-10 years hearing the "Blameless > RCA" phrase and liking it. Then people went and spoiled it. > > My intention behind blameless RCAs is to understand what people did, why > they did it. Sort of like trying to glean insight into their brain's L1 > cache at the time during the incident. -- There was /some/ amount of > sanity checking of the data / algorithms people applied. -- But I > always wanted to understand their state and how altering the state next > time might change things. > > In some ways, it's like the Flight Data Recorder. The FDR in and of > itself doesn't place blame. It may well show that the pilot did > something in error. It may also exonerate the pilot if there was a > mechanical malfunction or external influence. > > Sometimes the outcome of such an investigation will be training. > Sometimes the outcome of such an investigation will be a process change. > Sometimes the outcome of such an investigation will be new safety > guards so that someone doesn't stick their hand in front of a moving knife. > > > I understand why it feels to the victims as if the purpose is to > > spread blame around. > > In my (not so) humble opinion, if the person being asked the questions > feels like they are being blamed, then the person asking the questions > is doing it wrong. > > > But this is the time to look at everything that happened and see > > what should have been done differently. It's a great time to answer > > honestly "in the press of the moment, I never thought of that option", > > and "our logs show that we received that communication, but I don't > > recall it". > > #truth > > > Blame, shmame; the board presumably knows what happens in "the > > press of the moment", and this is my best opportunity to improve > > my decision-making. > > Sometimes it's best to mute a low priority alarm so that people can > focus on higher priority alarms. ;-) > > > (Which sounds heroically rational, but I still get all defensive > > during coding reviews.) > > I think there is some room for improvement in how people ask questions > during code reviews. E.g. "Please help me understand what you are doing > here and why you are doing it that way?" As if a student asking a > teacher a question. > > Conversely, the ""teacher needs to be both receptive and open minded to > such questions from the ""student. > > > > -- > Grant. . . . > unix || die > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe outage affecting W.Va. state agencies could take 48, 72 hours to resolve Inbox
On 7/29/22 8:48 AM, Bob Bridges wrote: Some of my favorite military authors talk about the dreaded post-battle analysis, in which a board sits on the officers involved and asks lots of penetrating questions: Why did you make that choice? If the enemy had done this, what would have been your options? Did you receive intelligence notification SR-45T, dated such-and-such, about the enemy's new tech, and did you take that into account when you arranged your forces? I remember the some time in the last 5-10 years hearing the "Blameless RCA" phrase and liking it. Then people went and spoiled it. My intention behind blameless RCAs is to understand what people did, why they did it. Sort of like trying to glean insight into their brain's L1 cache at the time during the incident. -- There was /some/ amount of sanity checking of the data / algorithms people applied. -- But I always wanted to understand their state and how altering the state next time might change things. In some ways, it's like the Flight Data Recorder. The FDR in and of itself doesn't place blame. It may well show that the pilot did something in error. It may also exonerate the pilot if there was a mechanical malfunction or external influence. Sometimes the outcome of such an investigation will be training. Sometimes the outcome of such an investigation will be a process change. Sometimes the outcome of such an investigation will be new safety guards so that someone doesn't stick their hand in front of a moving knife. I understand why it feels to the victims as if the purpose is to spread blame around. In my (not so) humble opinion, if the person being asked the questions feels like they are being blamed, then the person asking the questions is doing it wrong. But this is the time to look at everything that happened and see what should have been done differently. It's a great time to answer honestly "in the press of the moment, I never thought of that option", and "our logs show that we received that communication, but I don't recall it". #truth Blame, shmame; the board presumably knows what happens in "the press of the moment", and this is my best opportunity to improve my decision-making. Sometimes it's best to mute a low priority alarm so that people can focus on higher priority alarms. ;-) (Which sounds heroically rational, but I still get all defensive during coding reviews.) I think there is some room for improvement in how people ask questions during code reviews. E.g. "Please help me understand what you are doing here and why you are doing it that way?" As if a student asking a teacher a question. Conversely, the ""teacher needs to be both receptive and open minded to such questions from the ""student. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Got anomalies? Tell us more!
Take our 2-minute survey to share what you need to get ahead of a system outage. We'd like to improve your experience with managing system outages. Link to survey: https://www.surveygizmo.com/s3/6962389/Got-anomalies-Tell-us-more We'd appreciate your response by August 8, 2022. Thanks in advance for your participation! Regards, Doris Amouzou -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe outage affecting W.Va. state agencies could take 48, 72 hours to resolve Inbox
I never got upset when someone found a problem in my code, but I did get irritated when my boss didn't read it because he trusted me. "Even Jove nods." From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Friday, July 29, 2022 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe outage affecting W.Va. state agencies could take 48, 72 hours to resolve Inbox Some of my favorite military authors talk about the dreaded post-battle analysis, in which a board sits on the officers involved and asks lots of penetrating questions: Why did you make that choice? If the enemy had done this, what would have been your options? Did you receive intelligence notification SR-45T, dated such-and-such, about the enemy's new tech, and did you take that into account when you arranged your forces? I understand why it feels to the victims as if the purpose is to spread blame around. But this is the time to look at everything that happened and see what should have been done differently. It's a great time to answer honestly "in the press of the moment, I never thought of that option", and "our logs show that we received that communication, but I don't recall it". Blame, shmame; the board presumably knows what happens in "the press of the moment", and this is my best opportunity to improve my decision-making. (Which sounds heroically rational, but I still get all defensive during coding reviews.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* How bad is our traffic mess?Gridlock is so bad that as many as 15 percent of women drivers now pass the time by picking their noses. (The figure for men remains steady at 100 percent.) -Dave Barry, 2004-10-17 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Friday, July 29, 2022 01:19 This is exactly why I *LOVED* the extra time at the end of the coordinated D.R. Test window. We had extra hardware, we had copies of our systems (if we did our job correctly) and no threat of an outage. I thought it was *GREAT* that we could test things /after/ the D.R. Test results were declared but before people went home. Lots of learning and experiments happened in those 36-48 hours. --- On 7/28/22 3:22 PM, Bob Bridges wrote: > Belated comment: I got a couple of laughs out of this post originally, > but it might be well to realize that these stories are not of failures. > This is why we do DR tests. It'd be a failure if you have an actual D > and found you couldn't R. > > So we try it out ahead of time, discover what we don't know, and > repeat as necessary. That discovery is success, not failure. -- 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: REMOVE
beep boop beep boop (so listserv doesn't reject my post thinking I'm sending a command) "* To unsubscribe from the list: ibm-main-signoff-requ...@listserv.ua.edu" > --- Original Message --- > On Friday, July 29th, 2022 at 8:51 PM, joe.dechir...@csi-international.com > wrote: > > > > > Please remove me from your mailing list > > > > Michael DeChirico > > > > -- > > 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
REMOVE
Please remove me from your mailing list Michael DeChirico -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name
Yes, it is the SDFHMAC library. Our local CICS sysprogs established a set of DSN alias names with HLQ's CICS.BASE and CICS.NEXT to point to the current and next-release CICS-shipped libraries. I believe we are on CICS TS V5.4 and transitioning to V5.6. The local person responsible for the library setup is on jury duty at the moment so I am waiting for that person to be available again to resolve the issue. In the meantime our SCLM team made a temporary change to put SYS1.MACLIB ahead of the CICS.BASE.MACLIB library for the one application team that needed it so they could complete their work in a timely manner. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Friday, July 29, 2022 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name EXTERNAL EMAIL Which CICS release is being referred to? And what is the "current product version library" data set? CICS V5.2, 5.3, 5.4, 5.5, 6.0, 6.1, for example, do not appear to ship an IDENTIFY macro. I might have been looking in the wrong data set, though. I was looking at the install data set that ended with SDFHMAC. Peter Relson z/OS Core Technology Design -- 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: Mainframe outage affecting W.Va. state agencies could take 48, 72 hours to resolve Inbox
Some of my favorite military authors talk about the dreaded post-battle analysis, in which a board sits on the officers involved and asks lots of penetrating questions: Why did you make that choice? If the enemy had done this, what would have been your options? Did you receive intelligence notification SR-45T, dated such-and-such, about the enemy's new tech, and did you take that into account when you arranged your forces? I understand why it feels to the victims as if the purpose is to spread blame around. But this is the time to look at everything that happened and see what should have been done differently. It's a great time to answer honestly "in the press of the moment, I never thought of that option", and "our logs show that we received that communication, but I don't recall it". Blame, shmame; the board presumably knows what happens in "the press of the moment", and this is my best opportunity to improve my decision-making. (Which sounds heroically rational, but I still get all defensive during coding reviews.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* How bad is our traffic mess?Gridlock is so bad that as many as 15 percent of women drivers now pass the time by picking their noses. (The figure for men remains steady at 100 percent.) -Dave Barry, 2004-10-17 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Friday, July 29, 2022 01:19 This is exactly why I *LOVED* the extra time at the end of the coordinated D.R. Test window. We had extra hardware, we had copies of our systems (if we did our job correctly) and no threat of an outage. I thought it was *GREAT* that we could test things /after/ the D.R. Test results were declared but before people went home. Lots of learning and experiments happened in those 36-48 hours. --- On 7/28/22 3:22 PM, Bob Bridges wrote: > Belated comment: I got a couple of laughs out of this post originally, > but it might be well to realize that these stories are not of failures. > This is why we do DR tests. It'd be a failure if you have an actual D > and found you couldn't R. > > So we try it out ahead of time, discover what we don't know, and > repeat as necessary. That discovery is success, not failure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name
Which CICS release is being referred to? And what is the "current product version library" data set? CICS V5.2, 5.3, 5.4, 5.5, 6.0, 6.1, for example, do not appear to ship an IDENTIFY macro. I might have been looking in the wrong data set, though. I was looking at the install data set that ended with SDFHMAC. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
finding old cataloged tape datasets
Since there has been talk about finding uncataloged datasets, how about this. I have lots of old cataloged tape datasets on my systems. We just switched to DFRMM and found this when trying to run the CATSYNC process. What would be a way to find these and uncatalog them. None of them match the current volser range in use in RMM. Thanks Richard Oracle Cerner Richard McIntosh Lead Technical Architect, Foundation Solutions Office: +1.610.219.8082 CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
virtual Tape consumption statistics - DFRMM
Hello, Is there a sample JCL to list the top consumers of Virtual tape allocation or any smf record which can tell about the virtual tapes highest consumption based on the Jobs. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lead z/OS Systems Programmer posting
My company has a Lead z/OS Systems Programmer position just posted. Please apply if you are interested: https://usaa.wd1.myworkdayjobs.com/USAAJOBSWD/job/San-Antonio-TX---San-Antonio-Home-Office-I/z-OS-Systems-Programmer-Infrastructure-Engineer-Lead_R0081656-1 USAA has provided many amazing opportunities for me over many years. If you are looking for something new at a member-focused company, please consider applying. -- 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
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
AWS and IDRC/compression
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
