Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Fri Feb 06, 2004 5:23 am Post subject:
Frankjiang,
JES2 =Job Entry Subsystem 2 which is an MVS subsystem that receives jobs into the system, converts them to internal format, selects them for execution, processes their output, and purges them from the system. In an installation with more than one processor, each processor's JES2 subsystem independently controls job input, scheduling, and output processing.
JES3 =Job Entry Subsystem 3 which also an MVS subsystem that receives jobs into the system, converts them to internal format, selects them for execution, processes their output, and purges them from the system. In complexes that have several loosely coupled processing units, the JES3 program manages processors so that the global processor exercises centralized control over the local processors and distributes jobs to them via a common job queue.
The difference between JES2 & JES3 is shown in bold.
Joined: 10 Jan 2004 Posts: 17 Topics: 10 Location: england
Posted: Fri Feb 06, 2004 9:26 pm Post subject:
Hello kolusu:
Thank you for your answer.
As an application developer, I can code a job using JCL. Do I need to learn about JES2/JES3? What is necessary for an application developer about JES2/JES3?
As an application developer, I can code a job using JCL. Do I need to learn about JES2/JES3? What is necessary for an application developer about JES2/JES3?
Interesting question. In my opinion, an application developer should have already learned about the operating system basics (JES, DASD, Channels, tape, I/O processes, etc.) long before they ever got involved with applications design. An application developer has no business coding JCL. Ever. That function, along with QA, testing and turnover, is a low-level task that should be relegated to a lower-level, less technically skilled technician, not a highly skilled application developer, who's time should be spent on more productive tasks.
Should you learn about JES? Probably not. I would think that an application developer's time would be better spent learning how to code in other langauges, on other operating systems; how to use VSAM, CICS, TCP/IP, MQ Series, databases, etc. to build better applications on a variety of platforms.
An application developer has no business coding JCL. Ever.
I totally disagree with this statement!
I think that it's a lot easier and quicker for a developer to code their own JCL than to have to interface with a special 'JCL coder' who may not be available when needed, and may not properly understand your program's requirements. I have always coded my own JCL and never found it a significant overhead. I think knowing basic/intermediate JCL is an essential part of MVS programming for application or systems programmers.
Also, I think that testing (at least unit testing) your own code is much more efficient than having a seperate tester. As long as your testplan is provided by the specifier or independantly checked to ensure it is comprehensive, a competant programmer can test/fix/test/fix until the code is working much faster than if they have to bounce back and forth to a tester.
Just goes to show what radically different views people can have on these subjects....
As far as JES2/JES3 statements are concerned, typically you only need to know a few - e.g. for JES2 'route print','lines','route xeq' etc. and they are very simple.
Basically they are additional statements place in your JCL which are not actual JCL statements but which help control the execution and output of your JCL.
Superk - it appals and fascinates me that you remove QA and testing from the development process. I have worked in the testing arena for the last 8 or 9 years and the consensus amongst testing practitioners of any ilk is that testing should occur as early in the development life cycle as possible and is a mutually exclusive part of it. A quick read of testing methodologies will confirm this.
QA/Testing is far from being a low level task assigned to lesser skilled technicians. Au contraire - developers have an appalling record of delivering bug free code into production (on any platform). My experience with developers has been that whilst they know their own applications well and are technically proficient in that area, they fall to pieces when asked to consider any sort of integrated testing. Logic alone leads me to believe that more highly skilled people will produce higher quality results so leaving your QA up to lesser skilled people would be not only insane but futile.
By the way, how would you expect an application developer to diagnose an abend in a CICS or IMS region without being able to read or understand JCL? _________________ My opinions are exactly that.
As I stated, that was my opinion. After reading some of the responses, I see that I failed to take into account the different environments we all work in, as well as the different industries. My comment was made from a few different perspectives. One, from a mangement point-of-view. Two, since I am not nor have I ever been a programmer, I will confess that I am not intimately familiar with the normal responsibilities that that role involves. Third, I can only draw upon what my experience has been in the past. I have worked in finance, health care, and now, insurance (all in the U.S.) and for all these companies, the one common fact has been that tasks of programming (by which I specifically mean coding) has always been separated from the tasks of testing, debugging, implementation, and support.
If there was any offense taken by my reponse, then I am truly sorry. I tend to submit reponses such as the one I did for the sake of discussion, not as a slam to your profession.
Yeah, I was appalled... ...in the shocked sense of the word if you like - I wasn't offended, just blown away by ignorance from an otherwise capable and knowledgable contributor to these and other forums. You admitted your lack of experience arena which has allayed my righteous outrage somewhat
I will say this though, when giving your opinion to people who are clearly at or below entry level in a particular field, perhaps it would be wiser to point them to other resources for help or not answer at all rather than give an uninformed opinion.
That being said I will now be treading carefully in the forums where you hold the upper hand...and I have marshmallows at the ready if you feel the temptation to flame. _________________ My opinions are exactly that.
Superk - Iam curious about something that you have mentioned.
********
Third, I can only draw upon what my experience has been in the past. I have worked in finance, health care, and now, insurance (all in the U.S.) and for all these companies, the one common fact has been that tasks of programming (by which I specifically mean coding) has always been separated from the tasks of testing, debugging, implementation, and support
********
Is it that separation of programming from QA a management style these companies were adopting or is such a style required due to nature of the business domain itself (finance, healthcare and insurance)?
"Is it that separation of programming from QA a management style these companies were adopting or is such a style required due to nature of the business domain itself (finance, healthcare and insurance)?"
I would say a little of both. When I first started in I/T back in the early 80's, the management style was "lean and mean", which meant avoiding any excess overhead as much as possible. At that time, there were four groups in I/T: Operations, Programming (Application Support), Technical Services (Operating System/Network Programming), and Help Desk (Network Support).
Tech Support enforced standards and provided the language environments (compilers, optimizers, etc.) as well as any in-house or third-party utilities (lots of code from Share and Guide), and created charge-back from SMF using SAS and Easytrieve.
Programming developed the application code, CICS transactions, and overall system requirments, and were the laisons to the end users. Programming did all their own QA.
The Help Desk resolved problems with connectivity, outages, network issues, and handled basic data transmissions.
The operations staff handled scheduling, disaster recovery, wrote all the batch processes (JCL and PROC's), tape management, output management, laser and microfilm printer programming, and provided additional charge-back reports for such stuff as printer usage, microfilm usage, tape usage, and paper and toner usage.
As the years progressed, it seems that the managment directives took a different turn, and started to mandate the use of specialists wherever they were needed. Instead of having just programmers, now we had COBOL programmers, C programmers, SAS programmers, and even programmers working for other divisions outside of IT. This is a trend that seems to be reversing these days.
At the last shop I worked in, which was in healthcare, the nature of the business dictated that the QA process be removed from programming and be placed firmly on the shoulders of the business users. Part of this was the result of internal politics (the CIO reported to the Director of Finance, who reported to the CFO, who reported to the CEO). It was the CFO who mandated that his staff (under the Director of Finance) have then direct responsibility for QA testing. It actually makes sense. Since it is the business users who are directing the IT staff to work on their projects, it makes sense that they would be the ones to QA the end product. Also, they are the ones with all the rules of the business for the particular project. Also, since we were dealing with federal agencies (Medicare, CDC, HCFA, etc.), state agencies (Medicaid, Blue Cross/Blue Shield, etc.), hospitals, and private insurance agencies (Aetna, Cigna, WebMD, etc.), most of these companies had policies that allowed for only one point of contact for an organization, which would normally be a contact witihn the business group.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
...in the shocked sense of the word if you like - I wasn't offended, just blown away by ignorance from an otherwise capable and knowledgable contributor to these and other forums. You admitted your lack of experience arena which has allayed my righteous outrage somewhat 