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

[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 ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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, the full record is 
passed (with the correct length).  If not large enough, then an I/O error 
(buffer too small) is returned.  Application that read SPOOL using ACBs/RPLs 
(not really documented) are passed the actual length and they can come back in 
with a larger buffer and get the full record.  DCB interface is probably going 
to just fail.

>So the value of a very dynamic system symbol such as TIME could vary
from line to line within the same SYSIN?

Yes, that is true.  If you need it to be static, then set a JCL variable to the 
value and use that as variable in the instream data set.  You can now use 
system symbols in batch JCL.

More detail will be presented at the next SHARE so come to Boston and learn a 
lot more.

Tom Wasik
JES2 Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 editor will welcome this behavior;
those more familiar with POSIX here-documents may be less comfortable
with it.  But it's useful.

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.

>The substitution happens "just in time" as the application is running to pick 
>up the latest JES symbols.  JES symbols are dynamic as opposed to JCL symbols 
>that are static.
> 
So the value of a very dynamic system symbol such as TIME could vary
from line to line within the same SYSIN?

>I did not mention PARMDD because it did not hit JES2 at all so there was 
>nothing to really talk about.
> 
A short PDF on syntax with continuation conventions would yet
be welcome.  But I suppose the Reference will happen soon enough.

So for BPXWDYN the programmer will have his choice of PARMDD or
STDPARM.  I wonder if it makes any difference?

Thanks again,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 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.

The substitution happens "just in time" as the application is running to pick 
up the latest JES symbols.  JES symbols are dynamic as opposed to JCL symbols 
that are static.

I did not mention PARMDD because it did not hit JES2 at all so there was 
nothing to really talk about.

Tom
JES2 Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 seem dense -- is that a "no"?
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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*
time, not at conversion.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Martin Packer]

I think it would also make job cloning easier.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/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 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.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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
> 
Mentions:

o System Symbol Substitution in BATCH Jobs
• Any system symbol (IEASYMxx) can be referred to in JCL
• JOBLCASS SYSSYM=ALLOW|DISALLOW option 
• Substitution occurs at conversion time

At last?

o Symbolic Substitution in Instream Data Sets
•   SYMBOLS= keyword on DD DATA or DD * JCL
SYMBOLS=[ ( ] JCLONLY | EXECSYS | CNVTSYS [ , DDname])
•   Substitution as records are read by application

May I assume this means the value of symbols in the context of
the EXEC statement?

•   Blank elimination to try to make things fit •   Overflow if possible, 
I/O error if not

Embedded blanks, or only trailing?
Will this affect the LRECL of a RECFM=VB instream data set?

o Passing Symbols on INTRDR
• SYMLIST= keyword identifies symbols to pass

Will this be a keyword supported by TSO ALLOCATE and BPXWDYN,
presumably as a TU for SVC 99?

No mention of long PARM or PARMDD?

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Don Williams]

Probably related:
1. The PARM length field is historically treated as a signed half word number, 
so max value is 32767 (rather than unsigned 65535).
2. Minimum storage allocation increment, double word or 8 bytes, therefore 
32760 is the largest multiple of 8 less than or equal to 32767.

Don

> -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
> from here:
> 
> 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
> misbehaving badly on 32768.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 card-to-tape, card to-printer and tape to
printer DSP's than ASP. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 get SNA-NJE while JES2 customers got
SNA-NJE built in.  It was one of the nails in the coffin for JES3 at
my shop.  Thankfully we were able to get much of the function we
needed by a combination of CA7 which we were getting anyway, A great
exit 6 from the CBT tape which I extended to lo proc usage and set job
class based on submitter and resources and an MPF exit.

