Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Steve Conway
Lots of JES2 and JES3 work being done, a lot of it pointing to convergence of the two products. Interesting stuff. Cheers,,

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Richard Pinion
Creating JES2 was a half ASP job. --- steve_con...@ao.uscourts.gov wrote: From: Steve Conway To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here: Date: Tue, 5 Feb 2013 08:39:10 -0500 Lots of JES2 and JES3

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Steve Comstock
group, HASP was the ancestor of JES2 and ASP was the ancestor of JES3) Perhaps Lynn has some historic background available. --- steve_con...@ao.uscourts.gov wrote: From: Steve Conway To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rejoice! z/OS 2.1 addresses some long term JCL

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Mark Zelden
On Tue, 5 Feb 2013 06:59:41 -0700, Steve Comstock wrote: >On 2/5/2013 6:44 AM, Richard Pinion wrote: >> Creating JES2 was a half ASP job. > >Actually, my understanding was that it went the >other way: lots of HASP code was lifted into >ASP. There was probably some borrowing in the >other directi

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Paul Gilmartin
On Tue, 5 Feb 2013 07:27:11 -0600, John McKown wrote: > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP13-0013 > >In z/OS V2.1, a number of JCL improvements are planned: > >Support for passing parameter lists up to 32,760 bytes

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread John Gilmore
32760 = max[n | (n <= 32767) & (n = 0 mod(8))] On 2/5/13, Paul Gilmartin wrote: > On Tue, 5 Feb 2013 07:27:11 -0600, John McKown wrote: > >> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP13-0013 >> >>In z/OS V2.1, a number of

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Paul Gilmartin
On Tue, 5 Feb 2013 11:11:04 -0500, John Gilmore wrote: >32760 = max[n | (n <= 32767) & (n = 0 mod(8))] > But why "n = 0 mod(8)"? The PARM length is specified in single bytes in a halfword. As an experiment, I've passed a PARM of 32767 bytes to HLASM, which processed it correctly while misbehavi

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread John Gilmore
This is an old discussion. Why is storage allocated in doublewords on doubleword boundaries? This is done because the most exigent historical alignment requirements are met by doing so. (Very specialized quadword-alignment requirements do now sometimes arise.) Storing current length in a signed

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Ed Finnell
Btwrong! Jack posted a link with the gory details a few years back but can't find it. (Maybe it's a .pdf) It really was Half-ASP. Got cleaned up to become Houston-ASP. In a message dated 2/5/2013 8:00:13 A.M. Central Standard Time, st...@trainersfriend.com writes: Actually, my un

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Ed Finnell
One of my first SHAREs the UNIJES project was kicking off. Think one of my associates was on the team. I got trolled into SPF. Bob Shannon said due to politics UNIJES eventually got scrubbed The 'SUMMA CUM JES' badge was interesting. #441 1171 and 1172 at _www.mxg.com_ (http://www.mxg.com

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Anne & Lynn Wheeler
st...@trainersfriend.com (Steve Comstock) writes: > Actually, my understanding was that it went the > other way: lots of HASP code was lifted into > ASP. There was probably some borrowing in the > other direction, too, I would imagine. > > (For the relative newcomers in the group, > HASP was the a

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Steve Comstock
On 2/5/2013 12:44 PM, Anne & Lynn Wheeler wrote: st...@trainersfriend.com (Steve Comstock) writes: Actually, my understanding was that it went the other way: lots of HASP code was lifted into ASP. There was probably some borrowing in the other direction, too, I would imagine. (For the relative

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread W. Kevin Kelley
Yaaay! But why not 32767 or 65535? Actually32760 is plenty; just curious. Try passing HLASM 32768 to witness some bizarre behavior. But BPXBATCH is happy with 65535. 32760 was picked for several reasons: its the maximum blocksize and with an 8-byte header fits nicely in 32768. W. Kevin Kelle

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-05 Thread Clark Morris
On 5 Feb 2013 07:58:30 -0800, in bit.listserv.ibm-main you wrote: In the discussion below, I note that once again the JES2 customers get more new function than those using the higher priced JES3. Clark Morris who still nurses a grudge because JES3 customers had to buy BDT(Bulk Data Transfer) to g

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-06 Thread Shmuel Metz (Seymour J.)
In <51116fdb.4020...@trainersfriend.com>, on 02/05/2013 at 01:47 PM, Steve Comstock said: >This seems to support my recollection that HASP came first, or at >least at the same time; HASP is not Half-ASP as the almost clever >saying goes. ASP is half-HASP, perhaps. Yes, HASP had much better ca

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-06 Thread Don Williams
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Tuesday, February 05, 2013 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints &g

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-07 Thread Tom Wasik
If you are interested, there is some additional detail on the 2.1 JES2 JCL changes in my SHARE pitch from this week: http://share.confex.com/share/120/webprogram/Handout/Session13029/JES2%20Product%20Update%20and%20Latest%20Status.pdf Tom Wasik JES2 Development --

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Paul Gilmartin
On Fri, 8 Feb 2013 00:36:54 -0600, Tom Wasik wrote: >If you are interested, there is some additional detail on the 2.1 JES2 JCL >changes in my SHARE pitch from this week: >http://share.confex.com/share/120/webprogram/Handout/Session13029/JES2%20Product%20Update%20and%20Latest%20Status.pdf > Ment

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread zMan
So I've read the PDF but I'm still not clear on this: Does the enhanced symbol support mean that you can use symbols in places like this: REPRO INFILE(GIMZPOOL) + OUTDATASET(&HLQ..GLOBAL.CSI) ? That would sure make distributed SMP/E JCL easier for customers to modify.

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Martin Packer
/mydeveloperworks/blogs/MartinPacker From: zMan To: IBM-MAIN@listserv.ua.edu, Date: 02/08/2013 02:29 PM Subject:Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here: Sent by:IBM Mainframe Discussion List So I've read the PDF but I'm still

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread David Andrews
On Fri, 2013-02-08 at 09:29 -0500, zMan wrote: > Does the enhanced symbol support mean that you can use symbols in places > like this: > REPRO INFILE(GIMZPOOL) + > OUTDATASET(&HLQ..GLOBAL.CSI) Tom's presentation notes that substitution is done at application *read* tim

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread zMan
On Fri, Feb 8, 2013 at 10:01 AM, David Andrews wrote: > On Fri, 2013-02-08 at 09:29 -0500, zMan wrote: > > Does the enhanced symbol support mean that you can use symbols in places > > like this: > > REPRO INFILE(GIMZPOOL) + > > OUTDATASET(&HLQ..GLOBAL.CSI) > Sorry to

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Tom Wasik
The SYMBOLS= keyword is on the DD DATA or DD * JCL. It controls what symbols are substituted in the instream data sets ... so yes, in places like: REPRO INFILE(GIMZPOOL) + OUTDATASET(&HLQ..GLOBAL.CSI) The way the substitution works is it looks to compress blanks to t

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread David Andrews
On Fri, 2013-02-08 at 11:03 -0500, zMan wrote: > Sorry to seem dense -- is that a "no"? I didn't answer your question (sorry), but you brought to mind an interesting caveat. Read-time has 1001 uses, and probably a couple of gotchas. Excuse my digression. -- David Andrews A. Duda & Sons, Inc. d

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Paul Gilmartin
On Fri, 8 Feb 2013 10:15:25 -0600, Tom Wasik wrote: > >The way the substitution works is it looks to compress blanks to the right of >the symbol. It will compress strings down to 1 characters trying to keep >characters in the same column that they are in. > Programmers most familiar with ISPF e

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Tom Wasik
>It there aren't enough blanks to compress out, will the line be extended, possibly reallocating a buffer if necessary? (I'm assuming RECFM=VB for the SYSIN. If there are not enough blanks, then the length of the line is extended. If the application or utility passes in a large enough buffer, t

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

2013-02-08 Thread Shane Ginnane
On Fri, 8 Feb 2013 11:52:14 -0600, Tom Wasik wrote: >More detail will be presented at the next SHARE so come to Boston and learn a >lot more. Thanks Tom, nice info. Seems like lots of functionality coming we've all been hanging out for - for years ... :-) Shane ... --