Discussion:
IBM to stabilize JES3 (was: IBM to finally drop JES3)
Add Reply
Peter Relson
2017-08-30 11:43:59 UTC
Reply
Permalink
Raw Message
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.

Maybe in practice stabilization will result in some JES3 users choosing to
move (perhaps because they need new function that would become available
only in JES2), but IBM is not dropping JES3, nor did the statement of
direction say or imply anything about doing so. That's like saying just
because we might have stabilized some system service that you must stop
using it. That too would be a faulty conclusion.

Regardless, input such as what Cheryl W refers to is important.

(John Eells would probably have stated the above in a cleaner way;
apologies to him.)

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-08-30 14:06:23 UTC
Reply
Permalink
Raw Message
[Default] On 30 Aug 2017 04:43:59 -0700, in bit.listserv.ibm-main
Post by Peter Relson
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.
The handwriting was on the wall decades ago on JES3. SMS was made
available to JES2 shops on XA but not JES3. JES3 required the
licensing of BDT to get SNA NJE while JES2 had it native. SNA NJE
between JES3 and VSE did not work requiring resolution by what I
recall was the Network Protocol Board (I was the systems and JES3
programmer at the shop that was first to try it). Over the years the
more expensive job entry sub-system was the last to get some new
functions if it ever got them. I would highly recommend that JES3
shops have an active project to get off JES3 and save money.

Clark Morris
Post by Peter Relson
Maybe in practice stabilization will result in some JES3 users choosing to
move (perhaps because they need new function that would become available
only in JES2), but IBM is not dropping JES3, nor did the statement of
direction say or imply anything about doing so. That's like saying just
because we might have stabilized some system service that you must stop
using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dyck, Lionel B. , TRA
2017-08-30 14:22:46 UTC
Reply
Permalink
Raw Message
Clark - an active project to get off JES3 - that is easier said than done. There is no cost justification for doing so, there is no ROI, there is no significant benefit to such a project. All a site will encounter is significant costs to (a) retrain sysprogs, operators, all JECL users, (b) convert from using JES3 DJC to the not quite the same JES2 DJC networks, (c) loss of data set awareness allowing jobs to enter execution only to wait for data sets held exclusive (disp new/old) or trying to access data sets exclusive, (d) loss of functionality from locally developed DSPs, (e) conversion of all JES3 user exits with probable loss of functionality, (f) updating all automation tools to use JES2 commands (assuming there are equivalent commands), (g) the lost opportunity to use the resources spent on the migration for other projects that help the company be more competitive, more productive, save money, be more agile, improve operations, support their users/customers, etc.

Just my $0.01

This e-mail reflects only my opinion and not those of my employer or those I'm contracting with.

--------------------------------------------------------------------------
Lionel B. Dyck
Mainframe Systems Programmer - TRA


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Wednesday, August 30, 2017 8:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop JES3)
Post by Peter Relson
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.
The handwriting was on the wall decades ago on JES3. SMS was made available to JES2 shops on XA but not JES3. JES3 required the licensing of BDT to get SNA NJE while JES2 had it native. SNA NJE between JES3 and VSE did not work requiring resolution by what I recall was the Network Protocol Board (I was the systems and JES3 programmer at the shop that was first to try it). Over the years the more expensive job entry sub-system was the last to get some new functions if it ever got them. I would highly recommend that JES3 shops have an active project to get off JES3 and save money.

Clark Morris
Post by Peter Relson
Maybe in practice stabilization will result in some JES3 users choosing
to move (perhaps because they need new function that would become
available only in JES2), but IBM is not dropping JES3, nor did the
statement of direction say or imply anything about doing so. That's
like saying just because we might have stabilized some system service
that you must stop using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Beaver
2017-08-30 14:43:19 UTC
Reply
Permalink
Raw Message
There are probably several reasons IBM is shutting own JES3

The install base has dwindled such that is costs more to support
that revenue generated.
Also I have not seen in years people use a JES3 console. People
have scheduling systems
Vs. JES3 Scheduling

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Dyck, Lionel B. (TRA)
Sent: Wednesday, August 30, 2017 9:24 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)