>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 in length to a
>>program from JCL. A new PARMDD DD statement keyword is planned to
>>allow more than 100 characters to be passed to any program in JCL. A
>>new LONGPARM binder attribute is planned to enable APF-authorized
>>programs to use this new function. No changes are planned to be needed
>>for unauthorized programs. This new support is intended to make it
>>easier to pass a large number of parameters to a program without
>>writing intermediate programs.
>> 
>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.
>
>This has considerable overlap with:
>
>| execute the program with an argument greater than 100 bytes, then a
> BPX.EXECMVSAPF.program_name profile should be defined. 
>
>Do we really need two ways of doing this?  If they conflict, which one
>predominates.  (This was introduced by APAR which I'd call an integrity
>APAR, which was mentioned in the manual.  The reference to the APAR
>seems to have vanished.)
>
>>Enhancements for symbol processing in JCL in JES2 environments. This
>>new function is designed to make both JCL and system symbols available
>>during job execution. For example, you will be able to specify that
>>symbols be used in instream data sets, such as SYSIN data sets, and
>>that symbols be retrieved from the system using new programming
>>services. This support is intended to make symbols more usable and
>>accessible and to make it easier to use identical copies of JCL in
>>multiple environments.
>>
>Yaaay!  Synergistic with PARMDD.  But still no system symbols in
>batch JCL?  Rats!  How is record overflow handled when a
>symbol's value exceeds the length of its name.  72-column
>limitation?  Continuation convention?
>
>>Support for the use of exported JCL symbols that are accessible in
>>other contexts, including programmatic access. A corresponding
>>function is planned for Language Environment .
>>
>>Support for new, JES-independent JCL specifications. New SYSTEM and
>>SYSAFF keywords for the JOB statement are planned to allow you to
>>specify z/OS MVS? system names, JES2 MAS member names, and JES3 main
>>system names. Both job entry subsystems will be designed to direct the
>>job to an appropriate system.
>>
>>JES2 is planned to add support to allow you to specify the JES2
>>procedure library concatenation to be used for a job, improve OUTPUT
>>processing by allowing you to specify that an OUTPUT statement be used
>>for multiple SYSOUT data sets, and optional improvements in
>>converter/interpreter processing. These changes are intended to make
>>it easier to write JCL that can run unchanged under either primary
>>subsystem, JES2 or JES3.
>>...
>>JES3 is planned to support in-stream data sets in cataloged procedures
>>and INCLUDE groups. This is intended to allow you to simplify the JCL
>>used in PROCs by using in-stream data sets in place of those pointed
>>to by DD statements that use the DSN keyword.
>> 
>Didn't this appear a release or two ago?  Or only JES2?  May we assume
>(always dangerous to assume consistency from IBM)  that those
>instream data sets may include PARMDD, with symbol substution, and
>that different symbol values will be substituted if the same PROC is
>invoked in different steps?  (I.e. the substitution is performed at the
>point of PROC expansion, not at PROC definition.)
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 Kelley - IBM POK Lab - z/OS Core Technical Development


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 newcomers in the group,
  HASP was the ancestor of JES2 and ASP
  was the ancestor of JES3)

Perhaps Lynn has some historic background available.



my wife was in the gburg JES group for awhile ... before being con'ed
into going to POK to be responsible for loosely-coupled architecture
... (where she did peer-coupled shared data architecture ... saw very
little uptake except for IMS hot-standby, until sysplex & parallel
sysplex)
http://www.garlic.com/~lynn/submain.html#shareddata

one of her tasks in the JES group was part of the ASP catchers to turn
it into JES3 ... she did a lot of the initial type-1 documentation.

she then did JESUS ... JES Unified System ... the essential features
from both JES2 & JES3 that the respective customers couldn't live w/o
... internal politics prevented it from getting very far.

old post
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

with lots of old tales ... justification for adding virtual
memory to MVT, other stuff. I had done various stuff with HASP
as undergraduate in the 60s.

Simpson, Crabtree and others at Houston Manned Space Center, used their
experience on Moonlight (DCS) system for HASP (Houston Automatic
Spooling Priority System). At the same time, west region used their
experience with Moonlight to create ASP.


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.



