Re: GO TO "cobol"
The equivalent Marine rank (E-3) is Lance Corporal. The Marines do use the
rank of Private First Class, but it is one grade lower, the equivalent of an
Army Private (E-2).
And, with a nod to Shmuel ("Give me back my Air Force") , the Air Force
equivalent is A1C (Airman First Class), which may be confusing to people
diagnosed with diabetes. :-)
Bob
--
On Tuesday, April 17, 2012 05:10:36 AM you wrote:
> PFC = Private First Class. An Army rank. The Marines may also use it.
>
>
> Lloyd
>
>
> - Original Message
> From: Paul Gilmartin
> To: IBM-MAIN@bama.ua.edu
> Sent: Mon, April 16, 2012 7:27:30 PM
> Subject: Re: GO TO "cobol"
>
> On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
> >You could have the exact same result by placing a period
> >after the "2000-exit". Then the End-if is not needed.
> >
> >
>
> I sure am glad that COBOL attained its design objective
> of being intelligible (intuitively? unambiguously?) to a
> PFC-level programmer with only an understanding of
> vernacular English.
>
> (Is "PFC" a Navy rank?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Terminology
On Saturday, December 03, 2011 at 02:22 am Dale Miller wrote: > I hope, since this is not about "USS", that I won't be moderated on > this. I wish to reply to a question John McKown raised on 18 Nov > :"And what is the proper word for the PL/1 "not" sign' ? (x'00AC' in > Unicode). It is a standard operator in formal mathematical language, > AFAIK almost universally used to indicate logical negation in an > expression, and normally called the "negation symbol", but > informally called the "not sign". Users of x3270 tend to call it a "CircumNot" (I'm not sure whether Paul Mattes coined the term, or one of the earlier x3270 maintainers). Other old 3270 users just call it "Shift-6" (but don't try that on your PC keyboard). Bob Woodside -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Darren's approval
On Thursday 16 December 2010 07:52, Shmuel Metz (Seymour J.) wrote: > In > <77142d37c0c3c34da0d7b1da7d7ca3430880b...@nwt-s-mbx2.rocketsoftware.c >om>, on 12/15/2010 > >at 10:16 PM, Bill Fairchild said: > >Perhaps Shmuel was punning? > > I never pun[1]. That's my story and I'm sticking to it. > > [1] Especially in comments Aww I just hope nobody feels that we're causing this thread to grow too overly tortuous (OT). :-) Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Darren's approval
On Monday 13 December 2010 19:01, Shmuel Metz (Seymour J.) wrote: > If your response would have been tortuous when sent privately, why > would it be safe to post it publicly? s/tortuous/tortious/ Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
On Friday 05 November 2010 16:46, Shmuel Metz (Seymour J.) wrote: > In , > on 11/05/2010 > >at 09:46 AM, "Roach, Dennis (N-GHG)" said: > > >Try the TSO EDIT command from ready some time. > > I have. > > >Make you like vi. > > No. Yes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What data area contains number of CPU running on a processor
On Saturday 09 October 2010 03:11, Gerhard Postpischil wrote: > On 10/6/2010 11:06 AM, Bill Fairchild wrote: > > When I was very young, sometimes during dinner my mom or dad > > would use a word that I didn't understand. When I would ask > > what it meant, my dad would invariably say "You know how to > > spell. You know how to read. Look it up in the dictionary > > or encyclopedia." I always did just that, and today I am > > still an insatiable knowledge junkie. > > Which begs the question of how you found knowledge or > psychology, among others. s/begs/raises/ perhaps? Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: auditor request question
On Wednesday 11 August 2010 19:58, Rick Fochtman wrote: > --- >--- > > >> <>This has been an interesting thread. It seems we all really > >> ENJOY auditors... Can someone say prostate exam? > >> > >> Isn't that essentially a different kind of audit ??? > > - >--- Yes it is, but I'm not sure which one is more of an insult > to a man's basic dignity. :-) Having been through the full course of the medical variety - PSA, digital, biopsy (I flunked), radiation, and semi-annual exams thereafter...I vote for the auditors that triggered this thread as the greater affront. :-) Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C-I-C-S vs KICKS
On Monday 02 August 2010 20:30, Joel C. Ewing wrote: > Try as I might, I have been totally unsuccessful in breaking our > console Operators (whose familiarity with EXCP is limited to SDSF > displays) from the habit of erroneously referring to it as an > "exception" count. "exec pee" would be an improvement. Golly! Plus ça change, plus c'est la même chose, indeed! I was trying to break operators of saying that back in the early '70's, when I was one of them. Cheers, Bob > JC Ewing > > On 08/02/2010 03:49 PM, J R wrote: > > Back in the '60s, a new recruit to our group introduced himself by > > claiming that he was already familiar with EXEC-P (exec pee). It > > was a while before we all realized he was talking about EXCP (ee ex > > cee pee). Of course, it also turned out that he wasn't as familiar > > with it as he claimed. > > > >> Date: Mon, 2 Aug 2010 14:27:13 -0600 > >> From: howard.bra...@cusys.edu > >> Subject: Re: C-I-C-S vs KICKS > >> To: IBM-MAIN@bama.ua.edu > >> > >> There are hybrids - for instance pronouncing DASD as Das-Dee. > > ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C-I-C-S vs KICKS
On Monday 26 July 2010 14:25, Bill Fairchild wrote: > Then there are the FIFO, LIFO, WINO (Whenver In, Never Out), and other > queueing algorithms Not to overlook FIST (First In, Still There), commonly used in the Windows environment, I believe Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS -> KICKS (Re: PROP instead of POPS, PoO, et al.)
On Monday 26 July 2010 11:23, R.S. wrote: > Bill Fairchild pisze: > > > > The Russian name, when transliterated into English, is Kaliningrad, > > and the German name means King's Mountain. > > Just to complement this off-topic thread: OT, yes, but entertaining. > Kaliningrad can be > translated as City of Kalinin. Kalinin was Russian communist, > Stalin's co-worker. Polish name was Królewiec or Królówgród, which is > PARTIALLY similar to Koenigsberg (Król = Koenig = King) > (Gród=town/city=Burg <> Berg). So German equivalent name should be > (but it's NOT) KoeningsBURG. Actually, I believe the German name was a translation of the Latin name, Regiomontium. > BTW: Immanuel Kant lived there. And he most likely called it Königsberg. Which leads me to wonder what was the etymology of the town's name in Old Prussian (which died out shortly before Kant's time). I find mention of 2 names, Twānkstathe and Kunnegsgarbs. The latter I take to be a variant of the King's Thing names, but I've no clue about the former. Of course, my knowledge of Baltic languages is even scarcer than my knowledge of Polish (non-existent) and Russian (nearly so). Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS -> KICKS (Re: PROP instead of POPS, PoO, et al.)
On Monday 26 July 2010 10:17, Bill Fairchild wrote: > Bob, > > You left out the other "in" syllable in "Kaliningrad". Finger check in the banana problem algorithm. I probably should have just written "Königsberg". Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS -> KICKS (Re: PROP instead of POPS, PoO, et al.)
On Monday 26 July 2010 11:28, Peter Nuttall wrote: > My German might be a bit rusty, but isn't Burg - Castle and Berg - > Mountain ? Ganz richtig. Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS -> KICKS (Re: PROP instead of POPS, PoO, et al.)
On Saturday 24 July 2010 09:40, R.S. wrote: > BTW: KICKS in polish is jargon name for futball shot that horribly > misses the target (or squint). Well, I have heard a couple of criticisms of CICS that weren't too far removed. Not from me, mind you. > BTW2: We have no problem to pronounce Szczebrzeszyn or Chrzczonowice, > but we very hardly distinguish differences in 'bitch', 'beach' and > 'beech'. Or 'witch' and 'which'. That sometimes leads to funny > stories. I'm trying to imagine a Monty Python style sketch involving a pair of Indo-European specialists, one English and the other Polish, debating the philological significance of the famous, um, "bitch line" running from Kalingrad (or Królewiec, if you prefer) to Odessa. (And yes, my hovercraft is full of eels.) Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS -> KICKS (Re: PROP instead of POPS, PoO, et al.)
On Friday 23 July 2010 11:52, zMan wrote: > It's always appeared to me to be: > Americans: see-eye-see-ess > Others: kicks I think you might occasionally hear "cheeks" in Italy. :-) Among Americans, I think it depends on how much contact the staff of a particular shop have with European users of Cumbersome Initials Connoting Something. In particular those who've had contact with the CICS development team at Hursley Park seem most likely to adopt - and spread - the UK pronunciation. Most of the people I've worked with over the past 30 years in the Northeast have said "kicks", but that's been in IBM or in an ISV with strong UK ties. I used to hear see-eye-see-ess in Houston ages ago. But as others have pointed out, the phenomenon seems to defy regionalization within the US. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PROP instead of POPS, PoO, et al.
On Friday 23 July 2010 01:18, Ted MacNEIL wrote: > >Shouldn't that have been Start Subchannel??? > > This errant pedantry up with I shall not put! s/errant/arrant/ But I think we could suspend this rule in the case of a knight arrant. :-) Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE calling assembler with 64 bit register usage
On Friday 23 July 2010 00:17, Phil Smith III wrote: > > Do not anger the LE, for its wrath is not pretty! I think that's "Do not meddle in the affairs of the LE, for it is subtle and quick to anger." Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disk replacing Tape?
On Monday 21 June 2010, McKown, John wrote: > > Long term data should be enscribed on granite and stored in the > Egyptian desert. This is proven technology! > My goodness, is it Friday already? -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BMC reveals 'free money' mainframe and DB2 tools
On Tuesday 01 June 2010, Jan MOEYERSONS wrote: > On Mon, 24 May 2010 18:45:49 +, Bill Fairchild > > wrote: > monitoring and DB2 database tools so they could run in what is called > System Resource Block (SRB) mode so the workload manager in the z/OS > operating system could dispatch the code to the System z Integrated > Information Processor, or zIIP." > > > I can't find the phrase "System Resource Block" in that article... > The article appears to have been redacted sometime in the past week. (Do the folks at The Register follow this mailing list?) -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
On Wednesday 05 May 2010, Paul Gilmartin wrote: > On Tue, 4 May 2010 23:18:14 -0500, Bob Wood wrote: > >Filezilla os OK as long as you don't > > have a need to transfer files to USS, which it does not handle > > well. > > I'm mystified. I use Filezilla server for SMP/E RECEIVE FROMNETWORK, > which transfers to Unix files, quite successfully. What are the > problems? Or are you thinking of Filezilla client, with which I > have no experience. I regularly use the FileZilla client on Windows, Linux, and Solaris workstations to connect to both the MVS and Unix sides of z/OS with no problem. However, there are a couple of caveats: You need an up to date version - older versions of the FileZilla indeed didn't understand the Unix side of z/OS. The oldest version I can find on any of my workstations id 3.0.1, which works fine. You need to specify the server type as Unix under the Advanced tab to access you Unix filesystem. -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: XMIT Manager
On Thursday 18 March 2010, Shane Ginnane wrote: > Oh joy - Virtual PC. Last I looked at it, it was the worst of the > virtualizers available - by a long shot. And (of course) this is only > available on the "premium" Win7 versions. I think you can import Virtual PC images into either VMware or VirtualBox. I've never tried it, though. -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPARs: More or Less?
On Monday 08 March 2010, Stephen Y Odo wrote: > I've been trying to get Linux onto our z890 (even have CENTOS running > in an LPAR as a proof-of-concept) What version of CentOS, and where did you find an installation image? I looked around for one a year or so ago, but couldn't find one that wasn't years out of date. iirc, the CentOS folks used to maintain regular builds for 390/System z, but seem to have stopped some time ago. I guess there aren't any mainframers active in the CentOS project anymore. (Sad to say, that sort of thing is symptomatic of moribundity in a platform.) > but our management has decreed that all future development will be > Solaris/SPARC or Linux/Intel. Why no Solaris/Intel option? -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
On Saturday 06 March 2010, Scott T. Harder wrote: > Incredibly BAD idea. It cannot be understated what a BAD idea this > is. s/understated/overstated/ There. Fixed that for you. I'm with Ted, in that I'll withhold any further comment until we see an authoritative word from someone within IBM; but if true it bodes no good for anyone. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The ISPF people must be laughing their heads off
On Friday 05 March 2010, Ed Gould wrote: > Microsoft: Don't press F1 key in Windows XP > > http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_ >F1_key_in_Windows_XP > More chuckles from the Slashdot crowd: http://tech.slashdot.org/story/10/03/02/1924237/Microsoft-Says-Dont-Press-the-F1-Key-In-XP -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help finding error code definition REXX SYSCALL
On Friday 05 February 2010, McKown, John wrote:
> > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Veilleux, Jon L
> > Sent: Friday, February 05, 2010 7:23 AM
> >
> > Also you must be a superuser or issue "seteuid 0" when issuing
> > chown.
> >
>
> Or define CHOWN.UNRESTRICTED in the UNIXPRIV class.
>
>
> To allow all z/OS UNIX users to transfer ownership of files they own
> to any UID or GID on the system, create a discrete profile in the
> UNIXPRIV class called CHOWN.UNRESTRICTED. If this profile is defined
> on your system, all z/OS UNIX users can issue the chown command to
> transfer ownership of files that they own.
>
But please don't do it! :-)
(Same goes for the Solaris boot parm that has the same effect.)
--
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 (and COBOL 4.2) new features summary
On Wednesday 16 September 2009, Guy Gardoit wrote: > Nice to see that z/OS has caught up with z/VM!! Hmm, let's see now...we've been able to do that in VM for *how many* decades? :-) > On Wed, Sep 9, 2009 at 5:44 AM, Steve Comstock wrote: > > ..snip > > _TSO, CLIST, REXX, ISPF/Dialog Manager:_ > > > > * TSO: with LOGONHERE support, you can logon / reconnect > > even if there has not been a disconnect; this allows > > you to reconnect from one workstation while you are > > still logged on to a different workstation; basically, > > your session follows you! This is now the default > > behavior. [Have not yet tested this] > > Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USS misuse
On Thursday 06 August 2009, Barbara Nitz wrote: > > The hints about developers being busy with other stuff and/or laid > off make me think that IBM has stripped itself also in this area of > the necessary manpower, a story I heard quite often in the last > months! I'm afraid you're probably right. Google a bit on "ibm india software labs". I get the impression that they've shipped most - or at least a lot - of z/OS "expertise" to Bangalore and other picturesque subcontinent spots. I've no idea how many stateside people took IBM up on their draconian offer to "take a salary cut and move to India or hit the road", and how many z/OS development and support personnel are rank newbies/amateurs. But this really concerns me about the future of z/OS. I'd really like it if someone could allay my fears, but I'm not too hopeful. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hercules; more information requested.
On Monday 03 August 2009, P S wrote:
> On Mon, Aug 3, 2009 at 11:37 AM, Bill Fairchild
wrote:
> > Not trying to be pendantic, but I think the word is "pedant". :-)
>
> True, but pe(n)dants are used to being hung...
[ groan! ]
--
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation?
On Thursday 30 July 2009, W. Kevin Kelley wrote: > I think we supported 3370 but not 3375 (which I think was the FBA > device). The 3370 was the FBA device. I remember working on access method support for the 3310 & 3370 back in the early 1980's. -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 27 July 2009, Vikesh Bhoola wrote: > Thanks for your reply. > > > On Friday 24 July 2009, Bob Woodside wrote: > > Does the cmsmvs version fail like this if you execute it under > z/Unix? > > Tried that and it does not fail with an error : > > > Or does it just fail when you run it via the MVS JCL? > > Yes, it looks to just fail when run via MVS JCL. This is very strange. I have no idea at the moment why the Zip64 fix to cmsmvs.c would not have corrected this - but only when the program is run via MVS JCL. At least you can get around this temporarily with the -fz option. It will take me a while to set up an environment where I can test this. I'm also trying to figure out which problem to attack first with my limited resources - this one, or the problem with filename handling between zip and unzip. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USS misuse
On Wednesday 29 July 2009, R.S. wrote: > Is it so hard to understand that acronym/abbreviation is not a thing > that IBM or other company could establish? Or any grammar Nazi wanna-be. > This is simply part of language we use > > Like SMS: for us it's Storage Management Subsystem, but Windows > people know other meaning and we all us SMS in our mobile phones (not > to mention Novell SMS). None of these acronyms had to be formally > accpepted by any company or agency. > > In most cases the meaning of acronym is obvious from the context, for > exceptions it is perfectly OK to make disambiguation at the beginning > - like "Unix System Services (USS)" or simply avoid acrynyms at all. > And voila. No holy war is needed. Amen. Let's take another example: DSN. Any serious mail administrator *knows* that it stands for Delivery Status Notification - end of discussion - although most of the world's database administrators mistakenly believe that it stands for Data Source Name (ODBC). And both look on the meaning of "Data Set Name" as an amusing atavism, if they've ever heard of it at all. As one whose academic background was in linguistics before stumbling into the field of computers, I have to reiterate David Alcock's dictum: > Languages evolve. Thou shalt evolve too. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 24 July 2009, Vikesh Bhoola wrote: > > On Friday 24 July 2009, Bob Woodside wrote: > >I don't see how zip can be failing now. Everything seems to be > > defined correctly. > > This is an odd one. > > Has anyone else verified the zip patches (cmsmvs version) applied > results in the same message when zipping files over 4GB : > > " zip error: Entry too big to split, read, or write (Poor compression > resulted in unexpectedly large entry - try -fz)" > > or does it work ? Does the cmsmvs version fail like this if you execute it under z/Unix? In other words, by running the version you get in zip31b/mvs when you build in cmsmvs with "gmake -f mvs.mki hfs". Or does it just fail when you run it via the MVS JCL? Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 22 July 2009, Vikesh Bhoola wrote: > On Wednesday 22 July 2009, Bob Woodside wrote: > >Try this. Edit the file zip.c. > [snip] > Thanks for your assistance, done the above & I get the following : > [snip] > Zip special compilation options: > * size of int: 4 > * size of long:4 > * size of long long: 8 > * size of off_t: 8 > __LF is defined. >off_t must be defined as a long long > SYMLINK_SUPPORT (symbolic links supported) > LARGE_FILE_SUPPORT (default settings) > ZIP64_SUPPORT(use Zip64 to store large files in I don't see how zip can be failing now. Everything seems to be defined correctly. I uploaded a fixed patch for unzip to the the Info-ZIP forum this evening. It should not fail now. However, I think it still needs some work to get the MVS filename handling in sync with the changes that Lutz made to zip. I'm hoping we can get him to give us a hand there, but I haven't heard anything from him lately. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 22 July 2009, Vikesh Bhoola wrote: > Bob, thanks for the info on the patches. I have re-done this and did > not get any prompts or rejects this time round. Uploaded the file to > z/OS & it compiled successfully. I verified the patches are in, but > still get the error for zipping a file over 4GB : > > > zip warning: Entry too big:HLQ.FOURGIG.Q123.DNR2007R > > zip error: Entry too big to split, read, or write (Poor compression > resulted in unexpectedly large entry - try -fz) I have no idea what's wrong. Unfortunately, I won't be able to test anything till tonight at the earliest. Try this. Edit the file zip.c. At line 1219 you'll see # if 0 Change that to # if 1 and rebuild zip. Then run "zip -v" and let me know what zip reports. In particular, we want to see the following: Zip special compilation options: * size of int: 4 * size of long:4 * size of long long: 8 * size of off_t: 8 __LF is defined. off_t must be defined as a long long If you see anything else, we have a real problem. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downloading large datasets to PC is that Mainframe any Performance issue ?????
On Wednesday 22 July 2009, Klein, Kenneth wrote: > ftp put from the mainframe would be faster than ftp get from the pc. Of course, this implies that he would have an ftp server running on the PC. (Why would this be faster, by the way?) > > I am downloading it through FTP... normally i download from the PCOM > > itself... That's good. The TN3270 file transfer protocol is about the slowest thing going. I wouldn't ever use it for a very large file. Just how large is the dataset? A lot depends on what ftp client you're using on the PC - some are more efficient than others. (I use FileZilla on either Unix or Windoze workstations.) System performance shouldn't take too big a hit from this. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 21 July 2009, Bob Woodside wrote: > and extracted zip31-try04.zip... s/zip31-try04.zip/zip31-try04.diff/g ...but you knew that. :-) > Cheers, > Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 21 July 2009, Vikesh Bhoola wrote: > On Tuesday 21 July 2009, Bob Woodside wrote: > >I don't understand why there would be a boundary condition at > > 7GB. 4GB, yes, but not 7GB. Have you tried zipping a file that is > > just a little larger than 4 GB? > > Sorry about that - Yes, you are right, problem is the 4GB boundary. I > had to create me a file of over 4GB and tried is and it too failed > with > > > zip error: Entry too big to split, read, or write (Poor compression > resulted in unexpectedly large entry - try -fz) Whew! That's a relief! At least we can figure that one out. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 20 July 2009, Vikesh Bhoola wrote: > Bob, > ZIP was run this weekend against some large files, using the cmsmvs > version ZIP module. >[snip] > Now, I'm not sure if the apply of the patches in the diff file was > correct as you mentioned this issue was resolved. Also I had made the > changes manually (and using the patch command). > > Do you perhaps have the correct GNU patch command to apply the fix > automatically? > I've tried : > patch -u -p1 < zip31-try04.diff > > and I get some rejects as a result. I applied the patch, on a Linux system, as follows: 1) Downloaded the latest version from the zip forum (diff_8942.zip) and extracted zip31-try04.zip into a temporary directory (/tmp, actually). 2) Copied a freshly unzipped zip31b directory into the temp dir under the name of orig. 3) Ran patch as follows: > my...@myhost:/tmp$ patch -d orig -p1 patching file CHANGES > patching file README.zOS > patching file cmsmvs/cmsmvs.c > patching file cmsmvs/cmsmvs.h > patching file cmsmvs/mvs.mki > patching file fileio.c > patching file tailor.h > patching file unix/Makefile > patching file unix/configure > patching file unix/osdep.h > patching file zip.c > patching file zipfile.c > my...@myhost:/tmp$ No prompts and no rejects. Then, of course, the whole source tree needs to be uploaded to the mainframe and rebuilt. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 20 July 2009, Vikesh Bhoola wrote: > Bob, > ZIP was run this weekend against some large files, using the cmsmvs > version ZIP module. > > For zipping files over 7GB, I got the following error: See my other reply - 7GB makes no sense to me. > zip warning: Entry too big:HLQ.Q2.Q125.DN2008Q5 > zip error: Entry too big to split, read, or write (Poor compression > resulted in unexpectedly large entry - try -fz) > > As a work around I specified -fz, I see that specifying this worked > for you according to the Info-ZIP thread discussions, so specified it > and worked for a majority of the files to ZIP. > > Now, I'm not sure if the apply of the patches in the diff file was > correct as you mentioned this issue was resolved. Also I had made the > changes manually (and using the patch command). > > Do you perhaps have the correct GNU patch command to apply the fix > automatically? > I've tried : > patch -u -p1 < zip31-try04.diff > > and I get some rejects as a result. I'll have to try this with a downloaded copy of the patch and a fresh copy of the zip31b directory when I have a few free minutes. There should be no rejects - this suggests to me that something is out of sync. It seems like either the patch is defective, or there's some other maintenance in the directory that clashes with it. I'll let you know as soon as I find out what's going on here. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 21 July 2009, Vikesh Bhoola wrote: > > I don't require the MVS unzip (cmsmvs version) as urgently as I > required the zip function. Good, because I haven't had much time to look at this lately. :-( > For now your USS unzip patch works well (& fast as well) with Kirk's > CoZBATCH utility. I'm able to at least write to an MVS dataset, with > the zip file residing in USS. > > On the topic of ZIP (MVS/cmsmvs version): > > I've received feedback that all the zipped files using Info-ZIP were > readable by the application. Except the following two issues : > > 1. Only problem experienced was that mentioned in my previous note of > having to specify -fz option for zipping files > 7GB. I thought this > was resolved. I don't understand why there would be a boundary condition at 7GB. 4GB, yes, but not 7GB. Have you tried zipping a file that is just a little larger than 4 GB? If that works, then this is a complete mystery to me; if it does not work, then either the patch is defective or it wasn't applied completely. > 2. Also for zipping a 46GB file (with the -fz specified) I get the > following error : > zip I/O error: EDC5013I No hiperspace blocks are available for > expansion. > zip error: Output file write failure (write error on zip file) > > > I tried specifying MEMLIMIT=NOLIMIT in the JCL, but gives the same > error. > > It looks to be that we've reached our limit on hiperspace blocks > (Address space reaches 2GB when it ends with RC=14 and the above > mentioned error). Not sure where/how to specify more. Whew! Sorry, I can't help you on this one. I'm barely able to scrounge up enough resources to test a 4GB file. I can't even come close to a 46GB file. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 21 July 2009, Vikesh Bhoola wrote: > On the topic of bzip2 (as alternative to UNZIP MVS/cmsmvs version): > == > > On Friday 17 July 2009, Bob Woodside wrote: > >Vikesh -- > > Would a version of bzip2 help you out for the time being? I had > > just > > > >done a z/OS USS port of the latest version (1.0.5) earlier this > > week, before you reported the unzip problem. It supports large > > files, and appears to be working well. I think it might work for > > you in conjunction with Kirk's utilities. > > Bob, I've tested bzip2 version (1.0.4) which came with our latest > order of "IBM Ported Tools". > I've found it to be at least 4 time slower in comparison to Info-ZIP. > Not sure how bzip2 verion 1.0.5 compares to Info-ZIP? I would expect bzip2 to be slower, but maybe not this much. The Ported Tools version is probably not aggressively optimized. bzip2 is known to be fairly slow at compressing, and pretty fast at decompressing. My results with my build of bzip-1.0.5, compiled with max optimization, are: compression:about 2.5 times slower than zip decompression:about the same as unzip These tests were done using the -9 (max compression) option in bzip2, and the default compression level in zip - so there's a slight inconsistency. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, Chase, John wrote: > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Bob Woodside > > > > [ snip ] > > > > The old version of bzip2 that used to be available from IBM has > > been withdrawn; I don't know what version it was or whether it > > supported large files. There is now a "supported" version which you > > have to pay for, and looks to be heavily modified by IBM - mainly to > > provide IBM-style messages, as far as I can tell. I can't imaginw > > wanting such a beast, but that's the subject of a different thread! > > Well, bzip2 from IBM is now a part of the "Licensed Program Product" > called "IBM Ported Tools" or similar, but it's a "no-charge" product; > i.e., you do have to "license" it now, but it still doesn't cost any > money. Oops - I didn't read the IBM Ported Tools description closely enough, and missed the words "a non-priced program product". My apologies. I still think I'd rather have a straight build of the latest version (hmm, come to think of it, I guess I do now!), because: 1) I see small value in having a lot of IBM mods just to fit the messages into an IBM-style scheme. As always,YMMV. (I wouldn't have a problem with this if the mods were fed back to the bzip2 developers and became a part of the regular code base rather than being a separately maintained IBM fork. I like standardized message prefixes and good documentation as well as the next person. No, really.) 2) The Supplementary Toolkit version appears to be 1.0.4, which is documented to have a potential security vulnerability (CERT-FI 20469, corrected in 1.0.5). Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Offload work to zIIP with zPRIME
On Friday 17 July 2009, Steve Comstock wrote: > Eric Chevalier wrote: > > On 17 Jul 2009 06:30:15 -0700, > > > > ibm...@woodsway.com (Bob Woodside) wrote: > >>> For reference, > >>> http://dtsc.dfw.ibm.com/MVSDS/%27HTTPD2.PT217.HTML(INDEX)%27 > >> > >>This link appears borken. :-( > >borken? borken : adj : Standard Internet slang for "broken"; formed as an intentional tupo (or tyop). cf. the following entries in the Jargon File.: http://catb.org/jargon/html/B/borken.html http://catb.org/jargon/html/T/tyop.html > If I click on the link in Thunderbird, it switches to my > Firefox browser with this in the URI bar: > > http://dtsc.dfw.ibm.com/MVSDS/%20HTTPD2.PT217.HTML%20INDEX%20%20#7792 >310775959509782 > > which results in 404 Page not found!! Yup, 404 is the result I got, only mine was just truncated exactly like Eric's quoted below till I did the cut 'n paste thing. T-bird's transmogrification is a bit creative! (The pair of "%27" characters are apostrophes or single quotes, by the way.) > > That may be an issue with your news reader or e-mail client. I > > follow this mailing list via the newsgroup, using Forte Agent. > > Agent considers the end of the link to be the text ".HTML". > > However, in fact, the complete URL *includes* the trailing > > characters "(INDEX)%27". > > > > You may need to copy the complete link from the message and paste > > into your browser, rather than just trying to click on the link. I think that the number of different behaviors respondents have reported among various mail clients/newsreaders reinforces my opinion that this sort of url is truly lame. And it also strengthens my long-standing suspicion that most web developers must not really be web *users*. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, Kirk Wolf wrote: > I agree. bzip2 or gzip seem like much better choices than zip. > AFAIK, zip files have a "directory" at the end of the archive with a > pointer to the "end" at the very beginning. This might explain why > unzip is failing with pipes or special files. Well, yes and no. It fails with a regular zip file as input, even a small one. There's a bug somewhere in my code - it isn't picking up the length of the file correctly, hence it doesn't now how much to read to look for the directory signatures. Maybe this weekend I'll have time to track it down. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, McKown, John wrote: > > -Original Message- > > > The question is whether jar can support the Zip64 file > > format, and > > hence can support archives that can 1) be larger than 4 GB, and 2) > > contain individual files that are larger than 4 GB. > > > > As far as I know, Zip64 support is only available in the > > latest Sun beta of JDK7. Is my info not up to date? > > Well, this likely doesn't help. But on my Linux/Intel system, I > created a text file which was 4.7 Gb (5,033,145,276 bytes). I used > the jar command to create a .zip file which was 260Mb (272,331,844 > bytes) in size. I am running the "IcedTea" version of Java on my > Linux system, which is 1.6.0 . Good to know - guess my info *is* out of date. I'll have to try this out. > Unfortunately, I cannot test on z/OS as I just can't get that much > storage. I know the problem well. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, McKown, John wrote: > Why not use the jar command in z/UNIX? It is basically a zip/unzip > type program. That is, it will unzip a .zip file and will create a > .zip file as well as a .jar file. Actually, a .jar file __is__ a .zip > file. Just with "special" files inside it such as the manifest et al. > > And I am fairly sure that it can legally and morally be run on a > zAAP. The question is whether jar can support the Zip64 file format, and hence can support archives that can 1) be larger than 4 GB, and 2) contain individual files that are larger than 4 GB. As far as I know, Zip64 support is only available in the latest Sun beta of JDK7. Is my info not up to date? Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Offload work to zIIP with zPRIME
On Friday 17 July 2009, Ed Finnell wrote: > In a message dated 7/17/2009 8:01:44 A.M. Central Daylight Time, > > ibm-m...@tpg.com.au writes: > > http://dtsc.dfw.ibm.com/MVSDS/%27HTTPD2.PT217.HTML(INDEX)%27 > > Thanks for the attempt Alan, but I wonder how many of the unwashed > masses have access to that page. > > Haven't bathed today, but it popped right up. I've showered, but I still had to copy/paste the url into my browser to get it to work. My mail client (KMail) didn't feed the full string to the browser (Konqueror) when I just clicked on it. I do have to opine that it's a pretty lame sort of url. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, Kirk Wolf wrote: > Looks like unzip doesn't like your input data. I'll bet that if you > copy it to HFS it will also fail. Kirk -- Yes, it will. The problem is that my current patch is very badly borken [sic]. :-(. > What RECFM is the dataset? If it is RECFM=F*, maybe it has extra > bytes in the last record, in which case unzip probably won't like it. This version of MVS unzip just sings "...and I don't like anybody very much!" no matter what you feed it. I've tried it against a bunch of zip files, old and new, always with the same result as Vikesh gets. So far I've tracked it down to the fact that unzip isn't finding the file size correctly - everything goes downhill from there. Somewhere there is still an incompatible mix of 32-bit and 64-bit functions that I haven't located yet. Vikesh -- Would a version of bzip2 help you out for the time being? I had just done a z/OS USS port of the latest version (1.0.5) earlier this week, before you reported the unzip problem. It supports large files, and appears to be working well. I think it might work for you in conjunction with Kirk's utilities. The old version of bzip2 that used to be available from IBM has been withdrawn; I don't know what version it was or whether it supported large files. There is now a "supported" version which you have to pay for, and looks to be heavily modified by IBM - mainly to provide IBM-style messages, as far as I can tell. I can't imaginw wanting such a beast, but that's the subject of a different thread! I suggest this because I've no idea when I'll be able to fix the unzip patch. By the way, if you haven't done so, would you please post your problem to the Info-ZIP form as well? Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Offload work to zIIP with zPRIME
On Friday 17 July 2009, Alan Altmark wrote: > On Thu, 16 Jul 2009 16:48:09 -0400, Bob Shannon > > wrote: > >IBM provides an API to vendors to allow preemptible SRBs to be > > routed to zIIPs > > For reference, > http://dtsc.dfw.ibm.com/MVSDS/%27HTTPD2.PT217.HTML(INDEX)%27 This link appears borken. :-( -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Find the computer error
On Wednesday 15 July 2009, Roach, Dennis (N-GHG) wrote: > One too many digits for VISA. Account number + check digit? > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Hillock, Timothy > Sent: Wednesday, July 15, 2009 3:01 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Find the computer error > > Account number may have been used instead of the amount. Cheers, Bob Woodside -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 15 July 2009, Vikesh Bhoola wrote:
> Bob,
> Thanks, I've successfully managed to install UNZIP (cmsmvs version)
> made all the changes according to the provided diff file using gmake.
>
> However, cannot test this as I don't seem to have the correct UNZIP
> JCL syntax.
It's not the JCL - I can't say whether your JCL will work, but
there's something that's still not quite right in the code for the MVS
(cmsmvs) build of unzip.
You can get this same error (" End-of-central-directory signature
not found") running the MVS version from the Unix command line; but the
Unix build works just fine.
I'll let you know as soon I have time to figure out what the latest
problem is. I'm really sorry this is taking so long. Thanks for your
input.
> Does anyone perhaps have a working UNZIP JCL or even one that writes
> to OUTDD to allocate with correct DSORG=PS, LRECL, RECFM, etc.
>
I've never tried running unzip with MVS JCL (till today), and I
haven't looked into the code too carefully. So I don't really know how
it handles output file allocation under MVS - or whether unzip 6.0 is
compatible yet with the "dots" code in the zip 3.1b beta.
Cheers,
Bob
--
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 13 July 2009, Vikesh Bhoola wrote: > Bob, > I've made all the changes and the compiles goes through with no > issues using gmake. > The compile loops for some reason using "make -f mvs.mki" (but than > its documented to use "gmake") ;) Yes, I think the part of Lutz' patch that I left out was intended to make it work with the IBM make. > Ran some tests on files > 2GB and it worked wonderfully. Even got > good performance for the zip - for me, equal to that previously run > under USS which is most acceptable. Super! The USS and the MVS versions should be running about the same speed now, and both should be a little faster than the USS version was previously. I've set the optimization level to the max for both versions now. > Now need to run the data through a program to verify the data is > readable as cannot open such a huge files in Wordpad/Notepad. > > Once this is confirmed there will be no need for handling of filename > through stdin issue on the uss version either as the mvs version > works great! > I will do the same for unzip tomorrow and let you know. I'm looking forward to hearing your results. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 10 July 2009, Vikesh Bhoola wrote: > Bob, just replied to your update on the Info-ZIP forum. > > > If you would like, I can send you the diff for my working version, > > which has Lutz' code mixed in with mine. You should be able to use it > to run the MVS version of zip. Let me know if you would like me to do > this. > > Yes, I would be most grateful. I could test this out in the meantime > until your final post to the Info-ZIP forum. I just uploaded both patches to the Info-ZIP forum. Look at the following threads for the patches: zip thread: http://www.info-zip.org/board/board.pl?m-1244753050/s-15/ patch: http://www.info-zip.org/board/board.pl?v-download/f-diff_8942.zip/ unzip thread: http://www.info-zip.org/board/board.pl?m-1244753420/s-0/ patch: http://www.info-zip.org/board/board.pl?v-download/f-diff_8806.zip I did not fix the crypto code in unzip. This is not really a z/OS issue. I'll look into it later. I included some of Lutz' patch, and left out other parts - see the forum post for notes on what and why. I'd like to know if this works for you without his changes to unix/Makefile. The patch is a unified diff - you'll need to apply it on a workstation with GNU diff, then upload the source to your mainframe. z/OS diff is a little primitive. Let me know how this works for you. By the way, I don't suppose there's anyone following this thread that has access to a z/VM system, is there? (I don't at the moment.) The CMS code is in the same state of neglect (about 10 years' worth) as the z/OS-MVS code was. Cheers, Bob Bob Woodside http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 10 July 2009, Vikesh Bhoola wrote: > Bob, just replied to your update on the Info-ZIP forum. > > > If you would like, I can send you the diff for my working version, > > which has Lutz' code mixed in with mine. You should be able to use it > to run the MVS version of zip. Let me know if you would like me to do > this. > > Yes, I would be most grateful. I could test this out in the meantime > until your final post to the Info-ZIP forum. If I can't get the final posted today, I'll send you the temp version. I'm fixing the optimization settings - that's why the cmsmvs version was so slow. > Thanks, I will look out for your patch on unzip 6.0 (cmsmvs version?) Yes, the unzip patch addresses both the Unix and the MVS versions. By the way, I called it "almost final" because I want to fix the crypto code as long as I'm tweaking stuff - it was never made "large file" clean for unzip. Don't test with encrypted files and everything will work fine with the patch I posted last night. Oh, yes, and I still have to add the optimization fix to unzip - the MVS version will also be slow. I hope to have all this stuff posted to the forum before the weekend - with a little bit of luck. :-) Cheers, Bob Bob Woodside rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS "zip file processing" - an idea
On Saturday 27 June 2009, Bob Woodside wrote: > On Friday 26 June 2009, Kirk Wolf wrote: > > Not only possible, but already available! > > > > See the sample program "com.ibm.jzos.sample.ZipDatasets" in the > > JZOS Sample programs download, which is available here: > > http://www-03.ibm.com/servers/eserver/zseries/software/java/product > >s/ jzos/jzossamp.html > > 2) I'm not sure whether the java.util.zip package supports the new > Zip64 extensions to handle file sizes > 4GB. (Check whether the > ZipEntry's setSize method can take an argument > 0x - I'm not > so sure it can, but I'd love to be proven wrong here!) According to the most recent doc I could find on java.util.zip, setSize - even though it takes a 64-bit long (Java-style) as an argument - throws an IllegalArgumentException "if the specified size is less than 0 or greater than 0xFFFFFFFF bytes". So it looks like it can't handle the "large files". Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 29 June 2009, Vikesh Bhoola wrote:
> On Friday 26 June 2009, Bob Woodside wrote:
> >By the way, Vikesh, did you have to apply the patches against
> > zip 3.1b that Lutz posted to the Info-ZIP forum to get the "dots"
> > stuff to work?
>
> Yes, I did. Lutz's solution works 100% to get the "dots" to work -
> Bob, thanks for the pointer on that info.
Vikesh --
I have the cmsmvs ("native MVS") build of zip working correctly now.
I'd like to post the patch to the Info-ZIP forum soon.
I'm still trying to untangle my stuff from Lutz' stuff. If you would
like, I can send you the diff for my working version, which has Lutz'
code mixed in with mine. You should be able to use it to run the MVS
version of zip. Let me know if you would like me to do this.
Otherwise, keep checking the forum.
(By the way, I just posted an update to the companion patch for
unzip 6.0. It's "almost final".)
Cheers,
Bob
Bob Woodside
rwoodsi...@woodsway.com
http://www.woodsway.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS "zip file processing" - an idea
On Friday 26 June 2009, Kirk Wolf wrote: > Not only possible, but already available! > > See the sample program "com.ibm.jzos.sample.ZipDatasets" in the JZOS > Sample programs download, which is available here: > http://www-03.ibm.com/servers/eserver/zseries/software/java/products/ >jzos/jzossamp.html This is well worth looking into. I'd be curious to see some timing comparisons of the Java code against Info-ZIP. However, I still see a need for an up to date Info-ZIP. For one thing, FOSS seems, to me at least, to be sadly under utilized on z/OS, and I'd like to help change that in some small way. Info-ZIP is a standard tool that's been ported to almost any OS you can think of, but a) the IBM supplied version is way out of date, and b) the support in the code for MVS - OS/390 - z/OS is likewise way out of date. I'd like to fix that. Then, there is the fact that the java.util.zip package does have some limitations: 1) Although almost all recent zip files use either the STORE or DEFLATE compression methods, there are a bunch of legacy methods from ancient times, and unzip can still has code to read old files compressed with them. However, java.util.zip only supports the STORE and DEFLATE methods. 2) I'm not sure whether the java.util.zip package supports the new Zip64 extensions to handle file sizes > 4GB. (Check whether the ZipEntry's setSize method can take an argument > 0x - I'm not so sure it can, but I'd love to be proven wrong here!) Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 26 June 2009, Vikesh Bhoola wrote: > Yes, I do have a batch JCL for the cmsmvs zip set up : > > //INFOZIP EXEC PGM=ZIP, > // PARM='/-avl -1 -MV=dots DD:OUT ''INPUT.DATASET.NAME''' By the way, Vikesh, did you have to apply the patches against zip 3.1b that Lutz posted to the Info-ZIP forum to get the "dots" stuff to work? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 26 June 2009, Vikesh Bhoola wrote: > > It appears getting the cmsmvs version LARGE_FILES is proving to be > more challenging than I've anticipated. Or I. I managed to run several tests of both versions last night, and I found that the cmsmvs version would run successfully if I added the -fz flag. I don't like this hack for a couple of reasons: 1) it isn't documented - at least "zip -h" doesn't explain it, yet; 2) it violates the convention that "-fz" should be equivalent to "-f" and "z" (which are both valid flags in their own right); and 3) this is a workaround that just masks a program bug (that doesn't happen in the Unix build). But we may go with that as a temporary solution to get you something that will work soon. The thing that bothers me more is that the cmsmvs version ran for about 40 minutes to zip a large file that the regular Unix version handled in about 10 minutes. There's clearly a lot more work to be done here. > Yes, I do have a batch JCL for the cmsmvs zip set up : Thanks for the JCL. I'll keep you posted. Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 24 June 2009, Bob Woodside wrote: > I think I have the cmsmvs version of zip pretty well done as of > last night, but I need to do some more testing, etc. Nope, not quite ready. When I tried to add a large file to an archive, I got this error message: > zip error: Entry too big to split, read, or write (Poor compression > resulted in unexpectedly large entry - try -fz) The message is clearly bogus - the file is 4GB+ of nothing but binary zeros so the compression is surpassingly good! I think the problem is that the code doesn't expect a file > 4GB to be fitting into an archive < 4 GB. I've got to track down why this happens. The strange thing is that it didn't happen with the regular Unix build, just the cmsmvs build. Oh, well. We keep plodding along. > So you might want to start reviewing the zip documentation on > setting up the JCL to run zip and unzip - or have you already got > that set up? I've never tried doing that from the MVS side of the > house... Do you have some batch JCL for zip set up? Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 24 June 2009, Shane wrote: > On Wed, 2009-06-24 at 15:11 -0400, Bob Woodside wrote: > > (When I can edit my source files directly on > > z/OS with Nedit, I'll be a happy camper!) > > I thought Nedit had quietly died a few years back. Nice editor. It's still alive on my machines, but there doesn't seem to have been any new development in a few years. I don't know what happened there - I dropped off their mailing list a few years ago. On my *nix boxen I like to have both Nedit and Kate available, and use both heavily. But KDE 4 has led me to wonder how long I'll be using Kate :-( Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com > Shane ... > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 24 June 2009, Kirk Wolf wrote: > I'm not an nedit user, but why don't you port the nedit "server" part > to z/OS, which should be much simpler and sounds pretty cool to me: Actually, I always use it in client-server mode, with the client (nc) and server (nedit -server) running on the same workstation. This gives me only one instance of nedit no matter how many times I invoke nc to open another file. (The client often gets renamed to nedit-client to avoid clashing with the netcat nc.) And yes, it is way cool. But I've never tried using it the way you suggested. I'll have to do that sometime soon. I guess it ought to work like that - I'll have to look into whether it uses inet or just local unix sockets. For cross-machine use, I've just always used it like any other remote X app. Nedit has been ported to z/OS - I think it's in the Tools 'n Toys collection. But sadly, like so many of these tools, the version is very old - before tabs were introduced. And I haven't gotten around to trying it. Cheers, Bob Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 24 June 2009, Vikesh Bhoola wrote: > Kirk, thanks for info on Co:Z. > > Its not that I hate OMVS... I should hope not! > Apart from the single "-" file name within zip this is great. I > assume there is no way getting around this one ? This is a limitation of zip - no external tool can get around it. That's the way zip handles input from stdin. Using stdin is a hack solution at best. It's just that zip doesn't like the idea of having a filename that starts with "//". You'd have to request a change to zip/unzip from the developers, along the lines of the "dots" vs "slashes" stuff that's been done. I think that this would be a good idea, actually. That said, your technique of using zip isn't much different from using gzip or bzip2 - you typically depend on the filename of the compressed file to identify what you're extracting. (Yes, I know that gzip actually carries the name of the compressed file internally, but most people don't care because they're piping to and from tar.) > We are hoping to get gzip2 installed soon (still waiting on the > order) than perhaps can get past this. Do you mean bzip2? I think the latest gzip is 1.3.12 or something. (I think that once we have zip/unzip for z/OS up to the current release, we should try building bzip2 1.0.5 and gzip 1.3.12 - both of which support large files! Has anybody tried that?) Neither gzip nor bzip2 gets around the one file per archive issue; they are both just compressors, not archivers. And bzip2 doesn't even carry the name of the original file in the archive (just like the ancient Unix compress program - no meta data, just the file data). I know that they allow you to concatenate a series of files into one compressed file - but I really don't think you'll like the result. In other news, however... I think I have the cmsmvs version of zip pretty well done as of last night, but I need to do some more testing, etc. Then I have to make a comprehensive patch combining that plus the stuff for the Unix version, , undo a couple of changes that I've rethought, do a bunch of code cleanup, and convince the Info_ZIP guys of the impeccable correctness of my changes so they'll accept it into the next release. So you might want to start reviewing the zip documentation on setting up the JCL to run zip and unzip - or have you already got that set up? I've never tried doing that from the MVS side of the house, but I've got a loadlib with what I *think* are workable copies of zip 3.1b++ unzip 6.0 in it. That "++" means that I've gotten my patches all tangled up with Lutz' recent patches, and I have to back up to the 3.1b base and create a clean set of just my stuff. :-( As far as I can tell, the quick and dirty little unzip 6.0 patch I submitted a couple of weeks ago was all that was needed for unzip - I've been using it for the last couple of weeks on all kinds of zip files - large and small, new and old, good and corrupted - with no problems; Lutz reported that it worked fine for him, too. Cheers, Bob Bob Woodside rwoodsi...@woodsway.com http://www.woodsway.com > > http://www.zjournal.com/index.cfm?section=article&aid=1075 > > Thanks for this link, a solution we may consider. > > Regards, > Vikesh > Please Note: This email and its contents are subject to our email > legal notice which can be viewed at > http://www.sars.gov.za/Email_Disclaimer.pdf > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 24 June 2009, Kirk Wolf wrote: > Bob, > > We could really use you as a contributor in http://oss4zos.org > > Let me know if you would like an id so you can post (We don't > have an open registration process since wiki-spammers nailed us). Yes, please send me whatever info I need, and thanks in advance. > Here's a page that should be updated with your very nice Info-Zip > work: http://oss4zos.org/wiki/index.php?title=Info-ZIP Yes, I had a look at the site a while back at Timothy's suggestion. I'd certainly like to see a lot more activity in the area of utilizing OSS natively on z/OS USS. (When I can edit my source files directly on z/OS with Nedit, I'll be a happy camper!) Cheers, Bob Bob Woodside rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 23 June 2009, Bob Woodside wrote: > > Ah, but that I was just playing around with the code to see what > would happen. Based on EG's comments, I've modified the function > local_to_display_string in fileio.c to play nicer with EBCDIC - at > least it seems nicer to me. That's the function that formats the > z->oname string, so you should be able to back out that little hack. > > I've got a bunch of mods to the Unix version that I think are > fairly clean, and I'm hoping to create a good set of diffs later > today. I'll post then here and on the InfoZIP forum. OK, I posted the latest version of the patch to the Info-ZIP forum. You can grab it from this thread: http://www.info-zip.org/board/board.pl?m-1244753050/ (I decided that continuing to post patches here also is overkill.) > I'd like to get some feedback from the developers who are > familiar with the code, because there are still areas I'm not too > sure about when it comes to large file support - like the encryption > code, which never even uses the 64-bit functions (???). My bad -- it's the crypt.c in *unzip* that uses the 32-bit fseek. zip is ok, as sms pointed out. Looking at too many pieces of code with too little sleep > But, for the basic zip functions - adding, updating, deleting - > under z/OS USS, it should be OK. So feel free to give the Unix version a try. I'll start on the cmsmvs version soon, I hope. Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 23 June 2009, Vikesh Bhoola wrote: > > > See comments on the Info-ZIP forum where I offer some SWAG > > theorizing about how I must have broken the name display -- and > > somebody (EG, I > > > > think) explains the use of the 3 name fields. > > Thanks, I seen the comments made on the forum and changed z->oname to > z->name which appears to resolve the display problem. Ah, but that I was just playing around with the code to see what would happen. Based on EG's comments, I've modified the function local_to_display_string in fileio.c to play nicer with EBCDIC - at least it seems nicer to me. That's the function that formats the z->oname string, so you should be able to back out that little hack. I've got a bunch of mods to the Unix version that I think are fairly clean, and I'm hoping to create a good set of diffs later today. I'll post then here and on the InfoZIP forum. I'd like to get some feedback from the developers who are familiar with the code, because there are still areas I'm not too sure about when it comes to large file support - like the encryption code, which never even uses the 64-bit functions (???). But, for the basic zip functions - adding, updating, deleting - under z/OS USS, it should be OK. Once that's done, I'll start looking at the cmsmvs side again. (My feeble brain was getting too confused trying to keep both sorted out at the same time.) Cheers, Bob Bob Woodside rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tuesday 23 June 2009, Andy Robertson wrote:
> We use this, Barbera
>
> Might help
>
> I hope email code page problems don't trash the special characters
> I'm using . . .
Looks clean except for all those pound sterling symbols, which need
to be changed to dollar signs.
Cheers,
Bob
>
>
> * Top of Data
>
> #
> # shell script to bring down daemon if running
> #
> set -x
>
> #
> #
> # the following finds the pids by piping the output of ps -ef through
> # three greps (pattern matching) and an awk (to get the second
> column). # The two extra greps filter out the grep process itself and
> the # jlp_killprocess
> #
> #
> pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
>
> |awk '{print £2}'`
>
> # pids is now the process id(s) of the syslog daemon(s) running
>
> running=0
> for pid in £pids
> do
> running=1
> done
> if test £running -eq 0
> then
> echo "jlp_killprocess: "£1" is not running "
> exit 0
> fi
>
>
> echo "jlp_killprocess: issueing kill for "£pids
> for pid in £pids
> do
> kill -s TERM £pid
> done
> sleep 10
> for pid in £pids
> do
> kill -s KILL £pid
> done
> sleep 5
>
>
> # check to make sure it ain't there any more . . .
>
> pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
>
> |awk '{print £2}'`
>
> running=0
> for pid in £pids
> do
> running=1
> done
> if test £running -eq 0
> then
> echo "jlp_killprocess: "£1" has been killed "
> exit 0
> fi
>
> echo "jlp_killprocess: "£1" - kill failed "
> exit 12
>
> Bottom of Data
> ***
>
>
>
>
>
>
>
>
> Andy Robertson telephone mobile 0777 214 9545 home
> 01308 420797
>
>
>
> -IBM Mainframe Discussion List wrote:
> -
>
>
> To: IBM-MAIN@bama.ua.edu
> From: David Crayford
> Sent by: IBM Mainframe Discussion List
> Date: 06/23/2009 11:41AM
> Subject: Re: And you ask why I hate OMVS?
>
> Barbara Nitz wrote:
> > My shutting down the fork service brought WBIFN to a halt, and
> > probably rightly so. On the other hand, a 'real' MVS component
> > would have had recovery in place with provisions for that service
> > happening and
>
> terminating all
>
> > on its own. Just think of the lengths IMS goes to *not* to have an
> > MPR canceled from under it!
>
> IMS and it's BPE framework has it's hooks firmly in OMVS. IMS Connect
> cannot run without it. An IMS Java MPP/BPP requires OMS (anybody
> using IMS Java?). As Aussie Shane noted, the horse has bolted (you
> just can't avoid it).
>
> BTW, I enjoy reading your posts very much. You are obviously a good
> value expert. There's nothing better than a customer use case when
> things suck. IBM should take notice!
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> *
>* This email is confidential and may contain copyright material of the
> John Lewis Partnership. If you are not the intended recipient, please
> notify us immediately and delete all copies of this message. (Please
> note that it is your responsibility to scan this message for
> viruses). Email to and from the John Lewis Partnership is
> automatically monitored for operational and lawful business reasons.
> *
>*
>
> John Lewis plc
> Registered in England 233462
> Registered office 171 Victoria Street London SW1E 5NN
>
> Websites: http://www.johnlewis.com
> http://www.waitrose.com
> http://www.greenbee.com
> http://www.johnlewispartnership.co.uk
>
> *
>*
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where should processing be done was Re: IBM Software Secure Support via USA Citizens
On Monday 22 June 2009, Howard Brazee wrote: > On 21 Jun 2009 15:05:18 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: > >Maybe not yet, but there is a bill in front of Federal parliament > > that, if passed, won't even require a warrant to get the > > information to CSIS). > > We'll be as safe and secure and free the other states that have state > control over information. Scary thought. - Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BPXF135E RETURN CODE 00000081, REASON CODE 0594003D. THE MOUNT FAILED FOR FILE SYSTEM SVS.RESZS1.OMVS.ROOT.
On Monday 22 June 2009, Bonno, Tuco wrote: > // this is an example of why I like straphanging all these various > listerservers --- I'm always getting to learn new tricks and cool > stuff > Ditto. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Saturday 20 June 2009, McKown, John wrote: > > You could also enclose in " marks. > > /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip "//'userid.BIG.FILE'" > > or > > "//'userid.BIG.PDS(MEMBER)'" Sadly, it's all a dead end, because it looks like zip can't handle this kind of filename: > /u/myuserid/tmp/> zip zjunk.zip //test.outlist > zip warning: name not matched: //test.outlist > zip error: Nothing to do! (zjunk.zip) It looks like all that "dots" stuff in the filename handling code needs another wrinkle added for full MVS + USS support. And the idea of piping out of and into tar doesn't work, because tar (IBM's, at least) won't handle the filenames either. > /u/myuserid/tmp/tmp/> tar cf - //etc.ipnodes >ipnodes2 > tar: //etc.ipnodes: EDC5129I No such file or directory. What *will* work, though, is something like this: > /u/myuserid/tmp/> cat //etc.ipnodes | zip31 mvsjunk.zip - > adding: - (deflated 49%) > /u/myuserid/tmp/> unzip60 -l mvsjunk.zip > Archive: mvsjunk.zip > Length DateTimeName > - -- - > 1263 06-20-2009 15:45 - > - --- > 1263 1 file followed by something like > /u/myuserid/tmp/> unzip60 -p mvsjunk.zip > ipnodes or > /u/myuserid/tmp/tmp/> unzip60 -p mvsjunk.zip > //test.ipnodes to unpack it. Not elegant, and you're limited to one (unnamed) file per archive. You really don't have an archiver, just a compressor, like gzip or bzip2. But it's usable for this limited purpose. I haven't tried doing this with a "large" file - I don't have the large file stuff stable yet -- and that was the whole purpose of this exercise. Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Storage
On Saturday 20 June 2009, Ted MacNEIL wrote: > Why an ad? > What does this have to do with storage? > What does this have to do with Mainframes? Let's cut AC a little slack here. I think that the ad verbiage is dreck that Juno inserts into your mail willy-nilly - and I suspect that the first message (that was nothing but ad text) was a case of accidentally hitting "Send" before typing some text. And the second message was actually germane to the discussion. Of course, teasing a poster about getting a better mail hosting service is certainly a valid activity, if done in moderation. :-) Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com > --Original Message-- > From: esst...@juno.com > Sender: IBM Mainframe Discussion List > To: IBM Mainframe Discussion List > ReplyTo: IBM Mainframe Discussion List > Sent: Jun 20, 2009 09:19 > Subject: Re: Storage > > > Prices, software, charts & analysis. Click here to open your online > FX trading account. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIyVhVcYXoQFMUh8gLX >EsjbNsf6k7PQTOFHeY3NTWW4OGzXIkwLT6/ > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > - > Too busy driving to stop for gas! > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 19 June 2009, Vikesh Bhoola wrote: > I finally managed to get enough space for a ZFS to test the zip of a > file > 2Gb : I successfully zipped a 4.7GB file (in USS). Great! It looks like you're getting the same results I did. > Translating to ASCII... > adding: È_ø>¬¿ñèë¡ÈÌÈ See comments on the Info-ZIP forum where I offer some SWAG theorizing about how I must have broken the name display -- and somebody (EG, I think) explains the use of the 3 name fields. > Also, I know it was mentioned by Timothy earlier that > ...it may be possible to read directly from MVS files > using "//" syntax. > I tried it using : > /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip //userid.BIG.FILE See my other post from a few minutes ago. > Bob, please let me if you managed to get the -D_LARGE_FILE support > working for cmsmvs/mvs.mki makefile I tried to following your > descriptions for the changes on this, but I still get "zip error: Not > supported (LARGE_FILE_SUPPORT enabled but OS not supporting it)." As well as I recall, I had that version building cleanly, and working with small files, but I hadn't the chance yet to try it with a large one. I've been really busy this week with that darn day job, and haven't had time to follow up on this since last weekend. (Can't really complain about that in today's economy, a week like that is a Good Thing!). I have posted a few comments on the Info-ZIP forum, and read some comments from Lutz, EG, and sms, but that's about it. Maybe this weekend I can refresh my memory of what I did and send you a proper diff. Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com > Thanks for all assistance thus far, > Vikesh > Please Note: This email and its contents are subject to our email > legal notice which can be viewed at > http://www.sars.gov.za/Email_Disclaimer.pdf > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 16 June 2009, Kirk Wolf wrote:
> Try it - it seems to give you an archive with no files in it. After
> all, what would the file name in the zip directory be?
Well, yes and no. Let's just say "no named files". Unzip shows
something like this:
> unzip -l ../backup.zip
> Archive: ../backup.zip
> Length Date TimeName
>
> 20480 06-19-09 20:27 -
> ---
> 20480 1 file
Reading a little further in the man page, we find:
> The backup can be restored using the command
>
> unzip -p backup | tar xf -
It's sort of using zip in place of gzip or bzip2.
It's a little strange, but it actually works.
Cheers,
Bob
Bob Woodside
Woodsway Consulting, Inc.
rwoodsi...@woodsway.com
http://www.woodsway.com
> On Mon, Jun 15, 2009 at 6:30 PM, Bob Woodside
wrote:
> > On Monday 15 June 2009, Kirk Wolf wrote:
> >> I could be wrong, but I don't believe that zip allows input from
> >> stdin. If info-zip uses fopen() to open files, then it might be
> >> possible to read mvs datasets directly as input files.
> >
> > I've never tried it, but here's a quote from the zip man page:
> >> zip also accepts a single dash ("-") as the name of a
> >> file to be compressed, in which case it will read the file
> >> from standard input, allowing zip to take input from another
> >> program. For example:
> >>
> >> tar cf - . | zip backup -
> >
> > Cheers,
> > Bob
> >
> >
> > Bob Woodside
> > Woodsway Consulting, Inc.
> > rwoodsi...@woodsway.com
> > http://www.woodsway.com
> >
> > ---
> >--- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> > INFO Search the archives at
> > http://bama.ua.edu/archives/ibm-main.html
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BPXF135E RETURN CODE 00000081, REASON CODE 0594003D. THE MOUNT FAILED FOR FILE SYSTEM SVS.RESZS1.OMVS.ROOT.
On Thursday 18 June 2009, Bonno, Tuco wrote: > or, get into omvs itself ( at ispf6, do a "tso omvs" command ) and > then issue the "df" command -- Or just "oshell df". Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 19 June 2009, Vikesh Bhoola wrote: > > You might try double quotes around the file name construct, > > with single quotes embedded to prevent prefixing; so: > > > > /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip > > "//'userid.BIG.FILE'" This should do the trick: /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip //\'userid.BIG.FILE\' The single quotes have to be escaped. (If this is the same userid you're currently logged in as, you don't need to specify the userid or the quotes.) It's not relevant for this file, but if the MVS file you are referencing in Unix land is a PDS member, you have to escape the parentheses, too, like this: //\'userid.BIG.PDS\(MEMBER\)\' Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com > Thanks, I tried that, still get : > > /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip "//'userid.BIG.FILE'" > Translating to ASCII... > zip warning: name not matched: //'userid.BIG.FILE' > > zip error: Nothing to do! (/tmp/BIG_FILE.zip) > Please Note: This email and its contents are subject to our email > legal notice which can be viewed at > http://www.sars.gov.za/Email_Disclaimer.pdf > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 15 June 2009, Kirk Wolf wrote:
> I could be wrong, but I don't believe that zip allows input from
> stdin. If info-zip uses fopen() to open files, then it might be
> possible to read mvs datasets directly as input files.
I've never tried it, but here's a quote from the zip man page:
>zip also accepts a single dash ("-") as the name of a file
> to be compressed, in which case it will read the file from
> standard input, allowing zip to take input from another program.
> For example:
>
> tar cf - . | zip backup -
Cheers,
Bob
Bob Woodside
Woodsway Consulting, Inc.
rwoodsi...@woodsway.com
http://www.woodsway.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Monday 15 June 2009, Vikesh Bhoola wrote: > Bob, thanks for the gmake link and the update - it sounds promising. > > I've just downloaded gmake and going to install it. > Just want to confirm if gmake is required for the cmsmvs/mvs.mki ? I don't know if it is required for you. Our make isn't properly configured and won't run at all, and I don't have the time to look into that problem. But our gmake works fine, so I just use that. However, I have seen comments on the forums that IBM's make doesn't play nice with Info-ZIP. YMMV. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
Vikesh -- Like I said, keep following the discussions on the Info-ZIP forums. I've managed to piece together clues from you, Lutz, and sms, and got a clean build from the cmsmvs/mvs.mki makefile that looks like it actually works. I just posted some initial info on the Info-ZIP forums. I'll probably post more detail tomorrow night - after I review what I did and run some more tests to convince me that I'm not hallucinating. :-) (The short description of the fix is: adding -D_LARGE_FILES to the makefile, and tweaking tailor.h to point zfseeko to fseeko.) Did you ever manage to get gmake from the link I posted? Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 12 June 2009, Vikesh Bhoola wrote: > > What I have working is the version in the unix directory, built > > under USS as a Unix executable. > > Thanks Bob, it is disappointing, but at least that explains the > differences I was seeing. > > We don't have gmake installed, and so with make -f /unix/Makefile & > Configure does not compile successfully by me. Just tried to get > gmake, however it is not available on z/OS Unix Tools and Toys page > for download. > Ahem http://www-03.ibm.com/servers/eserver/zseries/zos/unix/library/IBM+Redbooks/index.html#gmake > > But these won't help you build a zip load module into an MVS PDS > > with the makefiles in cmsmvs, so it's back to the drawing board > > forthat one. > > This is a issue, as we really don't have the additional space to copy > the 14GB MVS file to USS just to zip it. I was able to create a 5GB file during off-hours last night to test with, and it works. (It's really impressive how compactly a 5GB file of nothing but binary zeros compresses!) The patch isn't quite ready for Prime Time, there's a bug in how it displays the "adding: bigfile ..." message, which comes out as "adding: ÂÑÅÃÑ%Á ...". Duh! > > I don't know when I'll have a chance to look at those. Keep following the discussions on the Info-ZIP forums. In the thread "zip tools for X/OS USS" Lutz has just uploaded a new patch file - I haven't had a chance to check it out, but he does appear to be building the mvs.mki makefile as well as the regular Unix version. I need to get in sync with what he's doing as soon as I have time. I can't get mvs.mki to compile - I get a bogus error on cmsmvs.c at line 164: > ERROR CCN3282 ./../cmsmvs/cmsmvs.c:164 The type of the parameters > must be spec ified in a prototype. I have to get it to build at all before I can try forcing the LARGE_FILE_SUPPORT into it. The good news is the the mvs.mki makefile for unzip 6.0 builds just fine for me with both the HFS and native MVS targets, so fixing that should be much more straightforward. But, of course, it doesn't help you much till we can get zip fixed. :-( > We would really appreciate it if you do get a chance or anybody else > does get this working, please could you keep me in mind. Certainly. Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 10 June 2009, Edward Jaffe wrote: > Bob Woodside wrote: > > I'll look at the configure script later to see what needs to be > > done there. Then I'll do the same with unzip 6.0. And the code > > should probably be patched to recognize a ZOS define as well as > > OS390 -- time to move the mainframe support into the 21st century. > > > > I'll keep you posted as I make progress. And when I have all > > the changes, I'll post a diff to the developers' forum. > > THANK YOU! I posted unified diffs against zip 3.1b and unzip 6.0 to the developers' forum about half an hour ago. These are slightly different from the ones I posted to this list. Most developers like unified diffs (though I don't know what the current Info-ZIP maintainers like). Anyway, these were created on my Linux workstation. But z/OS diff doesn't support unified diffs; so the ones I posted here are regular context diffs created by z/OS diff that someone could use on a z/OS system - I hope. These patches only address building zip and unzip for the USS environment. Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Thursday 11 June 2009, Vikesh Bhoola wrote:
> Thank you Bob.
>
> > [ snip ]
>
> So, I'd be interested in the code once you manage to get this
> working. Comparing the difference between your CFLAGS & mine, I see
> mine : -D_OPEN_SYS -DMVS -DREENTRANT -DLARGE_FILE_SUPPORT
> Yours :
> -DOS390 -DEBCDIC -DSYSV -DNO_PARAM_H -DLARGE_FILE_SUPPORT
>
> Its obvious you've done a lot of changes as my compile fails with
> these options:
> /u/userid/zip31b/cmsmvs: >make -f mvs.mki
> cc -c -o ../mvs/zip.o -DOS390 -DEBCDIC -DSYSV -DNO_PARAM_H
> -DLARGE_FILE_SUPPORT
> -I.. -I../cmsmvs ../zip.c
Bummer! I hadn't noticed in your last couple of posts that you're
trying to build the old cmsmvs versions rather than the one in the unix
directory. I haven't looked at those at all, and have no idea whether
anyone has built those successfully in the past decade! Are the
developers working on the stuff in the cmsmvs directory?
(Shouldn't you be running from the zip31b directory, and using the
command "gmake -f cmsmvs/mvs.mki"? And have you tried using gmake
instead of make? IBM's make doesn't work for me with zip.)
What I have working is the version in the unix directory, built
under USS as a Unix executable. This only required modifications to
unix/configure and unix/Makefile. I can send the diff files for zip31b
and unzip60, or I can send you the entire Makefile and configure files,
if this would help you, or if you'd like to try them out.
You would build like so, in either the zip31b or unzip60
directories:
gmake -f unix/Makefile clean
gmake -f uniz/Makefile zos
But these won't help you build a zip load module into an MVS PDS
with the makefiles in cmsmvs, so it's back to the drawing board for
that one. I don't know when I'll have a chance to look at those. Has
anybody else tried them?
If anyone wants to try this out, I'm attaching USS style diffs for
zip 31b and unzip 60. USS doesn't grok unified diff, which is what I
would send to the developers. These are created on z/OS with diff -rc,
so they should work as input to the USS patch. If anyone wants the
whole Makefile and configure files, let me know and I'll send them to
you off-list.
Cheers,
Bob
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
diff -rc ./Makefile patched/Makefile
*** ./Makefile Wed Jun 10 21:48:25 2009
--- patched/Makefile Thu Jun 11 09:06:11 2009
***
*** 923,935
LF2="-arch i386 -arch m68k -object -s"
# IBM OS/390 (formerly MVS) compiled under "OpenEdition" shell
! os390:unix_make
! set -x; \
! $(MAKE) $(MAKEF) unzips \
!CC=c89 LD="\$$(CC) -Wl,EDIT=NO" \
!CF="$(CF) -DSYSV -DUNIX -DOS390 -DEBCDIC -DNO_PARAM_H \
!-DNO_LCHOWN -DNO_LCHMOD \
!-D_ALL_SOURCE $(HOST_VERSINFO)" LF2=""
# Sequent Symmetry running Dynix/ptx (sort of SysV.3): needs to link
# with libseq to get symlink().
--- 923,951
LF2="-arch i386 -arch m68k -object -s"
# IBM OS/390 (formerly MVS) compiled under "OpenEdition" shell
! #os390: unix_make
! # set -x; \
! # $(MAKE) $(MAKEF) unzips \
! # CC=c89 LD="\$$(CC) -Wl,EDIT=NO" \
! # CF="$(CF) -DSYSV -DUNIX -DOS390 -DEBCDIC -DNO_PARAM_H \
! # -DNO_LCHOWN -DNO_LCHMOD \
! # -D_ALL_SOURCE $(HOST_VERSINFO)" LF2=""
!
!
! # RBW -- 2009/06/10 --
! # It's way past time to bring the mainframe setup into the 21st
! # century - it's been about a decade now, I think.
! # The configure script has fixes to set -DSYSV -DOS390 -DEBCDIC
! # and -DNO_PARAM_H.
! # os390 is effectively just an alias for zos - the z/OS kernel still
! # identifies itself as OS/390 - remind anyone of Solaris?
! # This is really the same technique as the generic target, which
! # should also work now for z/OS systems.
! os390:zos
!
! zos: flags # now try autoconfigure first
! eval $(MAKE) $(MAKEF) unzips ACONF_DEP=flags `cat flags`
!
# Sequent Symmetry running Dynix/ptx (sort of SysV.3): needs to link
# with libseq to get symlink().
diff -rc ./configure patched/configure
*** ./configure Wed Jun 10 21:48:25 2009
--- patched/configure Thu Jun 11 09:06:11 2009
***
*** 456,463
done
CFLAGSR="${CFLAGSR} ${OPT}"
echo Check for non existent include files
! for inc in stdlib.h stddef.h unistd.h fcntl.h string.h langinfo.h
do
echo "#include <$inc>" > conftest.c
$CPP conftest.c >/dev/null 2>/dev/null
--- 456,464
done
CFLAGSR="${CFLAGSR} ${OPT}"
+ + # RBW -- 2009/06/10 -- added param.h test for z/OS (doesn't have it)
echo Check for non existent include files
! for inc in stdlib.h stddef.h unistd.h fcntl.h string.h langinfo.h param.h
do
echo "#include <$inc>" > conftest.c
$CP
Re: INFOZIP >2Gb
On Wednesday 10 June 2009, Vikesh Bhoola wrote: > Bob, thanks for the detailed information, it is very much > appreciated. > [snip -- this thread was getting too long for my little mind] OK, I did a quick 'n dirty test with a hacked Makefile and a hand-patched flags file, and built zip 3.1b successfully with large file support. I added -DOS390 -DEBCDIC -DSYSV -DNO_PARAM_H and -DLARGE_FILE_SUPPORT to the flags file. I don't have a large file to test it with at the moment - I'll have to create one when I have the time to find a volume with enough free space on it. I'll look at the configure script later to see what needs to be done there. Then I'll do the same with unzip 6.0. And the code should probably be patched to recognize a ZOS define as well as OS390 -- time to move the mainframe support into the 21st century. I'll keep you posted as I make progress. And when I have all the changes, I'll post a diff to the developers' forum. Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
Now, this is seriously weird! I tried building both zip 3.1b and 3.0, and the newly-released unzip 6.0 yesterday evening, and they all 3 built without errors. This is on a z/OS 1.10 system. That was after a couple of false starts where I built the generic target instead of the os390 target. After switching to the os390 target, I did get warnings like this > cc -c -I. -DUNIX -DOS390 -DEBCDIC -DSYSV -DNO_PARAM_H zip.c > WARNING CCN3236 ./zip.h:215 Macro name __EBCDIC has been redefined. > FSUM3065 The COMPILE step ended with return code 4. but nothing fatal, and I now have a perfectly usable zip and unzip. Almost. But Although flags has -DLARGE_FILE_SUPPORT set, it doesn't get picked up by the compiles (see the pasted line above), so it's not built in. I don't know what's going on - whether the Makefile needs some doctoring for the mainframe, or whether the source needs some hacking. It was too late last night to start delving into this. Maybe I can find some time to look into it later today. OK, took a quick peek at the Makefile. That's the first thing to fix - and the configure script. You can tell from the "os390" target that that section hasn't been updated in about a decade. It doesn't use the flags file created by configure. But flags isn't right either - configure doesn't set -DOS390 or -DEBCDIC, so some work is needed there. Later Cheers, Bob Bob Woodside Woodsway Consulting, Inc. rwoodsi...@woodsway.com http://www.woodsway.com On Wednesday 10 June 2009, Vikesh Bhoola wrote: > Bob, thanks for the detailed information, it is very much > appreciated. > > I've tried adding -DLARGE_FILE_SUPPORT however received the following > errors during compilation : > > cc -c -o ../mvs/cmsmvs.o -D_OPEN_SYS -DMVS -DREENTRANT > -DLARGE_FILE_SUPPORT -I.. -I../cmsmvs ../cmsmvs/cmsmvs.c ERROR > CCN3343 ./../cmsmvs/cmsmvs.c:193 Redeclaration of filetime differs > from previous declaration on line 774 of "../zip.h". CCN0793(I) > Compilation failed for file ./../cmsmvs/cmsmvs.c. Object file not > created. FSUM3065 The COMPILE step ended with return code 12. > FSUM3017 Could not compile ../cmsmvs/cmsmvs.c. Correct the errors and > try again. FSUM8226 make: Error code 3 > > The complete compile output with other WARNING messages is attached > (if it comes through the listserver). > > I did manage to compile with -DZIP64_SUPPORT option. It however does > not allow the zip of big files (>2GB). > > Also according to zip31b.ann file the -MV should be in : > - MVS updates, including new -MV option to control path translations. > > I have also posted this to Info-Zip forum. > Your assistance is appreciated. > > Kind Regards, > > Vikesh Bhoola > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Bob Woodside Sent: 09 June 2009 07:21 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: INFOZIP >2Gb > > On Tuesday 09 June 2009, Vikesh Bhoola wrote: > > Thanks for the links. > > While waiting for our order on bzip2, > > > > > I tried downloading INFO-Zip > > 3.1b (Beta version) - as Zip 3.0 does not compile. I finally > > managed to compile INFO-ZIP Zip 3.1b to create a ZIP module. > > > >[snip] > > > > How do I specify LARGE_FILE_SUPPORT in my compile > > What follows is based on the information in the INSTALL file in > the zip31b directory. This may not work, but it's the first step to > try. > > It looks like the configure script (invoked from the Makefile) > failed to detect that your OS can handle large files. Try the > following to coerce make into setting the LARGE_FILE_SUPPORT and > ZIP64_SUPPORT options. > > When you ran make, it should have left a file called flags in > your zip31b directory. You need to edit this - it's one long line > with all the complier/linker flags. > > Look for the CFLAGS string - it should look something like this: > > CFLAGS="-I. -DUNIX -O3 ... ... ..." > > and add " -DLARGE_FILE_SUPPORT " to this string. > > Then re-run make, and see if it builds without errors. Try to run > zip to see if it works. Enter "zip -v", and check what special > options it says it was built with. Try to zip a small file. > > If zip reported that is was built with ZIP64_SUPPORT - which > should be set automagically if you specified LARGE_FILE_SUPPORT - > then you are ready to try a large (>2GB) file. > > If no ZIP64_SUPPORT, go back and edit the flags file again. This > time add " -DZIP64_SUPPORT " to the cFLAGS string. Ru
Re: INFOZIP >2Gb
On Tuesday 09 June 2009, Vikesh Bhoola wrote: > Thanks for the links. > While waiting for our order on bzip2, > I tried downloading INFO-Zip > 3.1b (Beta version) - as Zip 3.0 does not compile. I finally managed > to compile INFO-ZIP Zip 3.1b to create a ZIP module. >[snip] > How do I specify LARGE_FILE_SUPPORT in my compile What follows is based on the information in the INSTALL file in the zip31b directory. This may not work, but it's the first step to try. It looks like the configure script (invoked from the Makefile) failed to detect that your OS can handle large files. Try the following to coerce make into setting the LARGE_FILE_SUPPORT and ZIP64_SUPPORT options. When you ran make, it should have left a file called flags in your zip31b directory. You need to edit this - it's one long line with all the complier/linker flags. Look for the CFLAGS string - it should look something like this: CFLAGS="-I. -DUNIX -O3 ... ... ..." and add " -DLARGE_FILE_SUPPORT " to this string. Then re-run make, and see if it builds without errors. Try to run zip to see if it works. Enter "zip -v", and check what special options it says it was built with. Try to zip a small file. If zip reported that is was built with ZIP64_SUPPORT - which should be set automagically if you specified LARGE_FILE_SUPPORT - then you are ready to try a large (>2GB) file. If no ZIP64_SUPPORT, go back and edit the flags file again. This time add " -DZIP64_SUPPORT " to the cFLAGS string. Run make again. If it builds, try zip out on a small file again, then on a big (>2GB) one. If you got compile/link errors after forcing these options, or if it built OK but still fails, let us know what errors you got, and on which step you got them. Oh, and you might try posting that info to the Info-ZIP forum also. > as well as make use > of the MVS dataset name format ie. -MV=dots ?? It was unclear to me from the forum whether the -MV=dots argument made it into the 3.1 beta. Did it? > Has anyone got this part to work or tested on z/OS ? I haven't had a chance to try this, and probably won't for a couple of days. By the way, if you get this working, you will need the new 6.0 release of unzip - just out of beta - to unzip the large files. Cheers, Bob > > My Zip -v states I've the following : > Zip special compilation options: > SYMLINK_SUPPORT (symbolic links supported) > PASSWD_FROM_STDIN > Ýencryption, version 2.91 of 05 Jan 2007¨ (modified for Zip > 3) > > Thank you for your assistance. > > Kind Regards, > > Vikesh > Please Note: This email and its contents are subject to our email > legal notice which can be viewed at > http://www.sars.gov.za/Email_Disclaimer.pdf > > - >- For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: strange codepage issue in ISPF
On Friday 05 June 2009, Chase, John wrote:
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth
> >
> >
> >
> > <>!*''# waka waka bang splat tick tick hash
> > ^...@`$$- carat at back-tick dollar dollar dash
> > *!'$_ splat bang tick dollar underscore
> > %*<>#4 percent splat waka waka number four
> > &)../ ampersand right-paren dot dot slash
> > {~|**SYSTEM HALTED curly bracket tilde pipe splat splat crash
>
> I prefer "right-banana" over "right-paren". :-)
And left- and right-elbow for '<' and '>' (aka "angle-brackets").
But, of course, using these technically correct terms would spoil the
metre. :-)
- Bob
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST equivalent to REXX STRIP
On Friday 05 June 2009, Klein, Kenneth wrote:
> I like the REXXTRY program. It should prove very useful. But I am
> still disappointed in my efforts to run showzos in batch mode. I'd
> like to run it every week and keep a few months of generations on
> hand just for debugging and historical reasons. But when I run it in
> batch, I only get a few lines of output. When run in foreground, I
> get tons of output. What am I missing here?? TIA
I'm not familiar with showzos. Is this one of those things that needs to
be invoked from IKJEFT01 in batch because it's using TSO features?
Cheers,
Bob
- - - -
Bob Woodside
Woodsway Consulting, Inc.
www.woodsway.com
>
>
> Ken Klein
> Sr. Systems Programmer
> kenneth.kl...@kyfb.com
> 502-495-5000 x7011
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Michel Castelein
> Sent: Friday, June 05, 2009 6:23 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CLIST equivalent to REXX STRIP
>
> "Gilbert Saint-Flour" wrote in message
> news:<200906051003.17401.usenet5...@yahoo.com>...
>
> > On Thursday 04 June 2009 16:56, Paul Gilmartin wrote:
> > >>I'm trying to find a way to translate this REXX instruction to a
> > >>CLIST equivalent ...
> > >
> > > Why?
> >
> > I wrote a bunch of CLISTs until I started writing REXX execs in
> > 1991, but
>
> I
>
> > wrote very few CLISTs since then. I wish a REXX exec could start
> > with
>
> PROC,
>
> > like a CLIST can, so from time to time I write a CLIST just because
> > of
>
> PROC.
>
> > BTW, this is the less-complex way I found to simulate REXX STRIP in
> > a
>
> CLIST:
> > SET XXX = &STR(' AA-BB ')
> > REXXTRY RETURN STRIP(&XXX)
> > SET XXX=&STR(&RESULT)
> >
> > And this is the pure-REXX equivalent :
> >
> > XXX = ' AA-BB '
> > XXX = STRIP(&XXX)
> >
> > REXXTRY is described here:
> > http://gsf-soft.com/Freeware/REXXTRY.shtml
> >
> > --
> > Gilbert Saint-Flour
> > GSF Software
> > http://gsf-soft.com/
>
> IMHO, there is indeed no CLIST equivalent.
> &STR prevents the value ' AA-BB ' to be treated as an arithmetic
> expression, but it also prevents the removal of the leading and
> trailing blanks.
> A kind of Catch-22 condition.
>
> Michel Castelein
> z/OS instructor & consultant
> http://www.geocities.com/michelcastelein/
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Wednesday 03 June 2009, Vikesh Bhoola wrote: > > We would have liked INFOZIP to work for files > 2Gb as it appears to > be quicker than the jar method. > I guess the best free working solution is the jar function. It takes > a bit longer, but it does the job. > > Our windows zip product successfully unzips the 1.2Gb (using jar > method) to 14.6Gb file, so I guess we don't have any 2Gb limit there. > So for INFOZIP, perhaps it's the _LARGE_FILES feature macro as > mentioned - not sure how to get pass that though. I think that your only option with Info-ZIP is to build from the latest source distributions (3.0 for zip, and 6.0 for unzip.) The 6.0 release of unzip is still Beta, but appears to be fairly solid; earlier unzip releases don't support file sizes > 2GB. There used to be a ton of Info-ZIP pre-built binaries floating around for various platforms (including the venerable mainframe), but there don't seem to be in recent years. Cheers, Bob - - - - Bob Woodside Woodsway Consulting, Inc. www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Friday 22 May 2009, Jim McAlpine wrote: > On Fri, May 22, 2009 at 9:18 AM, Jim McAlpine wrote: > > Walter, many thanks. We will certainly give this a try. > > > > Jim McAlpine > > OK, we've implemented that bit of code and got to the point of > executing IKJEFTSR to issue a LISTDS command but that invocation > failed with - > > IKJEFTSR FAILED - RC= -1 > REASON CODE= 68 > and the following - > > IKJ56652I You attempted to run an authorized command or program. > This is not supported under the Dynamic TSO Environment. > > which seems self explanatory. I've checked in the AUTHCMD names > table and LISTDS is in there. Two further questions - > > 1. Does LISTDS absolutely need to be in AUTHCMD. > 2. Do most sites have LISTDS in AUTHCMD. Jim -- Can you make do with using the SYSDSN command instead of LISTDS, or do you need more fine grained info about the file than just whether it exists? I don't believe that SYSDSN requires authorization (won't have a chance to double check this till sometime this afternoon, though). -- Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Thursday 21 May 2009, Jim McAlpine wrote: > > Thanks for all the replies and suggestions. Having spoken again to > the developer who originally asked the question, it seems it is a > tad more complicated in that he actually wants to do i/o against the > file from the REXX program. The question now becomes, can we call > TSO from a COBOL program without being authorised. And to answer > Walts suggestion, no we can't have the COBOL program invoked from > IKJEFT01 as that part of the architecture is carved in stone. So, I think Paul has nailed it - do they need anything more than SVC 99 services and basic EXECIO style I/O (which can both be achieved without a TSO environment)? If there are specific TSO services needed, then pull out your trusty "TSO/E Programming Services" and bone up on IKJTSOEV and IKJEFTSR. Note that you can't use any authorized TSO services via this interface. If you need that, then the stones may really need to be re-cut, along the lines that Walt suggested. Cheers, Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Thursday 21 May 2009, McKown, John wrote: > > I feel rejected . Doesn't anybody like using the "new" > Enterprise COBOL feature which does the DYNALLOC behind the scenes? There, there...that would be fine also. We've just been exploring all the options available to OP. (I haven't really used COBOL in [mumblemumble] years, so I haven't kept up with the newer features. Sounds slick.) Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Paul Gilmartin wrote: > > Doesn't IKJEFT01 require that it be invoked only from an > APF authorized program, which might be an obstacle to the > OP? Actually, I believe I spoke before thinking earlier. I think the program would need to call IKJTSOEV and IKJEFTSR, and I don't think they're restricted to authorized programs. But your suggestion of calling BPXWDYN is much more sensible. > If the OP intends to process the file in the COBOL program, > might allocating it in Rexx shortcut the need to allocate > it in the COBOL code? If all the Rexx program is used for is to check whether the file exists, then they can eliminate it altogether by just calling BPXWDYN directly from the COBOL program. But if there's more to it than that, then yes, if the Rexx program call to BPXWDYN succeeded it might as well leave the file allocated, and the COBOL program needn't do that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Bob Woodside wrote: > > Would it be feasible for you to invoke IKJEFT01 instead of > the Rexx interpreter... On the other hand Forget my earlier lame suggestion. As a couple of other people have already pointed out, calling BPXWDYN is the way to go. It will do exactly what you need. You should be able to call it directly from your COBOL program. Or, you could call it from your Rexx program, which you might want to have available for other programs to call, from a variety of environments - TSO, MVS batch, or USS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Jim McAlpine wrote: > We have a REXX program which is called from COBOL in batch in which > we need to check for the existence of a file. Obviously there is no > TSO environment here so no commands like LISTDS. Is there anyway to > acheive this without the TSO environment. Would it be feasible for you to invoke IKJEFT01 instead of the Rexx interpreter to run your Rexx exec? That way you have the TSO environment available to your Rexx script, and can use SYSDSN and friends. IKJEFT01 will return the return value from last command executed. Or is your COBOL program linked with compiled Rexx code? How does your program communicate with Rexx? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRM CPU Mgmt Table layout?
On Monday 18 May 2009, Mark Zelden wrote: > On Mon, 18 May 2009 08:43:56 -0400, Bob Woodside wrote: > > Can anyone tell me where the SRM CPU Management Control > > Table (CCT) layout is documented? [ snip ] > > I don't really want to include examples that I can't > > document properly. Some folks don't really like being told "Well, > > that's just part of the Great Oral Tradition (TM)". > > It's not GUPI, but see SYS1.MODGEN(IRACCT). I would have thought that it would have been - but it wouldn't be the first time that a fairly well known [storage area | feature technique | what have you] wasn't considered GUPI. Thanks. Bob -- Bob Woodside Woodsway Consulting, Inc. www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRM CPU Mgmt Table layout?
On Monday 18 May 2009, Rob Scott wrote: > SYS1.MODGEN(IRACCT) Thanks -- that's exactly what I was looking for; even though, as Mark pointed out a few minutes later, it's not officially considered GUPI. Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Share Website Hacked
On Monday 18 May 2009, Gilbert Saint-Flour wrote: > On Monday 18 May 2009 13:48, Mark Jacobs wrote: > > On the main page is a picture of a penguin with some rude words > > attached. > > Most of the things I see on http://www.share.org/ have a .aspx > suffix, which, if I'm not mistaken, tells us they use a Microsoft Web > server. Ahem. According to Netcraft, this is what they're running: Windows Server 2003 Microsoft-IIS/6.0 18-May-2009 38.106.213.17 > Perhaps they should use something that's less likely to be > broken into ? Perhaps something like Apache/IBM HTTP Server running on a z-Series box? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SRM CPU Mgmt Table layout?
Can anyone tell me where the SRM CPU Management Control Table (CCT) layout is documented? In my copy of "MVS Data Areas", I hit a dead end at the RMCT, which contains the RMCTCCT field pointing to the CCT. I can't find a layout for the CCT itself. I want to include, in a class I'm teaching, a sample Rexx exec that fetches the CCVUTILP field from this control block and displays the current CPU utilization, to illustrate the use of the Rexx STORAGE function to chase through MVS control blocks. I've used this technique in a variety of languages, and I don't even remember where I first found the recipe for it. The sequence is CVT::CVTOPCTP==>> RMCT RMCT::RMCTCCT ==>> CCT CCT + offset x'66' = CCVUTILP I don't really want to include examples that I can't document properly. Some folks don't really like being told "Well, that's just part of the Great Oral Tradition (TM)". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
