On Mon, Mar 28, 2016 at 6:37 PM, Rick Troth <[email protected]> wrote:
> Do a little googling on the license question. I can't think of any > problems from going with the MIT license, but IANAL. > > > On 03/28/16 10:25, John McKown wrote: > >> ... >> Anyway, I'm still thinking of how it will be designed. But I am curious if >> the requirement of z/OS 2.1 would make it unusable to a lot of people >> here. >> I know we have some members who are still on OS/390. My employer is >> stabilized on z/OS 1.12. >> > > But you're talking about interfacing with a feature of z/OS 2.1 and above. > Yes, this will be tested on a friend's z/OS 2.2 system, not on my employer's system. > > I wanted to say something about "avoid excessive requirements", but don't > make your life complicated. (Unless you just wanna re-invent ENF code 78 > functionality.) Keep it simple. > Looks like ENF code 70 is very similar, except that it is invoked for _every_ JOB, STC, and TSU that goes through JES. Whereas ENF 78 is only invoked for JOBs which are submitted when the JES symbol SYS_JOB_NOTIFY exists. Apparently with _any_ value, just that it simply exists. > > > Oh, any_decent_ ideas about what to call this? I'm so non-marketing >> oriented, I would likely call is YAJSTS (Yet Another Job Submission & >> Tracking System). Which a decent synopsis of what it_is_, but is not >> pronounceable. I'll work on that name. >> > > I can't help with that, but ... _the name is essential_. I remember one > guy, a brilliant programmer, who simply could not start on a certain > project until he had the name. (It became a major tool in that organization > in those days.) So ... excellent vision recognizing that need at this > stage. Please just don't name it after a child's pet or toy. "USPS Jeep" > would be more fitting. Or maybe Take-a-Number. No, that one's taken. > Well, right now, I'm writing code and documentation on Linux/Intel. It's sitting in the directory: ~/zos/YAJSTS for lack of a better name. Some of what I'm doing might be ?unacceptable? to z/OS people because I'm writing documentation, like the README, in Linux for rendering on Linux. E.g. README.md is a plain text README file, in "markdown" format. This is readable by people as is, but can be rendered into HTML or UNIX man or a number of other formats using a program called pandoc. When I actually get around to writing documentation, I plan to use either LyX, or (more likely) TeXstudio. LyX uses its own, plain text, file format, and renders into LaTeX. TeXstudio uses LaTeX as its native file format. LaTeX is a plain-text markup language which can be converted via a number of different programs into many formats such as HTML, HTML5, PDF, MS Word docx (why would I do that?!?), and a ton of others. Basically, this means that the entire system is being developed with a UNIX mind-set instead of a conventional z/OS mind-set. I, personally, consider this acceptable because the code is going to be using UNIX facilities, so UNIX will need to be running correctly for it to work at all. I will likely include a job to copy the UNIX resident files into PDSE libraries. I say PDSE because that's what I use. I guess it might be possible to use a legacy PDS as well. I know that many here despise PDSEs. I've been very fortunate to have never had a problem with them. > > -- R; <>< > > -- How many surrealists does it take to screw in a lightbulb? One to hold the giraffe and one to fill the bathtub with brightly colored power tools. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