some more discussion of "Project Moonlight" (effort to extend life of
7090/7094) ... says somebody's notes from a share 79 presentation:
http://computer-programming-forum.com/10-asm370/c0d31d8bd52f759c.htm
session O441 - The History of HASP and JES2


Which includes:

"Later when the S/360 was out, the former Project Moonlight team from
Houston went to Los Angeles to build the "Attached Support Processor" for
S/360.  They took ASP back with them to Houston"

So this is a little ambiguous - as almost all good history is!

... SHARE 79

http://www.redbug.org/dba/sharerpt/share79/o441.html

I was has at the March 1968 houston share meeting ... I had done a whole
lot of work on HASP & MFT ... but I was also doing a lot of work on cp67
... I was at the session for the science center announcement for
(virtual machine) cp67 ... but also went to HASP sessions.

other trivia mentioned in above ... refers to HASP networking turning
into JES2 networking coming from a univ. for long time the code running
on the internal network nodes still carried "TUCC" identifier in all the
source cards. problem was thatq the networking support JES2 inherited
used left-over entries in the 255-slot psuedo device table and would
trash traffic where either the origin &/or destination was defined in
the table (usually limited to around 160 entries). the internal network
was very quickly more than 255 entries ... so required limiting
HASP/JES2 nodes to boundaries to keep them from excessively trashing
traffic. The other characteristic was that header had mixed up JES2 and
networking information ... and traffic between different JES2 systems
could result in system crashes and requiring MVS to be rebooted.

misc. past posts mentioning HASP &/or JES2
http://www.garlic.com/~lynn/submain.html#hasp

misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 ancestor of JES2 and ASP
>  was the ancestor of JES3)
>
> Perhaps Lynn has some historic background available.


my wife was in the gburg JES group for awhile ... before being con'ed
into going to POK to be responsible for loosely-coupled architecture
... (where she did peer-coupled shared data architecture ... saw very
little uptake except for IMS hot-standby, until sysplex & parallel
sysplex)
http://www.garlic.com/~lynn/submain.html#shareddata 

one of her tasks in the JES group was part of the ASP catchers to turn
it into JES3 ... she did a lot of the initial type-1 documentation.

she then did JESUS ... JES Unified System ... the essential features
from both JES2 & JES3 that the respective customers couldn't live w/o
... internal politics prevented it from getting very far.

old post
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

with lots of old tales ... justification for adding virtual
memory to MVT, other stuff. I had done various stuff with HASP
as undergraduate in the 60s.

Simpson, Crabtree and others at Houston Manned Space Center, used their
experience on Moonlight (DCS) system for HASP (Houston Automatic
Spooling Priority System). At the same time, west region used their
experience with Moonlight to create ASP.

some more discussion of "Project Moonlight" (effort to extend life of
7090/7094) ... says somebody's notes from a share 79 presentation:
http://computer-programming-forum.com/10-asm370/c0d31d8bd52f759c.htm
session O441 - The History of HASP and JES2 ... SHARE 79
http://www.redbug.org/dba/sharerpt/share79/o441.html

I was has at the March 1968 houston share meeting ... I had done a whole
lot of work on HASP & MFT ... but I was also doing a lot of work on cp67
... I was at the session for the science center announcement for
(virtual machine) cp67 ... but also went to HASP sessions.

other trivia mentioned in above ... refers to HASP networking turning
into JES2 networking coming from a univ. for long time the code running
on the internal network nodes still carried "TUCC" identifier in all the
source cards. problem was thatq the networking support JES2 inherited
used left-over entries in the 255-slot psuedo device table and would
trash traffic where either the origin &/or destination was defined in
the table (usually limited to around 160 entries). the internal network
was very quickly more than 255 entries ... so required limiting
HASP/JES2 nodes to boundaries to keep them from excessively trashing
traffic. The other characteristic was that header had mixed up JES2 and
networking information ... and traffic between different JES2 systems
could result in system crashes and requiring MVS to be rebooted.

