M.S.S. Inc LOGO The SHARED SPOOL MODS Page

McColley Systems Software Inc.
If it's assembler, WE CAN HELP!
" Elegant Solutions for Your Processing Needs "


Home   Shared Spool Mods   ESSM!   Tip of the Month   Articles   Free Source   LINKS   ASSEMBLER SURVIVAL GUIDE   ABOUT US  


I am finally able to offer annual support and maintenance contracts for the Mellon Shared Spool Mods! Details and contact information are located at the ,bottom of this page, let me know if need formal support to run the Shared Spool Mods.

The "Shared Spool Mods" also formerly known as the "Mellon Shared Spool Mods" (a set of JES2 exits written in assembler language) have been around for over 20 years that I know of. I have personally maintained them for the last 15+ years including a major rewrite so that they no longer modified JES2 code directly, but instead used only well documneted, supported exits and interfaces.

Our new product ESSM - Enhanced Shared Spool Mods can be used to replace all of the Shared Spool Mods functionality, and provide you with additional control that the Shared Spool Mods were never intended to provide. See the ESSM! Page for additional information. or use the contact information at the bottom of this page to request more information about the ESSM product.

The Shared Spool Mods expand the function of JES2 job selection and scheduling. One of the original purposes of the mods was to allow job routing based on some local resource definitions that could be moved or attached to one or more, but not necessarily all of the JES2 nodes in a MAS configuration. For instance, let's assume you have a shop with 2 LPARs that share a JES2 spool in a single MAS configuration, ok so far so good. Now let's say we have some special piece of equipment, like a fiche writer, that is attached to one system or the other, but never both, and you also have batch jobs that must allocate the fiche writer. How do you code your JCL so that your job always runs where the fiche reader is attached even when you don't know where it will be attached when your job runs? Well, short of a special 'fiche jobs only' jobclass, you can't, not without something like the shared spool mods. They allow a shop to define a resource, like a fiche writer, or a tape drive, or a CICS or DB2 region, or third shift that could be logically associated with different LPARs at different times from day to day, and allow the shop to define where the resource currently lives, and if it is currently active anywhere. If they are defining a fiche machine that needs to be moved from one LPAR to another, or a CICS that might run on one LPAR today, and on another tomorrow, the shop can also redefine where the resource is at any point in time. Further, new JCL (JECL actually) is defined to allow you to specify that your job needs to run where your needed resource lives.

If that all sounds a heck of a lot like JES2 Scheduling environments and resources, that's good - because the JES2 / WLM scheduling environment and the new JCL keyword SCHENV= came directly out of a long standing requirement that JES2 adopt the same scheduling capabilities that the 'Mellon Shared Spool Mods' had offered for years through it's exits and "/*ROUTE XEQ " card processing!

Of course the 'Shared Spool Mods' as they are known today, did a good bit more than just job routing based on scheduling environments. They also provide for complex job serialization of multiple jobs - which is an excellent way to serialize a Software of batch job that update anything. For instance this facility can be used to serialize all SMP/e jobs that perform updates, as long as the JCL in each job specifies a common resource and claims exclusive use of the resource. Another feature is to schedule jobs to run 'BEFORE' or 'AFTER' other named jobs run, still other features allow jobs to be held until a specific time of day occurs, or to be held for at least a specified number of hours, minutes, and seconds which combined with job submission through the internal reader is able to provide a crude job scheduling for jobs that must run on some fixed frequency. Another feature of the 'Shared Spool Mods' is that you can limit the total number of jobs that are allowed to run in any given jobclass, on a single JES2, regardless of initiator setup. This same thing can now be accomplished via standard JES2 parms and commands, but at the time it first became available that was not true.

The features all work very well. They are incorporated into a handful of documented, supported JES2 exits, and the entire source is supplied as part of the package you can download from the CBT Tape web site. I think you will find it on file #766, and the mods should still work on z/OS 1.10 anyway. Although as a good friend of mine recently found out, you can be a very good assembler programmer, but JES2 exit coding is a very special environment, not to be entered into lightly. In other words, " Don't try this at home - we are professionals ", but all kidding aside you can modify the mods with great care, and plenty of testing!

There is one warning that I need to pass along. If you intend to use the mods with work load managed initiators, under certain circumstances they may cause jobs in a given service class (whether they are using Shared Spool Mods controls or not) to simply no longer be selected for work, perhaps for a very long time.

Of course if you don't intend to use work load managed initiators, the Shared Spool Mods work very well.

Since I wrote the current incarnation of the Shared Spool Mods, I would like to tell you that I am working on a fix for the WLM problem, and that it will be incorporated into the existing free set of code. Unfortunately the WLM 'problem' is going to require a significant rewrite and may have to for some time simply not work well in shops that also require the use of WLM managed initiators. I do intend to correct that particular little problem as soon as I can get the time.

The good news is that there is a COMMERCIAL REPLACEMENT coming for the Shared Spool mods! It is called ESSM - Enhanced Shared Spool Mods. I expect to have ESSM ready by the 1st quarter of 2012. This new product ESSM - Enhanced Shared Spool Mods will be able to completely replace the need for the Shared Spool Mods.

I thought I should give you some idea as to what "ESSM" will be able to do, so here are some of the intended features.



For full details, to add your requirements to the features list, or to participate in out BETA testing program, See the ESSM! link for more info!


I can finally offer annual maintenance and support contracts for the Shared Spool Mods

For those of you who are simply not comfortable running unsupported JES2 exits - even if you have all of the source for the exits, as is the case with the Shared Spool Mods, I can finally offer you an annual maintenance and support contract.

I understand the perceived problem, even though the software is free, and you have the entire source code, what happens if it stops working? Is there anyone in your shop that is capable of quickly diagnosing the problem and correcting it? If there is someone, will he or she be available and do they have the time? The Shared Spool Mods are considered by most to be a critical component for their operations, and if they fail, whether or not it is likely that they will fail, what can you do if they do fail? What if they don't fail, what if it only appears that the Shared Spool Mods have failed but the problem really lies elsewhere? Do you have senior systems programmers on site that are capable of debugging that type of scenario? I suppose the final question that this all comes down to is "Is running an unsupported critical component defensible if anything does go wrong?"   I am afraid we all know the answer to that question already.

But now, I can offer you both technical support - via phone and or e-mail on either a 24 X 7 or 9am - 5pm weekday basis, as well as guaranteed timely updates for every operating system update IBM makes available - within 45 days of the time IBM makes the operating system available to us. I have been providing 24 X 7 support for the Mellon Shared Spool Mods as well as many other products to a large regional bank for the last 15 years. I have plenty of experience supporting the Shared Spool Mods, indeed I wrote the current version of the mods myself. Even if you are simply curious about the cost of the support, for your own piece of mind, please use the contact information at the bottom of this page so that I can contact you, and I will be happy to quote you a price.

By the way, the price for a maintenance and support contract, or for that matter the price of any software package that I sell, is never based on the size of your processor. I do however; have an additional charge if you run multiple processing centers, exclusive of hot disaster recovery sites. So just let us know how many sites you have processors located in, that will run the Shared Spool Mods, and I can give you a price that you can be sure will never increase simply because your processor size changes, you may want to ask why your other vendors feel they should charge more whenever you grow your business.

Remember -

Use this link to Contact Us. if your e-mail system is on this machine.

Or simply give us a call during normal business hours M - F, at (770)-335-0478

Stephen.McColley@MVSProgrammer.com


Valid XHTML 1.0 Transitional Valid CSS!
Last updated August 2011 - copyright © 2011 McColley Systems Software Inc.
Return to top of Page.