How is ISPF packed data compressed? Is it simple run length encoding? Couldn't some clever soul write some sort of generalized un-PACK command or utility program that could somehow front-end other commands? Use pipes or a behind-the-scenes temporary dataset or ... ?
Yeah, I know, wrong place in the stack. I'm not a DFSMS guy. What does PACK do for you that dataset compression does not? Do we really need ISPF-level compression when we have system-level compression? Hmmm. Am I reading this right? Compressed implies extended-format and PDSE does not support extended-format? That's ... um, unfortunate. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, February 15, 2018 5:02 PM To: [email protected] Subject: Re: J line command was: TSO temp dataset On Fri, 16 Feb 2018 00:32:53 +0000, Jesse 1 Robinson wrote: >Nice catch! I never considered the effect of PACK. The reason why ISPF >allocates and copies to a separate data set is that the JCL on the screen does >not necessarily match the current physical content on disk. The JCL may not >have been saved yet (or ever), or !aha! it may be PACKed on disk. TSO SUBMIT >and apparently the J command read the disk copy directly to the internal >reader, so PACKed records are just garbage. I do not PACK my data, so J worked >fine for me. > How modular is the un-PACK code? Wouldn't it be reasonable for J to recognize PACKed data as other functions do (how?) and un-PACK it on-the-fly while passing it to INTRDR? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