misc. past posts mentioning HASP &/or JES2
http://www.garlic.com/~lynn/submain.html#hasp

misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet


-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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) 
 I loaned my copy of 1172 to a DBA for Halloween and never got it  back.
 
 From 441 description:
 
The Future WorkFlow Management Task Force developed the Future Work  Flow 
Management Task Force Report, especially concerned with Job Entry  
Subsystems. This was the second in a series of heavy-duty SHARE task forces in  
the 
80s: LSRAD, FWFM, InterSYS, SSTF. This was the "beta" version of the button,  
about 1/2 dozen of which were made. The "gold" release was the SumJes logo  
surrounded by "Get it up once -- Keep it up forever" and "Continuous  
Operations". See buttons 1171 and 1172
 
 
In a message dated 2/5/2013 7:39:18 A.M. Central Standard Time,  
steve_con...@ao.uscourts.gov writes:

Lots of  JES2 and JES3 work being done, a lot of it pointing to convergence 
of the  two products.

Interesting  stuff.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 halfword yields control-block
overflow at 32768.

On 2/5/13, Paul Gilmartin  wrote:
> 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
> misbehaving badly on 32768.
>
> -- gil
>

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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
misbehaving badly on 32768.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 JCL improvements are planned:
>>
>>Support for passing parameter lists up to 32,760 bytes in length to a
>>program from JCL. A new PARMDD DD statement keyword is planned to
>>allow more than 100 characters to be passed to any program in JCL. A
>>new LONGPARM binder attribute is planned to enable APF-authorized
>>programs to use this new function. No changes are planned to be needed
>>for unauthorized programs. This new support is intended to make it
>>easier to pass a large number of parameters to a program without
>>writing intermediate programs.
>>
> 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.
>
> This has considerable overlap with:
>
> | execute the program with an argument greater than 100 bytes, then a
>  BPX.EXECMVSAPF.program_name profile should be defined.
>
> Do we really need two ways of doing this?  If they conflict, which one
> predominates.  (This was introduced by APAR which I'd call an integrity
> APAR, which was mentioned in the manual.  The reference to the APAR
> seems to have vanished.)
>
>>Enhancements for symbol processing in JCL in JES2 environments. This
>>new function is designed to make both JCL and system symbols available
>>during job execution. For example, you will be able to specify that
>>symbols be used in instream data sets, such as SYSIN data sets, and
>>that symbols be retrieved from the system using new programming
>>services. This support is intended to make symbols more usable and
>>accessible and to make it easier to use identical copies of JCL in
>>multiple environments.
>>
> Yaaay!  Synergistic with PARMDD.  But still no system symbols in
> batch JCL?  Rats!  How is record overflow handled when a
> symbol's value exceeds the length of its name.  72-column
> limitation?  Continuation convention?
>
>>Support for the use of exported JCL symbols that are accessible in
>>other contexts, including programmatic access. A corresponding
>>function is planned for Language Environment .
>>
>>Support for new, JES-independent JCL specifications. New SYSTEM and
>>SYSAFF keywords for the JOB statement are planned to allow you to
>>specify z/OS MVS� system names, JES2 MAS member names, and JES3 main
>>system names. Both job entry subsystems will be designed to direct the
>>job to an appropriate system.
>>
>>JES2 is planned to add support to allow you to specify the JES2
>>procedure library concatenation to be used for a job, improve OUTPUT
>>processing by allowing you to specify that an OUTPUT statement be used
>>for multiple SYSOUT data sets, and optional improvements in
>>converter/interpreter processing. These changes are intended to make
>>it easier to write JCL that can run unchanged under either primary
>>subsystem, JES2 or JES3.
>>...
>>JES3 is planned to support in-stream data sets in cataloged procedures
>>and INCLUDE groups. This is intended to allow you to simplify the JCL
>>used in PROCs by using in-stream data sets in place of those pointed
>>to by DD statements that use the DSN keyword.
>>
> Didn't this appear a release or two ago?  Or only JES2?  May we assume
> (always dangerous to assume consistency from IBM)  that those
> instream data sets may include PARMDD, with symbol substution, and
> that different symbol values will be substituted if the same PROC is
> invoked in different steps?  (I.e. the substitution is performed at the
> point of PROC expansion, not at PROC definition.)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

