Re: Automation Software and Replacing AF/Operator?
We saw an heavy increase in the number of sites switching from AF/Operator to our system automation suite of products and I had wondered why it seemed that suddenly people were understanding that we were just as comprehensive but a (very) small percentage of the cost. After all we have been in the marketplace for almost 10 years and have added features that they have no chance of duplicating. It never occurred to me to ask anyone her to query them on why they were converting. I just assumed it was because they saw we were more cost effective. Now I'm a little depressed to find that it might be because IBM was forcing them to take another look at their automation support. Bummer. Brian Westerman Syzygy Incorporated www.SyzygyInc.com On Thu, 5 Jun 2014 14:20:52 +0800, Timothy Sipples sipp...@sg.ibm.com wrote: Withdrawal from marketing does not mean withdrawal from service. IBM has not announced an end of service date for AF/OPERATOR Version 3.4.1, and as far as I'm aware there are no plans to do so. There are two core automation tools for z/OS that IBM continues to market: IBM Tivoli System Automation for z/OS (TSAz) and IBM Automation Control for z/OS (ACz). If your automation requirements tend to be quite advanced, TSAz is generally the better choice. Otherwise, take a look at ACz, a new option introduced in 2013. Since these two tools are built on common technology foundations you can start with ACz then move to TSAz if your requirements grow (e.g. GDPS). Or in some cases it may make sense in multi-machine environments to have ACz on one or a couple machines and TSAz on others. For example, if you have one machine placed in a remote country you might equip it with ACz while using TSAz back in your home office on your core Sysplex. (Operational practices and skills are very consistent.) Tivoli NetView for z/OS is a prerequisite for TSAz but not for ACz. But there's certainly no emergency or urgency here. If AF/OPERATOR continues to meet all your needs, no problem. My personal view is that this withdrawal from marketing makes sense given the debut and success of ACz, a tool that frankly filled a gap in IBM's automation offerings, e.g. automation for many new z/OS customers (and for z/OS customers new to automation). TSAz is now a very straightforward upgrade from ACz -- the EC and the BC in the automation toolset, as it were. As another example, there are a lot of customers not running GDPS today who would at least like that option in the future, and again ACz is a great choice because you can roll right into TSAz (and one or more of the GDPS offerings) when/if the time comes. Automation has become part of a much bigger picture, in other words. All that said, I like AF/OPERATOR. If you've got it, and it's doing the job, no problem, stay with it. If there's something in TSAz (or ACz) that attracts you, OK, have a chat with your friendly IBM representative. That migration is non-trivial but a well-worn, successful path. Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automation Software and Replacing AF/Operator?
On Fri, 6 Jun 2014 01:47:53 -0500, Brian Westerman wrote: Now I'm a little depressed to find that it might be because IBM was forcing them to take another look at their automation support. Bummer. Don't be like that mate - console yourself that there are now a few more enlightened souls, and you got the extra business. Can't be all bad. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Any need? DFSORT interface to C language
The COBOL language has a SORT verb which interfaces very well with the DFSORT and Syncsort product. Just as a curiosity, I was wondering if there is any need for a standardized C interface, along the lines of the qsort() run time subroutine. As an aside, does anybody know why C included qsort() and no other sort algorithm? qsort() is O(n log n) in general, but is O(n^2) in degenerate cases (already sorted). I might like an hsort() to implement heap sort which is O(n log n) in all cases. But wouldn't a bsort(), bubble sort, be useful to sort a small amount of data? Would it be worth while to bother writing some code for CBT distribution which implements the above interface to DFSORT, and maybe even includes an hsort() and bsort()? Or is C just not the language for this sort (pun intended) of processing? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 2014-06-06 at 06:58 -0500, John McKown wrote: But wouldn't a bsort(), bubble sort, be useful to sort a small amount of data? Yes, but for no more than a double handful of elements. If simplicity is your goal then consider comb sort, a small tweak to bubble sort with an impressive dividend. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
If you want to do the work, a C interface to DFSORT and/or SYNCSORT on
the model of the IBM-supplied COBOL and PL/I interfaces would be very
useful.
The relative merits of C as a language for implementing sort
algorithms are not really of much interest. Controversy about these
merits can be avoided. Every non-trivial sort is I/O bound. The
efficiency of its specialized I/O operations makes or breaks a sort,
and they are implemented in assembly language by specialists. Novices
and even people with years of experience in other kinds of development
cannot expect to be useful.
Perhaps also worth noting is that in your discussions of
sort-algorithm performance you have underestimated the merits of the
bubble sort for already fully [or almost fully] ordered data and, of
course, for this case only. A bubble sort is optimal, does just N - 1
verificatory comparisons and no exchanges for the N keys in the
multiset
K = {k(1) = k(2) = . . . = k(i) = . . . = k(N)}.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
John, Not exactly a SORT Verb interface, but you CAN call both DFSORT and ICETOOL from C and C++ programs. The key is to use the system() function in the C/C++ program and supply the needed JCL and control statements when you execute the program. Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/06/2014 04:58:33 AM: From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 06/06/2014 04:58 AM Subject: Any need? DFSORT interface to C language Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu The COBOL language has a SORT verb which interfaces very well with the DFSORT and Syncsort product. Just as a curiosity, I was wondering if there is any need for a standardized C interface, along the lines of the qsort() run time subroutine. As an aside, does anybody know why C included qsort() and no other sort algorithm? qsort() is O(n log n) in general, but is O(n^2) in degenerate cases (already sorted). I might like an hsort() to implement heap sort which is O(n log n) in all cases. But wouldn't a bsort(), bubble sort, be useful to sort a small amount of data? Would it be worth while to bother writing some code for CBT distribution which implements the above interface to DFSORT, and maybe even includes an hsort() and bsort()? Or is C just not the language for this sort (pun intended) of processing? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, Jun 6, 2014 at 11:25 AM, Sri h Kolusu skol...@us.ibm.com wrote: John, Not exactly a SORT Verb interface, but you CAN call both DFSORT and ICETOOL from C and C++ programs. The key is to use the system() function in the C/C++ program and supply the needed JCL and control statements when you execute the program. Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 Thanks, Kolusu DFSORT Development IBM Corporation Thanks for that reference! Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? The book mentions UNIX files, but not named pipes (FIFOs). That might be an interesting way to emulate the INPUT and OUTPUT procedure facility that the COBOL SORT verb has, rather than trying to implement the equivalent of the E15 and E35 exit points in C. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 09:25:09 -0700, Sri h Kolusu wrote: John, Not exactly a SORT Verb interface, but you CAN call both DFSORT and ICETOOL from C and C++ programs. The key is to use the system() function in the C/C++ program and supply the needed JCL and control statements when you execute the program. Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 JCL? I thought that system() runs a POSIX shell. But I suppose that shell could use the submit utility to submit batch JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, Jun 6, 2014 at 12:09 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Fri, 6 Jun 2014 09:25:09 -0700, Sri h Kolusu wrote: John, Not exactly a SORT Verb interface, but you CAN call both DFSORT and ICETOOL from C and C++ programs. The key is to use the system() function in the C/C++ program and supply the needed JCL and control statements when you execute the program. Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 JCL? I thought that system() runs a POSIX shell. But I suppose that shell could use the submit utility to submit batch JCL. That's what I thought too. It turns out that on z/OS, system() has two modes: POSIX(ON) and ANSI (or POSIX(OFF)) mode. In POSIX(ON) it works like a UNIX person would expect, running UNIX programs or shell scripts by doing a spawn() of /bin/sh to run the argument command. But in ANSI mode, the system() uses a z/OS LINK macro to run the specified program, with an optional PARM which is like the JCL EXEC PARM=. Apparently the ANSI form of system() runs the LINK'ed to program in the same address space as the caller. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1C0/3.1001.3 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? John, Yes you can. Check this example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/11.5.11 Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/06/2014 09:54:44 AM: From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 06/06/2014 09:55 AM Subject: Re: Any need? DFSORT interface to C language Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Fri, Jun 6, 2014 at 11:25 AM, Sri h Kolusu skol...@us.ibm.com wrote: John, Not exactly a SORT Verb interface, but you CAN call both DFSORT and ICETOOL from C and C++ programs. The key is to use the system() function in the C/C++ program and supply the needed JCL and control statements when you execute the program. Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 Thanks, Kolusu DFSORT Development IBM Corporation Thanks for that reference! Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? The book mentions UNIX files, but not named pipes (FIFOs). That might be an interesting way to emulate the INPUT and OUTPUT procedure facility that the COBOL SORT verb has, rather than trying to implement the equivalent of the E15 and E35 exit points in C. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
It's clear that Sri's suggestion is functionally adequate; but it is, I think, less perspicuous than the sort of thing you were proposing. Anyone who understands the, usually, several sets of conventions involved can of course call/invoke anything from C; but only a few of the applications programmers who are most likely to want to invoke/ATTACH an external sort from C do in fact understand them. Moreover, a properly designed interface can insulate its users from trivial changes in their environments. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z article: Artifacts -- Holding on to History
Right and thanks! Buttons are covered in second part; I sent the editor an added sentence about Barry's buttons. Ed Finnellefinnel...@aol.com said: http://www.mxg.com/thebuttonman/index.htm dasdbi...@comcast.net writes: Holy horrors, Batman! You omitted Barry Merrill's very hefty white lab coat, covered outside and in with buttons. -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, Jun 6, 2014 at 12:54 PM, John Gilmore jwgli...@gmail.com wrote: It's clear that Sri's suggestion is functionally adequate; but it is, I think, less perspicuous than the sort of thing you were proposing. Anyone who understands the, usually, several sets of conventions involved can of course call/invoke anything from C; but only a few of the applications programmers who are most likely to want to invoke/ATTACH an external sort from C do in fact understand them. Moreover, a properly designed interface can insulate its users from trivial changes in their environments. John Gilmore, Ashland, MA 01721 - USA One of my hopes is that, if I do write something, it would be as conceptually as easy for a C programmer to use as the SORT verb is for the COBOL programmer. Perhaps with an interface similar to what qsort() uses. I would guess most C programmers who need to sort would be familiar with qsort(). I may well not be qualified to actually accomplish this. But it would be a glorious failure! grin/ Even more ambitious would be a DFSORT class for C++. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
I would argue you should expose the full function of DFSORT control statements if you can. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 06/06/2014 19:06 Subject:Re: Any need? DFSORT interface to C language Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Fri, Jun 6, 2014 at 12:54 PM, John Gilmore jwgli...@gmail.com wrote: It's clear that Sri's suggestion is functionally adequate; but it is, I think, less perspicuous than the sort of thing you were proposing. Anyone who understands the, usually, several sets of conventions involved can of course call/invoke anything from C; but only a few of the applications programmers who are most likely to want to invoke/ATTACH an external sort from C do in fact understand them. Moreover, a properly designed interface can insulate its users from trivial changes in their environments. John Gilmore, Ashland, MA 01721 - USA One of my hopes is that, if I do write something, it would be as conceptually as easy for a C programmer to use as the SORT verb is for the COBOL programmer. Perhaps with an interface similar to what qsort() uses. I would guess most C programmers who need to sort would be familiar with qsort(). I may well not be qualified to actually accomplish this. But it would be a glorious failure! grin/ Even more ambitious would be a DFSORT class for C++. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, Jun 6, 2014 at 1:22 PM, Martin Packer martin_pac...@uk.ibm.com wrote: I would argue you should expose the full function of DFSORT control statements if you can. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Well, there seems to be some interest, if I can do it well enough. My first order of business is to read up on DFSORT. I know the basics, but not much about the exits. I am especially concerned about the compatibility with C and the use of POSIX(ON) for UNIX and POSIX(OFF) for legacy. And how to implement some features which, in COBOL, are done using special registers. sigh/ design is not my strong suit. I'm a sysprog, Jim! not a software engineer! -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 10:47:46 -0700, Sri h Kolusu wrote: Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? John, Yes you can. Check this example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/11.5.11 Is them UNIX pipes or BatchPipes? For the former, I'd expect to see such as //SORTIN DD PATH='/...'. What's SUBSYS=PIPE? What's SUBSYS=BP01? publibz? Not InfoCenter? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
Not following the link I don't know how you got to BP01 or PIPE but the first of these two (at least) sounds like a BatchPipes/MVS subsystem name. In fact it's the classic example name. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu To: IBM-MAIN@listserv.ua.edu Date: 06/06/2014 20:05 Subject:Re: Any need? DFSORT interface to C language Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Fri, 6 Jun 2014 10:47:46 -0700, Sri h Kolusu wrote: Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? John, Yes you can. Check this example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/11.5.11 Is them UNIX pipes or BatchPipes? For the former, I'd expect to see such as //SORTIN DD PATH='/...'. What's SUBSYS=PIPE? What's SUBSYS=BP01? publibz? Not InfoCenter? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automation Software and Replacing AF/Operator?
Don't get me wrong, I'm please that we picked up another 90 people so far this year, when we normally add only about 30 all year long, but I was really hoping it was because of the new automatic sending of the MaxCC and StepCC email/text messages or the ability to store job information for years without using tons of resources. That's just two of the big things I've added in the past year, but it appears that it might be that IBM releasing one short service end notice was better for us than thousands of hours of design and coding work. :) They could have said something sooner and I could have taken a vacation. Brian On Fri, 6 Jun 2014 02:10:25 -0500, Shane Ginnane ibm-m...@tpg.com.au wrote: On Fri, 6 Jun 2014 01:47:53 -0500, Brian Westerman wrote: Now I'm a little depressed to find that it might be because IBM was forcing them to take another look at their automation support. Bummer. Don't be like that mate - console yourself that there are now a few more enlightened souls, and you got the extra business. Can't be all bad. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 12:26:00 -0500, John McKown wrote: Check out the smart DFSORT Trick C/C++ calls to DFSORT and ICETOOL at http://www.ibm.com/support/docview.wss?uid=isg3T794 JCL? I thought that system() runs a POSIX shell. But I suppose that shell could use the submit utility to submit batch JCL. That's what I thought too. It turns out that on z/OS, system() has two modes: POSIX(ON) and ANSI (or POSIX(OFF)) mode. In POSIX(ON) it works like a UNIX person would expect, running UNIX programs or shell scripts by doing a spawn() of /bin/sh to run the argument command. But in ANSI mode, the system() uses a z/OS LINK macro to run the specified program, with an optional PARM which is like the JCL EXEC PARM=. Apparently the ANSI form of system() runs the LINK'ed to program in the same address space as the caller. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1C0/3.1001.3 Wherein I see: The system() function has two different behaviors. These behaviors are designated as ANSI system() and POSIX system(). The ANSI system() behavior is based on the ISO C standard definition of the function, whereas the POSIX system() behavior is based on the POSIX standard definition. The ANSI system() behavior is used when a) running POSIX(OFF) or b) when running POSIX(ON) and environment variable __POSIX_SYSTEM is set to NO. Otherwise the POSIX system() behavior is used. They seem to be trying to make me believe that the ISO C standard definition is incompatible with the POSIX standard definition. I bet it's not and that the POSIX behavior is entirely compatible with ANSI/ISO. It's a shame that while both behaviors might be useful within a single program, the programmer is required to choose between them with a global setting. But does it work to run POSIX(ON) and toggle the __POSIX_SYSTEM(YES|NO) locally about calls to system()? IBM would have done better to make system() follow the prevailing POSIX convention and invent a new name, e.g. __IBM_system() for the idiosyncratic one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 11:54:44 -0500, John McKown wrote: Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? The book mentions UNIX files, but not named pipes (FIFOs). That might be an interesting way to emulate the INPUT and OUTPUT procedure facility that the COBOL SORT verb has, rather than trying to implement the equivalent of the E15 and E35 exit points in C. I just tried it successfully with SORTIN allocated to a POSIX pipe (not a BatchPipe). The spirit of UNIX, suggested by the first three letters of its name, is that everything is a file, and all files are (mostly) the same. The hazard might arise if DFSORT attempted to reposition its SORTIN, not possible with special files. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, Jun 6, 2014 at 3:01 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: snip IBM would have done better to make system() follow the prevailing POSIX convention and invent a new name, e.g. __IBM_system() for the idiosyncratic one. I wouldn't even have bothered with using system() to do a LINK function. I'd likely have created a __link() function instead. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 15:49:48 -0500, John McKown wrote: IBM would have done better to make system() follow the prevailing POSIX convention and invent a new name, e.g. __IBM_system() for the idiosyncratic one. I wouldn't even have bothered with using system() to do a LINK function. I'd likely have created a __link() function instead. The non-POSIX variant has two subvariants, one for LINK and one for TMP. I think Rexx did well with: address SH address TSO address LINKPGM address LINKMVS ... and many others, all different. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
Gil, My apologies. Pipes in here meant BatchPipes. SUBSYS is a Jcl parameter. Here is a sample to write to an unix pipe. This job will create a pipe with 2000 records. //HFSDAT1 EXEC PGM=SORT //SORTDIAG DD DUMMY //SYSOUT DD SYSOUT=* //SORTIN DD * //SORTOUT DD PATH='/tmp/HFSINP', //LRECL=80,BLKSIZE=3200,RECFM=FB,DSNTYPE=PIPE, //PATHOPTS=(OWRONLY,OCREAT), //PATHMODE=(SIWUSR,SIRUSR), //PATHDISP=(KEEP,DELETE) //SYSINDD * OPTION COPY OUTFIL REPEAT=1000 //* Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/06/2014 12:05:37 PM: From: Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu To: IBM-MAIN@listserv.ua.edu, Date: 06/06/2014 12:05 PM Subject: Re: Any need? DFSORT interface to C language Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Fri, 6 Jun 2014 10:47:46 -0700, Sri h Kolusu wrote: Do you know if DFSORT supports allocating SORTIN and SORTOUT to UNIX pipes (FIFOs)? John, Yes you can. Check this example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/11.5.11 Is them UNIX pipes or BatchPipes? For the former, I'd expect to see such as //SORTIN DD PATH='/...'. What's SUBSYS=PIPE? What's SUBSYS=BP01? publibz? Not InfoCenter? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Metal C
All: Does anyone know where I can find a comparison of Metal C vs IBM XL C ….? I am particularly interested in what Metal C does not support. Does it support threads and TCPIP ? Regards, Scott www.idmworks.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C
Scott, This is the Metal C Programming Guide and Reference (watch the wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CCRUG130/CCONTENTS?SHELF=cbcbs1c0DN=SA23-2225-03DT=20100705233441 To answer your questions, No and No. AFAICT, Metal C is intended as an HLL (FSVO HLL) replacement for assembler, to be used for such things as exits or any other reason(s) you may have that require assembler-level capabilities. As the name suggests, it is a bare metal flavor of C, with a very limited number of C library functions available. All library functions are installed standard in z/OS system memory and accessed via jump control blocks. IOW, no LE here, and no actual library of functions so no dynamic load or static link of library routines, and if you write it on your system it should run on someone else's system at the same or higher (and sometimes lower) level. So no C library routines for threads or for TCPIP, but you could write your own in Metal C if you should choose to do so. I wouldn't, but maybe that's just me. OTOH you can write Metal C code that ATTACHes real z/OS tasks and WAIT's on real ECB lists (using the real assembler macros), or uses BSAM for playing with datasets, etc. There's more, but those are the bare facts as I know them. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, June 06, 2014 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Metal C All: Does anyone know where I can find a comparison of Metal C vs IBM XL C ….? I am particularly interested in what Metal C does not support. Does it support threads and TCPIP ? Regards, Scott -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
On Fri, 6 Jun 2014 13:06:00 -0500, John McKown wrote: One of my hopes is that, if I do write something, it would be as conceptually as easy for a C programmer to use as the SORT verb is for the COBOL programmer. Perhaps with an interface similar to what qsort() uses. I would guess most C programmers who need to sort would be familiar with qsort(). I may well not be qualified to actually accomplish this. But it would be a glorious failure! grin/ Even more ambitious would be a DFSORT class for C++. I don't know if this helps but there are Java classes in the JZOS toolkit: http://www.ibm.com/developerworks/java/zos/javadoc/jzos/com/ibm/jzos/sample/dfsort/package-summary.html http://www.ibm.com/developerworks/java/zos/javadoc/jzos/jzos240/index.html?com/ibm/jzos/sample/nonvsam/file/package-summary.html Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C
Peter, I assumed no based on what I read but I didn't see it in the manual per se. I appreciate the help. Just means we write in XL C ... Scott ford www.identityforge.com from my IPAD On Jun 6, 2014, at 6:24 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Scott, This is the Metal C Programming Guide and Reference (watch the wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CCRUG130/CCONTENTS?SHELF=cbcbs1c0DN=SA23-2225-03DT=20100705233441 To answer your questions, No and No. AFAICT, Metal C is intended as an HLL (FSVO HLL) replacement for assembler, to be used for such things as exits or any other reason(s) you may have that require assembler-level capabilities. As the name suggests, it is a bare metal flavor of C, with a very limited number of C library functions available. All library functions are installed standard in z/OS system memory and accessed via jump control blocks. IOW, no LE here, and no actual library of functions so no dynamic load or static link of library routines, and if you write it on your system it should run on someone else's system at the same or higher (and sometimes lower) level. So no C library routines for threads or for TCPIP, but you could write your own in Metal C if you should choose to do so. I wouldn't, but maybe that's just me. OTOH you can write Metal C code that ATTACHes real z/OS tasks and WAIT's on real ECB lists (using the real assembler macros), or uses BSAM for playing with datasets, etc. There's more, but those are the bare facts as I know them. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, June 06, 2014 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Metal C All: Does anyone know where I can find a comparison of Metal C vs IBM XL C ….? I am particularly interested in what Metal C does not support. Does it support threads and TCPIP ? Regards, Scott -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any need? DFSORT interface to C language
An example in another language is always helpful. And I know trust the peoples who first designed and implemented JZOS. On Jun 6, 2014 6:23 PM, Norbert Friemel nf.ibmm...@web.de wrote: On Fri, 6 Jun 2014 13:06:00 -0500, John McKown wrote: One of my hopes is that, if I do write something, it would be as conceptually as easy for a C programmer to use as the SORT verb is for the COBOL programmer. Perhaps with an interface similar to what qsort() uses. I would guess most C programmers who need to sort would be familiar with qsort(). I may well not be qualified to actually accomplish this. But it would be a glorious failure! grin/ Even more ambitious would be a DFSORT class for C++. I don't know if this helps but there are Java classes in the JZOS toolkit: http://www.ibm.com/developerworks/java/zos/javadoc/jzos/com/ibm/jzos/sample/dfsort/package-summary.html http://www.ibm.com/developerworks/java/zos/javadoc/jzos/jzos240/index.html?com/ibm/jzos/sample/nonvsam/file/package-summary.html Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TS7740 Migration to New Data Center
1) Set up an appropriate mgmtclas that includes the correct copy consistencies of the final destination. 2) Set up storage class to set the volumes for highest priority to clear from cache. 3) Build LIBRARY commands to alter the volumes MGMTCLAS STORCLAS 4) Mount each and every volume in order from BVIR report as suggested by Graham On Fri, Jun 6, 2014 at 7:40 AM, Graham Harris harris...@gmail.com wrote: The way we load things into cache is to use the BVIR logical-to-physical mapping report to build JCL streams to reference the logical tapes to bring them into the cache, with a single physical mount. Can't help you with removing from the cache, but would interested if you do find out! Thought i did find a LIBRARY command to remove things from cache at one point, but it didnt appear to do anything. On 5 June 2014 22:45, Joe Ogle joe.o...@baer-consulting.com wrote: Hello all - Have a client with a two cluster TS7740 grid with TS3500 backstore. All but 6TB of 600TB of tape resides in the backstore, and time in cache for a given vtape is about a week. Client is migrating data centers - has purchased duplicate config for their new location, and we're adding those to the existing grid to affect the replication. Boxing up the physical cartridges and overnighting is not in play for reasons I'm not privy to. We're having to engineer a way to do this via copy consistency on the grid. Trying to figure out a largely hands-off way to get a vtape loaded to cache from the backstore such that it will trigger a pull from the destination cluster via copy consistency settings and then force it off the cache when done. And of course, I have to throttle this in a way that I don't fill the cache in a manner that an unacceptable number of production mounts are pulled from the backstore. Bonus functionality would be to get this to load all vtapes stored on a single 3592 so I'm not hanging/reading the same cartridge multiple times. I can't see a way to make this happen via LIBRARY commands, Sitting in front of a browser clicking on the TS7740 MI's and doing this manually has little appeal, but I'm out of ideas. Any suggestions would be most welcome and appreciated. Joe Ogle Senior Systems Consultant Baer Consulting, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