Clark - an active project to get off JES3 - that is easier said than done.
There is no cost justification for doing so, there is no ROI, there is no
significant benefit to such a project. All a site will encounter is
significant costs to (a) retrain sysprogs, operators, all JECL users, (b)
convert from using JES3 DJC to the not quite the same JES2 DJC networks, (c)
loss of data set awareness allowing jobs to enter execution only to wait for
data sets held exclusive (disp new/old) or trying to access data sets
exclusive, (d) loss of functionality from locally developed DSPs, (e)
conversion of all JES3 user exits with probable loss of functionality, (f)
updating all automation tools to use JES2 commands (assuming there are
equivalent commands), (g) the lost opportunity to use the resources spent on
the migration for other projects that help the company be more competitive,
more productive, save money, be more agile, improve operations, support
their users/customers, etc.

Just my $0.01

This e-mail reflects only my opinion and not those of my employer or those
I'm contracting with.

--------------------------------------------------------------------------
Lionel B. Dyck
Mainframe Systems Programmer - TRA


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, August 30, 2017 8:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)

[Default] On 30 Aug 2017 04:43:59 -0700, in bit.listserv.ibm-main
Post by Peter Relson
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.
The handwriting was on the wall decades ago on JES3. SMS was made available
to JES2 shops on XA but not JES3. JES3 required the licensing of BDT to get
SNA NJE while JES2 had it native. SNA NJE between JES3 and VSE did not work
requiring resolution by what I recall was the Network Protocol Board (I was
the systems and JES3 programmer at the shop that was first to try it). Over
the years the more expensive job entry sub-system was the last to get some
new functions if it ever got them. I would highly recommend that JES3 shops
have an active project to get off JES3 and save money.

Clark Morris
Post by Peter Relson
Maybe in practice stabilization will result in some JES3 users choosing
to move (perhaps because they need new function that would become
available only in JES2), but IBM is not dropping JES3, nor did the
statement of direction say or imply anything about doing so. That's
like saying just because we might have stabilized some system service
that you must stop using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-08-30 15:04:27 UTC
Reply
Permalink
Raw Message
I think with the job scheduling function in JES2, the fact that JES2 is able to
handle the JES3 JCL cards, it is probably not as difficult to move JES3 to JES2
usage.

Lizette
Post by Dyck, Lionel B. , TRA
-----Original Message-----
Behalf Of Steve Beaver
Sent: Wednesday, August 30, 2017 7:44 AM
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)
There are probably several reasons IBM is shutting own JES3
The install base has dwindled such that is costs more to support that
revenue generated.
Also I have not seen in years people use a JES3 console. People have
scheduling systems
Vs. JES3 Scheduling
-----Original Message-----
Behalf Of Dyck, Lionel B. (TRA)
Sent: Wednesday, August 30, 2017 9:24 AM
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)
Clark - an active project to get off JES3 - that is easier said than done.
There is no cost justification for doing so, there is no ROI, there is no
significant benefit to such a project. All a site will encounter is
significant costs to (a) retrain sysprogs, operators, all JECL users, (b)
convert from using JES3 DJC to the not quite the same JES2 DJC networks, (c)
loss of data set awareness allowing jobs to enter execution only to wait for
data sets held exclusive (disp new/old) or trying to access data sets
exclusive, (d) loss of functionality from locally developed DSPs, (e)
conversion of all JES3 user exits with probable loss of functionality, (f)
updating all automation tools to use JES2 commands (assuming there are
equivalent commands), (g) the lost opportunity to use the resources spent on
the migration for other projects that help the company be more competitive,
more productive, save money, be more agile, improve operations, support their
users/customers, etc.
Just my $0.01
This e-mail reflects only my opinion and not those of my employer or those
I'm contracting with.
--------------------------------------------------------------------------
Lionel B. Dyck
Mainframe Systems Programmer - TRA
-----Original Message-----
Behalf Of Clark Morris
Sent: Wednesday, August 30, 2017 8:56 AM
Subject: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop JES3)
[Default] On 30 Aug 2017 04:43:59 -0700, in bit.listserv.ibm-main
Post by Peter Relson
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.
The handwriting was on the wall decades ago on JES3. SMS was made available
to JES2 shops on XA but not JES3. JES3 required the licensing of BDT to get
SNA NJE while JES2 had it native. SNA NJE between JES3 and VSE did not work
requiring resolution by what I recall was the Network Protocol Board (I was
the systems and JES3 programmer at the shop that was first to try it). Over
the years the more expensive job entry sub-system was the last to get some
new functions if it ever got them. I would highly recommend that JES3 shops
have an active project to get off JES3 and save money.
Clark Morris
Post by Peter Relson
Maybe in practice stabilization will result in some JES3 users choosing
to move (perhaps because they need new function that would become
available only in JES2), but IBM is not dropping JES3, nor did the
statement of direction say or imply anything about doing so. That's
like saying just because we might have stabilized some system service
that you must stop using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dyck, Lionel B. , TRA
2017-08-30 15:11:39 UTC
Reply
Permalink
Raw Message
The JES2 implementation of DJC is not as transparent as it could be - there are some features that will cause a JCL error from what I saw in the SHARE presentation on JES2 support for JES3 JECL - and I guarantee that your most critical jobs use it :-)

