On Sun, Nov 10, 2013 at 9:02 AM, John McDowell <[email protected]> wrote:
> My thought is to contain the changes to the Converter only, no changes to > the Interpreter or any other components. This will restrict what new > functions can be provided but I think it has the potential to provide some > significant new capability as well as provide a good platform for other > future changes. > OK, this really helps me to understand the scope of what to think on. > > Your comment regarding "new Coke" goes to the heart of my concern. If the > "new JCL" does not provide an overwhelming improvement such that people > want to use it then it probably doesn't make any sense. So the question I > am trying to explore is can there be enough new capability added to the > Converter (only) to get over this threshold ? I think there is, but it all > depends upon what the collective sense what the existing JCL deficiencies > are. > > It probably doesn't need to be said but I will anyway, the introduction of > the "new JCL" would need to exist side by side with the "old JCL". So > unlike the introduction of "new Coke" wherein "Coke classic" suddenly > became a precious commodity "old JCL" will live on :-) I know you are a > Linux/Unix guy so I would describe this as a "fork" (or is it a spawn ?), I > am not a Unix guy so I will defer to you on that :-) You just gotta tip > your hat to an OS that allows you to say: "I need to kill the daemon spawn" > with a straight face :-) > <snip> > > >// JCLLIB ORDER= - One guess - Correct! Allow me to specify a UNIX > >directory for PROCs and members which are // INCLUDE . Again, lower case > >and >8 characters would be nice. > The use of z/OS UNIX directories could actually be contained as a > Converter only change, and thus falls into what I believe is containable. > Although I suspect that "lower case and >8 characters" may be a bridge to > far :-( and would not make the cut. (Note: My guess (I have no specific > knowledge) is that the Converter currently uses FIND or perhaps BLDL to > locate PROCs/INCLUDEs, neither of which provide the needed support. There > is a faint glimmer of hope for this. it would first require that DESERV be > added to the list of services that support z/OS UNIX directories and then > the Converter could take advantage of this support.) > I always thought that the 8 character limit was due to the natural limit of PDS member names. Seems reasonable to retain this due to the "pain" of trying to increase it. But I am certain that FIND / BLDL is in no way restricted to upper case alphabetics only. SMP/E maintained PDS libraries contain really weird (unprintable hex) member names with _no_ problems. And I'm as certain as I can be without having access to the source that SMP/E uses standard BPAM for most of its functions. There is no documentation in the DFSMS manuals about not using any hex value, other than 8x'FF', as a member name. <snip> > >> Snip << > > >John McKown > > John, I judge you to be someone who can see both "classic" z/OS and "new" > Linux/Unix capabilities and is always looking for opportunities to bring > the "new" to the "classic". I think this is a useful and creative outlook > so I thank you for contributions to this discussion. > I'm a Windows refugee who has embraced Linux. And I really even enjoyed MS-DOS and CP-M/80 (let's not talk about TRSDOS, OK?) I do enjoy z/OS UNIX. I am not the partisan that Gil is. But I will use it when it helps _me_ to get _my_ work done. I'll even admit to using awk at times. And liking it! <grin/>. And I absolutely love the stuff that Dovetailed Technologies has done to support z/OS UNIX. Wonderful software that I can run with a no-cost license. > > John McDowell > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
