Re: Rexx (was: OT? ... deliberately unfriendly)
I have been using Regina Rexx for some years, started when I was to teach a Rexx course and wanted a good Windows Rexx capability. The OS interfaces are different, but easy enough to use, and it is well documented. It can be found at http://regina-rexx.sourceforge.net/ it is obviously being updated regularly as I am using 3.5 and 3.7 is available and the price is right. Sample of I/O code below. Other OS interfaces I have not used, no need yet. /* Read the file into an array */ INFILE1 = C:\WineBase32\TextFile\WineList.csv lines = 0 do while lines(infile1)0 lines = lines + 1 iline.lines = linein(infile1) end iline.0 = lines Paul -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, 29 November 2013 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx (was: OT? ... deliberately unfriendly) Gil, Haven't used Regina , but have used Open Object Rexx and like the Linux interface. Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Nov 28, 2013, at 11:20 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 28 Nov 2013 07:41:14 -0600, Mike Schwab wrote: http://www.rexxinfo.org/ http://www.rexxla.org/links/ On Thu, Nov 28, 2013 at 3:29 AM, Elardus Engelbrecht wrote: deleted I miss Rexx in command line for OS/2. I believe there are Rexx for windoze, but I haven't looked at it. deleted Google finds many hits for REGINA CYGWIN. But any Rexx stands or falls on the quality of its host command interfaces. THE? Would you want a comand interface to Notepad? I am very pleased with the SYSCALL command environment of Rexx for z/OS (called TSO, but I can forgive that). -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TCBJLB doesn't point to a DCB
The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
Can I use what's pointed to by TCBJLB as a param for DESERV quite frankly the TCB's I have looked at the 4 byte field at offset X'28' from the TCB doesn't look like a address Sent from my iPhone On Nov 29, 2013, at 10:38 AM, Rob Scott rsc...@rocketsoftware.com wrote: The DCB foundation is a different format before and after OPEN and the DCBDDNAM (and other fields) are overlaid by post-OPEN fields - for example DCBTIOT Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 29 November 2013 15:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: TCBJLB doesn't point to a DCB The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname Thanks -- 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
Re: DESERV function get DCB address
In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEKoZLIDu81dAuZgILTrHA0kBAA==@optonline.net, on 11/28/2013 at 02:00 PM, MichealButz michealb...@optonline.net said: I having been using BLDL to get program directory information I found the macro to not give correct results. Please be more specific. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
quite frankly the TCB's I have looked at the 4 byte field at offset X'28' from the TCB doesn't look like a address Post-OPEN DCBs do NOT have an address at offset x'28' - it contains the DCBTIOT field and DCBMACRF Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 29 November 2013 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCBJLB doesn't point to a DCB Can I use what's pointed to by TCBJLB as a param for DESERV quite frankly the TCB's I have looked at the 4 byte field at offset X'28' from the TCB doesn't look like a address Sent from my iPhone On Nov 29, 2013, at 10:38 AM, Rob Scott rsc...@rocketsoftware.com wrote: The DCB foundation is a different format before and after OPEN and the DCBDDNAM (and other fields) are overlaid by post-OPEN fields - for example DCBTIOT Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 29 November 2013 15:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: TCBJLB doesn't point to a DCB The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname Thanks -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
In 0c0cd1f6-1815-4b07-8465-c57f54ae0...@optonline.net, on 11/28/2013 at 03:31 PM, Micheal Butz michealb...@optonline.net said: Binyamin I saw a previous post by you Instructing a user to use TCBJLB For TSOLIB I thought that TSOLIB Was a task library while TCBJLB Points to the joblib DCB [JOB|STEP]LIB is a tasklib. You need to run through the TCB chain trying each tasklib in turn, or use BLDL to find out which is relevant. You didn't say what the incoorect results were; is the concatenation number wrong? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 2290167024549142.wa.zatlas1yahoo@listserv.ua.edu, on 11/28/2013 at 08:08 PM, Ze'ev Atlas zatl...@yahoo.com said: What I envision is a central system catalog that any file name created (reasonably or virtually no limitations on file names, level of hierarchies or any other such limitations [obviously more, much more than 44 characters and 5 levels]) would be transparently cataloged into (by the kernel itself.) Obviously, that catalog entry would have to record (hard coded information such as volser, mounting point or whatever have you) where is that file resides in an absolute manner. Mount point is dynamic, not static. Its more analogous to volser than to device address. Once such a thing is implemented, all you need to do is mention the file name or alias, regardless of where in the system or file system you are. When I ask for 'SYS1.LINKLIB', which of my 20 SYS1.LINKLIB data sets do I get? For people who are not techno-geeks this is much simpler than anything available today. In what way is it simpler than the catalog and directory structures that currently exist? The ordinary user does not need to worry about creating user catalogs or about mounting file systems on empty directories. It's all transparrent to him. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEERlz2jvBKRHoxzeV+FfuzABAA==@optonline.net, on 11/29/2013 at 10:26 AM, MichealButz michealb...@optonline.net said: The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname No; you have to open a DCB before you use it as a tasklib, so the relevant layout is that for an open DCB, not that for a closed DCB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
Using TCBJLB as the input DCB For DESEREV I get a return code of X'0C' reason X'421' invalid DCB Sent from my iPhone On Nov 29, 2013, at 11:10 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEKoZLIDu81dAuZgILTrHA0kBAA==@optonline.net, on 11/28/2013 at 02:00 PM, MichealButz michealb...@optonline.net said: I having been using BLDL to get program directory information I found the macro to not give correct results. Please be more specific. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Rexx (was: OT? ... deliberately unfriendly)
On Fri, 29 Nov 2013 20:59:26 +1100, Paul Gillis wrote: I have been using Regina Rexx for some years, started when I was to teach a Rexx course and wanted a good Windows Rexx capability. The OS interfaces are different, but easy enough to use, and it is well documented. It can be found at http://regina-rexx.sourceforge.net/ it is obviously being updated regularly as I am using 3.5 and 3.7 is available and the price is right. Sample of I/O code below. Other OS interfaces I have not used, no need yet. IOW, it uses Rexx-standard I/O instead of z-peculiar I/O. /* Read the file into an array */ INFILE1 = C:\WineBase32\TextFile\WineList.csv lines = 0 do while lines(infile1)0 lines = lines + 1 iline.lines = linein(infile1) end iline.0 = lines (But it would be useful to be able to read a file into a compound variable with a single instruction rather than coding a loop. Hmmm... I wonder how this works if infile is a terminal?) Disastrously, the z/OS Rexx provides two instances of the standard Rexx I/O. One, adjunct to the Rexx compiler, deals only with legacy data sets; the other, adjunct to Unix System services, deals only with UNIX files. Conway's law. I wonder whether CMS Rexx deals alike with MDFS, SFS, and BFS flles, accessing SFS files via directory paths rather than filemodes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Wed, 6 Nov 2013 10:06:23 +0800, David Crayford wrote: On 6/11/2013 8:31 AM, Jon Perryman wrote: ... standard security on z/OS is provided by a single programming interface regardless of the ESM you are using. It's a shame to same can't be said of the file system. In Unix everything is a file and shares the same API. I use the same interface for files, sockets, printers, terminals, modems or any other device. I wish OS/360 had a similar unifying design principle back in the day. I believe OS/360 started out with the right idea: all I/O was done via DCBs. But as capabilities were extended, the designers elected to develop alternatives rather than broadening existing interfaces. E.g. TSO's terminal I/O's spurning DCBs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
On Fri, 29 Nov 2013 11:32:45 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 0717adf1-8fde-41db-940d-77a882817...@optonline.net, on 11/29/2013 at 10:45 AM, Micheal Butz michealb...@optonline.net said: Can I use what's pointed to by TCBJLB as a param for DESERV ObFoma Yes. quite frankly the TCB's I have looked at the 4 byte field at offset X'28' from the TCB doesn't look like a address Why would you expect it to? Look at your DCBD macro expansion. Why would you expect a TCB to match the DCB DSECT? Clearly, at that point he is talking about TCB+X'28, not DCB+X'28'. I'm too lazy to check if that is a 4 byte address though, and not one of the three byte relics with something else in the top byte. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Thu, 28 Nov 2013 20:08:59 -0600, Ze'ev Atlas wrote: What I envision is a central system catalog that any file name created (reasonably or virtually no limitations on file names, level of hierarchies or any other such limitations [obviously more, much more than 44 characters and 5 levels]) There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Mount point is dynamic, not static. Its more analogous to volser than to device address. Again, you discuss the shortcoming of a specific system while I have a broad view. Implementation would have to take things like volser, mount points or whatever and hide them once and for all from the user Once such a thing is implemented, all you need to do is mention the file name or alias, regardless of where in the system or file system you are. When I ask for 'SYS1.LINKLIB', which of my 20 SYS1.LINKLIB data sets do I get? There would always be the need to disambiguate. That need would either be answered either automatically by the system examining the context, or, and I've mentioned it, one may add hints to lead the system to the one file he or she needs. The example given by Shmuel is z/OS specific and if the user is sophisticated enough to need a specific SYS1.LINKLIB, he or she would probably be sophisticated enough to provide hinting information. Otherwise, whatever the system chooses is probably the correct one. For people who are not techno-geeks this is much simpler than anything available today. In what way is it simpler than the catalog and directory structures that currently exist? The ordinary user does not need to worry about creating user catalogs or about mounting file systems on empty directories. It's all transparrent to him. That's correct and that's where I took the idea from. That concept needs improvements which many in this conversation had alluded to. Another great idea from the z/OS that deserve implementation in that context (i.e. Central System Catalog) is the famous GDG. Whenever I explain the concept to my Unix friends they agree that such a brilliant idea should have been implemented in Unix as well. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
You can (in theory -- I have) create a dataset: A.B.C... Which would limit you to 22 levels. The level is not the limit: it's the combination of node length (8 bytes) and DSN length (44) that determines 'levels'. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Paul Gilmartin paulgboul...@aim.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 29 Nov 2013 11:36:21 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers On Thu, 28 Nov 2013 20:08:59 -0600, Ze'ev Atlas wrote: What I envision is a central system catalog that any file name created (reasonably or virtually no limitations on file names, level of hierarchies or any other such limitations [obviously more, much more than 44 characters and 5 levels]) There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. -- 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
Re: OT? Opinion article on software design being deliberately unfriendly
Most interesting talk. Many thanks for the link. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, November 29, 2013 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT? Opinion article on software design being deliberately unfriendly On Wed, 27 Nov 2013 14:21:47 -0500, John Gilmore wrote: Shmuel characterizes my notion that there is an ineluctable conflict between power andease of use as a copout. I wish it were; but here the microsoft view that choices are the enemy is often correct. Users do not ordinarily know what they want to do in any constructive sense. They have global ease-of-use and performance goals, functional objectives. They seldom have even a vague notion what processing strategies are in use and what effects the parameterizations/choices available to them will have on performance or resource use. ... http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html -- 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 11/29/2013 12:36 PM, Paul Gilmartin wrote: There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. While I don't remember a 5-level limit, there always was (and will be?) a practical limit. Using every possible legal name, even at a single level, exhausts space available on any early DASD. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I don't recall the official limit. I did just allocate USER123.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.RS Not sure what this proves.. On 11/29/2013 12:49 PM, Gerhard Postpischil wrote: On 11/29/2013 12:36 PM, Paul Gilmartin wrote: There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. While I don't remember a 5-level limit, there always was (and will be?) a practical limit. Using every possible legal name, even at a single level, exhausts space available on any early DASD. Gerhard Postpischil Bradford, Vermont -- 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Under OS/360 the notional, antetypical 'longest' index had the syntax level1.level2.level3.level4.level5 Then, since leveli values could be at most 8 characters in length, 5 x 8 + 4 yielded the maximal character count of 44. The 44-character and 8-character maxima remain; the 5-level maximum does not. 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Should be 22 levels (A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V is a valid DSN). Todd Burrell, PMP, ITIL Expert | Project Manager | ITSO AHB | Centers for Disease Control and Prevention (CDC) Contractor - HP Enterprise Services | 1600 Clifton Rd, Building 21, MS D24, RM 1300 | Atlanta, GA 30338 | 404-971-7275 (Blackberry) 404-723-2017 (Mobile) | z...@cdc.gov THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is for use only by the intended recipient. If you received this in error, please notify the sender and delete the communication from all computers. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Babonas Sent: Friday, November 29, 2013 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers I don't recall the official limit. I did just allocate USER123.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.RS Not sure what this proves.. On 11/29/2013 12:49 PM, Gerhard Postpischil wrote: On 11/29/2013 12:36 PM, Paul Gilmartin wrote: There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. While I don't remember a 5-level limit, there always was (and will be?) a practical limit. Using every possible legal name, even at a single level, exhausts space available on any early DASD. Gerhard Postpischil Bradford, Vermont -- 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
Re: TCBJLB doesn't point to a DCB
On 11/29/2013 10:26 AM, MichealButz wrote: The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task Can you provide a reference - the statement may be true in some limited context. But for tasklibs, the DCB is set for EXCP (or could be BPAM if user provided) and can support up to 16 libraries, with a total extent limit of 256. I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname I just tried this on my system. FTCB has 0 for TCBJLB (region control task). LTCB actually turned up some DCBs, all of which were open and pointed to an EXCP DCB. Re Shmuel's earlier comment - TCBJLB and DCBDDNAM coincidentally both have an offset of x'28'. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Todd Burrell is right. The secondary-school algebra is immediate: n x 1 + n - 1 = 44, 2n - 1 = 44, n = 45/2 = 22.5, floor(22.5) = 22. Twenty-two levels is of course clumsy for human use, but program-constructed indices having so many levels may well be useful in some situations. 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 2013-11-29, at 12:16, John Gilmore wrote: Under OS/360 the notional, antetypical 'longest' index had the syntax level1.level2.level3.level4.level5 Then, since leveli values could be at most 8 characters in length, 5 x 8 + 4 yielded the maximal character count of 44. The 44-character and 8-character maxima remain; the 5-level maximum does not. It should be easy to relax the 8-character maximum (except, perhaps on the HLQ) without incompatibility with existing data areas, even was done for the antetypical 5-level maximum. In an article here about a week ago that I haven't the stamina to find, the writer argued that the customary syntactic limits should be retained in new or upgraded components for reasons of some sort of compatibility. Hmmm. Called from Assembler, allocation, BLDL, STOW, and I suspect (haven't tried) ATTACH, LINK, LOAD, and XCTL support far beyond the customary majuscule alphameric plus a handful of special characters. Similarly for Binder with CASE(MIXED) and for catalog with DISABLE(DSNCHECK) in effect. I disagree with that writer. In an environment where facility A accepts a more tolerant syntax and facility B accepts only a more restrictive syntax, if I were crafting an application that might interact with either A or B, what should I do? I might choose to support the syntax of A, aware of the risk that I might create objects that would be inaccessible to B, or I might choose to support only the syntax of B, aware of the risk that I would be unable to access objects created by A. I would unhesitatingly choose A's syntax; in fact the union of all the grammars I might need to deal with. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
In 5737414652770988.wa.woodagozemail.com...@listserv.ua.edu, on 11/29/2013 at 11:25 AM, Andy Wood woo...@ozemail.com.au said: Why would you expect a TCB to match the DCB DSECT? Clearly, at that point he is talking about TCB+X'28, not DCB+X'28'. Whoops! That would be a 24-bit address, not a 31-bit address, and bits 0-7 should be zeroed. Which still leaves the question of whether DESERVE will make a special case of the linklist DCB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 0378217484586824.wa.zatlas1yahoo@listserv.ua.edu, on 11/29/2013 at 11:47 AM, Ze'ev Atlas zatl...@yahoo.com said: Again, you discuss the shortcoming of a specific system while I have a broad view. You're specific systems; I'm still trying to figure out what it is in them that you want to change. There would always be the need to disambiguate. Then what behavior do you want to change? For normal use in Unix, including z/OS, and for legacy z/OS data sets, the user just gives a name and the system figures out where it is. That's correct and that's where I took the idea from. That concept needs improvements No doubt, but so far you haven't identified any defect that a new type of catalog would resolve. Another great idea from the z/OS that deserve implementation in that context (i.e. Central System Catalog) is the famous GDG. Whenever I explain the concept to my Unix friends they agree that such a brilliant idea should have been implemented in Unix as well. They'd do better stealing the idea from DEC, specifically from VMS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In cae1xxdesuckurytxfugpi7kz3fzsap2np4xcuk+1tavy93g...@mail.gmail.com, on 11/29/2013 at 02:16 PM, John Gilmore jwgli...@gmail.com said: Under OS/360 the notional, antetypical 'longest' index had the syntax level1.level2.level3.level4.level5 I can't speak for release 1, but certainly in OS/360 R14 there was no such limit. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 11/29/2013 3:00 PM, Paul Gilmartin wrote: It should be easy to relax the 8-character maximum (except, perhaps on the HLQ) without incompatibility with existing data areas, even was done for the antetypical 5-level maximum. This could be done except for TSO, due to unfortunate dependences on both the high and low portion of the data set name. The designers, in their infinite wisdom, chose to define the PSCB to contain a 7-byte user id (or user specified prefix), followed by a one byte length. For OS/360 MVT, the Technion had zaps to get around the limitation (Shmuel may have a better idea just how many modules they modified). For the last level, TSO EDIT and possibly other programs, rely on a table of data characteristics by name (e.g., DATA, CNTL) that also would require changes. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Fri, 29 Nov 2013 17:35:04 -0500, Gerhard Postpischil wrote: On 11/29/2013 3:00 PM, Paul Gilmartin wrote: It should be easy to relax the 8-character maximum (except, perhaps on the HLQ) without incompatibility with existing data areas, even was done for the antetypical 5-level maximum. This could be done except for TSO, due to unfortunate dependences on both the high and low portion of the data set name. The designers, in their infinite wisdom, chose to define the PSCB to contain a 7-byte user id (or user specified prefix), followed by a one byte length. For OS/360 MVT, the Technion had zaps to get around the limitation (Shmuel may have a better idea just how many modules they modified). For the last level, TSO EDIT and possibly other programs, rely on a table of data characteristics by name (e.g., DATA, CNTL) that also would require changes. Hmmm. That somewhat proves my point. Under TSO, I was able to allocate a data set with both HLQ and LLQ of 8 characters; edit it (with ISPF) and browse it. I couldn't catalog it because I don't know of an 8-character HLQ to which I have access, but I believe that's an administrative limitation, not anything imposed by the OS. This is a good example of not letting the limitations of one component (TSO) impose a restriction on many others. And earlier, I neglected to laud IBM for a likewise good decision. Early in the history of Unix System Services, Allocation and JCL were enhanced to support allocating a UNIX pathname to a DDNAME, regardless that a data set so allocated would be unusable by BLDL, STOW, BSAM, QSAM, ATTACH, LINK, STEPLIB, and many others. But doing so opened the way: BLDL (but not STOW or DESERV), BSAM, and QSAM, at least now support data sets allocated to UNIX pathnames. This could not have happened if IBM had chosen to allow the limitations of many components to restrict enhancement of another. I'm eagerly waiting for the support to grow. Bye. Gotta go delete my uncatalogued data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Curiosity: ETXR exit code (ATTACHX macro)
Suppose that I have a program which is heavily multitasking. There is the parent task and multiple subtasks, all direct children of the single parent. The ATTACHX macro uses the ETXR parameter, which specifies a single routine which does housekeeping of some sort. Also assume that the subtasks are being created and ending randomly. That is the main task is doing its thing, then a subtask ends and drives the ETXR code under the parent TCB (I think under an IRB). Now this can happen anywhere in the parent's main loop, so I know that I need to serialize properly between the main loop code and the ETXR code. Assume that I have done so. I am wondering if a second child terminates while the parent TCB is in the ETXR code for a child, will the ETXR code be interrupted and redriven for the newly terminating child TCB. Or does RTM itself serialize the ETXR code so that a second instance is not driven until the first instance finishes (by exiting, thus going back to the parent's main loop). I.e. can the RB chain at some point look like: PRB of parent, IRB of ETXR #1, IRB of ETXR #2, IRB of ETXR #3 for a time line like: main TCB loop running child #1 ends, ETXR#1 starts running on main TCB child #2 ends, ETXR#2 starts running on main TCB (EXTR#1 interrupted) ETXR#2 ends, ETXR#1 resumes where it left off ETXR#1 ends, main TCB code loop resumes from where it was interrupted. or is the second ETXR deferred until the previous invocation does an SVC 3 to return to the main routine. Timeline like: main TCB loop child ends, causing ETXR to be invoked on main TCB child ends while ETXR active, is queued ETXR #1 ends queued ETXR starts execution ETXR #2 ends main TCB loop resumes I think the former. with ETXR#2 interrupting ETXR#1 is what really happens. I can't think of a way, off hand to test this. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
I *think* the latter. I seem to recall that exits don't get re-entered. Not an expert. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, November 29, 2013 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Curiosity: ETXR exit code (ATTACHX macro) Suppose that I have a program which is heavily multitasking. There is the parent task and multiple subtasks, all direct children of the single parent. The ATTACHX macro uses the ETXR parameter, which specifies a single routine which does housekeeping of some sort. Also assume that the subtasks are being created and ending randomly. That is the main task is doing its thing, then a subtask ends and drives the ETXR code under the parent TCB (I think under an IRB). Now this can happen anywhere in the parent's main loop, so I know that I need to serialize properly between the main loop code and the ETXR code. Assume that I have done so. I am wondering if a second child terminates while the parent TCB is in the ETXR code for a child, will the ETXR code be interrupted and redriven for the newly terminating child TCB. Or does RTM itself serialize the ETXR code so that a second instance is not driven until the first instance finishes (by exiting, thus going back to the parent's main loop). I.e. can the RB chain at some point look like: PRB of parent, IRB of ETXR #1, IRB of ETXR #2, IRB of ETXR #3 for a time line like: main TCB loop running child #1 ends, ETXR#1 starts running on main TCB child #2 ends, ETXR#2 starts running on main TCB (EXTR#1 interrupted) ETXR#2 ends, ETXR#1 resumes where it left off ETXR#1 ends, main TCB code loop resumes from where it was interrupted. or is the second ETXR deferred until the previous invocation does an SVC 3 to return to the main routine. Timeline like: main TCB loop child ends, causing ETXR to be invoked on main TCB child ends while ETXR active, is queued ETXR #1 ends queued ETXR starts execution ETXR #2 ends main TCB loop resumes I think the former. with ETXR#2 interrupting ETXR#1 is what really happens. I can't think of a way, off hand to test this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR exit code (ATTACHX macro): I think the former. with ETXR#2 interrupting ETXR#1 is what really happens. I can't think of a way, off hand to test this. To test, attach a few subtasks (which have a dispatching Priority lower than the main task) which each wait on their own ECB. Have the main task post the ECBs (since it is the higher priority, all the POSTs will fire before the WAITs get satisfied). Now do a STIMER for 45 seconds in the main task so the sub tasks can run and complete (ie: exit when the ECB got POSTed). Have the EXTR run the CB chain and report if there is more than one IRB. Log the results so you know if one IRB waited to occur once the prior one was over or if there was a chain of IRBs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
A-Z@#$: 29 characters for the first character, plus 0-9 for up to 7 additional characters. 29 One character. 1,131 Two character. 44,109 Three character. 1,720,251 Four character. 67,089,789 Five character. 2,616,501,771 Six character. 102,043,569,069 Seven character. 3,979,699,193,691 Eight character. 4,084,428,119,840 1-8 character level. On Fri, Nov 29, 2013 at 12:49 PM, Gerhard Postpischil gerh...@valley.net wrote: On 11/29/2013 12:36 PM, Paul Gilmartin wrote: There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. While I don't remember a 5-level limit, there always was (and will be?) a practical limit. Using every possible legal name, even at a single level, exhausts space available on any early DASD. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
I can try that. Thanks. On Nov 29, 2013 8:33 PM, Robert A. Rosenberg hal9...@panix.com wrote: At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR exit code (ATTACHX macro): I think the former. with ETXR#2 interrupting ETXR#1 is what really happens. I can't think of a way, off hand to test this. To test, attach a few subtasks (which have a dispatching Priority lower than the main task) which each wait on their own ECB. Have the main task post the ECBs (since it is the higher priority, all the POSTs will fire before the WAITs get satisfied). Now do a STIMER for 45 seconds in the main task so the sub tasks can run and complete (ie: exit when the ECB got POSTed). Have the EXTR run the CB chain and report if there is more than one IRB. Log the results so you know if one IRB waited to occur once the prior one was over or if there was a chain of IRBs. -- 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: Curiosity: ETXR exit code (ATTACHX macro)
You're welcome. I hope that you can add the missing pieces to my overview set of instructions. The basic idea is to get a few subtasks running, have them end while delaying the launch of the EXTR routine until all are ended, and then have the routine do the check for you. I attempted to suggest a way that this criteria was met (the lower priority, etc.). After you try it, a report here on your findings might be welcome to those who are interested in this issue. At 21:30 -0600 on 11/29/2013, John McKown wrote about Re: Curiosity: ETXR exit code (ATTACHX macro): I can try that. Thanks. On Nov 29, 2013 8:33 PM, Robert A. Rosenberg hal9...@panix.com wrote: At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR exit code (ATTACHX macro): I think the former. with ETXR#2 interrupting ETXR#1 is what really happens. I can't think of a way, off hand to test this. To test, attach a few subtasks (which have a dispatching Priority lower than the main task) which each wait on their own ECB. Have the main task post the ECBs (since it is the higher priority, all the POSTs will fire before the WAITs get satisfied). Now do a STIMER for 45 seconds in the main task so the sub tasks can run and complete (ie: exit when the ECB got POSTed). Have the EXTR run the CB chain and report if there is more than one IRB. Log the results so you know if one IRB waited to occur once the prior one was over or if there was a chain of IRBs. -- 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
Re: CRONTAB and SYSLOGD
SYSLOGD and CRON work the same as on UNIX. Talk to your UNIX admin about these to get a solution that is suitable for your environment. If you have an MVS automation product or job scheduler, then you can use it in place of CRON. Jon Perryman. From: Fred Kaptein fred.kapt...@hp.com We are looking for the statements to insert into /etc/syslog.conf to do the following - retain the unix syslog in a file directory /xxx/ (we have not yet decided on a directly, but please let us know if there is an IBM recommended directory) - only retain 30 days of the unix syslog data (it is not important if the data is lost across IPLS) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
On 11/29/2013 7:57 PM, John McKown wrote: terminating child TCB. Or does RTM itself serialize the ETXR code so that a second instance is not driven until the first instance finishes (by exiting, thus going back to the parent's main loop). Unless the manual explicitly specifies that or how an exit is serialized, assume the worst - exit must be re-entrant and you are responsible for any needed serialization. While it was a different set of exits, I was asked to diagnose an 0Cx of a commercial product on the market since the mid-seventies - two exits were invoked concurrently, and they used the same save area! Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx (was: OT? ... deliberately unfriendly)
On 29 Nov 2013 08:47:35 -0800, in bit.listserv.ibm-main (Message-ID:0895521555071176.wa.paulgboulderaim@listserv.ua.edu) paulgboul...@aim.com (Paul Gilmartin) wrote: (But it would be useful to be able to read a file into a compound variable with a single instruction rather than coding a loop. Hmmm... I wonder how this works if infile is a terminal?) For anyone just joining, this was about Regina REXX on a PC. To do a single read of a file into a compound variable: code call rxfuncadd 'sysloadfuncs','RexxUtil','sysloadfuncs' call sysloadfuncs call RegStemRead file, inline. /code The 1st two lines are needed only once per execution, not once per file read. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at pobox dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