--------------------------------------------------------------------------
Lionel B. Dyck
Mainframe Systems Programmer - TRA

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Wednesday, August 30, 2017 10:06 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop JES3)

I think with the job scheduling function in JES2, the fact that JES2 is able to handle the JES3 JCL cards, it is probably not as difficult to move JES3 to JES2 usage.

Lizette
Post by Dyck, Lionel B. , TRA
-----Original Message-----
On Behalf Of Steve Beaver
Sent: Wednesday, August 30, 2017 7:44 AM
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)
There are probably several reasons IBM is shutting own JES3
The install base has dwindled such that is costs more to support that
revenue generated.
Also I have not seen in years people use a JES3 console. People have
scheduling systems
Vs. JES3 Scheduling
-----Original Message-----
On Behalf Of Dyck, Lionel B. (TRA)
Sent: Wednesday, August 30, 2017 9:24 AM
Subject: Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)
Clark - an active project to get off JES3 - that is easier said than done.
There is no cost justification for doing so, there is no ROI, there is
no significant benefit to such a project. All a site will encounter is
significant costs to (a) retrain sysprogs, operators, all JECL users,
(b) convert from using JES3 DJC to the not quite the same JES2 DJC
networks, (c) loss of data set awareness allowing jobs to enter
execution only to wait for data sets held exclusive (disp new/old) or
trying to access data sets exclusive, (d) loss of functionality from
locally developed DSPs, (e) conversion of all JES3 user exits with
probable loss of functionality, (f) updating all automation tools to
use JES2 commands (assuming there are equivalent commands), (g) the
lost opportunity to use the resources spent on the migration for other
projects that help the company be more competitive, more productive,
save money, be more agile, improve operations, support their users/customers, etc.
Just my $0.01
This e-mail reflects only my opinion and not those of my employer or
those I'm contracting with.
----------------------------------------------------------------------
----
Lionel B. Dyck
Mainframe Systems Programmer - TRA
-----Original Message-----
On Behalf Of Clark Morris
Sent: Wednesday, August 30, 2017 8:56 AM
Subject: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop
JES3)
[Default] On 30 Aug 2017 04:43:59 -0700, in bit.listserv.ibm-main
Post by Peter Relson
It is very disturbing to see someone use an inflammatory
representation such as the initial subject of this thread when that
is very much *not* what the SOD said.
The handwriting was on the wall decades ago on JES3. SMS was made
available to JES2 shops on XA but not JES3. JES3 required the
licensing of BDT to get SNA NJE while JES2 had it native. SNA NJE
between JES3 and VSE did not work requiring resolution by what I
recall was the Network Protocol Board (I was the systems and JES3
programmer at the shop that was first to try it). Over the years the
more expensive job entry sub-system was the last to get some new
functions if it ever got them. I would highly recommend that JES3 shops have an active project to get off JES3 and save money.
Clark Morris
Post by Peter Relson
Maybe in practice stabilization will result in some JES3 users
choosing to move (perhaps because they need new function that would
become available only in JES2), but IBM is not dropping JES3, nor did
the statement of direction say or imply anything about doing so.
That's like saying just because we might have stabilized some system
service that you must stop using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2017-08-30 15:17:43 UTC
Reply
Permalink
Raw Message
Post by Steve Beaver
Also I have not seen in years people use a JES3 console.
Haha! Probably because JES3 console support was removed in MVS/ESA 5.2.1.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Larre Shiller
2017-08-30 14:17:45 UTC
Reply
Permalink
Raw Message
...in fact, the Statement Of Direction doesn't even mention the word "stabilization"...!