t.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 in length to a
>program from JCL. A new PARMDD DD statement keyword is planned to
>allow more than 100 characters to be passed to any program in JCL. A
>new LONGPARM binder attribute is planned to enable APF-authorized
>programs to use this new function. No changes are planned to be needed
>for unauthorized programs. This new support is intended to make it
>easier to pass a large number of parameters to a program without
>writing intermediate programs.
> 
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.

This has considerable overlap with:

| execute the program with an argument greater than 100 bytes, then a
 BPX.EXECMVSAPF.program_name profile should be defined. 

Do we really need two ways of doing this?  If they conflict, which one
predominates.  (This was introduced by APAR which I'd call an integrity
APAR, which was mentioned in the manual.  The reference to the APAR
seems to have vanished.)

>Enhancements for symbol processing in JCL in JES2 environments. This
>new function is designed to make both JCL and system symbols available
>during job execution. For example, you will be able to specify that
>symbols be used in instream data sets, such as SYSIN data sets, and
>that symbols be retrieved from the system using new programming
>services. This support is intended to make symbols more usable and
>accessible and to make it easier to use identical copies of JCL in
>multiple environments.
>
Yaaay!  Synergistic with PARMDD.  But still no system symbols in
batch JCL?  Rats!  How is record overflow handled when a
symbol's value exceeds the length of its name.  72-column
limitation?  Continuation convention?

>Support for the use of exported JCL symbols that are accessible in
>other contexts, including programmatic access. A corresponding
>function is planned for Language Environment .
>
>Support for new, JES-independent JCL specifications. New SYSTEM and
>SYSAFF keywords for the JOB statement are planned to allow you to
>specify z/OS MVS� system names, JES2 MAS member names, and JES3 main
>system names. Both job entry subsystems will be designed to direct the
>job to an appropriate system.
>
>JES2 is planned to add support to allow you to specify the JES2
>procedure library concatenation to be used for a job, improve OUTPUT
>processing by allowing you to specify that an OUTPUT statement be used
>for multiple SYSOUT data sets, and optional improvements in
>converter/interpreter processing. These changes are intended to make
>it easier to write JCL that can run unchanged under either primary
>subsystem, JES2 or JES3.
>...
>JES3 is planned to support in-stream data sets in cataloged procedures
>and INCLUDE groups. This is intended to allow you to simplify the JCL
>used in PROCs by using in-stream data sets in place of those pointed
>to by DD statements that use the DSN keyword.
> 
Didn't this appear a release or two ago?  Or only JES2?  May we assume
(always dangerous to assume consistency from IBM)  that those
instream data sets may include PARMDD, with symbol substution, and
that different symbol values will be substituted if the same PROC is
invoked in different steps?  (I.e. the substitution is performed at the
point of PROC expansion, not at PROC definition.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 direction, too, I would imagine.
>
>(For the relative newcomers in the group,
>  HASP was the ancestor of JES2 and ASP
>  was the ancestor of JES3)
>
>Perhaps Lynn has some historic background available.
>

Perhaps the archives have the information also (hint!). :-)

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Steve Comstock]

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 direction, too, I would imagine.

(For the relative newcomers in the 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 complaints from 
here:
Date: Tue, 5 Feb 2013 08:39:10 -0500



Lots of JES2 and JES3 work being done, a lot of it pointing to convergence
of the two products.

Interesting stuff.


Cheers,,


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 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:

[Steve Conway]

Lots of JES2 and JES3 work being done, a lot of it pointing to convergence 
of the two products.

Interesting stuff.


Cheers,,