For the record, it states:

<snip>
For several decades, z/OS has offered two spooling subsystems: JES2 (formerly HASP) and JES3 (formerly ASP). JES2 is used by the majority of z/OS customers and has evolved into nearly a superset of functionality over JES3. IBM is affirming that JES2 is the strategic Job Entry Subsystem for z/OS. New function in spooling subsystems will be primarily developed only for JES2. JES2 supports unique features in the area of availability such as spool migration, online merging of spool volumes, and in the area of function such as support for email notification when a job completes and soon in the area of security with encryption of spool data.

JES3 continues to be supported and maintained with its current function.
<snip>

So... the only thing that it actually says about the future direction of JES3 is that "...JES2 is the strategic Job Entry Subsystem for z/OS" and that "...new function in spooling subsystems will be *primarily* [emphasis mine] developed only for JES2." To my mind, that doesn't mean that no new functionality will be introduced to JES3... only that the focus will be on adding functionality to JES2. Now.... I suppose that one might equate all of that with "stabilization"... but truly, that's not one of the carefully chosen words the SOD and it's a characterization and a direction that SSA (as a JES3 customer) will certainly be pushing back on.

Larre Shiller
US Social Security Administration

"The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government."

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-08-30 14:19:46 UTC
Reply
Permalink
Raw Message
Peter certainly has no reason I can see to apologize for his post (and
certainly not to me!). Here's what was actually announced:

"For several decades, z/OS has offered two spooling subsystems: JES2
(formerly HASP) and JES3 (formerly ASP). JES2 is used by the majority of
z/OS customers and has evolved into nearly a superset of functionality
over JES3. IBM is affirming that JES2 is the strategic Job Entry
Subsystem for z/OS. New function in spooling subsystems will be
primarily developed only for JES2. JES2 supports unique features in the
area of availability such as spool migration, online merging of spool
volumes, and in the area of function such as support for email
notification when a job completes and soon in the area of security with
encryption of spool data.

"JES3 continues to be supported and maintained with its current function."

This is pretty far from "dropping JES3," at least for the foreseeable
future, from where I sit. We have any number of components for which we
never or rarely provide new function. This is not exactly a State
Secret. A quick glance through the table starting on p. 2 of z/OS V2.2
Planning for Installation (PDF p. 16) shows the last update for each
z/OS element. Some say "OS/390 V1R1" only because that's when we
created the book, and are actually older than that, such as EREP and
MICR/OCR.

My prediction, worth what you paid for it, is that JES3 will stick
around for a while.
Post by Peter Relson
It is very disturbing to see someone use an inflammatory representation
such as the initial subject of this thread when that is very much *not*
what the SOD said.
Maybe in practice stabilization will result in some JES3 users choosing to
move (perhaps because they need new function that would become available
only in JES2), but IBM is not dropping JES3, nor did the statement of
direction say or imply anything about doing so. That's like saying just
because we might have stabilized some system service that you must stop
using it. That too would be a faulty conclusion.
Regardless, input such as what Cheryl W refers to is important.
(John Eells would probably have stated the above in a cleaner way;
apologies to him.)
Peter Relson
z/OS Core Technology Design
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-30 14:36:05 UTC
Reply
Permalink
Raw Message
Post by Larre Shiller
.... I suppose that one might equate all of that with "stabilization"... but truly, that's not one of the carefully chosen words the SOD and it's a characterization and a direction that SSA (as a JES3 customer) will certainly be pushing back on.
Which compels IBM to dilute its development and support resource, to the
detriment of both JES2 and JES3 customers.

And it bisects the dwindling pool of experienced systems talent available
to customers' HR.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2017-08-30 15:16:00 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
Post by Larre Shiller
.... I suppose that one might equate all of that with "stabilization"... but truly, that's not one of the carefully chosen words the SOD and it's a characterization and a direction that SSA (as a JES3 customer) will certainly be pushing back on.
Which compels IBM to dilute its development and support resource, to the
detriment of both JES2 and JES3 customers.
Not true AT ALL! JES3 customers are paying IBM seriously big money ($$$)
to develop, maintain and support JES3. My most recent estimate is that
they receive ~50X the funding they need for this effort. More than
enough to hire, train and educate an entire army of young, energetic POK
(or Rochester or wherever) developers, testers and support people to
make JES3 do just about anything they want it to.

If there has been any detriment to JES2 customers in recent years, it
has been IBM "wasting" development resource desperately attempting to
"jam" JES3 functionality into JES2 in hopes of making JES2 a more
palatable spooling platform to its JES3 customers. Functions like 8-byte
job class, converter/interpreter, dependent job control, deadline
scheduling, accepting/understanding JES3 JECL, etc. are all part of this
effort. However, such JES2 technology improvements do little to address
the real costs of a JES strategy conversion and have therefore, for the
most-part, fallen on deaf ears in the JES3 community.

Based on my anecdotal observations of our JES2 customers, I would say
they don't seem too interested in these "improvements" either. JES2 DJC
has some interest on the surface, but no real traction that I have
observed, probably because the JCL is too complex. (They might get a few
to use the new, simplified z/OS 2.3 BEFORE/AFTER support that works
similar to the Mellon mods.) A handful of JES2 customers seem to be
using HOLDUNTL= and related keywords. That's about it. The rest of the
functionality is being eschewed -- probably because JES2 folks recognize
those features as coming from that *other* JES. Yuck! LOL
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-08-30 14:55:22 UTC
Reply
Permalink
Raw Message
My $0.02:
Approx. 20 years ago I learnt that IBM prefer customers to use JES2, not
JES3. And JES2 is free - included in the price, while JES3 is extra
paid. And JES2 customer base is definitely bigger than JES3 users base.
The message was clear for me, pretty much.

Now, we hear no new features will be added to JES3. That's still the
same message.

IMHO IBM is veeeery patient with JES3 customers. It's almost like with
ISAM support ;-)
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Wasik
2017-08-30 18:46:58 UTC
Reply
Permalink
Raw Message
I apologize if my presentation on the JES2 support for the //*NET statement led you to believe that existing DJC NETs will get JCL errors when run in JES2. There are keywords that JES2 ignores, but they do not generate errors (they generate warning message in the JCL output but warning message in JES2 do not stop the job from successfully converting and running).

For the records, JES2 supports the keywords that make sense in a JES2 environment (NETID, NHOLD, RELEASE, NETREL, NORMAL, ABNORMAL, ABCMP, NRCMP, OPHOLD). The other keywords that don't make sense in a JES2 environment (DEVPOOL, DEVRELSE, RELSCHCT) are ignored (minimal syntax validation is done) but do NOT generate JCL errors.

JES2 support is complete for the supported keywords and was made to work like the JES3 support. In general, the implementation of JES3 JECL was based on what JES3 does (not what the books say) in an effort to be as compatible as we could. However, JES2's parsing of JECL is done using a generalized parser that may be stricter than what is used by JES3 (JES3 may detect JECL syntax errors that JES3 allows). Also, the character set for things like NETID may be different between JES3 and JES2 because JES2 uses the NETID as the name of a JOBGROUP (it must be a valid job name). For example, JES3 supports NETID=Z*+X but JES2 would JCL error because of the * and the +.

I hope this clarifies what we support.

Tom Wasik
JES Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Longfellow
2017-09-04 22:00:10 UTC
Reply
Permalink
Raw Message
I am a simple man, and can only go by the evidence of what I have seen in
my short (30 year) career using the IBM mainframe.

The term ''functionally stabilized has always been a road sign that the
product or feature is as good as dead. It may be decades, (ISAM, VSAM
Catalogs, etc) before the actual final death. But that phrase tells you
it is coming. Maybe IBM needs a better marketing team to keep us paying
for the walking dead?

Again, just my opinion based upon my experiences.

Loading...